Apresentação realizada no FLISOL 2016 em São Caetano do Sul, SP - Brasil

1. Segurança de Software
FLISOL 2016
São Caetano do Sul, Brasil

2. Agenda
• Sobre mim
• Brechas de segurança acontecem o tempo todo
• Informação vale o seu peso em ouro!
• A Segurança da Informação em números
• Há algum tempo atrás
• ...e então surgiu a Internet...
• ...e as empresas decidiram usá-la.
• Moral da estória
• Software tornou-se o elo mais fraco da corrente
• Os desafios da segurança de software
• Segurança no SDLC
• Dúvidas
Imagem da capa: https://mamasuburbs.wordpress.com/2013/03/25/castello-di-amorosa-a-castle-in-calistoga-ca/

3. Sobre mim
Alexandre Siqueira
• Graduado em Ciências da Computação pela UMESP
• Arquiteto de software na CA Technologies
• Especializado em segurança de software
Twitter: @alex_siqueira
LinkedIn: br.linkedin.com/in/siqueiraalexandre
Site: http://alexandre.siqueira.me

5. Brechas de segurança acontecem o tempo todo
Data: abril/2011
Empresa: Sony
Fato: Dados de mais de 70 milhões de clientes da
Playstation Network foram roubados por hackers.
Nomes, endereços, e-mails, nomes de usuários,
senhas e dados de cartão de crédito foram
acessados.
Causa: Especula-se que uma vulnerabilidade em
uma aplicação, provavelmente exposta através de
uma atualização de firmware, possa ter permitido o
acesso a um dos principais bancos de dados da
PSN. Essa causa nunca foi oficialmente confirmada.
Perda estimada: US$ 200 milhões em perdas
financeiras, além da indisponibilidade do serviço da
PSN por mais de 30 dias. As perdas de reputação
são incalculáveis,
Fonte: http://www.cnet.com/news/sony-personal-info-compromised-on-psn

6. Brechas de segurança acontecem o tempo todo
Data: novembro/2013
Empresa: Target
Fato: 40 milhões de números de cartão de crédito
foram obtidos dos terminais de pagamento das lojas
físicas da Target nos Estados Unidos.
Causa: As investigações mostraram que os hackers
utilizaram as credenciais de um funcionário da loja
para obter acesso à rede e instalar o malware
responsável pela captura dos cartões..
Perda estimada: Foram contabilizados US$ 148
milhões em perdas financeiras até o momento. A
perda de confiança dos clientes com o ocorrido
parece ser a causa da redução de vendas nas lojas
da Target nos últimos anos.
Fonte: http://www.bloomberg.com/news/articles/2014-03-13/target-missed-warnings-in-epic-hack-of-credit-card-data

7. Brechas de segurança acontecem o tempo todo
Data: setembro/2014
Empresa: Apple
Fato: Hackers obtém acesso a fotos pessoais de
pelo menos 100 celebridades através de suas contas
do iCloud. Essas fotos, em sua maioria nus, foram
publicadas na internet em um episódio que ficou
conhecido como “The Fappening”.
Causa: Ainda sob investigação, informações
preliminares apontam para uma vulnerabilidade no
serviço de autenticação do serviço “Find my iPhone”
disponível no iCloud.
Perda estimada: Ainda não foi mensurada. Os
danos à imagem e à reputação da empresa e das
pessoas envolvidas é notável.
Fonte: http://www.scmagazine.com/fbi-apple-investigate-celebrity-photo-hacking-incident/article/369340

8. Informação vale o seu peso em ouro!
• Empresas oferecem ferramentas, serviços, espaço
para armazenamento, conteúdo multimídia, apps
para celular e muitas outras facilidades aos seus
usuários em troca de seus dados pessoais e
comportamentais.
• Governos obtém informações pessoais de seus
cidadãos, muitas vezes de forma ilegal, para
investigar indivíduos suspeitos por crimes e
associação ao terrorismo.
• Numa sociedade onde, cada vez mais, a privacidade
é um artigo de luxo, a informação é o bem mais
valioso.
Fonte: http://www.cioturk.com/wp-content/uploads/2013/04/i-want-you-to-archive-your-data.jpg
I WANT YOUR
DATA

