O processo de segurança em desenvolvimento, que não é ISO 15.408

2,808 views

Published on

Palestra apresentada durante o ISSA Day patrocinado pela Conviso IT Security no dia 31 de agosto de 2010 no Genuíno, em São Paulo, SP.

Published in: Technology
1 Comment
1 Like
Statistics
Notes
  • Discordo da apresentação no slide 19 quando se conclui que a ISO 15408 e a Common Criteria devem ser esquecidas para segurança em desenvolvimento.

    Como explicitado no slide 7, o foco delas é em produto e essas normas podem sim auxiliar no processo de definição de requisitos, reduzindo o risco de desenvolvimento equivocado.

    Concordo plenamente que a segurança é fortemente garantida por um processo robusto de desenvolvimento, que incorpore conceitos de segurança em todas as suas fases, mas desconsiderar a ISO e a CC seria privar o processo de elementos que podem auxiliar o processo.

    Uma analogia que posso utilizar é implementar um sistema de gestão da qualidade e não informar aos usuários sobre as ferramentas da qualidade que podem ser utilizadas para melhorar tanto o produto quanto o processo. As ferramentas por si só não ajudam se você não dominar o método.

    Espero ter contribuído.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
2,808
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
97
Comments
1
Likes
1
Embeds 0
No embeds

No notes for slide

