Segurança no desenvolvimento de sistemas com metodologia ágil SCRUM

Bruno M. Rego, Inês Brosso

Faculdade de Computação e Informática – Universidade Presbiteriana Mackenzie Caixa Postal 01302 –907 – São Paulo – SP – Brasil

bmr@attom.com.br inesbrosso@mackenzie.com.br

Abstract. This paper presents a proposal for the integration of information security and software security best practices with SCRUM, beyond the challenges and how to measure the results of this integration.

Resumo. Este artigo apresenta uma proposta para a integração da segurança da informação e melhores práticas de segurança de software junto ao SCRUM, além dos desafios e como mensurar os resultados desta integração.

1. Introdução

O crescimento de computadores conectados à internet vem aumentando e, consequentemente, oferecendo mais possibilidades de ataques. Isto coloca o software e, consequentemente, as organizações e usuários em grande risco. (MCGRAW, 2006) O acompanhamento dessa evolução da Internet permitiu-nos desenvolver novos recursos para controles de segurança e de privacidade. Mesmo com estes diversos recursos e controles sofisticados na infraestrutura de redes e junto ao usuário final, o software sempre foi e será o principal vetor de ataque. Atualmente, esse cenário se torna cada vez mais complexo, pois a possibilidade de integração e de acoplamento de novos recursos aos softwares, geralmente chamados de extensões, afeta negativamente a sua segurança, aumentando o risco de acordo com o nível de integrações que a ele oferece. (MCGRAW, 2006) Sabendo da exposição das empresas e dos usuários que utilizam a internet, este trabalho propõe uma maneira de integrar os conceitos de segurança da informação, principais atividades e melhores práticas de segurança de software junto à metodologia ágil SCRUM para a construção de softwares seguros. O objetivo deste trabalho é propor a integração dos principais conceitos da segurança da informação, atividades e melhores práticas de segurança de software junto ao modelo ágil de desenvolvimento de software, o SCRUM. Enfim, O estudo se justifica uma vez que, atualmente, o software é a principal superfície de ataque, Como tal, deve ser eficientemente planejado, executado e controlado para que possa alcançar seus objetivos.

2. Segurança de Software A segurança de informação visa a garantir a confidencialidade, integridade e disponibilidade das informações, além de garantir a conformidade com a legislação vigente e a continuidade dos negócios. De forma mais ampla, pode-se definir como prática de gestão de riscos e de incidentes evitar o comprometimento dos três principais conceitos da segurança, descritos abaixo: Confidencialidade é o conceito que define que toda informação deve ser protegida de forma que o acesso não autorizado não seja permitido. Integridade é o conceito que define que toda a informação deve ser mantida da mesma forma que foi disponibilizada, visando à proteção contra quaisquer alterações. Disponibilidade é o conceito que define que toda informação disponibilizada por um individuo ou instituição deve estar acessível no momento em que houver necessidade para qualquer finalidade. Com base nos conceitos apresentdos acima a noção de risco de segurança de software tem se tornado de conhecimento comum, mas os programadores, arquitetos e cientistas da computação só agora começaram a estudar sistematicamente como criar um software seguro. (MCGRAW, 2006) Criação de um sistema seguro requer um processo de segurança integrado no ciclo de desenvolvimento do software. Este processo de segurança de software deve cobrir desde a arquitetura até a implantação do projeto e, principalmente, definir o papel dos profissionais de segurança de software dentro do ciclo de desenvolvimento de software, de modo que o processo seja aplicado de forma eficaz. (SWIDERSKI e SNYDER, 2004)

2.1 Desenho de Segurança Entender os princípios de proteção da informação é essencial para construir o desenho da arquitetura de um software de forma segura. De modo que a dificuldade de construir softwares seguros está relacionada com a qualidade negativa das definições, premissas e requisitos de segurança apresentados. (SALTZER e SCHROEDER, 1975) Softwares complexos são, provavelmente, menos seguros do que o software mais simples, então, se deve sempre se esforçar para produzir o software simples, conforme descrito por SALTZER e SCHROEDER, 1975, no princípio da economia de mecanismos. (SCHWABER, 2006) Todo o texto relacionado a desenho de segurança é referência obtida no documento desenvolvido por SALTZER e SCHROEDER, 1975, que descreve os princípios básicos para a definição do desenho e arquitetura de forma segura, extremamente críticos para a construção de um software seguro.