9. A Segurança da Informação em números
O relatório “2014 Neustar’s annual DDoS Attacks and Impact
Report” aponta:
• 60% das empresas americanas foram alvo de ataques de
DDoS. Dessas, 87% foram atacadas mais de uma vez no
período.
• para 40% das empresas atacadas, o custo estimado dos
ataques ultrapassou US$ 1 milhão / dia.
De acordo com o paper “The Continued rise of DDoS attacks”
da Symantec:
• As motivações para ataques DDoS são: extorsão,
distração, hacktivismo, disputas e efeitos colaterais.
Fonte: http://www-03.ibm.com/security/data-breach/
http://neustar.biz/resources/whitepapers/ddos-protection/2014-annual-ddos-attacks-and-impact-report.pdf
http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/the-continued-rise-of-ddos-attacks.pdf

10. A Segurança da Informação em números
Segundo o “2015 Cost of Data Breach Study” da Ponemon Institute
e IBM:
• o custo médio pago por registros perdidos ou roubados em
incidentes de segurança é de US$ 154 (aumento de 6% em
relação a 2014).
• as causas das brechas de segurança são:
• 47% causados por ataques maliciosos ou criminosos
• 29% causados por falhas de sistema
• 25% causados por falhas humanas (engenharia social)
• Dos 11 países avaliados pelo estudo, Brasil e França são os
países cuja probabilidade de brechas graves de segurança é
maior: para ambos, as chances ultrapassam 35%.
Fonte: http://www-03.ibm.com/security/data-breach/
http://neustar.biz/resources/whitepapers/ddos-protection/2014-annual-ddos-attacks-and-impact-report.pdf
http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/the-continued-rise-of-ddos-attacks.pdf

11. Há algum tempo atrás...
• Segurança da informação se resumia a manter os “caras maus” longe da sua rede.
• Aplicava-se a defesa do perímetro como estratégia de segurança
• Firewalls impediam acessos indesejados
• Zonas desmilitarizadas segregavam redes com equipamentos para acesso público de computadores restritos
• Esse modelo impede acessos ilegítimos a recursos sensíveis da organização.
Fonte: http://www.balettie.com/zenphoto/albums/vacation-photos/england-2006/18-july-2006-warwick-castle/Warwick Castle (5).jpg

12. ...e então surgiu a Internet...
• Em meados de 1980, com a interligação das redes ARPANET e NSFNET e a adoção do TCP/IP
como protocolo de comunicação, forma-se o backbone central do que seria conhecido como
Internet.
• ARPANET: Advanced Research Projects Agency Network
• NSFNET: National Science Foundation Network
• O principal objetivo da Internet na época era facilitar o acesso às pesquisas conduzidas por
universidades, agências do governo americano e institutos de pesquisa entre si.
• Diversas redes ao redor do mundo passaram a se conectar à Internet, a medida que novos
protocolos de comunicação surgiram, dando à Internet muitas das funcionalidades que conhecemos
hoje:
• SMTP – e-mail
• FTP – transferência de arquivos
• HTTP – hipertexto, que permitiu o surgimento da World Wide Web
Fonte: https://en.wikipedia.org/wiki/History_of_the_Internet

13. ...e as empresas decidiram usá-la.
• Organizações passaram a oferecer serviços aos seus clientes
através da Internet.
• lojas online
• internet banking
• leilões
• streaming de mídia
• redes sociais
• Informações sensíveis passaram a ser disponibilizadas para
pessoas através de web sites e aplicativos.
Fonte: https://en.wikipedia.org/wiki/History_of_the_Internet
http://img.thesun.co.uk/aidemitlum/archive/02008/SNF2726E---610_2008716a.jpg

14. Moral da estória
Construímos soluções de tecnologia que se tornaram essenciais para a vida das pessoas...
• baseadas em uma infraestrutura de rede concebida para facilitar o livre acesso à informação,
• utilizando protocolos de comunicação que não foram projetados para controlar processos
transacionais,
• abrindo canais de acesso à informações críticas de pessoas e organizações e
• cujos controles de segurança estão sob responsabilidade do software.
Qual é a moral da estória?

