Transferir como PDF, PPTX
Carregado porJeronimo Zucco
Validando a Segurança de Software
A apresentação discute a importância da segurança no desenvolvimento de software. Aborda os requisitos mínimos para um software ser considerado seguro, como revisão de código, análise de risco da arquitetura e pentesting. Também apresenta projetos da OWASP como o Top 10, ASVS e guia de testes que fornecem diretrizes para o desenvolvimento seguro de aplicações.
Mais conteúdo relacionado
Validando a Segurança de Software
- 1. Validando a Segurança! de Software Jerônimo Zucco jeronimo.zucco@owasp.org Terceira Jornada Acadêmica de Computação e Tecnologia da Informação da UCS:Tendências em TI
- 2. About Me •Blog: http://jczucco.blogspot.com • Twitter: @jczucco • http://www.linkedin.com/in/jeronimozucco • http://www.owasp.org/index.php/User:Jeronimo_Zucco • Algumas certificações na área de segurança
- 3. OWASP Open WebApplication Security Project • Uma comunidade aberta dedicada a ajudar as organizações a desenvolver, comprar e manter aplicações que possam ser confiáveis.
- 4. OWASP • Promovero desenvolvimento seguro • Auxiliar a tomada de decisão quanto ao risco • Oferecer recursos gratuitos • Promover a contribuição e compartilhamento de informação 4
- 5. OWASP no RS 5 https://www.owasp.org/index.php/Porto_Alegre
- 6. Quais os requerimentos mínimos para um software ser considerado seguro? 6
- 7.
- 8.
- 9.
- 10.
- 11. Segurança de Software • Anos 90: Java é seguro ! • Bíblia do C: Exemplos com bugs 11
- 12.
- 13.
- 14. É fácil testarse um recurso de um programa funciona ou não, mas é muito difícil afirmar se um sistema é suficientemente seguro para resistir á um ataque malicioso 14
- 15. Números • 86%dos sites testados possuem ao menos uma vulnerabilidade grave • 61% desses problemas foram corrigidos após notificação • 193 dias em média para a correção ser realizada desde a notificação 15 Fonte: Whitehat Stats Report 2013
- 16. Números Fonte: WhitehatStats Report 2013 16
- 17. Vulnerabilidades Fonte: WhitehatStats Report 2013 17
- 18. Vulnerabilidades por Linguagem 18 Fonte: Whitehat Stats Report 2014
- 19.
- 20.
- 21. Defeitos de Software BUGS x FALHAS 21
- 22. Defeitos de umSoftware • Bug: defeitos na implementação – Buffer overflow – Condições de corrida – Variáveis de ambiente inseguras – Chamadas de sistema inseguras – Entrada de dados não confiáveis 22
- 23. Defeitos de umSoftware • Falhas: defeitos no design – Não uso de criptografia – Problemas de compartimentalização – Falha na proteção de áreas privilegiadas – Falhas de segurança – Auditoria insegura – Controle de acesso quebrado 23
- 24. 6 Estágios deDebbuging 1. Isso não pode acontecer 2. Isso não acontece na minha máquina 3. Isso não deveria acontecer 4. Porque isso acontece? 5. Hum, eu vejo. 6. Como isso sempre funcionou? 24
- 25.
- 26. Revisão de Código • Análise estática: Análise de código sem execução. Pode gerar falso positivos, integrado com IDE (eclipse, (Ex: Coverity, Fortify (HP), FindBugs (Opensource) • Análise dinâmica: Análise de programa durante sua execução 26
- 27. Análise de Riscoda Arquitetura • Exemplos: Dados críticos sem proteção: web service sem autenticação ou controle de acesso • Ativo, Risco, Ameaça, Contramedida, Impacto • STRIDE (Microsoft), ASSET (Automated Security self-Evaluation Tool), OCTAVE (Operational Critical Threat, Assset and Vulnerability Evaluation), COBIT (ISACA) 27
- 28. Pentesting • Varreduras • Ferramentas • Spiders • Fuzzers • Ataques maliciosos • Validação de Controles • Blackbox, Whitebox 28
- 29. Casos de Abuso ! • Testes de segurança baseado no risco • Casos de abuso: – Tampering Attack • Requerimentos de segurança • Operações de segurança 29
- 30. Microsoft SDL Security Development Lifecycle https://www.microsoft.com/security/sdl/default.aspx 30
- 31. OWASP Top Ten2013 31
- 32. OWASP Top 10 • Top 10 Vulnerabilidades em Apps. Web – Atualizado a cada 3 anos. – Baseado em dados obtidos de aplicações na Internet – Aceitação crescente pela indústria • Um bom começo para criação de práticas seguras de desenvolvimento nas organizações 32
- 33. Top 10 2010-> 2013 33
- 34. IEEE Top 10Software Security Design Flaws • Earn or give, but never assume, trust • Use an authentication mechanism that cannot be bypassed or tampered with • Authorize after you authenticate • Strictly separate data and control instructions, and never process control instructions received from untrusted sources • Define an approach that ensures all data are explicitly validated 34
- 35. IEEE Top 10Software Security Design Flaws • Use cryptography correctly • Identify sensitive data and how they should be handled • Always consider the users • Understand how integrating external components changes your attack surface • Be flexible when considering future changes to objects and actors 35
- 36. OWASP ASVS ApplicationSecurity Verification Standard Project • Authentication Verification • Session Management Verification • Access Control Verification • Malicious Input Handling Verification • Cryptography at Rest Verification • Error Handling and Logging Verification • Data Protection Verification 36 Requisitos:
- 37. OWASP ASVS ApplicationSecurity Verification Standard Project • Communications Security Verification • HTTP Security Verification • Malicious Controls Verification • Business Logic Verification • Files and Resources Verification • Mobile Verification Requirements 37 Requisitos:
- 38. • Níveis ASVS: 38 OWASP ASVS Application Security Verification Standard Project
- 39. OWASP Testing_Guide v4 • Information Gathering • Configuration and Deployment Management Testing • Identity Management Testing • Authentication Testing • Authorization Testing • Session Management Testing 39
- 40. OWASP Testing_Guide v4 • Input Validation Testing • Testing for Error Handling • Testing for weak Cryptography • Business Logic Testing • Client Side Testing 40
- 41. Desenvolvedores • Requisitosde segurança de aplicações; • Arquitetura de aplicações seguras; • Controles de segurança padrões; • Ciclo de vida de desenvolvimento (SDL) • Educação sobre segurança de aplicações • Uso de componentes seguros • Projetos OWASP 41
- 42. Considerações • Nãoinicie com pessoas da área de segurança de rede • Segurança de software exige esforço multidisciplinar • Treine sua equipe de desenvolvimento • Determine o que é suficiente • Sem medir, não sabemos onde estamos e nem se estamos evoluindo 42
- 43. Considerações Saber quevocê possui um problema, normalmente é um bom primeiro passo. 43
- 44. Considerações "All softwaresucks. Make sure yours sucks less." 44
- 45. Referências • SoftwareSecurity: Gary McGraw (2005) • WhiteHat Statistics Security Report (2013 e 2014) • OWASP Top Ten Project: https://www.owasp.org/ index.php/Category:OWASP_Top_Ten_Project • OWASP Application Security Verification Standard Project: https://www.owasp.org/index.php/ Category:OWASP_Application_Security_Verification_ Standard_Project • OWASP Testing Project: https://www.owasp.org/ index.php/OWASP_Testing_Project 45
- 46. Referências • IEEETop 10 Software Security Design Flaws: http:// cybersecurity.ieee.org/center-for-secure-design/ avoiding-the-top-10-security-flaws.html • Bill Gates 2002 memo: http://news.microsoft.com/ 2012/01/11/memo-from-bill-gates/ • Microsoft Security Development Lifecycle: http:// www.microsoft.com/security/sdl/default.aspx • BSIMM - Building Security in Maturity Model: http://www.bsimm.com • Open Source Security Testing Methodology Manual (OSSTMM): http://www.isecom.org/research/ osstmm.html 46
- 47.
- 48. Perguntas? 48 jeronimo.zucco@owasp.org ! https://www.owasp.org/index.php/Porto_Alegre