Your SlideShare is downloading. ×
0
O processo de segurança em desenvolvimento, que não é ISO 15.408
O processo de segurança em desenvolvimento, que não é ISO 15.408
O processo de segurança em desenvolvimento, que não é ISO 15.408
O processo de segurança em desenvolvimento, que não é ISO 15.408
O processo de segurança em desenvolvimento, que não é ISO 15.408
O processo de segurança em desenvolvimento, que não é ISO 15.408
O processo de segurança em desenvolvimento, que não é ISO 15.408
O processo de segurança em desenvolvimento, que não é ISO 15.408
O processo de segurança em desenvolvimento, que não é ISO 15.408
O processo de segurança em desenvolvimento, que não é ISO 15.408
O processo de segurança em desenvolvimento, que não é ISO 15.408
O processo de segurança em desenvolvimento, que não é ISO 15.408
O processo de segurança em desenvolvimento, que não é ISO 15.408
O processo de segurança em desenvolvimento, que não é ISO 15.408
O processo de segurança em desenvolvimento, que não é ISO 15.408
O processo de segurança em desenvolvimento, que não é ISO 15.408
O processo de segurança em desenvolvimento, que não é ISO 15.408
O processo de segurança em desenvolvimento, que não é ISO 15.408
O processo de segurança em desenvolvimento, que não é ISO 15.408
O processo de segurança em desenvolvimento, que não é ISO 15.408
O processo de segurança em desenvolvimento, que não é ISO 15.408
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

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

2,523

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.

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,523
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
94
Comments
1
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

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

×