Segurança em desenvolvimento de software

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

• 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 ?

Janela de Exposição a
Vulnerabilidades Sérias - 2012 *
* Fonte:Whitehat Website Security Statics Report - Maio 2013

Incidentes de Segurança - 2012
* Fonte: CERT.br

Atacantes X Soﬁsticação de Ataques
* Fonte: CERT.br

• 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 notiﬁcação: 193 (342)
Dados de 2012 *

Quais as vulnerabilidades?

• Em média, os web sites estão ﬁcando 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 *

Top 10
2013*
1. Injection
2. Broken Authentication and Session Management
3. Cross-Site Scripting (XSS)
4. Insecure Direct Object References
5. Security Misconﬁguration
* Top 10 2013 Release Candidate

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

Segurança não é um
problema simples
de resolver.
Pergunta:

Pergunta:

• Prazos
• Aplicações legadas ou de terceiros
• Vulnerabilidades em Frameworks
• Rayls - Jan/2013
• Drupal - Fev/2013
• Django - Fev/2013
• Wordpress - Jan/2013
Alguns fatores

• Não seguir padrões
• Aderência à boas práticas de
programação
• Não uso de algoritmos padrões (ex:
criptograﬁa)
• Códigos disponíveis na web
Alguns fatores

• 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

O que pode ser feito ?

https://www.microsoft.com/security/sdl/default.aspx
Microsoft SDL Security
Development Lifecycle

• 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

• 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

• 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

• STRIDE (identiﬁcação das ameaças): Spooﬁng,
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

• 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

• 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

• 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:Veriﬁcação

• Criar um plano de resposta a incidentes
• Conduzir uma revisão ﬁnal de segurança
• Certiﬁcação do código de que ele cobre
a baseline e requisitos
Fase 6 SDL: Lançamento

• 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

• Software Assurance Maturity Model
(SAMM): http://www.opensamm.org
• ISO/IEC 15408 (Common Criteria) -
certiﬁca 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

• 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, certiﬁcados válidos, Browser/Plugins)
Algo mais

• 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

• 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

Referências - Livros

Segurança em desenvolvimento de software

Mais conteúdo relacionado

Mais procurados

Semelhante a Segurança em desenvolvimento de software

Mais de Jeronimo Zucco

Último

Segurança em desenvolvimento de software