O processo de segurança em desenvolvimento, que não é ISO 15.408

  1. 1. O processo de segurança em desenvolvimento, que não é ISO 15.408 <ul><li>Wagner Elias </li></ul><ul><li>Gerente de Pesquisa e Desenvolvimento </li></ul><ul><li>ISSA Day - São Paulo - 31 de Agosto 2010 </li></ul>
  2. 2. Por que Segurança em Desenvolvimento?
  3. 3. Investimentos em correção de software
  4. 4. Estatísticas de falhas em software <ul><li>Segundo o NIST </li></ul><ul><ul><li>92% das vulnerabilidades de segurança estão em software </li></ul></ul><ul><li>Segundo o Gartner </li></ul><ul><ul><li>75% dos incidentes são causados por falha de software </li></ul></ul>
  5. 5. Conformidade <ul><li>Atendimento a regulamentações e padrões </li></ul><ul><ul><li>PCI (Payment Card Industry Data Security Standard) </li></ul></ul><ul><ul><ul><li>Atendimento ao Requisito 6: Desenvolver e manter sistemas e aplicações seguras </li></ul></ul></ul><ul><li>Transparência e facilidade para auditorias </li></ul><ul><ul><li>Atendimento a auditorias de sistemas e de segurança </li></ul></ul>
  6. 6. Principais Erros
  7. 7. Usar ISO/IEC 15.408 ou Commom Criteria como base <ul><li>Estes padrões não tem como objetivo a implementação ou avaliar um processo de Segurança em Desenvolvimento </li></ul><ul><ul><li>Foco em Produto Pronto </li></ul></ul><ul><ul><li>Objetivo principal é certificar produto de software e não um sistema de gestão ou processo </li></ul></ul>
  8. 8. Por que só o Brasil associa esta norma a segurança em desenvolvimento de software?
  9. 9. Alguém conhece um case de implementação de SDL que tenha usado estes padrões como base? ISO/IEC 15.408 SDL Case
  10. 10. Abordagem baseada apenas em testes <ul><li>Apenas testes não resolvem </li></ul><ul><ul><li>Testes no Desenvolvimento </li></ul></ul><ul><ul><ul><li>Unitário </li></ul></ul></ul><ul><ul><ul><li>Integrado </li></ul></ul></ul><ul><ul><ul><li>Aceitação </li></ul></ul></ul><ul><ul><li>Testes de Segurança </li></ul></ul><ul><ul><ul><li>Testes Black-Box (Pentest/Análise de Vulnerabilidades) </li></ul></ul></ul><ul><ul><ul><li>Revisão de Código </li></ul></ul></ul>
  11. 11. Abordagem baseada apenas em documentação <ul><li>Documentação é um bom caminho para atendimento a determinas regulamentações, mas é apenas parte do processo </li></ul><ul><ul><li>Tipos de Documentação </li></ul></ul><ul><ul><ul><li>Políticas </li></ul></ul></ul><ul><ul><ul><li>Cartilhas de Boas Práticas </li></ul></ul></ul><ul><ul><ul><li>Checklists </li></ul></ul></ul>
  12. 12. O Caminho Certo
  13. 13. Processo de desenvolvimento de software <ul><li>Processo Claro e Estabelecido </li></ul><ul><ul><li>Controle de Versão </li></ul></ul><ul><ul><li>Documentação </li></ul></ul><ul><li>Controle de Demandas e Bugs </li></ul><ul><ul><li>Bug Tracking </li></ul></ul><ul><li>Testes e Gestão de Build </li></ul><ul><ul><li>Testes de Qualidade de Software </li></ul></ul><ul><ul><li>Integração Contínua </li></ul></ul>
  14. 14. Conscientização e Capacitação <ul><li>Conscientização </li></ul><ul><ul><li>Gestores </li></ul></ul><ul><ul><li>Envolvidos no desenvolvimento e contratação de software </li></ul></ul><ul><li>Capacitação </li></ul><ul><ul><li>Dos envolvidos na gestão do desenvolvimento em SDL </li></ul></ul><ul><ul><li>Dos desenvolvedores em boas práticas de desenvolvimento seguro </li></ul></ul><ul><ul><li>Dos testadores em testes de segurança </li></ul></ul>
  15. 15. Desenvolvimento de Software <ul><li>Requerimentos </li></ul><ul><ul><li>Requisitos claros de segurança e privacidade </li></ul></ul><ul><li>Modelagem de Ameaças </li></ul><ul><ul><li>A modelagem de ameaças irá apresentar uma visão clara dos riscos associados ao software e um plano de ação para tratamento dos riscos </li></ul></ul><ul><li>Arquitetura Segura </li></ul><ul><ul><li>É essencial que toda a arquitetura de suporte ao software tenha os requisitos adequados de segurança </li></ul></ul>
  16. 16. Revisão de Software <ul><li>Revisão de Design e Arquitetura </li></ul><ul><ul><li>Verificar se os requisitos de design e arquitetura foram atendidos </li></ul></ul><ul><li>Revisão de Código </li></ul><ul><ul><li>A revisão de código é importante para o desenvolvimento de um bom código e pode identificar fraquezas da equipe de desenvolvimento </li></ul></ul><ul><li>Testes de Segurança </li></ul><ul><ul><li>Os testes irão verificar se o software tem níveis de segurança aceitáveis para serem disponibilizados </li></ul></ul>
  17. 17. Software Implementado <ul><li>Fortalecimento do ambiente de produção </li></ul><ul><ul><li>Hardening dos ativos que suportam o software em produção </li></ul></ul><ul><li>Gestão de Vulnerabilidades </li></ul><ul><ul><li>Após a implementação do processo é necessário acompanhar e tratar as vulnerabilidades que o software pode apresentar </li></ul></ul><ul><li>Gestão de Mudanças </li></ul><ul><ul><li>Com o software em produção é preciso estabelecer um processo claro de resposta a possíveis incidentes e tratamento de vulnerabilidades identificadas </li></ul></ul>
  18. 18. Conclusões
  19. 19. Conclusões <ul><ul><li>Segurança em desenvolvimento é muito mais que compliance </li></ul></ul><ul><ul><li>Não existe um produto que implemente segurança em desenvolvimento </li></ul></ul><ul><ul><li>Não existe desenvolvimento seguro sem um bom processo de desenvolvimento de software </li></ul></ul><ul><ul><li>Esqueçam a ISO/IEC 15.408/Common Criteria ela não é para segurança em desenvolvimento </li></ul></ul>
  20. 20. Referências para SDL <ul><li>Microsoft SDL </li></ul><ul><ul><li>http://www.microsoft.com/security/sdl/ </li></ul></ul><ul><li>OWASP OpenSAMM </li></ul><ul><ul><li>http://www.opensamm.org/ </li></ul></ul><ul><li>BSIMM </li></ul><ul><ul><li>http://bsimm2.com/resources/ </li></ul></ul>
  21. 21. Blog: http://wagnerelias.com Twitter: http://www.twitter.com /welias

×