por quê o software continua inseguro (versão extendida)?

Por quê o softwarecontinua inseguro?

Vinícius Oliveira Ferreira

[email protected]

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

Continua mesmo?

Continua mesmo?

Figura extraída de [1].

Um problema não resolvido

Nova sintaxe para o padrão CVE.

• MITRE adota nova sintaxe ao padrão Common Vulnerabilities and Exposures (CVE):

Falhas o suficiente para se construir armas

Crescimento do mercado de vulnerabilidades

• O mercado de vulnerabilidades zero-dayencontra-se em franca expansão;

• Motivado pelo surgimento de um novo mercado -“The Gray Market” [2].


• 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.


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?



• 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.

Priests vs Acolytes

• Historicamente a segurança tem sido regida pelos administradores de rede e servidores. Os desenvolvedores ainda não desempenharam um protagonismo considerável na área.

Segurança de perímetro• Como consequência a segurança foi desenvolvida de acordo

com suas visões e expertise.

• Início do desenvolvimento da segurança de perímetro com o estabelecimento do Firewall, seu desenvolvimento foi catalisado pela disseminação do worm de morris em 1988.

Segurança de perímetro

Como a segurança de perímetro tem falhado?

O que é o perímetro hoje?

Segurança de perímetro• A segurança de perímetro não foi suficiente.

• Os envolvidos com o desenvolvimento de software precisam exercer maior protagonismo na segurança da informação.

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.

Como fazer segurança se não há ninguém no meio?

Ambos os grupos se enxergam equivocadamente

Entendendo o problema

• The Principal-Agent Problem;

• Incentivos conflitantes entre um principal que contrata um agente para desempenhar uma tarefa específica;

• A falta de alinhamento de incentivos é um grande problema em vários ramos da economia;

• Há um claro conflito de incentivos ao tratarmos de segurança e desenvolvimento no contexto atual;

Features...

The Principal-Agent Problem

• Como resolver:

• Alinhando os incentivos dos principais e agentes de modo a se criar complementaridade e não oposição.

• Algumas soluções encontradas:

• Elaboração de contratos mais detalhados;

• Rever as formas de recompensar os agentes;

• Exigência de garantias;

• Meios eficientes de 'monitorar' o desempenho dos agentes.

The Principal-Agent Problem

No contexto “Segurança vsDesenvolvimento”, como podemos alinhar

os incentivos?

Segurança deve ser top-down

• A equipe de desenvolvimento dança conforme a música, quando há uma cultura de segurança estabelecida isso se refletirá nos profissionais e consequentemente nos produtos gerados.

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.

Quando uma mentalidade top-down será implantada?

• Quando essa mentalidade será implantada?

• Quando as corporações entenderem de forma plena os riscos associados a seus produtos/informações.

• Uma exigência de mercado.

• Responsabilidade legal sobre os produtos desenvolvidos e as informações processadas/armazenadas.

Compreendendo os riscos

• Business Justification for Application Security Assessment –OWASP.

• 2015 Cost of Data Breach Study – Ponemon Institute/IBM.

• Damage control: the cost of security breaches it security risks special report series - Kaspersky Lab.

Uma exigência de mercado

• Novos recursos/funcionalidades são mais apelativos, em contrapartida a segurança é quase sempre invisível.

• No entanto, os consumidores sempre esperam estar adquirindo um produto seguro. Por muitos, a segurança é considerada uma premissa básica.

Responsabilidade legal

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.


•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.


• 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?



• 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).

Bill Gates's Trustworthy Computing memo

“So now, when we face a choice between adding features and resolving security issues, we need to choose security.” – Bill Gates, The Trustworthy Computing Memo.

Motivação

• CodeRed – Em 2001 explorou um overflow no MS-ISS server e infectou cerca de 300,000 em 14 horas;

• O prejuízo global foi de USD $2.6 bilhões em Julho e Agosto;

• Estima-se que mais de um milhão dos 5.9 milhões de servidores foram infectados.

Resultado

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.

Segurança como parte integral

Bugs vs Falhas (flaws)

50% 50%

Segurança como parte integral, como fazê-la:

ISO/IEC 27034


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).

Modelo de ameaças


Revisão de código• Detecção de código vulnerável:

Revisão de código

• Detecção de código vulnerável:

SELECT campolist FROM tabela WHERE campo = ‘[email protected]';

SELECT campolist FROM tabela WHERE field = '" + user.getMail() + "';

SELECT campolist FROM tabela WHERE campo = ‘qualquerCoisa' OR 'x'='x';

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?



• 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