2.1.1 Economia de mecanismos Sistemas e ou softwares complexos, com diversos recursos e dependências, podem apresentar erros de desenvolvimento, implantação e ou projeto, permitindo violações de segurança dificilmente detectadas, pois o sistema é utilizado normalmente. O princípio da economia de mecanismos é bem conhecido e se aplica a qualquer aspecto de um sistema, onde a recomendação é manter o desenho do software pequeno e simples o quanto. Em casos onde há necessidade de executar a revisão de código fonte, o princípio da economia de mecanismos facilita muito o trabalho do especialista de segurança de software responsável por essa atividade. 2.1.2 Mediação completa Todas as requisições devem ser verificadas, analisadas e autorizadas entre objetos e dependências do software. O princípio da mediação diz que todo acesso a um objeto deve ser verificado, autenticado e autorizado. Então, quando esse princípio é aplicado sistematicamente, ele se torna a base principal de proteção do sistema, forçando a validação de toda e qualquer. 2.1.3 Desenho aberto A arquitetura, o desenho e o código do software deveriam estar disponíveis para avaliação dos clientes. Com isso, os usuários mais exigentes e devidamente autorizados poderiam analisar, entender e se convencer de que o sistema atende realmente às suas necessidades. O princípio de desenho aberto diz que a arquitetura, desenho e código de um software não devem depender da ignorância dos atacantes em potencial, permitindo que todos possam fazer revisões e identificar possíveis problemas. 2.1.4 Separação de privilégios O princípio de separação de privilégios busca definir privilégios para acesso ao software como, por exemplo, autorização de usuários com diferentes perfis. 2.1.5 Privilégio mínimo Todo software e usuário deveriam realizar suas funções utilizando apenas o mínimo de privilégios necessários. O principio de privilégio mínimo busca limitar o perigo. Reduzindo os privilégios do software ou usuário a um escopo bem específico pode limitar possíveis incidentes.

2.1.6 Mínimo de mecanismos comuns O principio mínimo de mecanismos comuns busca limitar a utilização de mecanismos compartilhados para mais de um ou todos os clientes que utilizam o software. 2.1.7 Usabilidade É essencial que toda a interface seja de fácil manuseio, facilite o aprendizado dos usuários, tornando assim o sistema menos suscetível a erros. O princípio da usabilidade diz que, se a aprendizagem da atividade executada pelos clientes está de acordo com as proteções construídas para o sistema, então os erros serão minimizados.

2.2 Análise de Riscos e Modelagem de Ameaças A ideia da gestão de risco, como um princípio fundamental da segurança, é apresentada com diferentes nomes em software de segurança, tais como modelagem de ameaças e análise de risco. (MCGRAW, 2006) O principal resultado da modelagem de ameaça é um documento ou documentos que descrevem em alto nível o desenho da aplicação, lista de recursos que requerem proteção, identificação e categorização das ameaças e plano de mitigação. (HOWARD e LIPNER, 2006) A modelagem de ameaças pode, também, ajudar a executar atividades de revisão de código e a construção de testes de penetração. Abaixo, apresento as atividades relacionadas à modelagem de ameaças, utilizando como principal referência os livros HOWARD e LIPNER (2006) e, também, SWIDERSKI e SNYDER (2004), conforme relacionadas a seguir: 2.2.1 Criar ou verificar cenários Consiste em verificar as superfícies de ataque do cenário em questão, imaginando possíveis ações de agentes externos, com foco em gerar evidências caso ocorra algum incidente. Na criação dos cenários, é importante verificar se o usuário deve se proteger contra colaboradores internos ou externos, mal-intencionados.

2.2.2 Avaliar a lista de dependências externas

Sabe-se que a aplicação desenvolvida não é autossuficiente, que roda sob um sistema operacional, utiliza servidor web, serviço de banco de dados ou frameworks de aplicação. Devem ser identificadas e listadas todas estas dependências, considerando que o sistema operacional e os serviços estejam com as configurações seguras. 2.2.3 Determinar as premissas de segurança Premissas ou requisitos de segurança devem permanecer documentados e disponíveis aos programadores como referentes para a construção de um software seguro.

Pontualmente, cada projeto possui requisitos mais específicos e nesse momento, devem-se definir quais as premissas de segurança para esse ambiente operacional, como, por exemplo, segregação de ambientes lógicos e físicos; arquitetura de autenticação, autorização e auditoria; utilização de um framework padrão; arquitetura para armazenamento centralizado de logs e formato específico para envio. 2.2.4 Determinar tipos de ameaças A gigante de software Microsoft utiliza uma taxonomia de ameaças, criada e batizada por ela, chamada STRIDE (Spoofing, Tampering, Repúdio, Exposição de informações, Negação de serviço, Elevação de privilégio), descritos abaixo: 2.2.4.1 Spoofing Permite a um atacante se passar por alguém ou alguma coisa, tal como um usuário tentar se passar pelo presidente de uma empresa, uma biblioteca dinâmica que foi substituída, um servidor respondendo como microsoft.com, entre outros. 2.2.4.2 Tampering Interceptação e alterações nos dados em um canal de transmissão ou em código fonte.

