por quê o software continua inseguro?
TRANSCRIPT
Sobre o autor
• Vinícius Oliveira Ferreira.
• Pesquisador e analista no Laboratório ACME!
• Mestrando em Ciência da Computação pela UNESP –Universidade Estadual Paulista.
• Bolsista CAPES.
Agenda
• Continua mesmo?
• Problemas, problemas, problemas ...
• O que fazer para mudar?
• Conclusões
Agenda
• Continua mesmo?
• Problemas, problemas, problemas ...
• O que fazer para mudar?
• Conclusões
Continua mesmo?
Continua mesmo?
Continua mesmo?
Continua mesmo?
Continua mesmo?
Continua mesmo?
Figura extraída de [1].
Falhas o suficiente para se construir armas
Crescimento do mercado de vulnerabilidades
• O mercado de vulnerabilidades zero-day encontra-se em franca expansão;
• Motivado pelo surgimento de um novo mercado - “The Gray Market” [2].
Crescimento do mercado de vulnerabilidades
• White Market: Programas Bug Bounty (Google, Facebook, VCP, ZDI e etc).
• Recompensas variam de $500 a $5,000, mais reconhecimento pela comunidade.
• Black Market: Vulnerabilidades vendidas para organizações criminosas.
• Ética impedia que muitos dos pesquisadores migrassem para este mercado.
Crescimento do mercado de vulnerabilidades
We value the researcher ecosystem, and show that in a variety of ways, but we don’t think paying a per-vulnbounty is the best way. Especially when across the researcher community the motivations aren’t always financial. It is well-known that we acknowledge researcher’s contributions in our bulletins when a researcher has coordinated the release of vulnerability details with the release of a security update. Jerry Bryant –
Microsoft.
Crescimento do mercado de vulnerabilidades
We value the researcher ecosystem, and show that in a variety of ways, but we don’t think paying a per-vulnbounty is the best way. Especially when across the researcher community the motivations aren’t always financial. It is well-known that we acknowledge researcher’s contributions in our bulletins when a researcher has coordinated the release of vulnerability details with the release of a security update. Jerry Bryant –
Microsoft.
Gray Market: Vulnerabilidades vendidas a compradores legítimos: governos, empresas de espionagem e monitoramento e etc.
Gray Market
Gray Market
• Os preços geralmente começam em $20.000, podendo chegar a $200.000 [2].
• Empresas atuantes: VUPEN (França), ReVuln (Malta), Netragard, Endgame Systems e Exodus Intelligence (US).
• Grandes incentivos para os pesquisadores.
Gray Market
Gray Market
• Alguns Dados:
• Em 2013 a NSA gastou $25,000,000 com vulnerabilidades 0-day [3].
• Com o preço médio de $20,000 a $200,000 pode se estimar um valor de 125 a 1250 vulnerabilidades adquiridas;
• Algumas empresas vendem planos de assinaturas.
• Endgame Systems oferece 25 exploits por ano a uma assinatura de 2.5 milhões [4].
Até o Mitnick:
Problemas na ascensão do Gray Market
•Money talks:
• Dados vazados no ataque a HackingTeam indicaram negociações com países como: Rússia, Etiópia, Barém, Egito, Cazaquistão, Marrocos, Sudão, Arzeibajão e outros.
Problemas na ascensão do Gray Market
• Com maiores incentivos mais pesquisadores se envolverão na pesquisa por vulnerabilidades
• Problema: No Gray Market as vulnerabilidades não são corrigidas.
Agenda
• Continua mesmo?
• Problemas, problemas, problemas ...
• O que fazer para mudar?
• Conclusões
No Silver Bullet para o desenvolvimento de SW
• O SW é inerentemente complexo [5]
• Problemas acidentais e essenciais:
1. Acidentais (menos significantes): Limitações tecnológicas ...
2. Essenciais:
1. Complexidade: Há poucos elementos repetitivos e idênticos;
2. Conformidade: O SW precisa ser adaptado a todo tipo de instituição e sistema já existente;
3. Alterabilidade: O SW Por poder ser alterado muito facilmente, sofrend0 pressão por constantes alterações;
4. Invisibilidade: O software não é espacialmente representável; não existe um diagrama ou esquema lógico que o descreva.
No Silver Bullet para o desenvolvimento de SW
• O SW é inerentemente complexo [5]
• Algumas propostas para os problemas essenciais:
1. Comprar componentes prontos;
2. Refinamento de requisitos e prototipagem rápida;
3. Desenvolvimento Incremental;
4. Usar bons projetistas/programadores.
• Tais soluções ajudam, mas não são mágicas, não há uma bala de prata, e assim também é com segurança. Não existe pentest salvador.
Falta de capacitação em desenvolvimento seguro
• A maioria dos cursos de TI não abordam segurança em suas ementas, se abordam é de uma forma bastante superficial.
• Não advogamos a criação de cursos de segurança, acreditamos que a segurança deve estar presente em cada aspecto da tecnologia da informação.
• A segurança não é priorizada como deveria pela engenharia de SW.
• Há muito esforço para projetar, desenvolver e implantar, mas pouco é feito para que haja segurança nestas etapas.
• Os grandes autores (Pressman e Sommerville) quase sempre dedicaram pouco espaço à segurança em seus livros.
• Com exceção da última edição do livro Software Engineering - Ian Sommerville.
Polarização do conhecimento
• A falta de interdisciplinaridade entre segurança e outros assuntos fundamentais (e.g. desenvolvimento de SW) da computação se refletem nos profissionais gerados.
• O que se vê hoje é uma grande polarização entre profissionais de segurança e de desenvolvimento de SW.
Polarização do conhecimento
Polarização do conhecimento
Developers -> Security Guys
Polarização do conhecimento
Security Guys -> Developers
Indisposição para investir
• Segurança custa, para tê-la é preciso investir.
• Sem investimento não se cria nenhuma iniciativa de segurança. Sem incentivos nada funciona.
• Segurança é um investimento preventivo
• Poucos se previnem, o urgente é sempre colocado acima do prioritário.
Por fim, como as coisas tem sido feitas
• Como é difícil lidar com o SW, vamos proteger seu entorno.
A utilização de Antivírus, SO,firewalls e outras ferramentas desegurança se assemelha autilização de barreiras para aproteção de um interiorvulnerável.
• O problema é que barreirassão sempre transpassadas!!!
Corretude vs Segurança
• Atributos de sistemas de Software:
• Corretude: O que o sistema deve fazer;
• Segurança: O que o sistema não deve fazer.
• Grande parte dos desenvolvedores aplicam seus esforços para alcançar corretude e não segurança.
Corretude vs Segurança
•Sob a ótica da corretude.
• Todos os softwares possuem bugs:
• A correção de todos eles é infactível, prioriza-se então a correção dos bugs que surgirão em situação típicas e afetarão o maior número de usuários.
• Os bugs restantes surgem de situações atípicas, frutos de raras interações com o sistema. Ainda quando surgem, os usuários procuram contornar o problema.
• Quando um bug afeta muitos usuários ele então é corrigido.
Corretude vs Segurança
• Sob a ótica da segurança.
Um atacante não é um usuário comum
• Enquanto usuários comuns evitam os bugs, um atacante tenta reproduzi-los, entender sua causa e então manipula-los para criar uma situação de exploração.
• Portanto, além de considerarmos típicos casos de uso, quando falamos em segurança, precisamos também considerar casos de abuso.
Agenda
• Continua mesmo?
• Problemas, problemas, problemas ...
• O que fazer para mudar?
• Conclusões
Na verdade já começou
• Writing Secure Code - Michael Howard e David Leblanc (2001);
• Building Secure Software - Gary McGraw e John Viega(2001);
• Bill Gates's Trustworthy Computing memo (2002).
Na verdade já começou
Segurança como parte integral
• O que aprendemos: Não há solução mágica, a segurança precisa ser adicionada integralmente a todo o ciclo de desenvolvimento de SW.
• Pentest não resolve tudo!!!
Segurança como parte integral
Bugs vs Falhas (flaws)
50% 50%
Segurança como parte integral, como fazê-la:
ISO/IEC 27034
Segurança como parte integral, como fazê-la:
Figura extraída de [6].
Segurança como parte integral, como fazê-la:
Figura adaptada de [6].
Requisitos de Segurança
• Envolva o cliente com os aspectos de segurança.
• Isso o ajudará a compreender os possíveis riscos;
• Permitirá a elicitação de requisitos especiais de proteção ao software;
• Realize a classificação dos dados.
• Considere novos requisitos que podem surgir dos casos de abuso (abuse cases).
Segurança como parte integral, como fazê-la:
Figura adaptada de [6].
Figura extraída de [7].
Segurança como parte integral, como fazê-la:
Figura adaptada de [6].
Modelo de ameaças
Figura extraída de [8].
Segurança como parte integral, como fazê-la:
Figura adaptada de [6].
Segurança como parte integral, como fazê-la:
Figura adaptada de [6].
Revisão de código• Detecção de código vulnerável:
SELECT * FROM usuarios WHERE login = '" + user.getLogin() + "'
Segurança como parte integral, como fazê-la:
Figura adaptada de [6].
Segurança como parte integral, como fazê-la:
Figura adaptada de [6].
Operações de segurança
• Instalação segura (permissões);
• Um Software nunca deve reduzir a segurança de um ambiente.
• Registre e gerencie Logs do sistema.
• Tenha um plano de resposta aos incidentes.
Deve ser um processo recursivo
Agenda
• Continua mesmo?
• Problemas, problemas, problemas ...
• O que fazer para mudar?
• Conclusões.
Conclusões
The Rugged Manifesto
The Rugged ManifestoEu sou robusto e, mais importante, o meu código é robusto.
Eu reconheço que o software se tornou uma fundação de nosso mundo moderno.
Eu reconheço a enorme responsabilidade que vem com este papel fundamental.
Eu reconheço que meu código será usado de maneiras que eu não posso prever, de
forma que não foi concebido, e por mais tempo do que jamais foi destinado. Eu
reconheço que meu código será atacado por adversários talentosos e persistentes
que ameaçam a nossa segurança física, econômica e nacional.
Eu reconheço essas coisas - e eu escolhi ser robusto.
Eu sou robusto porque me recuso a ser uma fonte de vulnerabilidades ou
fraqueza. Eu sou robusto porque eu garanto que meu código irá suportar sua
missão.
Eu sou robusto porque o meu código pode enfrentar esses desafios e persistir
apesar deles.
Eu sou robusto, não porque é fácil, mas porque é necessário e estou pronto para o
desafio.
Referências
[1] National Vulnerability Database - Statistics. Disponível em: <https://web.nvd.nist.gov/view/vuln/statistics>. Acesso em: 08 de outubro de 2015
[2] Lemos, R. Market For Vulnerability Information Grows. Information Security Magazine. 2012.
[3] The NSA hacks other countries by buying millions of dollars’ worth of computer vulnerabilities. Disponível em: <http://www.washingtonpost.com/blogs/the-switch/wp/2013/08/31/the-nsa-hacks-other-countries-by-buying-millions-of-dollars-worth-of-computer-vulnerabilities/>. Acesso em: 29 de janeiro de 2015.
[4] Frei, S. The Known Unknowns - Empirical Analysis Of Publicly Unknown Security Vulnerabilities. NSS Labs. 2013.
Referências
[5] Brooks, F.P., Jr., "No Silver Bullet Essence and Accidents of Software Engineering," in Computer , vol.20, no.4, pp.10-19, April 1987. doi: 10.1109/MC.1987.1663532.
[6] McGraw, G. Software Security: Building Security. 1 ed. Addison-Wesley. ISBN-13: 978-0321356703. 2006.
[7] OWASP. Application Threat Modeling. Disponível em: <https://www.owasp.org/index.php/Application_Threat_Modeling>. Acesso em: 08 de outubro de 2015.
[8] Microsoft - SolutionAccelerators. IT Infrastructure Threat Modeling Guide. 2009.
@viniciusofer
Vinicius Oliveira Ferreira