Scrum-Seg: Uma extensão da Metodologia Scrum para Aplicações Seguras Manoel R. M. de Andrade 1, Anderson A. L. Queiroz 1, Ruy J. G. B. de Queiroz 1 1 Centro de Informática Universidade Federal de Pernambuco (UFPE) Caixa Postal 7851 50.732-970 Recife PE Brazil {mrma,aalq,ruy}@cin.ufpe.br Abstract. This article will present an introduction about the subject of agile methodologies for software development, particularly the Scrum methodology, and what are their impacts in the context of information security. We discuss in this article concepts of macro Scrum methodology and information security. Describe the process of software production through the Scrum agile methodology, its features, artifacts, production process and its actors. This proposal will pursue an extension of agile Scrum, adding professionals specializing in information security, in order to produce an extension of the agile methodology, the Scrum-seg. Resumo. Este artigo irá apresentar uma introdução sobre a questão das metodologias ágeis de desenvolvimento de software, em especial a metodologia Scrum, e quais são seus impactos no contexto da segurança da informação. Abordaremos neste artigo conceitos macro da metodologia Scrum e da segurança da informação. Descrevemos o processo de produção de software com o uso da metodologia ágil Scrum, apresentando suas características, artefatos, processo produtivo e os seus atores. Esta proposta procurar realizar uma extensão da metodologia ágil Scrum, acrescentando profissionais especializados em segurança da informação, a fim de produzir uma extensão da metodologia ágil, o Scrum-seg. 1. Introdução Este trabalho busca obter um modelo de desenvolvimento de software para aplicações críticas que precisam de uma atenção no requisito de segurança, devido ao recente aumento nos números de incidentes de segurança reportados. Conforme apresentado na Figura 1 abaixo.
Figura 1. Incidentes reportados de 1999 até junho de 2010. CERT.br (2010) Torna-se visível que, com o passar dos anos, existe um aumento significativo dos incidentes de segurança, e a observância da classificação percentual por tipo de incidentes reportados evidencia o cuidado necessário com as aplicações desenvolvidas. 2. Motivação Normalmente segurança não faz parte dos requisitos de sistema, tampouco se prevê qualquer mecanismo de atualização do software para proteção contra novas ameaças. Por outro lado, apenas definições simples, como o uso de login e passwords, preveem a persistência destes dados de forma criptografada. Baseando-se na metodologia de desenvolvimento convencional, temos que, para cada 1000 linhas de código, existem em média 15 defeitos de segurança, desta forma uma aplicação típica de 200 mil linhas, existirão, aproximadamente 3000 defeitos de segurança que precisarão ser identificados e corrigidos. David Thomason e Durval Costa (2009). Com o aparecimento das metodologias ágeis para desenvolvimento de software, esse problema pode estar se agravando, já que tais metodologias podem dar margem a interpretações erradas. Segundo Kent B., Arie van B., et al. (2010) com o manifesto ágil, estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através deste manifesto, passa-se a valorizar: Indivíduos e interação entre eles mais que processos e ferramentas; Software em funcionamento mais que documentação abrangente; Colaboração com o cliente mais que negociação de contratos; Responder a mudanças mais que seguir um plano. Segundo os princípios da metodologia ágil, alguns valores apresentam maior importância em relação a outros. A Tabela 1 abaixo apresenta em destaque (em negrito), os valores que são evidenciados pela metodologia.
Tabela 1. Comparativo de valor dos itens do manifesto ágil Indivíduos e interação (+) Processos e ferramentas Software em funcionamento (+) Colaboração com o cliente (+) Documentação abrangente Negociação de contratos Responder a mudanças (+) Seguir um plano Conforme observamos na Tabela 1, os itens em negrito evidenciam que a metodologia ágil dificulta a criação de aplicações com requisitos de segurança bem elaborados, o que pode aumentar sensivelmente os problemas de vulnerabilidades destas aplicações. 3. O Scrum Para entender o que significa Scrum, não é necessário escrever nenhuma definição, pois não se trata de uma sigla de abreviações. É uma expressão utilizada no jogo e rúgbi, que simboliza a reunião de uma equipe para recuperar uma bola perdida. No jogo, o Scrum é um modo de recomeçar a partida depois de uma falta. Os membros das duas equipes ficam em posição de disputa de bola, formando um túnel. A força da equipe como um todo é o que importa para o sucesso. Daí a inspiração da metodologia ágil de desenvolvimento Scrum. Revista Info Exame (2009). O que transforma o Scrum numa metodologia ágil é basicamente o conceito de equipe ou time, em que cada membro tem seu papel e é responsável por cada parte ou etapa no processo de desenvolvimento. Porém, todos têm a visão da equipe com um objetivo comum a ser atingido, evitando assim o acúmulo de burocracia para o desenvolvimento do produto. 3.1. Elementos do Scrum A metodologia do Scrum é constituída de elementos básicos para o seu funcionamento, são eles: os atores, as interações e os artefatos produzidos. Tabela 2. Elementos básicos da Metodologia Scrum Atores Interações Artefatos Product Owner Planejamento Product Backlog Scrum Master Revisão / Retrospectiva Sprint Backlog Equipe Reuniões Diárias Burndown Charts A fim de entendermos o funcionamento do Scrum, faz-se necessário conhecer um conceito de estimativa de tempo utilizado na metodologia Scrum, chamado de sprint. Sprint é a unidade de medida de execução do projeto utilizando o Scrum, e não existe uma forma padronizada de duração pelos usuários da metodologia, mas algumas recomendações que ajudam a correta elaboração e definições.
Durante uma sprint o produto deve ser projetado, codificado e testado. Sprint: é um período normalmente de 30 dias (não necessariamente, porém, a duração do Sprint tem de ser constante durante todo o projeto) onde a equipe se compromete com a entrega de determinadas tarefas que constam no Backlog. IDG Now (2009). Em uma sprint a equipe de desenvolvimento tem que codificar e testar as funcionalidades. A Figura 2 apresenta o fluxograma de trabalho do Scrum. Seleção Product BackLog Scrum - Master Time de Desenvolvimento Planejamento Planejamento Retrospectiva Sprint BackLog Scrum - Master Time de Desenvolvimento Scrum - Master Time de Desenvolvimento Dono do produto Sprint Time de Desenvolvimento Product BackLog Nova Funcionalidade Dono do produto Figura 2. Fluxograma Scrum de Trabalho. Boris Gloger (2006) 4. O SCRUM-SEG Abordaremos nesta etapa a nossa proposta de uma extensão da metodologia ágil Scrum para atender os requisitos de segurança, objetivando tornar as aplicações críticas menos vulneráveis a problemas com a segurança da informação. Assim, criaremos dois novos atores para a metodologia, o Security Master e o Security Team, ambos com finalidades de avaliar e implementar requisitos ligados aos conceitos de segurança da informação para as aplicações desenvolvidas. Para isso, é necessário entender em que nível de subordinação estes novos atores serão inseridos na metodologia, para que o seu papel seja bem desempenhado. Na proposta apresentada, o modelo hierárquico se apresentaria da seguinte forma:
Figura 3. Hierarquia Funcional do SCRUM-SEG É preciso compreender que os novos atores propostos deverão ter o conhecimento e a formação adequada em segurança da informação. Por outro lado, existe uma dificuldade para manutenção de uma equipe exclusiva de segurança da informação. Então, a extensão do Scrum aqui proposta poderá ser realizada por uma equipe externa que auxilie no projeto. 4.1. Security Master O Security Master tem como objetivo coordenar as ações para o uso dos conceitos de segurança da informação, a fim de que o produto final desenvolvido contemple os requisitos das melhores práticas. Na prática, o Security Master deve orientar e produzir o backlog, em conjunto com o dono do produto, sendo possível classificar a funcionalidade de acordo com o risco apresentado, sob a ótica da segurança da informação. Fica sobre sua responsabilidade o acompanhamento do desenvolvimento seguro, e é necessária a competência para sanar qualquer dúvida tanto da equipe de desenvolvimento, bem como do dono do produto. Como acontece com o Scrum master, o Security Master deve impedir que interferências externas atrapalhem o trabalho desenvolvido pela sua equipe e tem um papel fundamental em ser o elo de comunicação entre a equipe de desenvolvimento e a equipe de segurança. Tem também o papel de conscientizar o dono do produto sobre a importância do investimento em segurança, para garantir que pelo menos os requisitos mínimos sejam desenvolvidos em cada funcionalidade. 4.2. Team Security Trata-se de uma equipe multidisciplinar com conhecimentos em segurança da informação, capaz de realizar análises de vulnerabilidades e testes para certificação do produto contra técnicas de ataques. Durante o planejamento da sprint, a equipe deve elaborar um security backlog, em paralelo à elaboração do sprint backlog, que constará de uma lista de requisitos de segurança para cada funcionalidade especificada no sprint backlog. Isto de forma que eles sejam conhecidos e possam ser estimados e desenvolvidos pela equipe de desenvolvimento.
Vejamos na tabela abaixo um exemplo de como pode ser construído o security backlog, de forma a manter o ciclo funcional do Scrum original. Realizar upload de arquivo Tabela 3. Security Backlog Tarefas Requisitos Estimativa Status Assinar digitalmente 4 Opcional Checar extensão permitida 5 Crítico Validar hash de integridade 4 Crítico Verificar a assinatura digital do arquivo 6 Essencial 4.3. Forma de Trabalho do Scrum-SEG Para aplicar a extensão ao Scrum proposta neste trabalho, faz-se necessário que o fluxograma de trabalho original do Scrum sofra algumas pequenas alterações para permitir a participação dos novos agentes propostos. Abaixo, segue o fluxograma proposto para o funcionamento do Scrum-seg: Seleção Product BackLog Planejamento Security team Security Master Security BackLog Scrum - Master Time de Desenvolvimento Scrum - Master Time de Desenvolvimento Planejamento Scrum - Master Time de Desenvolvimento Dono do produto Retrospectiva Security Master Security Team Sprint BackLog Product BackLog Sprint Time de Desenvolvimento Product BackLog Security Master Nova Funcionalidade Auditoria Security team Dono do produto Figura 4. Fluxograma do SCRUM com a extensão SCRUM-SEG
Com base na figura acima, podemos visualizar de forma prática o funcionamento do Scrum seg. Um comparativo entre os fluxogramas do Scrum original e o Scrum-seg evidencia as seguintes diferenças estruturais: Depois do Dono do produto entregar o product backlog original, o Security Master adiciona a ele o grau de severidade para cada funcionalidade, sob a ótica da segurança da informação; Depois da primeira reunião de planejamento, quando são selecionadas as funcionalidades do product backlog para a sprint, a equipe de segurança define, para cada funcionalidade, a quantidade mínima de requisitos de segurança a serem atendidos e aprovados na fase de teste do produto; Durante a sprint, enquanto a equipe de desenvolvimento produz as funcionalidades, os responsáveis pelos requisitos de segurança realizam os testes e as auditorias conforme estabelecido no security backlog; Na reunião de retrospectiva, quando todos os atores participam, é necessário que a equipe de segurança esteja presente, visto que o dono do produto pode mudar requisitos e valores importantes do product backlog durante o processo. 5. Conclusão Visualizando uma nova metodologia de gerenciamento de projetos que está ganhando espaço no mercado de T.I, que se utiliza dos conceitos do manifesto ágil, nosso estudo se objetiva a conhecer um pouco dessa metodologia e analisar a realidade da questão da segurança vivida hoje nas aplicações disponíveis na web. Usando um ponto de vista macro sobre as questões de segurança, relatamos as ameaças oriundas da web, as falhas de sistemas que elas exploram e algumas estratégias de defesa que nos auxiliam no processo de correção das falhas de segurança. Apresentamos também os conceitos-chave da nova metodologia chamada Scrum, descrevendo o papel de cada ator envolvido na metodologia, as iterações usuais e os artefatos produzidos. A partir dessas análises iniciais, pudemos listar necessidades que fizeram surgir uma extensão da metodologia ágil preocupada fundamentalmente com a segurança das aplicações desenvolvidas. Assim, considerando que não existem muitos estudos sobre o impacto da segurança em aplicações desenvolvidas por metodologias ágeis, a principal contribuição deste trabalho foi o estudo de uma abordagem ágil que contemple a temática da segurança da informação. A referida extensão proposta neste trabalho, encontra-se em processo de avaliação, sendo implantada em alguns projetos de sistemas que inicialmente utilizavam a metodologia Scrum tradicional.
6. Referências CERT.br (2010) http://www.cert.br/stats/incidentes/, Julho. CERT.br Fraudes (2010) http://www.cert.br/stats/incidentes/2010-apr-jun/fraude.html, Agosto. David Thomason e Durval Costa (2009) Segurança das Aplicações Web, http://www.risco.org.br, Dezembro. Kent B., Arie van B., et al. (2010) Manifesto para Desenvolvimento Ágil de Software, http://www.manifestoagil.com.br/, Abril. International Organization for Stardadization, International Eletrotechnical Committee (1989) Information Processing Systems Open Systems Interconnection Basic reference Model Part 2: Security Architecture. International Standard 7498-2, Março. Soares, Luis F. G. L. Guido. Colcher Sérgio (1995), Redes de computadores das LANs, MANs e WANs às Redes ATM. Editora Campus 2º edição. Bersnstein, T., Bhimani, A.B., Schultz, E. e Siegel, C.A (1997), Segurança na Internet. Editora Campus. Revista Info Exame (2009), Metodologias Ágeis de Desenvovimento de Projeto, Editora Abril, Agosto. IDG Now (2009), Gerencie seu projeto de forma e ágil, http://idgnow.uol.com.br/internet /deep_in_tech/archive/2009/02/16/scrum-gerencieseu-projeto-de-forma-diferente-e-gil/, Fevereiro. Beedle M. Schwaber, Ken P. Hall (2009), Agile Software Development with Scrum, PTR 1ºedição, Setembro. Henrik Kniberg (2007), Scrum e Xp direto das Trincheiras como fazemos Scrum, Outubro. Cohn, Mike (2008), Uma Introdução ao Scrum, Adaptação Brod, Cesar, http://www.brod.com.br, Novembro 2009. Boris Gloger (2006), Scrum Check Lists. Sprint IT 3ª edição, Outubro.