2.2.4.3 Repúdio Consistem em repúdio, uma ação executada que não pode identificar o real individuo responsável. Já o não repúdio é a habilidade de conter a ameaça de repúdio. Um exemplo interessante é quando um usuário executa uma ação no sistema e não pode ser identificado, pois não existem evidências daquela ação. 2.2.4.4 Exposição de Informações Esta ameaça envolve a exposição das informações a indivíduos que não deveriam ter acesso a elas. Imagine um arquivo confidencial sendo lido por uma pessoa mal-intencionada que não tem privilégios para acesso. 2.2.4.5 Negação de serviço Os ataques de negação de serviço têm como objetivo degradar ou tornar indisponível. De alguns anos pra cá, os ataques de negação de serviço têm ocorrido a partir de diversas origens, sendo conhecidos como ataque de negação de serviço distribuídos (DDOS). 2.2.4.6 Elevação de Privilégios Esta ameaça ocorre quando um usuário consegue aumentar seus privilégios, executando atividades de usuários com privilégios administrativos, ou superusuários. 2.2.5 Identificando ameaças O processo de identificação de ameaças, primeiramente, lista as entidades externas que interagirão com o software, os processos, o fluxo de dados e onde os dados serão armazenados. A principal contribuição deste processo é uma matriz que detalha os tipos de ameaças relacionadas às entidades externas e suas interações junto ao software, os processos, o fluxo de dados e onde os dados serão armazenados. 2.2.6 Determinando os riscos A grande dificuldade para determinar o risco é determinar qual é a chance do ataque ocorrem. De posse dessa informação, a fórmula abaixo pode ser utilizada:

Risco = Chance de o Ataque Ocorrer × Estrago em potencial

Historicamente, especialistas de segurança utilizam cálculos numéricos para identificar os riscos, mesmo sabendo que os números podem ser subjetivos. 2.2.7 Plano de mitigação A mitigação, geralmente, consiste em uma defesa ou contramedida, tentando reduzir ou eliminar o risco de uma ameaça. Abaixo, a descrição das estratégias de mitigação. A estratégia para mitigar o risco é não fazer nada que possa ser uma estratégia válida. Caso o risco identificado seja conhecido e considerado baixo, nada a ser feito. Outra possibilidade para a mitigação do risco é remover o recurso ou funcionalidade, garantindo que o risco identificado seja levado ao menor nível. Esta mitigação deve ser usada quando o risco é muito grande, e a mitigação é insustentável. Desligar o recurso e funcionalidade também garante a mitigação pontual do risco, garantindo que os recursos ou funcionalidades afetadas pelo risco sejam mitigados ou permaneçam desligadas. Em outros casos, notificar o usuário pode ser uma alternativa para algumas ameaças, lembrando que somente notificar o usuário, informando que a ameaça existe, pode não ser a melhor decisão.

2.3 OWASP TOP 10 O The Open Web Application Security Project (OWASP) é uma organização mundial sem fins lucrativos, focada na melhoria da segurança do software, oferece, gratuitamente, para toda a sociedade diversos projetos de segurança de software, onde o documento mais conhecido e que mais contribui para este trabalho é o OWASP Top 10. 2.3.1 A1 – Injeção Falhas de injeção de códigos são comuns em aplicações web, principalmente a injeção de código SQL. Estas falhas ocorrem quando dados fornecidos nos campos de entrada são interpretados como parte de comandos ou consultas, permitindo que um atacante acesse a base de dados da aplicação e execute consultas arbitrárias. Para mitigar essa vulnerabilidade é recomendável que todas as informações enviadas à aplicação sejam validadas, tratando possíveis erros e exceções, evitando a exposição de informações sensíveis aos clientes.

2.3.2 A2 - Cross Site Scripting (XSS) Conhecido como XSS, ocorre quando uma aplicação recebe os dados do usuário e os envia de volta ao navegador sem realizar validação ou codificação dos dados, permitindo a execução de códigos/scripts arbitrários. Para mitigar esta vulnerabilidade é necessário encodar e validar as informações enviadas ao sistema. 2.3.3 A3 - Quebra de autenticação ou sessão Autenticação apropriada e gerenciamento de sessão são mecanismos críticos para a segurança de aplicações Web. Apesar disso, é comum encontrar falhas nesses mecanismos, que podem colocar em risco as credenciais utilizadas pelos usuários ou identificador de sessão (session ID). Burlando os mecanismos de autenticação e de gerenciamento, é possível roubar a sessão do usuário obtendo acesso privilegiado sem autorização, junto à aplicação. Para mitigar esta vulnerabilidade, é recomendável não utilizar identificadores de sessão pré-definidos ou reutilizados, eliminar ou invalidar a sessão após a utilização, garantir que as funções de logout e timeout foram implementadas corretamente. 2.3.4 A4 - Referência insegura a objetos Ocorre quando um objeto é acessado de forma direta, sem utilizar qualquer tipo de proteção. Objeto, neste caso, pode ser entendido como um arquivo de sistema ou banco de dados, diretórios ou chaves, utilizadas em URLs ou como parâmetros de formulário. Para mitigar esta vulnerabilidade, é necessário verificar a integridade dos objetos, garantir que o acesso ao objeto está autorizado, garantir que os objetos não estão expostos. 2.3.5 A5 - Cross Site Request Forgery (CSRF) O ataque consiste em forçar a vítima autenticada no sistema a enviar requisições a uma aplicação vulnerável, realizando operações sem o conhecimento da vítima. Ações realizadas com a participação da vítima, porém sem seu conhecimento. Para mitigar esta vulnerabilidade, são necessários: filtrar todos as informações enviadas à aplicação; utilizar tokens randômicos para cada requisição à aplicação com sessão de autenticação estabelecida; não utilizar a URL para realizar requisições com dados sensíveis. 2.3.6 A6 - Configuração não apropriada de segurança Essa falha existe por conta de instalações-padrão não seguras, por falta de atualizações, ou senhas padrão em ambiente de produção, por exemplo:

