Segurança em desenvolvimento de software

1,282 views

Published on

Apresentação realizada na ForTI (grupo de TI das universidades particulares gaúchas) em Maio/2013.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,282
On SlideShare
0
From Embeds
0
Number of Embeds
379
Actions
Shares
0
Downloads
27
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Segurança em desenvolvimento de software

  1. 1. Segurança emDesenvolvimentode SoftwareUniversidade de Caxias do SulJerônimo ZuccoForTI Univattes - Maio 2013quarta-feira, 15 de maio de 13
  2. 2. • NIST: 92% das vulnerabilidades desegurança estão em software• GARTNER: 75% dos incidentes sãocausados por falha em software• Segurança é uma propriedade emergentede sistemas (como qualidade)Porque Segurança de Desenvolvimento ?quarta-feira, 15 de maio de 13
  3. 3. Janela de Exposição aVulnerabilidades Sérias - 2012 ** Fonte:Whitehat Website Security Statics Report - Maio 2013quarta-feira, 15 de maio de 13
  4. 4. Janela de Exposição aVulnerabilidades Sérias - 2012 ** Fonte:Whitehat Website Security Statics Report - Maio 2013quarta-feira, 15 de maio de 13
  5. 5. Janela de Exposição aVulnerabilidades Sérias - 2012 ** Fonte:Whitehat Website Security Statics Report - Maio 2013quarta-feira, 15 de maio de 13
  6. 6. Incidentes de Segurança - 2012* Fonte: CERT.brquarta-feira, 15 de maio de 13
  7. 7. Atacantes X Sofisticação de Ataques* Fonte: CERT.brquarta-feira, 15 de maio de 13
  8. 8. • 86% de todos os websites possuíam aomenos uma vulnerabilidade séria• Número médio de vulnerabilidades sériaspor site: 56• Número médio de dias para a correçãoapós a notificação: 193 (342)Dados de 2012 ** Fonte:Whitehat Website Security Statics Report - Maio 2013quarta-feira, 15 de maio de 13
  9. 9. Quais as vulnerabilidades?* Fonte:Whitehat Website Security Statics Report - Maio 2013quarta-feira, 15 de maio de 13
  10. 10. • Em média, os web sites estão ficando maisseguros a cada ano: a média era 1000vulnerabilidades em 2007 e agora é deapenas 56 em 2012• SQL injection, o vetor de ataque mais sérioe mais popular, foi encontrado em apenas7% dos sitesAlgumas Boas Notícias ** Fonte:Whitehat Website Security Statics Report - Maio 2013quarta-feira, 15 de maio de 13
  11. 11. Top 102013*1. Injection2. Broken Authentication and Session Management3. Cross-Site Scripting (XSS)4. Insecure Direct Object References5. Security Misconfiguration* Top 10 2013 Release Candidatequarta-feira, 15 de maio de 13
  12. 12. Top 1020136. Sensitive Data Exposure7. Missing Function Level Access Control8. Cross-Site Request Forgery (CSRF)9. Using Components with KnownVulnerabilities10. Unvalidated Redirects and Forwards* Top 10 2013 Release Candidatequarta-feira, 15 de maio de 13
  13. 13. Segurança não é umproblema simplesde resolver.Pergunta:quarta-feira, 15 de maio de 13
  14. 14. Pergunta:quarta-feira, 15 de maio de 13
  15. 15. • Prazos• Aplicações legadas ou de terceiros• Vulnerabilidades em Frameworks• Rayls - Jan/2013• Drupal - Fev/2013• Django - Fev/2013• Wordpress - Jan/2013Alguns fatoresquarta-feira, 15 de maio de 13
  16. 16. • Não seguir padrões• Aderência à boas práticas deprogramação• Não uso de algoritmos padrões (ex:criptografia)• Códigos disponíveis na webAlguns fatoresquarta-feira, 15 de maio de 13
  17. 17. • 10 Reasons SQL Injection Still Workshttp://is.gd/w7qHC4• Software [In]security:Top 11 ReasonsWhy Top 10 (or Top 25) Lists Don’t Workhttp://is.gd/sq8w1c• 2011 CWE/SANS Top 25 MostDangerous Software Errorshttp://cwe.mitre.org/top25/Alguns fatoresquarta-feira, 15 de maio de 13
  18. 18. * Fonte:Whitehat Website Security Statics Report - Maio 2013O que pode ser feito ?quarta-feira, 15 de maio de 13
  19. 19. https://www.microsoft.com/security/sdl/default.aspxMicrosoft SDL SecurityDevelopment Lifecyclequarta-feira, 15 de maio de 13
  20. 20. • Treinamento da equipe de conceitosfundamentais na construcão de aplicativosseguros (Interno, externo, OWASP,Techtalks, Livros, etc)• Design de aplicações seguras• Testes de segurança• Análise de riscos• Modelagem de ameaçasFase 1 SDL:Treinamentoquarta-feira, 15 de maio de 13
  21. 21. • Estabelecer requerimentos de segurançae 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: Requerimentosquarta-feira, 15 de maio de 13
  22. 22. • Estabelecer requerimentos de designconsiderando os riscos• Análise/redução da superfície de ataque• Uso de modelagem de ameaçasFase 3 SDL: Designquarta-feira, 15 de maio de 13
  23. 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, andVulnerability Evaluation• CVSS: CommonVulnerability Scoring SystemModelagem de Ameaçasquarta-feira, 15 de maio de 13
  24. 24. • Identificar os ativos• Criar um panorama da arquitetura• Decompor o software• Identificar as ameaças• Documentar as ameaças• Classificar as ameaçasModelagem de Ameaçasquarta-feira, 15 de maio de 13
  25. 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 desubmeter ao repositório de versionamento defontes (Ex: Pylint, PEP 008, 257, 290)Fase 4 SDL: Implementaçãoquarta-feira, 15 de maio de 13
  26. 26. • Revisão da superfície de ataque• Realizar análises dinâmicas:• Servidor de integração (testesautomatizados)• Testes Fuzzing• Pentest (whitebox e blackbox)Fase 5 SDL:Verificaçãoquarta-feira, 15 de maio de 13
  27. 27. • Criar um plano de resposta a incidentes• Conduzir uma revisão final de segurança• Certificação do código de que ele cobrea baseline e requisitosFase 6 SDL: Lançamentoquarta-feira, 15 de maio de 13
  28. 28. • Executar um plano de resposta aincidentes• Corrigir antes é mais barato do quenessa fase *• Tratar vulnerabilidades como bugsFase 7 SDL: Responder* Fonte: Software Defect Reduction Top 10 List - IEEEquarta-feira, 15 de maio de 13
  29. 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 Seguroquarta-feira, 15 de maio de 13
  30. 30. • Aplicar o conceito de menor privilégio• Cooperação entre os setores dedesenvolvimento, processos e infraestrutura• Tratar vulnerabilidades como bugs• Hardening da infraestrutura• Proteger também os usuários (HSTS, cookiesseguros, certificados válidos, Browser/Plugins)Algo maisquarta-feira, 15 de maio de 13
  31. 31. • Uso de Web Applications Firewalls (ModSecurity)• Envolvimento com a comunidade dedesenvolvimento seguro (OWASP POA)• A responsabilidade não é só do analista desegurança/suporte, e sim mais do desenvolvedor• Não existem sistemas invioláveisAlgo maisquarta-feira, 15 de maio de 13
  32. 32. • Whitehat Website Security Statics Report - Maio2013 - https://www.whitehatsec.com/assets/WPstatsReport_052013.pdf• https://www.owasp.org• Webinar Segurança de Desenvolvimento deSoftware - Wagner Elias: https://www.youtube.com/watch?v=ZVxZKgLR2yg• OWASP CLASP Project: https://www.owasp.org/index.php/Category:OWASP_CLASP_ProjectReferênciasquarta-feira, 15 de maio de 13
  33. 33. Referências - Livrosquarta-feira, 15 de maio de 13

×