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...
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].
Um problema não resolvido
Nova sintaxe para o padrão CVE.
• MITRE adota nova sintaxe ao padrão Common
Vulnerabilities and ...
Falhas o suficiente para se construir
armas
Crescimento do mercado de
vulnerabilidades
• O mercado de vulnerabilidades zero-day
encontra-se em franca expansão;
• Moti...
Crescimento do mercado de
vulnerabilidades
• White Market: Programas Bug Bounty (Google, Facebook,
VCP, ZDI e etc).
• Reco...
Crescimento do mercado de
vulnerabilidades
We value the researcher ecosystem, and show that in a
variety of ways, but we d...
Crescimento do mercado de
vulnerabilidades
We value the researcher ecosystem, and show that in a
variety of ways, but we d...
Gray Market:Vulnerabilidades vendidas a
compradores legítimos: governos, empresas de
espionagem e monitoramento e etc.
Gra...
Gray Market
• Os preços geralmente começam em $20.000, podendo
chegar a $200.000 [2].
• Empresas atuantes:VUPEN (França), ReVuln (Malt...
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,...
Até o Mitnick:
Problemas na ascensão do Gray
Market
•Money talks:
• Dados vazados no ataque a
HackingTeam indicaram
negociações com paíse...
Problemas na ascensão do Gray
Market
• Com maiores incentivos mais pesquisadores se envolverão
na pesquisa por vulnerabili...
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. ...
No Silver Bullet para o
desenvolvimento de SW
• O SW é inerentemente complexo [5]
• Algumas propostas para os problemas es...
Priests vs Acolytes
• Historicamente a segurança tem sido regida pelos administradores de
rede e servidores. Os desenvolve...
Segurança de perímetro
• Como consequência a segurança foi desenvolvida de acordo
com suas visões e expertise.
• Início do...
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 pr...
Falta de capacitação em
desenvolvimento seguro
• A maioria dos cursos deTI não abordam segurança em suas
ementas, se abord...
Polarização do conhecimento
• A falta de interdisciplinaridade entre segurança e outros
assuntos fundamentais (e.g. desenv...
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 p...
Features...
Features...
The Principal-Agent Problem
• Como resolver:
• Alinhando os incentivos dos principais e agentes de
modo a se criar complem...
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 esta...
Indisposição para investir
• Segurança custa, para tê-la é preciso investir.
• Sem investimento não se cria nenhuma inicia...
Quando uma mentalidade top-
down será implantada?
• Quando essa mentalidade será implantada?
• Quando as corporações enten...
Compreendendo os riscos
• Business Justification for Application Security Assessment –
OWASP.
• 2015 Cost of Data Breach S...
Uma exigência de mercado
• Novos recursos/funcionalidades são mais apelativos, em
contrapartida a segurança é quase sempre...
Responsabilidade legal
Responsabilidade legal
Corretude vs Segurança
• Atributos de sistemas de Software:
• Corretude: O que o sistema deve fazer;
• Segurança: O que o ...
Corretude vs Segurança
•Sob a ótica da corretude.
• Todos os softwares possuem bugs:
• A correção de todos eles é infactív...
Corretude vs Segurança
•Sob a ótica da segurança.
Um atacante não é um usuário comum
• Enquanto usuários comuns evitam os ...
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 McG...
Bill Gates'sTrustworthy Computing
memo
“So now, when we face a choice between adding
features and resolving security issue...
Motivação
• CodeRed – Em 2001 explorou um overflow no MS-ISS
server e infectou cerca de 300,000 em 14 horas;
• O prejuízo ...
Resultado
Segurança como parte integral
• O que aprendemos: Não há solução mágica, a segurança
precisa ser adicionada integralmente ...
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 risc...
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:
Revisão de código
• Detecção de código vulnerável:
SELECT campolist FROM tabela WHERE campo = ‘jao@mail.net';
SELECT campo...
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.
• Re...
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 ...
Referências
[1] NationalVulnerability Database - Statistics. Disponível em:
<https://web.nvd.nist.gov/view/vuln/statistics...
Referências
[5] Brooks, F.P., Jr., "No Silver Bullet Essence and Accidents of Software Engineering,"
in Computer , vol.20,...
@viniciusofer
Vinicius Oliveira Ferreira
Por quê o software continua inseguro (versão extendida)?
of 81

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

Anos e anos de esforços no desenvolvimento de software, mas nossa percepção sobre a insegurança dos sistemas tem aumentado dia após dia. Será que há fundamento para esta percepção? O software continua mesmo inseguro? Por mais que o software seja complexo por si só, e muitos usam isso como justificativa para o grande número de falhas encontradas, a questão vai muito além disso. Os problemas envolvendo o desenvolvimento de software se estendem desde a falta de capacitação das equipes de desenvolvimento, passa pela péssima integração entre as equipes de segurança e desenvolvimento e culmina com a falta de investimento por parte dos diretores, além de outras questões. Do outro lado vemos a ascensão do mercado de vulnerabilidades acompanhado de um crescente uso de armas cibernéticas na resolução de questões geopolíticas, tudo isso contribuindo para a criação de um ecossistema ainda mais inseguro para os sistemas. Esta palestra tem como objetivo trazer luz sobre estas e outras questões em torno da problemática da segurança (ou falta de) nos sistemas de software. Pretende-se discutir o cenário atual e possíveis caminhos para um futuro melhor e mais seguro para o software.
Published on: Mar 4, 2016
Published in: Software      
Source: www.slideshare.net


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

  • 1. Por quê o software continua inseguro? ViníciusOliveira Ferreira viniciusoliveira@acmesecurity.org
  • 2. 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.
  • 3. Agenda • Continua mesmo? • Problemas, problemas, problemas ... • O que fazer para mudar? • Conclusões
  • 4. Agenda • Continua mesmo? • Problemas, problemas, problemas ... • O que fazer para mudar? • Conclusões
  • 5. Continua mesmo?
  • 6. Continua mesmo?
  • 7. Continua mesmo?
  • 8. Continua mesmo?
  • 9. Continua mesmo?
  • 10. Continua mesmo? Figura extraída de [1].
  • 11. Um problema não resolvido Nova sintaxe para o padrão CVE. • MITRE adota nova sintaxe ao padrão Common Vulnerabilities and Exposures (CVE):
  • 12. Falhas o suficiente para se construir armas
  • 13. 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].
  • 14. 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.
  • 15. 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-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.
  • 16. 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-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.
  • 17. Gray Market:Vulnerabilidades vendidas a compradores legítimos: governos, empresas de espionagem e monitoramento e etc. Gray Market
  • 18. Gray Market
  • 19. • 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
  • 20. 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].
  • 21. Até o Mitnick:
  • 22. 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.
  • 23. 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.
  • 24. Agenda • Continua mesmo? • Problemas, problemas, problemas ... • O que fazer para mudar? • Conclusões
  • 25. 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.
  • 26. 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.
  • 27. 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.
  • 28. 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.
  • 29. Segurança de perímetro
  • 30. Como a segurança de perímetro tem falhado?
  • 31. O que é o perímetro hoje?
  • 32. 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.
  • 33. 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.
  • 34. 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.
  • 35. Como fazer segurança se não há ninguém no meio?
  • 36. Ambos os grupos se enxergam equivocadamente
  • 37. 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;
  • 38. Features...
  • 39. Features...
  • 40. 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.
  • 41. The Principal-Agent Problem No contexto “Segurança vs Desenvolvimento”, como podemos alinhar os incentivos?
  • 42. 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.
  • 43. 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.
  • 44. 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.
  • 45. 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.
  • 46. 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.
  • 47. Responsabilidade legal
  • 48. Responsabilidade legal
  • 49. 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.
  • 50. 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.
  • 51. 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.
  • 52. Agenda • Continua mesmo? • Problemas, problemas, problemas ... • O que fazer para mudar? • Conclusões
  • 53. 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).
  • 54. 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.
  • 55. 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.
  • 56. Resultado
  • 57. 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.
  • 58. Segurança como parte integral Bugs vs Falhas (flaws) 50% 50%
  • 59. Segurança como parte integral, como fazê-la: ISO/IEC 27034
  • 60. Segurança como parte integral, como fazê-la: Figura extraída de [6].
  • 61. Segurança como parte integral, como fazê-la: Figura adaptada de [6].
  • 62. 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).
  • 63. Segurança como parte integral, como fazê-la: Figura adaptada de [6].
  • 64. Figura extraída de [7].
  • 65. Segurança como parte integral, como fazê-la: Figura adaptada de [6].
  • 66. Modelo de ameaças Figura extraída de [8].
  • 67. Segurança como parte integral, como fazê-la: Figura adaptada de [6].
  • 68. Segurança como parte integral, como fazê-la: Figura adaptada de [6].
  • 69. Revisão de código • Detecção de código vulnerável:
  • 70. 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';
  • 71. Segurança como parte integral, como fazê-la: Figura adaptada de [6].
  • 72. Segurança como parte integral, como fazê-la: Figura adaptada de [6].
  • 73. 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.
  • 74. Deve ser um processo recursivo
  • 75. Agenda • Continua mesmo? • Problemas, problemas, problemas ... • O que fazer para mudar? • Conclusões.
  • 76. Conclusões The Rugged Manifesto
  • 77. 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.
  • 78. 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.
  • 79. 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.
  • 80. @viniciusofer Vinicius Oliveira Ferreira

Related Documents