Aplicação com usuário privilegiado, “admin” e senha “admin”. Banco de dados SQL Server, com usuário privilegiado “sa” e sem senha. Para mitigar esta vulnerabilidade, é recomendável que, durante o desenvolvimento da aplicação, deva-se garantir que todas as mensagens de erros sejam tratadas corretamente, criando mensagens genéricas para serem apresentadas quando ocorrer um erro na aplicação. 2.3.7 A7 - Falha na restrição de acesso a URLs O atacante pode obter acesso indiscriminado às funções a que não deveria ter acesso, como geração de conteúdos, administração de usuários, etc. Ocorre quando há acesso, com sucesso, a URLs, aparentemente não conhecidas pelo usuário e proibidas. Para mitigar esta vulnerabilidade é recomendado forçar o aspecto de autorização definindo privilégios no acesso quando este recurso for possível e assim não permitir o acesso de usuários não autorizado a arquivos controlados, de configuração, logs, etc. 2.3.8 A8 - Armazenamento inseguro de criptografia Falhas na implementação de mecanismos de criptografia podem colocar em risco as informações armazenadas. Podem ser consideradas vulnerabilidades: a utilização de cifra “fraca”, tamanho de chave criptográfica inadequada ou erros ao utilizar cifra forte. Um atacante pode aproveitar essa vulnerabilidade para tentar obter acesso aos conteúdos e, também, a dados sensíveis da aplicação. Para mitigar esta vulnerabilidade, não utilize algoritmos conhecidamente fracos, como: RC3, RC4 e MD5. Nunca utilize canais inseguros para a transmissão das chaves de criptografia. O BASE64 não é algoritmo de criptografia ou função de hash. Não construa algoritmos de criptografia próprios em produção e garanta que dados sensíveis estão sendo cifrados e armazenados em local seguro. 2.3.9 A9 - Comunicação insegura Informações sensíveis devem ser transmitidas em canais seguros utilizando SSL/TLS. Caso contrário, serão enviadas em texto plano e podem ser capturadas por pessoas mal-intencionadas. Um atacante pode utilizar um analisador de pacotes e obter acesso a informações privilegiadas, como cookies ou identificador de sessão, credenciais e outras informações críticas para a empresa e negócios. Para mitigar esta vulnerabilidade, é recomendado utilizar TLS/SSL para conexões que oferecem o mecanismo de autenticação ou transmitem dados sensíveis, além de garantir que a infraestrutura de comunicação está sendo feita de maneira correta.

2.3.10 A10 - Redirecionamento inseguro Possibilita encaminhar usuários a sites não desejados, os quais podem conter códigos maliciosos para roubar informações da sessão do usuário. Funções de redirecionamento sem a validação do destino. Para mitigar esta vulnerabilidade, é recomendado evitar a utilização redirecionamentos ou encaminhamento, validando se o site de destino não é malicioso, evitando que informações sensíveis sejam enviadas através da URL.

