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

Por quê o software
continua inseguro?
ViníciusOliveira Ferreira
viniciusoliveira@acmesecurity.org

Sobre o autor
• Vinícius Oliveira Ferreira.
• Pesquisador e analista no LaboratórioACME!
• 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?
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-day
encontra-se em franca expansão;
• Motivado pelo surgimento de um novo mercado -
“The Gray Market” [2].

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.

vulnerabilidades
We value the researcher ecosystem, and show that in a
variety of ways, but we don’t think paying a per-vuln
bounty 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

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

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.

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.

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

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 deTI 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;

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 vs
Desenvolvimento”, 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.

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.

Na verdade já começou
• Writing Secure Code - Michael Howard e David Leblanc
(2001);
• Building Secure Software - Gary McGraw e JohnViega
(2001);
• Bill Gates'sTrustworthy Computing memo (2002).

Bill Gates'sTrustworthy Computing
memo
“So now, when we face a choice between adding
features and resolving security issues, we need to
choose security.” – Bill Gates,TheTrustworthy
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.

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

como fazê-la:

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

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 = ‘jao@mail.net';
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?
• Problemas, problemas, problemas ...
• O que fazer para mudar?
• Conclusões.

Conclusões
The Rugged Manifesto

The Rugged Manifesto
Eu 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] NationalVulnerability Database - Statistics. Disponível em:
<https://web.nvd.nist.gov/view/vuln/statistics>. Acesso em: 08 de outubro de 2015
[2] Lemos, R. Market ForVulnerability 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. ApplicationThreat Modeling. Disponível em:
<https://www.owasp.org/index.php/Application_Threat_Modeling>. Acesso em: 08 de
outubro de 2015.
[8] Microsoft - SolutionAccelerators. IT InfrastructureThreat Modeling Guide. 2009.

@viniciusofer
Vinicius Oliveira Ferreira

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

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (15)

En vedette

En vedette (6)

Similaire à Por quê o software continua inseguro (versão extendida)?

Similaire à Por quê o software continua inseguro (versão extendida)? (20)

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