• Save
Segurança no Desenvolvimento de Sistemas com Metodologia Ágil SCRUM
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Segurança no Desenvolvimento de Sistemas com Metodologia Ágil SCRUM

on

  • 2,632 views

No cenário atual o que mais preocupa é a questão da segurança da informação e privacidade dos usuários e das empresas expostas por meio de softwares na rede mundial de computadores. ...

No cenário atual o que mais preocupa é a questão da segurança da informação e privacidade dos usuários e das empresas expostas por meio de softwares na rede mundial de computadores.
O objetivo do presente trabalho é abordar o problema da insegurança de software para o mercado e, também, para os pesquisadores.
Ao final, desta pesquisa, apresenta-se uma proposta para a integração dos conceitos de segurança da informação, atividades e melhores práticas de segurança de software junto à metodologia ágil SCRUM para a construção de softwares seguros.

Statistics

Views

Total Views
2,632
Views on SlideShare
2,565
Embed Views
67

Actions

Likes
3
Downloads
0
Comments
0

5 Embeds 67

http://paranoidmode.wordpress.com 34
http://paranoidmode.com 27
http://blog.atomsec.com.br 3
https://www.linkedin.com 2
http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NoDerivs LicenseCC Attribution-NoDerivs License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Segurança no Desenvolvimento de Sistemas com Metodologia Ágil SCRUM Document Transcript

  • 1. UNIVERSIDADE PRESBITERIANA MACKENZIE BRUNO MOTTA REGOSegurança no Desenvolvimento de Sistemas com Metodologia Ágil SCRUM. São Paulo 2011
  • 2. 2 BRUNO MOTTA REGO Segurança no Desenvolvimento de Sistemas com Metodologia Ágil SCRUM. Trabalho de Graduação Interdisciplinar apresentado a Faculdade de Computação e Informática, como requisito parcial para obtenção do título de Bacharel em Sistema de Informação da Universidade Presbiteriana Mackenzie.Orientadora: Profª Drª Maria Inês Lopes Brosso São Paulo 2011
  • 3. 3R343i Rego, Bruno Motta. Segurança no desenvolvimento de sistemas com metodologia ágil SCRUM / Bruno Motta Rego – 2011. 55 f. : il. ; 30 cm Trabalho de Graduação Interdisciplinar (Bacharelado em Sistemas de Informação) – Faculdade de Computação e Informática, Universidade Presbiteriana Mackenzie, São Paulo, 2011. Bibliografia: f. 54-55. 1. Segurança da informação. 2. Privacidade. 3. Segurança de software. 4. SCRUM. 5. XP (Extreme Programming). I. Título. CDD 005.8
  • 4. 4 BRUNO MOTTA REGO Segurança no Desenvolvimento de Sistemas com Metodologia Ágil SCRUM. Trabalho de Graduação Interdisciplinar apresentado a Faculdade de Computação e Informática, como requisito parcial para obtenção do título de Bacharel em Sistema de Informação da Universidade Presbiteriana Mackenzie.Aprovado em BANCA EXAMINADORA ___________________________________________ Profª Drª Maria Inês Lopes Brosso Universidade Presbiteriana Mackenzie _________________________________________ Profº Ms. Jorge F. Maxnuck Soares Universidade Presbiteriana Mackenzie ____________________________________________ Profº Ms. Mario Rozolem Universidade Presbiteriana Mackenzie
  • 5. 5DEDICATÓRIAÀ minha esposa Lívia Batista Ribeiro Ovídio, pelapaciência, apoio e cooperação incondicional.Ao meu irmão Thiago Motta Rego, por ser uma pessoamaravilhosa, grande amigo, sempre disponível.Em especial, aos meus pais, Leny Lopes Motta Rego eBruno Luiz da Silva Rego, pelo carinho e empenho emprol de repassarem os valores, educação e conhecimento,em busca de me tornar um profissional ético ecompetente.
  • 6. 6 AGRADECIMENTOSA Deus todo poderoso, por ter-me dado forças e energia para concluir mais essa etapa emminha vida.À minha orientadora, Professora Doutora Maria Inês Lopes Brosso, que no decorrer docurso, sempre me apoiou por meio do seu conhecimento e, principalmente, me orientou paraa conclusão dessa obra.À minha querida mãe, Leny Lopes Motta Rego, por ser uma mãe tão maravilhosa, amiga,carinhosa, símbolo de luta e principal referência para a minha vida.Ao meu pai, Bruno Luiz da Silva Rego, amigo, sempre disponível a escutar as minhasexperiências.A professora amiga, Cândida Iracema Ribeiro Ovídio, pelo apoio e também pelas correçõesdo português.Ao meu irmão, Thiago Motta Rego, por sempre me oferecer os mais modernos recursostecnológicos.As pessoas que, direta ou indiretamente, contribuíram para a conclusão do meu Trabalho deGraduação Interdisciplinar e, também, ao meu Bacharelado em Sistemas de Informação.
  • 7. 7O homem que vai mais longe é geralmente aquele que está disposto a fazer e a ousar.” (Dale Carnegie).
  • 8. 8 RESUMODevido à constante e crescente evolução das tecnologias da informação tornando ainternet cada vez mais disponível, faz-se mais necessária a construção de softwareseguro. Neste cenário, o que mais preocupa atualmente é a questão da segurançada informação e privacidade dos usuários e das empresas expostas por meio dosoftwares na rede mundial de computadores. O objetivo do presente trabalho éabordar o problema da insegurança de software para o mercado e, também, para ospesquisadores. Ao final, desta pesquisa, apresenta-se uma proposta para aintegração dos conceitos de segurança da informação, atividades e melhorespráticas de segurança de software junto à metodologia ágil SCRUM para aconstrução de softwares seguros.Palavras-chave: segurança da informação; privacidade; software seguro, SCRUM.
  • 9. 9 ABSTRACTDue to the constant and increasing development of information technologies makingthe Internet increasingly available, so it is necessary to build more secure software.In this scenario the most worrisome is the issue of information security and privacy ofusers and companies exposed by software in the World Wide Web. The aim of thispaper is to address the problem of insecure software to the market and also for theresearchers. Finally, this research presents a proposal for integrating the concepts ofinformation security activities and best practices of security software with the AgileScrum to build secure software.Keywords: information security; privacy; secure software; SCRUM.
  • 10. 10 LISTA DE SIGLASDOS Denial of ServiceDDOS Distributed Denial of ServiceDSDM Dynamic Systems Development MethodFDD Feature-Driven DevelopmentOWASP The Open Web Application Security ProjectXP Extreme ProgrammingSDL Security Development LifecycleUML Unified Modeling LanguageURL Uniform Resource Locator
  • 11. 11 LISTA DE TABELASTabela 1. Comparativo das metodologias ágeis SCRUM e XP................................. 26
  • 12. 12 SUMÁRIO1. INTRODUÇÃO ...................................................................................................... 141.1 OBJETIVO ........................................................................................................... 141.2 JUSTIFICATIVA ................................................................................................... 141.3 TRABALHOS RELACIONADOS ......................................................................... 151.4 ORGANIZAÇÃO DO TRABALHO ....................................................................... 161.5 METODOLOGIA .................................................................................................. 162. METODOLOGIAS ÁGEIS ..................................................................................... 172.1 SCRUM ................................................................................................................ 192.1.1 Papéis e responsabilidades .............................................................................. 192.1.2 Artefatos ........................................................................................................... 202.1.3 Cerimônias ........................................................................................................ 212.2 PROGRAMAÇÃO EXTREMA (XP) ..................................................................... 222.2.1 Papéis e responsabilidades .............................................................................. 222.2.2 Artefatos ........................................................................................................... 242.2.3 Cerimônias ........................................................................................................ 252.3 ESTUDO COMPARATIVO .................................................................................. 263. SEGURANÇA DA INFORMAÇÃO ........................................................................ 283.1 CONCEITO DE INFORMAÇÃO .......................................................................... 283.2 SEGURANÇA DA INFORMAÇÃO ....................................................................... 283.2.1 Aspectos de segurança da informação ............................................................ 293.2.2 Ameaças ........................................................................................................... 303.2.3 Vulnerabilidades ............................................................................................... 303.2.4 Medidas de segurança ..................................................................................... 304. SEGURANÇA DE SOFTWARE ............................................................................ 324.1 DESENHO DE SEGURANÇA ............................................................................. 324.1.1 Economia de mecanismos ................................................................................ 334.1.2 Mediação completa ........................................................................................... 334.1.3 Desenho aberto ................................................................................................ 334.1.4 Separação de privilégios .................................................................................. 344.1.5 Privilégio mínimo .............................................................................................. 344.1.6 Mínimo de mecanismos comuns ...................................................................... 344.1.7 Usabilidade ....................................................................................................... 344.2 MODELAGEM DE AMEAÇAS ............................................................................. 354.2.1 Criar ou verificar cenários ................................................................................. 354.2.2 Avaliar a lista de dependências externas ......................................................... 354.2.3 Determinar as premissas de segurança ........................................................... 364.2.4 Determinar tipos de ameaças ........................................................................... 364.2.5 Identificando ameaças ...................................................................................... 384.2.6 Determinando os riscos .................................................................................... 384.2.7 Plano de mitigação ........................................................................................... 384.3 OWASP TOP 10 .................................................................................................. 394.3.1 A1 - Injeção ....................................................................................................... 39
  • 13. 134.3.2 A2 - Cross Site Scripting (XSS) ........................................................................ 404.3.3 A3 - Quebra de autenticação ou sessão .......................................................... 404.3.4 A4 - Referencia insegura a objetos .................................................................. 414.3.5 A5 - Cross Site Request Forgery (CSRF) ......................................................... 414.3.6 A6 - Configuração não apropriada de segurança ............................................. 414.3.7 A7 - Falha na restrição de acesso a URLs ....................................................... 424.3.8 A8 - Armazenamento inseguro de criptografia ................................................. 424.3.9 A9 - Comunicação insegura ............................................................................. 424.3.10 A10 - Redirecionamento inseguro .................................................................. 434.4 MELHORES PRÁTICAS DE SEGURANÇA DE SOFTWARE ............................ 434.4.1 Revisão de código ............................................................................................ 444.4.2 Análise de risco da arquitetura ......................................................................... 444.4.3 Teste de penetração ......................................................................................... 444.4.4 Teste de segurança baseando no risco............................................................ 454.4.5 Casos de abuso ................................................................................................ 454.4.6 Requisitos de segurança .................................................................................. 464.4.7 Operação de segurança ................................................................................... 465. INTEGRAÇÃO DO SCRUM COM SEGURANÇA DE SOFTWARE ..................... 475.1 EDUCAÇÃO E CONSCIENTIZAÇÃO ................................................................. 475.2 PROCESSO ........................................................................................................ 485.2.1 Artefatos ........................................................................................................... 48 5.2.1.1 Backlog do produto e backlog da iteração........................................... 485.2.2 Cerimônias ........................................................................................................ 49 5.2.2.1 Primeira iteração ou apresentação do projeto ..................................... 49 5.2.2.2 Iteração ................................................................................................ 50 5.2.2.3 Revisão e retrospectiva da iteração ................................................... 515.3 DESAFIOS ........................................................................................................... 515.3.1 Documentação .................................................................................................. 515.3.2 Profissionais ..................................................................................................... 526. CONCLUSÃO ........................................................................................................ 53REFERÊNCIAS BIBLIOGRÁFICAS .......................................................................... 54
  • 14. 141. INTRODUÇÃO O crescimento de computadores conectados à internet vem aumentando e,consequentemente, oferecendo mais possibilidades de ataques. Isto coloca osoftware e, consequentemente, as organizações e usuários em grande risco.(MCGRAW, 2006) O acompanhamento dessa evolução da Internet permitiu-nos desenvolvernovos recursos para controles de segurança e de privacidade. Mesmo com estesdiversos recursos e controles sofisticados na infraestrutura de redes e junto aousuário final, o software sempre foi e será o principal vetor de ataque. Atualmente, esse cenário se torna cada vez mais complexo, pois apossibilidade 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 dainformação, principais atividades e melhores práticas de segurança de software juntoà metodologia ágil SCRUM para a construção de softwares seguros.1.1 OBJETIVO O objetivo deste trabalho é propor a integração dos principais conceitos dasegurança da informação, atividades e melhores práticas de segurança de softwarejunto ao modelo ágil de desenvolvimento de software, o SCRUM.1.2 JUSTIFICATIVA O estudo se justifica uma vez que, atualmente, o software é a principalsuperfície de ataque, Como tal, deve ser eficientemente planejado, executado econtrolado para que possa alcançar seus objetivos.
  • 15. 15 Com base em uma revisão da literatura a respeito do ciclo de vida dedesenvolvimento de software seguro, formou-se uma base teórica para atingir oobjetivo mencionado. Segundo RICE, 2007, no livro Geekonomics: The Real Cost of InsecureSoftware, “o custo econômico total de falhas de segurança no software está emtorno de 180 bilhões de dólares por ano”. Devido à ausência de referências bibliográficas e visando a analisar oproblema de segurança de software numa perspectiva estratégica e gerencial, foidesenvolvido no presente trabalho uma proposta para integrar as melhores práticasde segurança de software junto ao SCRUM.1.3 TRABALHOS RELACIONADOS O desenvolvimento deste trabalho se baseou na integração de três temasprincipais, desenvolvidos por especialistas em desenvolvimento de software,metodologias ágeis e segurança de software. Todos os conceitos de segurança da informação foram principalmentereferenciados a partir do livro SEMOLA (2003). As melhores práticas e atividades de segurança de software foramreferenciadas a partir do livro MCGRAW (2006). Os conceitos de modelagem de ameaças foram referências obtidas no livroHOWARD e LIPNER (2003) e também SWIDERSKI e SNYDER (2004). O SCRUM e XP, metodologias ágeis para o desenvolvimento de softwarereferências obtidas nos livros SCHWABER (2006), PRIES e QUIGLEY (2010) eTHOMAS, (2011). As vulnerabilidades com maior risco oferecido pela OWASP, organização semfins lucrativos, foram referências obtidas no documento “OWASP Top 10”.
  • 16. 161.4 ORGANIZAÇÃO DO TRABALHO Para atender ao objetivo proposto por este estudo, no primeiro capítulo, fareiuma análise geral sobre os principais conceitos de segurança da informação. Nocapítulo 2, explicarei os conceitos e princípios do manifesto ágil e as metodologiaságeis SCRUM e o XP, além de um comparativo entre as duas metodologias. Nocapítulo 3, serão apresentados os conceitos de segurança de informação, aspectos,principais características, técnicas e aplicações. No capítulo 4, explicarei asprincipais atividades e melhores práticas de software seguro. E, finalmente, quandoatingirmos o capítulo 6, apresentarei, com base nas pesquisas, uma proposta paraintegração das melhores práticas de segurança de software com o SCRUM.1.5 METODOLOGIA A pesquisa sustenta-se em proporcionar uma visão dos principais conceitosde segurança da informação, de segurança de software e de metodologia ágeis parao desenvolvimento de software. A partir desta pesquisa, deseja-se alcançar maior familiaridade com o temaabordado, a fim de torná-la mais didática e despertar curiosidades e hipóteses.Pode-se dizer que estas pesquisas remetem ao aprimoramento de ideias baseadasnas fontes de pesquisa e em experiências profissionais. No decorrer deste trabalho, para a definição da metodologia, foram avaliados,de forma geral, as metodologias ágeis SCRUM e o XP para o gerenciamento dodesenvolvimento de software, com o objetivo de justificar a escolha da principalmetodologia abordada, escopo deste trabalho. Segundo SUTHERLAND (2011), um estudo recente mostra que cerca de 50por cento dos profissionais que utilizam metodologias ágeis informam que suaequipe está utilizando o SCRUM. Outros 20 por cento dizem que estão utilizando oSCRUM com componentes do XP. Apenas 12 por cento dizem que estão fazendosomente o uso da metodologia ágil XP. Enfim, com base na pesquisa realizada e experiência profissional, serádefinida uma das metodologias para o desenvolvimento deste trabalho.
  • 17. 172. METODOLOGIAS ÁGEIS O desenvolvimento ágil não é uma metodologia em si, é um termo genéricoque descreve várias metodologias ágeis. O momento da assinatura do ManifestoÁgil em 2001 reuniu representantes das principais metodologias SCRUM, ExtremeProgramming (XP), Dynamic Systems Development Method (DSDM), Feature-DrivenDevelopment (FDD) e Crystal Orange. (SUTHERLAND, 2011) Nesse Manifesto Ágil, ficou estabelecido um conjunto de valoresfundamentais que servem para todas as metodologias ágeis. Ele detalha quatrovalores fundamentais visando a garantir maneiras melhores de se produzir software,conforme descrito integralmente abaixo: Estamos descobrindo maneiras melhores de desenvolver software, fazendo-onós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho,passamos a valorizar: Indivíduos e interações 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. Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens àesquerda. Princípios também foram estabelecidos por trás do Manifesto Ágil que foramintegralmente descritos abaixo: Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando à vantagem competitiva para o cliente. Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo.
  • 18. 18 Pessoas de negócio e programadores devem trabalhar diariamente em conjunto por todo o projeto. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face. Software funcionando é a medida primária de progresso. Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, programadores e usuários devem ser capazes de manter um ritmo constante indefinidamente. Contínua atenção à excelência técnica e bom design aumentam a agilidade. Simplicidade - a arte de maximizar a quantidade de trabalho não realizado - é essencial. As melhores arquiteturas, requisitos e designs emergem de equipes auto- organizáveis. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e, então refina e ajusta seu comportamento de acordo. Todas as metodologias ágeis têm uma abordagem ligeiramente diferente paraa execução dos valores e princípios fundamentais do Manifesto Ágil, assim como aslinguagens de computador, por exemplo, muitas manifestam as característicasprincipais e centrais da programação orientada a objetos de formas diferentes. Com base na pesquisa realizada e informações apresentadas acima, farei umbreve levantamento comparativo das duas principais metodologias ágeis, o SCRUMe o XP, com o objetivo de definir qual metodologia será utilizada para odesenvolvimento deste trabalho.
  • 19. 192.1 SCRUM O SCRUM é uma metodologia ágil focada nas necessidades de negócio doprojeto no desenvolvimento de produtos ou serviços. (PRIES e QUIGLEY, 2010) A palavra SCRUM não é uma sigla, mas os mecanismos no jogo de rugbypara obter uma saída de bola e colocá-la em jogo. (SCHWABER, 2004) O processo é bastante simples e se baseia em ciclos de aproximadamente 2até 4 semanas, chamados de iterações (em inglês, sprints), dedicados à entrega defuncionalidades bem definidas. Estas funcionalidades são reunidas e documentadasem uma lista de atividades chamada de backlog do produto, que pode ser atualizadae priorizada pelo dono do produto, de acordo com as necessidades e prioridades donegócio. O SCRUM não se concentra apenas em agregar valor ao negócio e sim emagregar o mais prioritário valor ao negócio, conforme definido pelo cliente e dono doproduto. (SCHWABER, 2004) Abaixo, descrevo informações relevantes, referentes a papéis eresponsabilidades, artefatos e cerimônias da metodologia ágil SCRUM.2.1.1 Papéis e Responsabilidades2.1.1.1 Dono do Produto O dono do produto é o profissional responsável pelo gerenciamento dobacklog 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íveisnovos recursos, priorizando as atividades de acordo com as necessidades daempresa e do negócio. (SCHWABER, 2004)
  • 20. 202.1.1.2 Scrum Master O scrum master é o profissional responsável pelo processo do SCRUM, suacorreta implementação e maximização dos seus benefícios. O scrum master temcomo principal atividade remover qualquer possível impedimento para a entrega doobjetivo, garantindo que as metas e as atividades definidas e estimadas na reuniãode planejamento da iteração sejam entregues. (SCHWABER, 2004)2.1.1.3 Equipe No SCRUM, a equipe é autogerida, e cada um tem a responsabilidade porsuas atividades e resultados. A equipe é formada por poucas pessoas comdiferentes habilidades, no máximo de 5 a 9 pessoas, necessárias para a execuçãodas tarefas.2.1.2 Artefatos2.1.2.1 Backlog do produto O backlog do produto é uma lista priorizada com os itens e recursosdesejados, com tempo estimado, que possam ser adicionados e deletadas durante oprojeto. (SCHWABER, 2004)
  • 21. 212.1.2.2 Backlog da iteração O backlog da iteração é uma lista de atividades oriundas do backlog doproduto que é definida pelo dono do produto, scrum master e toda a equipe durantea reunião de planejamento da iteração.2.1.2.3 Gráfico de Burndown O Gráfico de Burndown é uma representação gráfica que mostra a quantidadede pontos ou horas de trabalho restante ao longo da linha do tempo. (SCHWABER,2004)2.1.3 Cerimônias2.1.3.1 Planejamento da Iteração Reunião entre a equipe o scrum master e o dono do produto para escolher emensurar os pontos ou horas das atividades a serem executadas durante umaiteração; essa lista é chamada de backlog da iteração.2.1.3.2 Daily Scrum O daily scrum é uma reunião rápida onde cada integrante da equipe informa asua atividade para os outros integrantes, sinalizando qualquer possível impedimentoao scrum master para resolução das atividades. (SCHWABER, 2004)
  • 22. 22 Diariamente, sempre no mesmo horário, a equipe se reúne com o scrummaster com o objetivo de remover rapidamente qualquer impedimento relacionadoao desenvolvimento do produto. Nessa reunião, cada membro da equipe deveresponder 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?2.1.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 duranteaquela iteração. (SCHWABER, 2004)2.1.3.4 Retrospectiva da iteração A retrospectiva da iteração é a reunião que ocorre após cada iteração, onde aequipe se reúne para discutir melhorias no processo e também no produto.(SCHWABER, 2004)2.2 PROGRAMAÇÃO EXTREMA (XP) A programação extrema (em inglês, eXtreme Programming) foi criada em 6 demarço de 1996 e, desde então, é uma metodologia ágil muito bem sucedida,utilizada em muitas empresas de todos os tamanhos e indústrias do mundo inteiro. O XP vem fazendo sucesso em diversos países, por ajudar a criar sistemasde melhor qualidade, que são produzidos em menos tempo e de forma maiseconômica que o habitual, como em outras metodologias ágeis.
  • 23. 23 Um dos princípios do XP é fazer produtos de forma simples e funcionais,garantindo, assim, que o cliente terá a funcionalidade que deseja rapidamente e daforma que deseja. Abaixo, descrevo os papéis e responsabilidades, artefatos, cerimônias eprincipais características da metodologia ágil XP.2.2.1 Papéis e Responsabilidades2.2.1.1 Técnico O técnico é o responsável por verificar o comportamento da equipe frente aoXP, sinalizando os eventuais erros cometidos. Ele deve conhecer os princípios epráticas do manifesto ágil.2.2.1.2 Analista de Testes O analista de testes é o responsável por garantir a qualidade do sistemadefinido pelo cliente. Ao final de cada iteração, o analista de testes deve garantir queas necessidades do cliente foram testadas e estão de acordo com a sua expectativa.2.2.1.3 Redator O redator é o responsável pela documentação do sistema, garantindo quetoda a documentação seja bem definida e construída de forma que reflita o que foidesenvolvido.
  • 24. 242.2.1.3 Programador O programador é o responsável por entender, analisar e codificar o sistemade acordo com as necessidades especificadas pelo cliente.2.2.1.4 Cliente O XP sugere que o cliente esteja no dia-a-dia do projeto, acompanhando ospassos dos programador, onde a sua ausência representa riscos ao projeto.2.2.1.4 Gerente do Projeto Responsável pela interface entre o cliente e a equipe, responsável porremover qualquer impedimento, garantindo que toda a equipe esteja focada nodesenvolvimento e integração do produto.2.2.2 Artefatos2.2.2.1 Lançamentos As entregas do XP são denominadas como sendo lançamentos (em inglês,releases), pequenos intervalos de tempo onde funcionalidades que geram valor aocliente sejam entregues. Os lançamentos são definidos no início do projeto,geralmente com tamanhos fixos e pequenos. Dentro desses lançamentos, ashistórias são definidas e executadas dentro da iteração.
  • 25. 252.2.3 Cerimônias2.2.2.1 Jogo de Planejamento O jogo de planejamento é a reunião onde são definidas pelo cliente asfuncionalidades desejadas através de histórias, onde a equipe estima as atividadese pontos em dias, planejando os lançamentos e as iterações.2.2.2.2 Reunião de Levantamento A reunião de levantamento (em inglês, Stand UP), com no máximo 20minutos, tem o objetivo de atualizar toda a equipe sobre o que foi implementado nodia anterior e trocar experiências das dificuldades encontradas. Nesse momento,também são decididas as histórias e quem são os responsáveis pelas suasexecuções.2.3 ESTUDO COMPARATIVO Todos os métodos de desenvolvimento de software, incluindo os métodoságeis, possuem algum tipo de ciclo de vida do projeto, onde, em alguns casos, esseciclo é mais abstrato que em outros, o que torna realmente difícil saber quais são asatividades em andamento de desenvolvimento. Importante é ressaltar que todos elesusam termos diferentes para as mesmas atividades. (THOMAS, 2011) Ainda THOMAS (2001), o SCRUM foi desenvolvido com foco de oferecer umgerenciamento de projetos sem complexidade, e o XP, focado nas necessidadesespecíficas de desenvolvimento de software, realizado por equipes pequenas diantede requisitos vagos ou que podem ser alterados.
  • 26. 26 Em ambas as metodologias, XP e SCRUM, não existe uma fase bem definidapara a elaboração do projeto, onde, no caso do XP, o cliente é o responsável pelaelaboração do projeto e no SCRUM o dono do produto deve gerar essa demanda deacordo com as necessidades de negócio, além de incluir no backlog de produtos. NoXP são utilizadas metáforas para definir a visão do produto, ajudando acompreender todos os elementos básicos do produto e seus relacionamentos paradefinir e gerar as histórias. Após a elaboração e definição do projeto com funcionalidades bem definidase documentadas no backlog de produtos, no caso do SCRUM, o dono do produtoscrum master e a equipe, juntamente, definem na reunião de planejamento daiteração a quantidade de pontos, geralmente em horas, que cada atividade possuiu.Do mesmo modo, no XP, a maneira de mensurar as atividades é bastante parecida,onde o cliente e os programadores na reunião de planejamento da iteração,explicam quais são as necessidades e demandas a serem atacadas, permitindo queas atividades sejam mensuradas em dias, semanas e meses. Tabela 1: Comparativo das metodologias ágeis SCRUM e XP. (Fonte: TOMAS, 2011)Descrição SCRUM XPNúmero de equipes De 1 – 4 ou mais. 1 equipe por projeto.Tamanho dos times 5–9 3 – 16Membros da equipe Scrum Master, Analista de Gerente, Cliente, Analista de Qualidade, Engenheiro. Teste, Programador.Responsáveis pelo Gerente de Projeto, Scrum Alta Gerência.projeto Master e Dono do Produto.Artefatos backlog de produtos e Histórias e testes. backlog de iteração.Cerimônias Planejamento da iteração. Planejamento da iteração. Com base no que foi descrito acima, percebemos que o SCRUM e o XP sãometodologias ágeis de desenvolvimento bem parecido. Ambos possuem umareunião para o planejamento da iteração, onde são definidas e estimadas asatividades pelo dono do produto ou cliente, reuniões diárias, testes que devemocorrer durante a construção do produto e revisões do que foi executado.
  • 27. 27 Enfim, a melhor metodologia para se abordar neste trabalho não foi escolhidaa partir de uma avaliação estritamente técnica, pois acredito que as pequenasdiferenças entre as principais metodologias estudadas possam ser úteis anecessidades específicas de alguma empresa ou pesquisa que venha a implementaressas tecnologias. Desta forma, a escolha do SCRUM se deve a metodologia ágilmais utilizada atualmente, conforme SUTHERLAND (2011), e com o objetivo detornar o trabalho mais abrangente às empresas e pesquisadores. Desenvolvi este documento com o objetivo de apresentar uma proposta deintegração das atividades e melhores práticas de segurança.
  • 28. 283. SEGURANÇA DA INFORMAÇÃO Este capítulo apresenta os principais conceitos de segurança da informaçãocomo base para o bom entendimento dos princípios e necessidades para aconstrução de um software seguro. Os conceitos de segurança da informação apresentados neste capítulo foramobtidos a partir de uma pesquisa detalhada, onde a principal referência foi SEMOLA(2003), devido ao seu enfoque gerencial.3.1 CONCEITO DE INFORMAÇÃO A informação é um conjunto de dados trafegados entre indivíduos oumáquinas que pode estar presente ou ser manipulada por qualquer um desteselementos envolvidos, chamados ativos, os quais são alvos de proteção dasegurança da informação. O termo ativo oriundo da área financeira significa um elemento de valor paraum indivíduo ou organização, e que, por este motivo, necessita de proteçãoadequada.3.2 SEGURANÇA DA INFORMAÇÃO Pode-se definir segurança de informação como uma área de conhecimentocujo foco principal é a proteção dos ativos de uma empresa, contra acessos nãoautorizados, alterações indevidas ou sua indisponibilidade. A segurança de informação visa a garantir a confidencialidade, integridade edisponibilidade das informações, além de garantir a conformidade com a legislaçãovigente e a continuidade dos negócios.
  • 29. 29 Para alcançar e garantir a qualidade da segurança da informação sãodefinidas práticas e políticas voltadas à adequação operacional e gerencial dosativos. De forma mais ampla, pode-se definir como prática de gestão de riscos e deincidentes evitar o comprometimento dos três principais conceitos da segurança,descritos abaixo: A confidencialidade é o conceito que define que toda informação deve serprotegida de forma que o acesso não autorizado não seja permitido. A integridade é o conceito que define que toda a informação deve ser mantidada mesma forma que foi disponibilizada, visando à proteção contra quaisqueralterações. Disponibilidade é o conceito que define que toda informação disponibilizadapor um individuo ou instituição deve estar acessível no momento em que houvernecessidade para qualquer finalidade.3.2.1 Aspectos de Segurança da Informação Com base nos conceitos apresentados anteriormente, alguns elementos sãoessenciais para a prática da segurança da informação. O primeiro elemento descrito aqui é a autenticação, que é o processo deidentificação e reconhecimento formal da identidade dos elementos que entram emcomunicação, ou outro, que permite o acesso aos ativos por meios de controle deidentificação. Já, a autorização é a concessão de uma permissão para o acesso aosativos, por exemplo, a separação de privilégios em um sistema. O elemento auditoria visa à coleta de evidências a fim de identificar entidadesenvolvidas em meios onde os ativos são processados, armazenados e trafegados. Outro elemento importante é a autenticidade que visa garantir que asentidades identificadas, remetentes ou autores, sejam exatamente o que dizem ser.Muito parecida com a autenticidade, a irretratabilidade é a característica dainformação que possui uma identificação do seu emissor que autentica como o autorda informação, sinônimo de não repúdio.
  • 30. 30 A legalidade, onde todas as características das informações que possuemvalor legal devem estar de acordo com as cláusulas contratuais pactuadas oulegislação institucional, nacional ou internacional.3.2.2 Ameaças Agentes ou condições que causam incidentes que podem comprometer osativos, provocando perda da confidencialidade, integridade e disponibilidade. Asameaças podem ser divididas em naturais, involuntárias e voluntárias. As naturais são decorrentes de fenômenos da natureza, como, por exemplo,incêndio, enchentes, terremotos, entre outras. Involuntárias são ameaças que ocorrem acidentalmente, causados poracidentes, erros, falta de energia, entre outros. As voluntárias são ameaças propositais, causadas por agentes humanos mal-intencionados, invasores, espiões, ladrões, entre outros.3.2.3 Vulnerabilidades Fragilidade presente ou associada aos ativos que, para serem exploradas,necessitam de um agente causador ou condição favorável, que são as ameaças,causando perdas de confidencialidade, integridade e disponibilidade. Asvulnerabilidades se dividem em físicas, naturais, de hardware, de software, mídias,comunicação e humanas.3.2.4 Medidas de Segurança São as práticas adotadas para impedir que ameaças exploremvulnerabilidades, com o objetivo de minimizar o risco, podendo apresentar três
  • 31. 31características, que são: preventivas, evitando que incidentes venham a ocorrer;detectáveis, que buscam identificar condições ou elementos causadores depossíveis ameaças, e corretivas, ações voltada às correções, com objetivo deadaptarem-se às condições de segurança anteriormente estabelecidas reduzindo oimpacto.
  • 32. 324. SEGURANÇA DE SOFTWARE A noção de risco de segurança de software tem se tornado de conhecimentocomum, mas os programadores, arquitetos e cientistas da computação só agoracomeçaram a estudar sistematicamente como criar um software seguro. (MCGRAW,2006) Criação de um sistema seguro requer um processo de segurança integradono ciclo de desenvolvimento do software. Este processo de segurança de softwaredeve 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 dedesenvolvimento de software, de modo que o processo seja aplicado de formaeficaz. (SWIDERSKI e SNYDER, 2004) Neste capítulo, são descritos os principais conceitos e as melhores práticasde segurança de software, desde o desenho da arquitetura até a implantação doprojeto para a construção de software seguro.4.1 DESENHO DE SEGURANÇA Entender os princípios de proteção da informação é essencial para construir odesenho da arquitetura de um software de forma segura. De modo que a dificuldadede construir softwares seguros está relacionada com a qualidade negativa dasdefinições, premissas e requisitos de segurança apresentados. (SALTZER eSCHROEDER, 1975) Softwares complexos são, provavelmente, menos seguros do que o softwaremais 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 economiade mecanismos. (SCHWABER, 2006) Todo o texto relacionado a desenho de segurança é referência obtida nodocumento desenvolvido por SALTZER e SCHROEDER, 1975, que descreve osprincí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.
  • 33. 334.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, permitindoviolações de segurança dificilmente detectadas, pois o sistema é utilizadonormalmente. O princípio da economia de mecanismos é bem conhecido e se aplicaa qualquer aspecto de um sistema, onde a recomendação é manter o desenho dosoftware pequeno e simples o quanto. Em casos onde há necessidade de executar a revisão de código fonte, oprincípio da economia de mecanismos facilita muito o trabalho do especialista desegurança de software responsável por essa atividade.4.1.2 Mediação completa Todas as requisições devem ser verificadas, analisadas e autorizadas entreobjetos e dependências do software. O princípio da mediação diz que todo acesso aum objeto deve ser verificado, autenticado e autorizado. Então, quando esseprincípio é aplicado sistematicamente, ele se torna a base principal de proteção dosistema, forçando a validação de toda e qualquer.4.1.3 Desenho aberto A arquitetura, o desenho e o código do software deveriam estar disponíveispara avaliação dos clientes. Com isso, os usuários mais exigentes e devidamenteautorizados poderiam analisar, entender e se convencer de que o sistema atenderealmente às suas necessidades. O princípio de desenho aberto diz que aarquitetura, desenho e código de um software não devem depender da ignorânciados atacantes em potencial, permitindo que todos possam fazer revisões e identificarpossíveis problemas.
  • 34. 344.1.4 Separação de privilégios O princípio de separação de privilégios busca definir privilégios para acessoao software como, por exemplo, autorização de usuários com diferentes perfis.4.1.5 Privilégio mínimo Todo software e usuário deveriam realizar suas funções utilizando apenas omínimo de privilégios necessários. O principio de privilégio mínimo busca limitar operigo. Reduzindo os privilégios do software ou usuário a um escopo bem específicopode limitar possíveis incidentes.4.1.6 Mínimo de mecanismos comuns O principio mínimo de mecanismos comuns busca limitar a utilização demecanismos compartilhados para mais de um ou todos os clientes que utilizam osoftware.4.1.7 Usabilidade É essencial que toda a interface seja de fácil manuseio, facilite o aprendizadodos usuários, tornando assim o sistema menos suscetível a erros. O princípio dausabilidade 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ãominimizados.
  • 35. 354.2 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 comomodelagem de ameaças e análise de risco. (MCGRAW, 2006) O principal resultado da modelagem de ameaça é um documento oudocumentos que descrevem em alto nível o desenho da aplicação, lista de recursosque requerem proteção, identificação e categorização das ameaças e plano demitigação. (HOWARD e LIPNER, 2006) A modelagem de ameaças pode, também, ajudar a executar atividades derevisão de código e a construção de testes de penetração. Abaixo, apresento asatividades relacionadas à modelagem de ameaças, utilizando como principalreferência os livros HOWARD e LIPNER (2006) e, também, SWIDERSKI e SNYDER(2004), conforme relacionadas a seguir:4.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ênciascaso ocorra algum incidente. Na criação dos cenários, é importante verificar se ousuário deve se proteger contra colaboradores internos ou externos, mal-intencionados.4.2.2 Avaliar a lista de dependências externas Sabe-se que a aplicação desenvolvida não é autossuficiente, que roda sobum sistema operacional, utiliza servidor web, serviço de banco de dados ouframeworks de aplicação. Devem ser identificadas e listadas todas estas
  • 36. 36dependências, considerando que o sistema operacional e os serviços estejam comas configurações seguras.4.2.3 Determinar as premissas de segurança Premissas ou requisitos de segurança devem permanecer documentados edisponíveis aos programadores como referentes para a construção de um softwareseguro. Pontualmente, cada projeto possui requisitos mais específicos e nessemomento, devem-se definir quais as premissas de segurança para esse ambienteoperacional, como, por exemplo, segregação de ambientes lógicos e físicos;arquitetura de autenticação, autorização e auditoria; utilização de um frameworkpadrão; arquitetura para armazenamento centralizado de logs e formato específicopara envio.4.2.4 Determinar tipos de ameaças A gigante de software Microsoft utiliza uma taxonomia de ameaças, criada ebatizada por ela, chamada STRIDE (Spoofing, Tampering, Repúdio, Exposição deinformações, Negação de serviço, Elevação de privilégio), descritos abaixo:3.2.4.1 Spoofing Permite a um atacante se passar por alguém ou alguma coisa, tal como umusuário tentar se passar pelo presidente de uma empresa, uma biblioteca dinâmicaque foi substituída, um servidor respondendo como microsoft.com, entre outros.
  • 37. 373.2.4.2 Tampering Interceptação e alterações nos dados em um canal de transmissão ou emcódigo fonte.3.2.4.3 Repúdio Consistem em repúdio, uma ação executada que não pode identificar o realindividuo responsável. Já o não repúdio é a habilidade de conter a ameaça derepúdio. Um exemplo interessante é quando um usuário executa uma ação nosistema e não pode ser identificado, pois não existem evidências daquela ação.3.2.4.4 Exposição de Informações Esta ameaça envolve a exposição das informações a indivíduos que nãodeveriam ter acesso a elas. Imagine um arquivo confidencial sendo lido por umapessoa mal-intencionada que não tem privilégios para acesso.3.2.4.5 Negação de serviço Os ataques de negação de serviço têm como objetivo degradar ou tornarindisponível. De alguns anos pra cá, os ataques de negação de serviço têm ocorridoa partir de diversas origens, sendo conhecidos como ataque de negação de serviçodistribuídos (DDOS).
  • 38. 383.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.4.2.5 Identificando ameaças O processo de identificação de ameaças, primeiramente, lista as entidadesexternas que interagirão com o software, os processos, o fluxo de dados e onde osdados serão armazenados. A principal contribuição deste processo é uma matriz que detalha os tipos deameaças relacionadas às entidades externas e suas interações junto ao software, osprocessos, o fluxo de dados e onde os dados serão armazenados.4.2.6 Determinando os riscos A grande dificuldade para determinar o risco é determinar qual é a chance doataque 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 paraidentificar os riscos, mesmo sabendo que os números podem ser subjetivos.4.2.7 Plano de mitigação A mitigação, geralmente, consiste em uma defesa ou contramedida, tentandoreduzir ou eliminar o risco de uma ameaça. Abaixo, a descrição das estratégias demitigação.
  • 39. 39 A estratégia para mitigar o risco é não fazer nada que possa ser umaestratégia válida. Caso o risco identificado seja conhecido e considerado baixo, nadaa ser feito. Outra possibilidade para a mitigação do risco é remover o recurso oufuncionalidade, garantindo que o risco identificado seja levado ao menor nível. Estamitigaçã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 dorisco, garantindo que os recursos ou funcionalidades afetadas pelo risco sejammitigados ou permaneçam desligadas. Em outros casos, notificar o usuário pode ser uma alternativa para algumasameaças, lembrando que somente notificar o usuário, informando que a ameaçaexiste, pode não ser a melhor decisão.4.3 OWASP TOP 10 O The Open Web Application Security Project (OWASP) é uma organizaçãomundial sem fins lucrativos, de caridade, focada na melhoria da segurança dosoftware. O OWASP oferece, gratuitamente, para toda a sociedade diversos projetosde segurança de software, onde o documento mais conhecido e que mais contribuipara este trabalho é o OWASP Top 10. O documento OWASP Top 10 apresentauma lista dos dez riscos mais críticos em segurança de aplicações na Internetreferente a um ano específico. Cada item desse documento é identificado pela vogal“A” e um número que identifica o risco em ordem crescente. Abaixo, estãorelacionadas as vulnerabilidades para web mais crítica, relativas ao ano de 2010.4.3.1 A1 – Injeção Falhas de injeção de códigos são comuns em aplicações web, principalmentea injeção de código SQL. Estas falhas ocorrem quando dados fornecidos nos
  • 40. 40campos de entrada são interpretados como parte de comandos ou consultas,permitindo que um atacante acesse a base de dados da aplicação e executeconsultas arbitrárias. Para mitigar essa vulnerabilidade é recomendável que todas asinformações enviadas à aplicação sejam validadas, tratando possíveis erros eexceções, evitando a exposição de informações sensíveis aos clientes.4.3.2 A2 - Cross Site Scripting (XSS) Conhecido como XSS, ocorre quando uma aplicação recebe os dados dousuário e os envia de volta ao navegador sem realizar validação ou codificação dosdados, permitindo a execução de códigos/scripts arbitrários. Para mitigar estavulnerabilidade é necessário encodar e validar as informações enviadas ao sistema.4.3.3 A3 - Quebra de autenticação ou sessão Autenticação apropriada e gerenciamento de sessão são mecanismos críticospara a segurança de aplicações Web. Apesar disso, é comum encontrar falhasnesses mecanismos, que podem colocar em risco as credenciais utilizadas pelosusuários ou identificador de sessão (session ID). Burlando os mecanismos deautenticação e de gerenciamento, é possível roubar a sessão do usuário obtendoacesso privilegiado sem autorização, junto à aplicação. Para mitigar estavulnerabilidade, é recomendável não utilizar identificadores de sessão pré-definidosou reutilizados, eliminar ou invalidar a sessão após a utilização, garantir que asfunções de logout e timeout foram implementadas corretamente.
  • 41. 414.3.4 A4 - Referência insegura a objetos Ocorre quando um objeto é acessado de forma direta, sem utilizar qualquertipo de proteção. Objeto, neste caso, pode ser entendido como um arquivo desistema ou banco de dados, diretórios ou chaves, utilizadas em URLs ou comoparâmetros de formulário. Para mitigar esta vulnerabilidade, é necessário verificar aintegridade dos objetos, garantir que o acesso ao objeto está autorizado, garantirque os objetos não estão expostos.4.3.5 A5 - Cross Site Request Forgery (CSRF) O ataque consiste em forçar a vítima autenticada no sistema a enviarrequisições a uma aplicação vulnerável, realizando operações sem o conhecimentoda vítima. Ações realizadas com a participação da vítima, porém sem seuconhecimento. Para mitigar esta vulnerabilidade, são necessários: filtrar todos asinformaçõ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 realizarrequisições com dados sensíveis.4.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 deatualizações, ou senhas padrão em ambiente de produção, por exemplo: Aplicação com usuário privilegiado, “admin” e senha “admin”. Banco dedados SQL Server, com usuário privilegiado “sa” e sem senha. Para mitigar esta vulnerabilidade, é recomendável que, durante odesenvolvimento da aplicação, deva-se garantir que todas as mensagens de errossejam tratadas corretamente, criando mensagens genéricas para seremapresentadas quando ocorrer um erro na aplicação.
  • 42. 424.3.7 A7 - Falha na restrição de acesso a URLs O atacante pode obter acesso indiscriminado às funções a que não deveriater acesso, como geração de conteúdos, administração de usuários, etc. Ocorrequando há acesso, com sucesso, a URLs, aparentemente não conhecidas pelousuário e proibidas. Por exemplo: diretórios /admin, /painel, /console. Para mitigar esta vulnerabilidade é recomendado forçar o aspecto deautorização definindo privilégios no acesso quando este recurso for possível e assimnão permitir o acesso de usuários não autorizado a arquivos controlados, deconfiguração, logs, etc.4.3.8 A8 - Armazenamento inseguro de criptografia Falhas na implementação de mecanismos de criptografia podem colocar emrisco as informações armazenadas. Podem ser consideradas vulnerabilidades: autilização de cifra “fraca”, tamanho de chave criptográfica inadequada ou erros aoutilizar cifra forte. Um atacante pode aproveitar essa vulnerabilidade para tentarobter acesso aos conteúdos e, também, a dados sensíveis da aplicação. Para mitigar esta vulnerabilidade, não utilize algoritmos conhecidamentefracos, como: RC3, RC4 e MD5. Nunca utilize canais inseguros para a transmissãodas chaves de criptografia. O BASE64 não é algoritmo de criptografia ou função dehash. Não construa algoritmos de criptografia próprios em produção e garanta quedados sensíveis estão sendo cifrados e armazenados em local seguro.4.3.9 A9 - Comunicação insegura Informações sensíveis devem ser transmitidas em canais seguros utilizandoSSL/TLS. Caso contrário, serão enviadas em texto plano e podem ser capturadaspor pessoas mal-intencionadas.
  • 43. 43 Um atacante pode utilizar um analisador de pacotes e obter acesso ainformações privilegiadas, como cookies ou identificador de sessão, credenciais eoutras informações críticas para a empresa e negócios. Para mitigar esta vulnerabilidade, é recomendado utilizar TLS/SSL paraconexões que oferecem o mecanismo de autenticação ou transmitem dadossensíveis, além de garantir que a infraestrutura de comunicação está sendo feita demaneira correta.4.3.10 A10 - Redirecionamento inseguro Possibilita encaminhar usuários a sites não desejados, os quais podem contercódigos maliciosos para roubar informações da sessão do usuário. Funções deredirecionamento sem a validação do destino. Para mitigar esta vulnerabilidade, é recomendado evitar a utilizaçãoredirecionamentos ou encaminhamento, validando se o site de destino não émalicioso, evitando que informações sensíveis sejam enviadas através da URL.4.4 MELHORES PRÁTICAS DE SEGURANÇA DE SOFTWARE O objetivo da principal referência utilizada para o desenvolvimento destetrabalho, o livro Software Security: Building In é: “explorar e descrever um conjuntode 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 melhorespráticas de segurança de software ao SCRUM. Estas melhores práticas ou principaisatividades de segurança de software foram baseadas conforme a referência emMCGRAW (2006), e descritas abaixo.
  • 44. 444.4.1 Revisão de código A revisão de código no contexto de software seguro é uma análise desegurança sob o código de um software, com o objetivo de buscar por padrões eregras conhecidas de bugs e, possivelmente, por falhas. Existem diversas maneiras de fazer a revisão de código, uma delas é aanálise do código fonte que pode ser feita de forma manual, consumindo muitotempo, e também, de forma automática, a partir de ferramentas que verificam ocó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ódigoscompilados e byte-codes, que são: análise binária, engenharia reversa.4.4.2 Análise de risco da arquitetura A análise do desenho e arquitetura de um software é, sem dúvida, uma dasatividades mais importantes para garantir a segurança de um software. Analisar asentidades que interagem com o sistema, os componentes, o fluxo de dados e ondeos dados serão armazenados, sem dúvida, contribuem para mapear os riscos edescobrir maneiras de mitigá-los. O modelo de modelagem de ameaçasapresentado anteriormente é a maneira mais conhecida de modelar e mapear osriscos.4.4.3 Teste de penetração Atualmente, os testes de penetração de segurança de software, tambémconhecidos como testes de penetração em aplicação, são úteis, principalmente, paraidentificar problemas no ambiente e de configuração do sistema.
  • 45. 45 Os testes de penetração são executados através de ferramentas e exigemque o responsável pelos testes tenha habilidades avançadas em relação àsegurança de software. Atualmente, este é o principal recurso utilizado pelas empresas paraavaliação do software a ser instalado no ambiente de produção, não garantindo queo software foi construído com segurança, mas, se utilizado desde a primeira versãodo software, podendo encontrar bugs de segurança ainda não identificados.4.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 dosistema, como em componentes ou na integração deles, além de serem feitosusando duas metodologias, teste de caixa branca e teste de caixa preta. A análise de risco desenvolvida previamente é essencial e deve direcionar aconstrução de casos de abuso. Os testes de segurança baseados em riscos, também, exigem que oresponsá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 dosoftware.4.4.5 Casos de abuso No UML o caso de uso permite modelar e desenhar o software, detalhandocomo 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 deuso do UML, mas na visão de um cliente mal-intencionado, mapeando, assim,possíveis atividades maliciosas que, possivelmente, seriam executadas.
  • 46. 46 A análise de risco desenvolvida previamente pode contribuir e direcionar aconstrução de caso de abuso.4.4.6 Requisitos de segurança A definição e manutenção dos requisitos de segurança é uma tarefacomplexa, pois bons requisitos de segurança devem estar atualizados e abranger osrequisitos funcionais, não funcionais e outras características principais de cadasoftware. Os requisitos de segurança devem ser mantidos sempre disponíveis aosprogramadores, como principal referência para a construção de software seguro.4.4.7 Operação de segurança O responsável pela segurança de software deve contar com a habilidade dosoutros profissionais de segurança de redes e de sistema para a implantação doprojeto em ambiente de produção com controles anteriormente definidos. Além disso, discutir melhorias de segurança do sistema com outrosprofissionais de segurança pode contribuir na identificação de possíveis problemasde segurança em outras camadas de segurança.
  • 47. 475. INTEGRAÇÃO DO SCRUM COM SEGURANÇA DE SOFTWARE Para que as atividades e melhores práticas de segurança de software sejamintegradas ao SCRUM, é preciso, em primeiro lugar, apresentar e conscientizartodos os colaboradores, principalmente, os envolvidos e interessados na construçãode software seguro, sobre os conceitos de segurança da informação e segurança desoftware, possivelmente, através de pequenos treinamentos a estes colaboradores. Neste capítulo, descrevo a maior contribuição proposta por este trabalho, aintegração dos conceitos de segurança da informação e as melhores práticas desegurança de software, junto ao modelo ágil de desenvolvimento de software, oSCRUM.5.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égiosté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 aoscolaboradores de forma a incentivar uma visão crítica relacionada aos riscos dasegurança, gerando de forma proativa a construção de softwares seguros, atuandoem profundidade ou em outras diversas camadas e evitando incidentes oriundos deações internas erradas ou possivelmente maliciosas.
  • 48. 485.2 PROCESSO Quando o assunto é segurança da informação, é imprescindível ter o totalapoio da alta gerência, evitando que possíveis conflitos de interesses possamimpedir que controles definidos pela equipe de segurança de software não sejamaplicados. 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 eacessível por todos os colaboradores envolvidos e interessados no projeto. Umadocumentação clara, estando disponível, faz com que o profissional de segurançaesteja capacitado a desenvolver as primeiras analises do projeto, antes mesmo doprimeiro encontro com os outros integrantes do projeto. Conforme mencionado anteriormente, a proposta deste trabalho consiste emalinhar as melhores práticas de segurança de software junto ao SCRUM, mas, paraisso é importante levar em consideração que a equipe de segurança de softwaregeralmente e reduzida e o tempo é muito curto para análises e entregas de novasfuncionalizadas em metodologias de desenvolvimento ágil.5.2.1 Artefatos5.2.1.1 Backlog do produto e backlog da iteração Nestas fases, o profissional de segurança de software deve analisar o backlogdo produto em busca de identificar possíveis ameaças, entender como funcionará oproduto desse projeto, criando cenários, definindo o desenho e a arquitetura,reunindo e alinhando as premissas de segurança com todos os envolvidos einteressados pelo projeto. Executar as primeiras análises do desenho e arquitetura, a partir dasinformações encontradas no backlog do produto e backlog da iteração, já podedirecionar a definição de requisitos de segurança, mapeando as entidades,
  • 49. 49componentes ou dependências do sistema que ainda não foram identificadasdurante a apresentação do projeto. Entender quais as funcionalidades do sistema eas entidades que irão interagir permitindo o especialista em segurança de softwarecriar 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 devemser executadas periodicamente, com o objetivo de identificar possíveis bugs ouconfigurações inseguras, que serão incluídos no backlog do produto. A partir do backlog de produtos e backlog de iteração, as atividades desegurança de software a serem executadas são: definição dos requisitos epremissas de segurança para o projeto, análise de risco e modelagem de ameaças,e casos de abuso.5.2.2 Cerimônias5.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 eacompanhamento do projeto são essenciais e, por isso, o profissional de segurançade software precisa estar presente nesse momento. Nessa primeira reunião, toda a equipe envolvida e interessada no projetoestará presente. Dúvidas em relação ao desenho e arquitetura devem ser sanadaspelo profissional de segurança de software, bem como a linguagem a ser utilizada, oarmazenamento 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 daspremissas e requisitos de segurança que se encaixam no contexto do projeto. Essaspremissas e requisitos de segurança devem permanecer devidamentedocumentados, juntamente ao projeto, para servir de referência para todos osenvolvidos.
  • 50. 50 No momento da primeira iteração ou apresentação do projeto, as atividadesde segurança de software a serem executadas são: definição dos requisitos epremissas de segurança para o projeto, análise de risco e modelagem de ameaças,e casos de abuso.5.2.2.2 Iteração A cada iteração, novas funcionalidades e recursos são construídos eentregues em produção de duas a quatro semanas. Toda a rapidez provida peloSCRUM 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, fazendoum bom trabalho de documentação das premissas e requisitos de segurança, alémde um desenho da arquitetura muito bem definido. Ao final de cada iteração o profissional de segurança de software e ou oanalista de qualidade deverá executar o teste de penetração e de segurança com oobjetivo de identificar problemas no software ainda não identificados, mitigados ouproblemas de configuração no ambiente de produção. Todos os bugs ou falhas identificadas durante a iteração devem sersubmetidos a uma análise de risco pelo profissional de segurança de software, como objetivo de endereçar a resolução do problema de acordo com a criticidade. Emcasos onde os bugs ou falhas identificadas tenham risco baixo, o profissional desegurança poderá endereçar as tarefas no backlog, solicitando a priorização aodono do produto. Já, em situações identificadas onde os bugs ou falhas sãoconsiderados críticos, a correção deverá ocorrer o mais breve possível, notificando odono do produto e, se for necessário, deverá notificar a alta gerência em busca depriorizaçã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 geralmentepode oferecer. Além disso, a revisão de código exige total dedicação de umprofissional de segurança de software, por isso, geralmente, é demandada quando oproduto é extremamente crítico para a empresa.
  • 51. 51 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 desegurança e revisão de código necessário e possível. Dependendo da criticidade de cada vulnerabilidade identificada, o profissionaldeverá recomendar uma mudança emergencial no software ou incluir a atividade nobacklog para a mitigação na próxima iteração ou quando priorizadas pelo dono doproduto em cada projeto.5.2.2.3 Revisão e retrospectiva da iteração Na reunião de revisão ou retrospectiva, os bugs ou falhas identificadas devemser apresentadas juntamente com a criticidade identificada, onde profissional deveráincluir a atividade no backlog para a mitigação na próxima iteração, sugerindo apriorização ao dono do produto.5.3 DESAFIOS Com base na pesquisa desenvolvida para este trabalho e na vastaexperiência que adquiri durante todos estes anos de trabalho como profissional desegurança da informação, apresento desafios que devem ser levados emconsideração no momento.5.3.1 Documentação “A literatura de segurança de software começou a surgir na comunidadecientífica, mas, em termos práticos, a prática de segurança de software continua emsua infância.” (MCGRAW, 2006)
  • 52. 52 Ao iniciar o desenvolvimento deste trabalho, percebi a dificuldade deencontrar documentação de qualidade referente à segurança de software junto ametodologias de desenvolvimento ágil de software, sobretudo em português. Poreste motivo as poucas e principais referencias relacionadas a segurança de softwarede qualidade foram utilizadas como base para o desenvolvimento deste trabalho.5.3.3 Profissionais MCGRAW (2006) explica que existem dois perfis profissionais de segurançade software: o profissional chapéu preto (blackhat), que executa atividadesconsideradas “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 desegurança, arquitetura, análise de risco, revisão de código, entre outras. Os doisperfis de profissionais são necessários, pois, enquanto um profissional de segurançade 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 atuamjuntos, como, por exemplo, no desenvolvimento de casos de abuso, análise deriscos, testes de segurança, dentre outras atividades. Atualmente, encontrar profissionais com conhecimentos e habilidadesrelacionados à segurança de software é um grande desafio. (MCGRAW, 2006) “Profissionais de segurança de redes não conhecem muito sobre softwarepara ser um bom profissional de segurança de software. Eles podem não carregarmuitas características sobre como a operação de um software funciona (além do quedesenvolvedores e arquitetos sabem), mas não é isso que precisamos para resolvero problema de segurança de software. Profissionais operadores de segurança quasenunca sabem nada sobre compiladores, frameworks, linguagem, arquitetura desoftware, testes e outras coisas necessárias para ser um sólido profissional desegurança de software.” (MCGRAW, 2006) “O que fazer quando uma habilidade rara é necessária? Você converte essahabilidade rara em um processo, que outros podem seguir, reforçando edisciplinando as pessoas e verificando se está funcionando realmente.” (MCGRAW,2006)
  • 53. 536. CONCLUSÃO O assunto segurança de software no Brasil ainda é pouco explorado pelaspessoas, 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 quepossua conhecimentos e habilidades em segurança de software, disponível ededicado para um ou mais projetos de desenvolvimento de software dentro daempresa, devido à escassez dessas habilidades e, também, o custo do projeto. Quando a empresa dispõe de profissionais de segurança de software, aintegração das atividades e melhores práticas de segurança de software, junto aoSCRUM, é possível e pouco complexa, permitindo um acompanhamento próximodos projetos possibilitando a construção de softwares mais seguros. Conclui-se que, para que esta integração se torne viável, depois de aplicar asmelhores práticas de segurança de software, a equipe de segurança precisamensurar os benefícios dos controles definidos em tempo de construção.Acompanhar a redução dos incidentes de segurança de software já pode contribuirpara medir os resultados do trabalho executado. Sugere-se como contribuição acadêmica o estudo prático dos efeitos destaintegração, principalmente, a redução das vulnerabilidades identificadas. O estudoperiódico desses resultados possibilitará medir o resultado do trabalho realizado, asua qualidade e prover sugestão de melhorias e evolução.
  • 54. 54REFERÊNCIAS BIBLIOGRÁFICASHOWARD, 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ívelem:<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-WesleyProfessional, 2007.SALTZER, J.H. e SCHROEDER, M.D. The Protection of Information in ComputerSystems. 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 de2011.
  • 55. 55THOMAS, Steve. An Agile Comparison.Disponível em: <http://www.balagan.org.uk/work/agile_comparison.htm>.Acessado em 04 de junho de 2011