2.4 ATIVIDADES E MELHORES PRÁTICAS O objetivo da principal referência utilizada para o desenvolvimento deste trabalho, o livro Software Security: Building In é: “explorar e descrever um conjunto de melhores práticas de segurança de software que eu chamo de pontos de conto”. (MCGRAW, 2006) A principal contribuição deste trabalho é propor a integração das melhores práticas de segurança de software ao SCRUM. Estas melhores práticas ou principais atividades de segurança de software foram baseadas conforme a referência em MCGRAW (2006), e descritas abaixo. 2.4.1 Revisão de código A revisão de código no contexto de software seguro é uma análise de segurança sob o código de um software, com o objetivo de buscar por padrões e regras conhecidas de bugs e, possivelmente, por falhas. Existem diversas maneiras de fazer a revisão de código, uma delas é a análise do código fonte que pode ser feita de forma manual, consumindo muito tempo, e também, de forma automática, a partir de ferramentas que verificam o código fonte sem tentar executá-lo de forma eficiente e muito mais rápido. Além dessas, existem outras formas de fazer a revisão de código em códigos compilados e byte-codes, que são: análise binária, engenharia reversa. 2.4.2 Análise de risco da arquitetura A análise do desenho e arquitetura de um software é, sem dúvida, uma das atividades mais importantes para garantir a segurança de um software. Analisar as entidades que interagem com o sistema, os componentes, o fluxo de dados e onde os dados serão armazenados, sem dúvida, contribuem para mapear os riscos e descobrir maneiras de mitigá-los. O modelo de modelagem de ameaças apresentado anteriormente é a maneira mais conhecida de modelar e mapear os riscos.

2.4.3 Teste de invasão Atualmente, os testes de penetração de segurança de software, também conhecidos como testes de penetração em aplicação, são úteis, principalmente, para identificar problemas no ambiente e de configuração do sistema. Os testes de penetração são executados através de ferramentas e exigem que o responsável pelos testes tenha habilidades avançadas em relação à segurança de software. Atualmente, este é o principal recurso utilizado pelas empresas para avaliação do software a ser instalado no ambiente de produção, não garantindo que o software foi construído com segurança, mas, se utilizado desde a primeira versão do software, podendo encontrar bugs de segurança ainda não identificados. 2.4.4 Teste de segurança baseando no risco O objetivo desta fase é fazer um teste mais direcionado ao software, economizando tempo e tornando os testes mais eficientes, além de poder executá-los antes mesmo de o software estar pronto em um ambiente de produção. A grande diferença é que os testes podem ser executados em partes do sistema, como em componentes ou na integração deles, além de serem feitos usando duas metodologias, teste de caixa branca e teste de caixa preta. A análise de risco desenvolvida previamente é essencial e deve direcionar a construção de casos de abuso. Os testes de segurança baseados em riscos, também, exigem que o responsável por essa atividade tenha habilidades avançadas em relação à segurança de software, para análises estáticas e dinâmicas no código fonte do software. 2.4.5 Casos de abuso No UML o caso de uso permite modelar e desenhar o software, detalhando como os recursos devem ser desenvolvidos e o comportamento normal do sistema. Já, o caso de abuso permite modelar e desenhar o software, como no caso de uso do UML, mas na visão de um cliente mal-intencionado, mapeando, assim, possíveis atividades maliciosas que, possivelmente, seriam executadas.

3. SCRUM O SCRUM é uma metodologia ágil focada nas necessidades de negócio do projeto no desenvolvimento de produtos ou serviços. (PRIES e QUIGLEY, 2010)

A palavra SCRUM não é uma sigla, mas os mecanismos no jogo de rugby para obter uma saída de bola e colocá-la em jogo. (SCHWABER, 2004) O processo é bastante simples e se baseia em ciclos de aproximadamente 2 até 4 semanas, chamados de iterações (em inglês, sprints), dedicados à entrega de funcionalidades bem definidas. Estas funcionalidades são reunidas e documentadas em uma lista de atividades chamada de backlog do produto, que pode ser atualizada e priorizada pelo dono do produto, de acordo com as necessidades e prioridades do negócio. O SCRUM não se concentra apenas em agregar valor ao negócio e sim em agregar o mais prioritário valor ao negócio, conforme definido pelo cliente e dono do produto. (SCHWABER, 2004) Abaixo, descrevo informações relevantes, referentes a papéis e responsabilidades, artefatos e cerimônias da metodologia ágil SCRUM. 3.1 Papéis e Responsabilidades 3.1.1 Dono do Produto O dono do produto é o profissional responsável pelo gerenciamento do backlog do produto e tem como principal objetivo maximizar o valor do projeto. Fazem o papel do cliente, mapeando todas as mudanças planejadas e possíveis novos recursos, priorizando as atividades de acordo com as necessidades da empresa e do negócio. (SCHWABER, 2004) 3.1.2 Scrum Master O scrum master é o profissional responsável pelo processo do SCRUM, sua correta implementação e maximização dos seus benefícios. O scrum master tem como principal atividade remover qualquer possível impedimento para a entrega do objetivo, garantindo que as metas e as atividades definidas e estimadas na reunião de planejamento da iteração sejam entregues. (SCHWABER, 2004) 3.1.3 Equipe No SCRUM, a equipe é autogerida, e cada um tem a responsabilidade por suas atividades e resultados. A equipe é formada por poucas pessoas com diferentes habilidades, no máximo de 5 a 9 pessoas, necessárias para a execução das tarefas.

