O documento discute a importância da segurança no desenvolvimento de software. Apresenta estatísticas mostrando que a maioria das vulnerabilidades estão em software e levam meses para serem corrigidas. Também descreve o Ciclo de Vida de Desenvolvimento Seguro (SDL) da Microsoft, um framework para integrar práticas de segurança ao longo do ciclo de vida do software.

1. Segurança em
Desenvolvimento
de Software
Universidade de Caxias do Sul
Jerônimo Zucco
ForTI Univattes - Maio 2013
quarta-feira, 15 de maio de 13

2. • NIST: 92% das vulnerabilidades de
segurança estão em software
• GARTNER: 75% dos incidentes são
causados por falha em software
• Segurança é uma propriedade emergente
de sistemas (como qualidade)
Porque Segurança de Desenvolvimento ?
quarta-feira, 15 de maio de 13

3. Janela de Exposição a
Vulnerabilidades Sérias - 2012 *
* Fonte:Whitehat Website Security Statics Report - Maio 2013
quarta-feira, 15 de maio de 13

4. Janela de Exposição a
Vulnerabilidades Sérias - 2012 *
* Fonte:Whitehat Website Security Statics Report - Maio 2013
quarta-feira, 15 de maio de 13

5. Janela de Exposição a
Vulnerabilidades Sérias - 2012 *
* Fonte:Whitehat Website Security Statics Report - Maio 2013
quarta-feira, 15 de maio de 13

6. Incidentes de Segurança - 2012
* Fonte: CERT.br
quarta-feira, 15 de maio de 13

7. Atacantes X Sofisticação de Ataques
* Fonte: CERT.br
quarta-feira, 15 de maio de 13

8. • 86% de todos os websites possuíam ao
menos uma vulnerabilidade séria
• Número médio de vulnerabilidades sérias
por site: 56
• Número médio de dias para a correção
após a notificação: 193 (342)
Dados de 2012 *
* Fonte:Whitehat Website Security Statics Report - Maio 2013
quarta-feira, 15 de maio de 13

9. Quais as vulnerabilidades?
* Fonte:Whitehat Website Security Statics Report - Maio 2013
quarta-feira, 15 de maio de 13

10. • Em média, os web sites estão ficando mais
seguros a cada ano: a média era 1000
vulnerabilidades em 2007 e agora é de
apenas 56 em 2012
• SQL injection, o vetor de ataque mais sério
e mais popular, foi encontrado em apenas
7% dos sites
Algumas Boas Notícias *
* Fonte:Whitehat Website Security Statics Report - Maio 2013
quarta-feira, 15 de maio de 13

11. Top 10
2013*
1. Injection
2. Broken Authentication and Session Management
3. Cross-Site Scripting (XSS)
4. Insecure Direct Object References
5. Security Misconfiguration
* Top 10 2013 Release Candidate
quarta-feira, 15 de maio de 13

12. Top 10
2013
6. Sensitive Data Exposure
7. Missing Function Level Access Control
8. Cross-Site Request Forgery (CSRF)
9. Using Components with KnownVulnerabilities
10. Unvalidated Redirects and Forwards
* Top 10 2013 Release Candidate
quarta-feira, 15 de maio de 13

13. Segurança não é um
problema simples
de resolver.
Pergunta:
quarta-feira, 15 de maio de 13

14. Pergunta:
quarta-feira, 15 de maio de 13

15. • Prazos
• Aplicações legadas ou de terceiros
• Vulnerabilidades em Frameworks
• Rayls - Jan/2013
• Drupal - Fev/2013
• Django - Fev/2013
• Wordpress - Jan/2013
Alguns fatores
quarta-feira, 15 de maio de 13

16. • Não seguir padrões
• Aderência à boas práticas de
programação
• Não uso de algoritmos padrões (ex:
criptografia)
• Códigos disponíveis na web
Alguns fatores
quarta-feira, 15 de maio de 13

17. • 10 Reasons SQL Injection Still Works
http://is.gd/w7qHC4
• Software [In]security:Top 11 Reasons
Why Top 10 (or Top 25) Lists Don’t Work
http://is.gd/sq8w1c
• 2011 CWE/SANS Top 25 Most
Dangerous Software Errors
http://cwe.mitre.org/top25/
Alguns fatores
quarta-feira, 15 de maio de 13

18. * Fonte:Whitehat Website Security Statics Report - Maio 2013
O que pode ser feito ?
quarta-feira, 15 de maio de 13

19. https://www.microsoft.com/security/sdl/default.aspx
Microsoft SDL Security
Development Lifecycle
quarta-feira, 15 de maio de 13