15. Software tornou-se o elo mais fraco da corrente
Nos últimos anos, a maioria dos incidentes de segurança relatados possuem ao menos um aspecto em
comum: foram ataques que explorava alguma vulnerabilidade na camada de software.
O resultado da análise desses incidentes apontou para uma das seguintes causas:
• falhas de design do software.
• problemas de codificação.
• configuração e operação incorreta.
Fonte: PAUL, Mano – Oficial (ISC)2 Guide to the CSSLP – pag. 247-248

16. Os desafios da segurança de software
O desenvolvimento de software é uma atividade intimamente ligada às restrições do “triângulo de
ferro”.
Num cenário onde os recursos do “triângulo de ferro são rigidamente definidos, normalmente não há
margem para incorporar os requisitos básicos de segurança.
Na verdade, os requisitos de segurança e testes de software costumam ser os primeiros a serem
“postergados” para a próxima versão.
Fonte: PAUL, Mano – Oficial (ISC)2 Guide to the CSSLP – pag. 3-4
Escopo
Orçamento Tempo

17. Os desafios da segurança de software
A incorporação de controles de segurança afetam a usabilidade e
performance dos sistemas.
• Mecanismos de autenticação podem exigir senhas de 15 caracteres,
devendo conter caracteres maiúsculos, minúsculos, números e símbolos,
devendo ser trocadas a cada trinta dias!
• Consultas podem exigir a digitação de caracteres que só podem ser
identificados por pessoas (captchas)!
• O software demora para processar requisições, pois todas as ações
precisam ser armazenadas nas trilhas de auditoria e logs de acesso!
Fonte: PAUL, Mano – Oficial (ISC)2 Guide to the CSSLP – pag. 5
http://thejeshgn.com/2007/07/26/just-to-prove-you-a-human/

18. Os desafios da segurança de software
Enquete:
Quantos de vocês tiveram alguma matéria na graduação relacionada a Segurança da Informação
Pois é...
Fonte: PAUL, Mano – Oficial (ISC)2 Guide to the CSSLP – pag. 5

19. Os desafios da segurança de software
Existe a expectativa de que os desenvolvedores de software escreverão seus códigos e que estes serão
seguros por natureza. É como se a segurança fosse algo inerente ao processo de desenvolvimento de
software.
Mas construir software seguro exige ação consciente e nossos desenvolvedores não são treinados para
isso.
Pior, muitas vezes são ensinados a fazer errado:
<c:if teste=“${param.sayHello}”>
<!-- Let’s welcome the user ${param.name} -->
Hello ${param.name}!
</c:if>
Fonte: SCHUTTA, Nathaniel / ASLESON, Ryan – Foundations of Ajax
http://www.cnet.com/news/the-security-risk-in-web-2-0
“We never intended the code that’s in there to actually be
production-ready code.” – Ryan Asleson

20. Segurança no SDLC - Conceitos
Fonte: PAUL, Mano – Oficial (ISC)2 Guide to the CSSLP – pag. 7
Security Profile
Availability
Auditing
Configuration
management
Defense in depth
Complete mediation
Psychological
acceptability
Single point of failure
Integrity
Authorization
Error and exception
handling
Separation of duties
Economy of
mechanism
Least common
mechanisms
Weakest link
Confidentiality
Authentication
Session management
Least privilege
Fail secure
Open design
Leveragin existing
components
Core
General
Design

21. Segurança no SDLC - Requisitos
Fonte: PAUL, Mano – Oficial (ISC)2 Guide to the CSSLP – pag. 247-248
Durante a fase de levantamento de requisitos:
• Classificação de dados: nem todos os dados exigem o mesmo nível de proteção.
• Confidencialidade – Público, Confidencial, Restrito
• Integridade – Baixo, Médio, Alto
• Disponibilidade – Suporte, Essencial, Crítico
• Modelagem de casos de abuso:
• Complementar aos casos de uso, apoiam na identificação de requisitos de segurança a partir da modelagem de comportamento não
intencionais do sistema.

