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
Jun 28, 2015
1
O processo de segurança em desenvolvimento, que não é ISO 15.408Wagner 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 softwareProcesso 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.comTwitter: http://www.twitter.com/welias