Segurança em Desenvolvimento de Software

9,330 views

Published on

Palestras realizada dia 21 de Outubro de 2008 na UNIFRAN

Segurança em Desenvolvimento de Software

  1. 1. Segurança em Desenvolvimento de Software Wagner Elias, SANS GIAC, CBCP Gerente de Pesquisa e Desenvolvimento
  2. 2. Agenda <ul><li>Por que Segurança em Desenvolvimento </li></ul><ul><li>O SDL (Secure Development Lifecycle) </li></ul><ul><li>Abordagens de Testes de Segurança de Software </li></ul><ul><li>Criando planos de testes com base na Modelagem de Ameaças </li></ul><ul><li>Conclusão </li></ul><ul><li>Referências </li></ul>
  3. 3. Por que Segurança em Desenvolvimento
  4. 4. É mais barato identificar e corrigir de forma proativa Custo para corrigir uma vulnerabilidade Baseado no estágio que ela foi identificada $139 $455 $977 $7,136 $14,102 Fonte: &quot;Software Defect Reduction Top 10 List,&quot; IEEE Computer, IEEE Computer Society
  5. 5. A maioria das aplicações possuem falhas de segurança <ul><li>NIST: 92% das vulnerabilidades de segurança estão em software </li></ul><ul><li>GARTNER: 75% dos incidentes são causados por falha de software </li></ul>
  6. 6. O SDL (Secure Development Lifecycle)
  7. 7. O Processo
  8. 8. <ul><li>Oportunidade de considerar segurança desde o ínicio </li></ul><ul><li>São definidos os requisitos de segurança que devem ser atendidos pelo software </li></ul><ul><ul><li>Normas e exigências regulatórias </li></ul></ul><ul><ul><li>Certificações (Common Criteria, PCI) </li></ul></ul><ul><ul><li>Atendimento a políticas de segurança interna </li></ul></ul>Requisitos
  9. 9. <ul><li>Definir e documentar a arquitetura de segurança </li></ul><ul><li>Usar princípios de design seguro </li></ul><ul><li>Uso de camadas, código gerenciado, menor privilégio, redução de superfície de ataque </li></ul><ul><li>Documentar superfície de ataque e reduzir a exposição das configurações default </li></ul><ul><li>Criar modelos de ameaça e mitigar ameaças usando controles </li></ul><ul><li>Definir metas de segurança adicionais que sejam específicas para o produto </li></ul>Design
  10. 10. <ul><li>Uso de normas de codificação e teste </li></ul><ul><ul><li>Uso de checklists para aplicação das normas </li></ul></ul><ul><ul><li>Cartilhas de boas práticas </li></ul></ul><ul><li>Aplicação de ferramentas de teste de “fuzzing” </li></ul><ul><li>Aplicação de ferramentas de análise de código estático </li></ul><ul><li>Condução de revisões de código </li></ul>Implementação
  11. 11. <ul><li>Testes e verificação são realizados para garantir o lançamento de uma versão beta </li></ul><ul><ul><li>Atendimento dos requisitos </li></ul></ul><ul><ul><li>Revisão de Código </li></ul></ul><ul><ul><li>Testes de Segurança </li></ul></ul>Verificação
  12. 12. <ul><li>A Revisão Final de Segurança será realizada e a seguinte pergunta será respondida: &quot;Do ponto de vista da segurança, este software está pronto para ser lançado?“. </li></ul><ul><li>A avaliação precisa ser independente e com um único objetivo: garantir a segurança do software que será entregue ao cliente. </li></ul>Lançamento
  13. 13. <ul><li>Com o software habilitado ao uso pelo cliente é necessário garantir uma resposta caso um incidente ocorra. </li></ul><ul><ul><li>Time de Resposta a Incidentes </li></ul></ul><ul><ul><li>Gestão e liberação de patchs de correção </li></ul></ul><ul><ul><li>Estudos de causa raiz que servirão de base para o aperfeiçoamento e melhoria contínua do SDL </li></ul></ul>Fase de resposta
  14. 14. Abordagens de Testes de Segurança de Software
  15. 15. <ul><li>White-Box </li></ul><ul><li>Black-Box </li></ul><ul><li>Fuzzing </li></ul>Classificação dos testes
  16. 16. <ul><li>Teste onde o testador tem amplo conhecimento do software e acesso a código fonte </li></ul><ul><ul><li>Vantagens </li></ul></ul><ul><ul><li>Permite um teste completo de todas as características do software </li></ul></ul><ul><ul><li>Desvantagens </li></ul></ul><ul><ul><li>O teste pode ficar inviável com um número grande de linhas de código </li></ul></ul>White-Box
  17. 17. <ul><li>Teste onde o testador tem o mesmo conhecimento e privilégios de acesso de um usuário comum. </li></ul><ul><li>Vantagens </li></ul><ul><ul><li>Pode ser executado sem acesso a “solution” (código fonte compilavel) </li></ul></ul><ul><ul><li>É possível testar controles em “run-tyme” </li></ul></ul><ul><ul><li>Desvantagens </li></ul></ul><ul><ul><li>O testador necessita de conhecimentos avançados em segurança de software </li></ul></ul><ul><ul><li>Pode ser necessário realiazar um engenharia reversa do software </li></ul></ul>Black-Box
  18. 18. <ul><li>Técnica para injeção de falhas </li></ul><ul><li>Escalável – funciona com qualquer linguagem </li></ul><ul><li>Versátil – Host ou Rede </li></ul>Fuzzing
  19. 19. Criando planos de testes com base na Modelagem de Ameaças
  20. 20. <ul><li>Abordagem estruturada usada para identificar e mensurar riscos aos recursos gerenciados pelo software </li></ul><ul><li>Permite que o design enderece os riscos de segurança </li></ul><ul><li>Define os requisitos e recursos de segurança </li></ul><ul><li>Ajuda na definição dos testes e revisões de código </li></ul>Modelagem de Ameaças
  21. 21. O Processo
  22. 22. Conclusão
  23. 23. <ul><li>É necessário e viável economicamente garantir a segurança do software que desenvolvemos </li></ul><ul><li>Testes de segurança irão garantir que o software desenvolvido terá sua garantia de funcionalidade e não trará riscos aos seus beneficiados </li></ul><ul><li>O processo de resposta a incidentes, após a entrega do software, não será traumático devido a falhas que não foram identificadas durante o processo de desenvolvimento </li></ul><ul><li>Todas as informações e expectativas de segurança do cliente serão garantidas </li></ul>Conclusões
  24. 24. Referências
  25. 25. <ul><li>O processo SDL - Trustworthy Computing Security Development Lifecycle http://www.microsoft.com/brasil/security/guidance/topics/lifecicle/sdl.mspx </li></ul><ul><li>Modelagem de Ameaças http://www.microsoft.com/brasil/security/guidance/topics/devsec/secmod76.mspx </li></ul><ul><li>OWASP (Open Web Application Security Project) http://www.owasp.org/ </li></ul>Referências
  26. 26. Perguntas? <ul><li>Contatos </li></ul><ul><li>Wagner Elias http://wagnerelias.com [email_address] </li></ul><ul><li>Conviso IT Security http://www.conviso.com.br [email_address] </li></ul>Associe-se OWASP (Open Web Application Security Project) http://www.owasp.org ISSA (Information System Security Association) http://www. issabrasil.org

×