22. Segurança no SDLC - Design
Fonte: PAUL, Mano – Oficial (ISC)2 Guide to the CSSLP – pag. 177-178
Durante a fase de design, o principal objetivo é identificar falhas de software:
• Modelagem de ameaças:
• Através da perspectiva de um atacante ou usuário hostil, identificar pontos de entrada ou saída que podem ser explorados.
• Priorizar os pontos mais críticos
Definição
• Identificar os bens e objetivos a serem protegidos
• Mapear a aplicação
Modelagem
• Decompor a aplicação
• Identificar ameaças e vulnerabilidades
Ações
• Documentar as ameaças
• Priorizar as ameaças

23. Segurança no SDLC - Desenvolvimento
Fonte: HOWARD, Michael / LEBLANC, David / VIEGA, John – 19 Deadly Sins of Software Security – Foreword
“Ninety-five percent of software bugs are caused by the same 19 programming flaws”
Amit Yoran, Former Director of the Department of Homeland Security’s National Cybersecurity Division
• A pedido da Divisão de Cibersegurança do Departamento de Segurança Doméstica dos EUA, foi
compilada uma lista dos erros mais comuns cometidos por desenvolvedores de software.
• Essa lista foi a base do livro “19 Deadly Sins of Software Security”, publicado em 2005
• Na mesma época, surgiram:
• OWASP Top 10
• CWE/SANS Top 25 List of the most dangerous programing erros.
• Todas as publicações convergem para os mesmos erros, trazendo códigos de exemplo,
explicações detalhadas dos ataques e como identificar e corrigir as falhas no código.

24. Segurança no SDLC - Desenvolvimento
Fonte: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
OWASP Top 10 – 2015 Edition:
• A1 Injection
• A2 Broken Authentication and Session Management
• A3 Cross-Site Scripting (XSS)
• A4 Insecure Direct Object References
• A5 Security Misconfiguration
• A6 Sensitive Data Exposure
• A7 Missing Function Level Access Control
• A8 Cross-Site Request Forgery (CSRF)
• A9 Using Components with Known Vulnerabilities
• A10 Unvalidated Redirects and Forwards

25. Segurança no SDLC - Testes
Fonte: PAUL, Mano – Oficial (ISC)2 Guide to the CSSLP – pag. 325
Hierarquia de testes de qualidade de software:
QA Testing
Reliability
(functional)
Unit
Integration
Logic
Regression
Recoverability
Performance
Load
Stress
Scalability
Resilience
White box
Black box
Other
Environment
Privacy
User
acceptance

26. Segurança no SDLC - Produção
Fonte: PAUL, Mano – Oficial (ISC)2 Guide to the CSSLP – pag. 422
Gestão de incidentes:
• Garantir a existência de protocolos e passos a seguir caso surja uma brecha de segurança.
• Implementar o processo de ciclo de vida de um incidente de segurança:
1 – Preparação
2 – Detecção e
análise
3 – Contenção,
erradicação e
recuperação
4 – Atividades
pós-incidente

27. Segurança no SDLC - Produção
Fonte: PAUL, Mano – Oficial (ISC)2 Guide to the CSSLP – pag. 435
Processo de descarte
• São uma série de atividades técnicas e de negócio que, quando completos, asseguram que os
artefatos podem ser descartados.
• Dados
• Mídia
• Código-fonte
• Documentos
• Hardware

28. Considerações finais
Fonte: PAUL, Mano – Oficial (ISC)2 Guide to the CSSLP – pag. 435
• Os mecanismos tradicionais de proteção empregados pelos times de Segurança da informação
são fundamentais no combate a brechas de segurança.
• No entanto, quando falamos em segurança de software, esses mecanismos oferecem pouco
resultado.
• Nesses cenários, a melhor linha de defesa contra brechas de segurança é a segurança
praticada por não-especialistas:
• Desenvolvedores
• Analistas funcionais
• Testers
• Operadores

29. Dúvidas?