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.

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 Web Application
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
• Promover o 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. HISTÓRICO
7

8. 8

9. 9

10. 10

11. Segurança de Software
• Anos 90: Java é seguro
!
• Bíblia do C: Exemplos com bugs
11

12. 12
X

13. Perímetro
13

14. É fácil testar se 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: Whitehat Stats Report 2013 16

17. Vulnerabilidades
Fonte: Whitehat Stats Report 2013
17

18. Vulnerabilidades por
Linguagem
18 Fonte: Whitehat Stats Report 2014

19. 19

20. Segurança
20

21. Defeitos de Software
BUGS x FALHAS
21

22. Defeitos de um Software
• 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 um Software
• 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 de Debbuging
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. 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 Risco da
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 Ten 2013
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 10 Software
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 10 Software
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
Application Security 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
Application Security 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
• Requisitos de 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ão inicie 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 que você possui um
problema, normalmente é
um bom primeiro passo.
43

44. Considerações
"All software sucks. Make
sure yours sucks less."
44

45. Referências
• Software Security: 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
• IEEE Top 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. Livros Recomendados
47

48. Perguntas?
48
jeronimo.zucco@owasp.org
!
https://www.owasp.org/index.php/Porto_Alegre