3.2 Artefatos 3.2.1 Backlog do produto O backlog do produto é uma lista priorizada com os itens e recursos desejados, com tempo estimado, que possam ser adicionados e deletadas durante o projeto. (SCHWABER, 2004) 3.2.2 Backlog da iteração O backlog da iteração é uma lista de atividades oriundas do backlog do produto que é definida pelo dono do produto, scrum master e toda a equipe durante a reunião de planejamento da iteração. 3.2.3 Gráfico de Burndown O Gráfico de Burndown é uma representação gráfica que mostra a quantidade de horas de trabalho restante ao longo da linha do tempo. (SCHWABER, 2004) 2.3 Cerimônias 3.3.1 Planejamento da Iteração Reunião entre a equipe o scrum master e o dono do produto para escolher e mensurar os pontos ou horas das atividades a serem executadas durante uma iteração; essa lista é chamada de backlog da iteração. 3.3.2 Daily Scrum O daily scrum é uma reunião rápida onde cada integrante da equipe informa a sua atividade para os outros integrantes, sinalizando qualquer possível impedimento ao scrum master para resolução das atividades. (SCHWABER, 2004)

Diariamente, sempre no mesmo horário, a equipe se reúne com o scrum master com o objetivo de remover rapidamente qualquer impedimento relacionado ao desenvolvimento do produto. Nessa reunião, cada membro da equipe deve responder a três questões, que são: - O que eu fiz desde a última reunião (daily scrum)? - O que será feito entre agora e a próxima reunião (daily scrum)? - Existe algo prejudicando a execução das atividades planejadas?

3.3.3 Revisão da iteração A revisão da iteração é uma reunião que ocorre ao final de cada iteração, onde a equipe apresenta ao dono do produto o que foi feito e entregue durante aquela iteração. (SCHWABER, 2004) 3.3.4 Retrospectiva da iteração A retrospectiva da iteração é a reunião que ocorre após cada iteração, onde a equipe se reúne para discutir melhorias no processo e também no produto. (SCHWABER, 2004)

4. Integração das atividades de segurança de software com o SCRUM Para que as atividades e melhores práticas de segurança de software sejam integradas ao SCRUM, é preciso, em primeiro lugar, apresentar e conscientizar todos os colaboradores, principalmente, os envolvidos e interessados na construção de software seguro, sobre os conceitos de segurança da informação e segurança de software, possivelmente, através de pequenos treinamentos a estes colaboradores. Neste capítulo, descrevo a maior contribuição proposta por este trabalho, a integração dos conceitos de segurança da informação e as melhores práticas de segurança de software, junto ao modelo ágil de desenvolvimento de software, o SCRUM. 4.1 Educação e conscientização Treinar e conscientizar os profissionais acerca da segurança da informação, garantindo uma visão crítica sob ações que colocam ou representam riscos a “imagem” da empresa, é um grande desafio. “A real preocupação da maioria das escolas, universidades e colégios técnicos é ensinar recursos de segurança e não como construir um software seguro”. (HOWARD e LIPNER, 2006) O processo de educação e conscientização visa a garantir conhecimento aos colaboradores de forma a incentivar uma visão crítica relacionada aos riscos da segurança, gerando de forma proativa a construção de softwares seguros, atuando em profundidade ou em outras diversas camadas e evitando incidentes oriundos de ações internas erradas ou possivelmente maliciosas.

4.2 Processo Quando o assunto é segurança da informação, é imprescindível ter o total apoio da alta gerência, evitando que possíveis conflitos de interesses possam impedir que controles definidos pela equipe de segurança de software não sejam aplicados. Um dos requisitos mais importantes para a construção de software seguro é que a documentação do projeto seja bem feita e mantida em um local disponível e acessível por todos os colaboradores envolvidos e interessados no projeto. Uma documentação clara, estando disponível, faz com que o profissional de segurança esteja capacitado a desenvolver as primeiras analises do projeto, antes mesmo do primeiro encontro com os outros integrantes do projeto. Conforme mencionado anteriormente, a proposta deste trabalho consiste em alinhar as melhores práticas de segurança de software junto ao SCRUM, mas, para isso é importante levar em consideração que a equipe de segurança de software geralmente e reduzida e o tempo é muito curto para análises e entregas de novas funcionalizadas em metodologias de desenvolvimento ágil. 4.2.1 Artefatos 4.2.1.1 Backlog do produto e backlog da iteração Nestas fases, o profissional de segurança de software deve analisar o backlog do produto em busca de identificar possíveis ameaças, entender como funcionará o produto desse projeto, criando cenários, definindo o desenho e a arquitetura, reunindo e alinhando as premissas de segurança com todos os envolvidos e interessados pelo projeto. Executar as primeiras análises do desenho e arquitetura, a partir das informações encontradas no backlog do produto e backlog da iteração, já pode direcionar a definição de requisitos de segurança, mapeando as entidades, componentes ou dependências do sistema que ainda não foram identificadas durante a apresentação do projeto. Entender quais as funcionalidades do sistema e as entidades que irão interagir permitindo o especialista em segurança de software criar cenários na visão de um usuário mal-intencionado em casos de abuso. É importante ressaltar que as atividades de análise de vulnerabilidade devem ser executadas periodicamente, com o objetivo de identificar possíveis bugs ou configurações inseguras, que serão incluídos no backlog do produto. A partir do backlog de produtos e backlog de iteração, as atividades de segurança de software a serem executadas são: definição dos requisitos e premissas de segurança para o projeto, análise de risco e modelagem de ameaças, e casos de abuso.

