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