Jerônimo Zucco jeronimo.zucco@owasp.org

Validando a Segurança! de Software

Terceira Jornada Acadêmica de Computação e Tecnologia da Informação da UCS:Tendências em TI

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

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.

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

OWASP no RS

5

https://www.owasp.org/index.php/Porto_Alegre

Quais os requerimentos mínimos para um

software ser considerado seguro?

6

HISTÓRICO

7

8

9

10

Segurança de Software

• Anos 90: Java é seguro !

• Bíblia do C: Exemplos com bugs

11

12

X

Perímetro

13

É 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

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

15Fonte: Whitehat Stats Report 2013

Números

16Fonte: Whitehat Stats Report 2013

Vulnerabilidades

17

Fonte: Whitehat Stats Report 2013

Vulnerabilidades por Linguagem

18Fonte: Whitehat Stats Report 2014

19

Segurança

20

Defeitos de Software

BUGS x FALHAS

21

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

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

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

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

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

Pentesting

• Varreduras • Ferramentas • Spiders • Fuzzers • Ataques maliciosos • Validação de Controles • Blackbox, Whitebox

28

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

Microsoft SDL Security Development Lifecycle

30

https://www.microsoft.com/security/sdl/default.aspx

OWASP Top Ten 2013

31

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

Top 10 2010 -> 2013

33

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

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

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:

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:

• Níveis ASVS:

38

OWASP ASVS Application Security Verification

Standard Project

OWASP Testing_Guide v4

• Information Gathering • Configuration and Deployment

Management Testing • Identity Management Testing • Authentication Testing • Authorization Testing • Session Management Testing

39

OWASP Testing_Guide v4

• Input Validation Testing • Testing for Error Handling • Testing for weak Cryptography • Business Logic Testing • Client Side Testing

40

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

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

Considerações

Saber que você possui um problema, normalmente é um bom primeiro passo.

43

Considerações

"All software sucks. Make sure yours sucks less."

44

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

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

Livros Recomendados

47

Perguntas?

48

jeronimo.zucco@owasp.org !

https://www.owasp.org/index.php/Porto_Alegre