4.2.2 Cerimônias 4.2.2.1 Primeira iteração ou apresentação do projeto A primeira participação do profissional de segurança de software no projeto é na apresentação do projeto ou primeira iteração. O entendimento e acompanhamento do projeto são essenciais e, por isso, o profissional de segurança de software precisa estar presente nesse momento. Nessa primeira reunião, toda a equipe envolvida e interessada no projeto estará presente. Dúvidas em relação ao desenho e arquitetura devem ser sanadas pelo profissional de segurança de software, bem como a linguagem a ser utilizada, o armazenamento de dados sensíveis, tipos de dados, autenticação, autorização, entre outros recursos. No primeiro contato com o projeto, o profissional de segurança de software já deve orientar a todos os envolvidos e interessados, apresentando parte das premissas e requisitos de segurança que se encaixam no contexto do projeto. Essas premissas e requisitos de segurança devem permanecer devidamente documentados, juntamente ao projeto, para servir de referência para todos os envolvidos. No momento da primeira iteração ou apresentação do projeto, as atividades de segurança de software a serem executadas são: definição dos requisitos e premissas de segurança para o projeto, análise de risco e modelagem de ameaças, e casos de abuso. 4.2.2.2 Iteração A cada iteração, novas funcionalidades e recursos são construídos e entregues em produção de duas a quatro semanas. Toda a rapidez provida pelo SCRUM exige a grande dedicação de um profissional de segurança de software. Sabendo disso, o profissional de segurança precisa atuar de forma proativa, fazendo um bom trabalho de documentação das premissas e requisitos de segurança, além de um desenho da arquitetura muito bem definido. Ao final de cada iteração o profissional de segurança de software e ou o analista de qualidade deverá executar o teste de penetração e de segurança com o objetivo de identificar problemas no software ainda não identificados, mitigados ou problemas de configuração no ambiente de produção. Todos os bugs ou falhas identificadas durante a iteração devem ser submetidos a uma análise de risco pelo profissional de segurança de software, com o objetivo de endereçar a resolução do problema de acordo com a criticidade. Em casos onde os bugs ou falhas identificadas tenham risco baixo, o profissional de segurança poderá endereçar as tarefas no backlog, solicitando a priorização ao dono do produto. Já, em situações identificadas onde os bugs ou falhas são considerados críticos, a correção deverá ocorrer o mais breve possível, notificando o dono do produto e, se for necessário, deverá notificar a alta gerência em busca de priorização. Algumas atividades são extremamente complexas, como a revisão de código, pois exigem um volume maior de código do que apenas uma iteração geralmente pode

oferecer. Além disso, a revisão de código exige total dedicação de um profissional de segurança de software, por isso, geralmente, é demandada quando o produto é extremamente crítico para a empresa. As atividades de segurança de software na iteração a serem executadas são: testes de segurança baseados no risco, teste de penetração, operação de segurança e revisão de código necessário e possível. Dependendo da criticidade de cada vulnerabilidade identificada, o profissional deverá recomendar uma mudança emergencial no software ou incluir a atividade no backlog para a mitigação na próxima iteração ou quando priorizadas pelo dono do produto em cada projeto. 4.2.2.3 Revisão e retrospectiva da iteração Na reunião de revisão ou retrospectiva, os bugs ou falhas identificadas devem ser apresentadas juntamente com a criticidade identificada, onde profissional deverá incluir a atividade no backlog para a mitigação na próxima iteração, sugerindo a priorização ao dono do produto. 4.3 Desafios Com base na pesquisa desenvolvida para este trabalho e na vasta experiência que adquiri durante todos estes anos de trabalho como profissional de segurança da informação, apresento desafios que devem ser levados em consideração no momento. 4.3.1 Documentação “A literatura de segurança de software começou a surgir na comunidade científica, mas, em termos práticos, a prática de segurança de software continua em sua infância.” (MCGRAW, 2006) Ao iniciar o desenvolvimento deste trabalho, percebi a dificuldade de encontrar documentação de qualidade referente à segurança de software junto a metodologias de desenvolvimento ágil de software, sobretudo em português. Por este motivo as poucas e principais referencias relacionadas a segurança de software de qualidade foram utilizadas como base para o desenvolvimento deste trabalho. 4.3.2 Profissionais MCGRAW (2006) explica que existem dois perfis profissionais de segurança de software: o profissional chapéu preto (blackhat), que executa atividades consideradas “destrutivas”, como atacar o software, testes de penetração, exploits, entre outras; o chapéu branco (whitehat), para atividades consideradas “construtivas”, atuando na definição de requisitos de segurança, funcionalidades de segurança,