20. • Treinamento da equipe de conceitos
fundamentais na construcão de aplicativos
seguros (Interno, externo, OWASP,
Techtalks, Livros, etc)
• Design de aplicações seguras
• Testes de segurança
• Análise de riscos
• Modelagem de ameaças
Fase 1 SDL:Treinamento
quarta-feira, 15 de maio de 13

21. • Estabelecer requerimentos de segurança
e privacidade
• Criar baselines de segurança
(características mínimas aceitáveis)
• Análise de riscos de segurança (SRA)
• Análise de riscos de privacidade (PRA)
Fase 2 SDL: Requerimentos
quarta-feira, 15 de maio de 13

22. • Estabelecer requerimentos de design
considerando os riscos
• Análise/redução da superfície de ataque
• Uso de modelagem de ameaças
Fase 3 SDL: Design
quarta-feira, 15 de maio de 13

23. • STRIDE (identificação das ameaças): Spoofing,
Tampering, Repudiation, Information disclousure,
Denial of Service, Elevation of privilege
• DREAD (rate the threats): Damage potential,
Reproducibility, exploitability, affected users,
discoverability
• OCTAVE: Operationally Critical Threat,Asset, and
Vulnerability Evaluation
• CVSS: CommonVulnerability Scoring System
Modelagem de Ameaças
quarta-feira, 15 de maio de 13

24. • Identificar os ativos
• Criar um panorama da arquitetura
• Decompor o software
• Identificar as ameaças
• Documentar as ameaças
• Classificar as ameaças
Modelagem de Ameaças
quarta-feira, 15 de maio de 13

25. • Uso de ferramentas aprovadas
• Ferramentas de bugtrack (redmine, track),
versionamento (SVN, Git) e documentação
(Sphinx, wiki)
• Substituir funções inseguras
• Realizar análises estáticas:
• Validação do código antes e depois de
submeter ao repositório de versionamento de
fontes (Ex: Pylint, PEP 008, 257, 290)
Fase 4 SDL: Implementação
quarta-feira, 15 de maio de 13

26. • Revisão da superfície de ataque
• Realizar análises dinâmicas:
• Servidor de integração (testes
automatizados)
• Testes Fuzzing
• Pentest (whitebox e blackbox)
Fase 5 SDL:Verificação
quarta-feira, 15 de maio de 13

27. • Criar um plano de resposta a incidentes
• Conduzir uma revisão final de segurança
• Certificação do código de que ele cobre
a baseline e requisitos
Fase 6 SDL: Lançamento
quarta-feira, 15 de maio de 13

28. • Executar um plano de resposta a
incidentes
• Corrigir antes é mais barato do que
nessa fase *
• Tratar vulnerabilidades como bugs
Fase 7 SDL: Responder
* Fonte: Software Defect Reduction Top 10 List - IEEE
quarta-feira, 15 de maio de 13

29. • Software Assurance Maturity Model
(SAMM): http://www.opensamm.org
• ISO/IEC 15408 (Common Criteria) -
certifica o quanto o programa está
aderente a um baseline mínimo
• Building Security In Maturity Model -
BSIMM http://www.bsimm.com/
Maturidade de Código
≠Desenvolvimento Seguro
quarta-feira, 15 de maio de 13

30. • Aplicar o conceito de menor privilégio
• Cooperação entre os setores de
desenvolvimento, processos e infraestrutura
• Tratar vulnerabilidades como bugs
• Hardening da infraestrutura
• Proteger também os usuários (HSTS, cookies
seguros, certificados válidos, Browser/Plugins)
Algo mais
quarta-feira, 15 de maio de 13

31. • Uso de Web Applications Firewalls (ModSecurity)
• Envolvimento com a comunidade de
desenvolvimento seguro (OWASP POA)
• A responsabilidade não é só do analista de
segurança/suporte, e sim mais do desenvolvedor
• Não existem sistemas invioláveis
Algo mais
quarta-feira, 15 de maio de 13

32. • Whitehat Website Security Statics Report - Maio
2013 - https://www.whitehatsec.com/assets/
WPstatsReport_052013.pdf
• https://www.owasp.org
• Webinar Segurança de Desenvolvimento de
Software - Wagner Elias: https://
www.youtube.com/watch?v=ZVxZKgLR2yg
• OWASP CLASP Project: https://www.owasp.org/
index.php/Category:OWASP_CLASP_Project
Referências
quarta-feira, 15 de maio de 13

33. Referências - Livros
quarta-feira, 15 de maio de 13