Segurança emDesenvolvimento
de Software
Universidade de Caxias do SulJerônimo Zucco
ForTI Univattes - Maio 2013
quarta-feira, 15 de maio de 13
• 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
Janela de Exposição a Vulnerabilidades Sérias - 2012 *
* Fonte: Whitehat Website Security Statics Report - Maio 2013
quarta-feira, 15 de maio de 13
Janela de Exposição a Vulnerabilidades Sérias - 2012 *
* Fonte: Whitehat Website Security Statics Report - Maio 2013
quarta-feira, 15 de maio de 13
Janela de Exposição a Vulnerabilidades Sérias - 2012 *
* Fonte: Whitehat Website Security Statics Report - Maio 2013
quarta-feira, 15 de maio de 13
• 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
Quais as vulnerabilidades?
* Fonte: Whitehat Website Security Statics Report - Maio 2013quarta-feira, 15 de maio de 13
• 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
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
Top 10 2013
6. Sensitive Data Exposure
7. Missing Function Level Access Control
8. Cross-Site Request Forgery (CSRF)
9. Using Components with Known Vulnerabilities
10. Unvalidated Redirects and Forwards
* Top 10 2013 Release Candidate
quarta-feira, 15 de maio de 13
• 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
• 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
• 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
* Fonte: Whitehat Website Security Statics Report - Maio 2013
O que pode ser feito ?
quarta-feira, 15 de maio de 13
https://www.microsoft.com/security/sdl/default.aspx
Microsoft SDL Security Development Lifecycle
quarta-feira, 15 de maio de 13
• 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
• 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
• 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
• 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: Common Vulnerability Scoring System
Modelagem de Ameaças
quarta-feira, 15 de maio de 13
• 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
• 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
• 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
• 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
• 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
• 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
• 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
• 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
• 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