arquitetura, análise de risco, revisão de código, entre outras. Os dois perfis de profissionais são necessários, pois, enquanto um profissional de segurança de software “ataca” em busca de bugs ou falhas, o outro faz análises no código, define requisitos e a arquitetura. Existem situações em que os dois perfis atuam juntos, como, por exemplo, no desenvolvimento de casos de abuso, análise de riscos, testes de segurança, dentre outras atividades.

Atualmente, encontrar profissionais com conhecimentos e habilidades relacionados à segurança de software é um grande desafio. (MCGRAW, 2006) “Profissionais de segurança de redes não conhecem muito sobre software para ser um bom profissional de segurança de software. Eles podem não carregar muitas características sobre como a operação de um software funciona (além do que desenvolvedores e arquitetos sabem), mas não é isso que precisamos para resolver o problema de segurança de software. Profissionais operadores de segurança quase nunca sabem nada sobre compiladores, frameworks, linguagem, arquitetura de software, testes e outras coisas necessárias para ser um sólido profissional de segurança de software.” (MCGRAW, 2006) “O que fazer quando uma habilidade rara é necessária? Você converte essa habilidade rara em um processo, que outros podem seguir, reforçando e disciplinando as pessoas e verificando se está funcionando realmente.” (MCGRAW, 2006)

5. Conclusão O assunto segurança de software no Brasil ainda é pouco explorado pelas pessoas, empresas e mídia. Com base nas pesquisas e experiência profissional, percebe-se que, atualmente, existe grande dificuldade de contratar e manter um profissional que possua conhecimentos e habilidades em segurança de software, disponível e dedicado para um ou mais projetos de desenvolvimento de software dentro da empresa, devido à escassez dessas habilidades e, também, o custo do projeto. Quando a empresa dispõe de profissionais de segurança de software, a integração das atividades e melhores práticas de segurança de software, junto ao SCRUM, é possível e pouco complexa, permitindo um acompanhamento próximo dos projetos possibilitando a construção de softwares mais seguros. Conclui-se que, para que esta integração se torne viável, depois de aplicar as melhores práticas de segurança de software, a equipe de segurança precisa mensurar os benefícios dos controles definidos em tempo de construção. Acompanhar a redução dos incidentes de segurança de software já pode contribuir para medir os resultados do trabalho executado. Sugere-se como contribuição acadêmica o estudo prático dos efeitos desta integração, principalmente, a redução das vulnerabilidades identificadas. O estudo periódico desses resultados possibilitará medir o resultado do trabalho realizado, a sua qualidade e prover sugestão de melhorias e evolução.

6. Referências HOWARD, M. e LIPNER, S. The Security Development Lifecycle. Microsoft Press, 2006. Manifesto para Desenvolvimento Ágil de Software. Disponível em: <http://www.agilemanifesto.org/iso/ptbr/>. Acessado em 15 de maio de 2010. MCGRAW, Gary. Software Security: Building Security In. Addison-Wesley, 2006. OWASP Top Ten Most Critical Web Application Security Vulnerabilities. Disponível em:<http://owasptop10.googlecode.com/files/OWASP Top 10 - 2010.pdf>. Acessado em 15 de maio de 2010. PRIES, Kim H. e QUIGLEY, Jon M. Scrum Project Management. CRC Press, 2010. RICE, David. Geekonomics: The Real Cost of Insecure Software. Addison-Wesley Professional, 2007. SALTZER, J.H; SCHROEDER, M.D. The Protection of Information in Computer Systems. Disponível em: <http://www.cs.virginia.edu/~evans/cs551/saltzer/>. Acessado em 20 de abril de 2011. SCHWABER, Ken. Agile Project Management with Scrum. Microsoft Press, 2004. SEMOLA, Marcos. Gestão da Segurança da Informação. Campus Elsevier, 2002. SWIDERSKI, Frank e SNYDER, Window. Threath Modeling. Microsoft Press, 2004. SUTHERLAND, Jeff. Agile Principles and Values. Disponível em: <http://msdn.microsoft.com/en-us/library/dd997578.aspx>. Acessado em junho de 2011. THOMAS, Steve. An Agile Comparison. Disponível em: <http://www.balagan.org.uk/work/agile_comparison.htm>. Acessado em 04 de junho de 2011