TREINAMENTO DE DESENVOLVIMENTO SEGURO

VISÃO GERAL DO CICLO DE DESENVOLVIMENTO SEGURO

Autor: Edson Freire Nepomuceno

• Engenheiro Segurança da Informação Sênior
• Certified Secure Software Lifecycle Professional (CSSLP ® (ISC)²)
• GIAC Cutting Edge Hacking Techniques (GHTQ - SANS)
• Ethical Hacking and Countermeasures (CEH v5)
• Advanced Level Linux Professional (LPIC-2)
• Certified Information Forensics (IISFA)
AGENDA

 Conceitos de Software Seguro

 Requerimentos de Segurança para Software
 Design Seguro de Aplicações
 Implementando Código Seguro
 Testes de verificação
PARTE 1
- CONCEITOS DE SOFTWARE SEGURO
CICLO DE DESENVOLVIMENTO DE SOFTWARE

O ciclo de vida típico do desenvolvimento de software (SDL) contém uma série de práticas. Independentemente da
metodologia, seja ágil ou waterfall, sempre vemos as seguintes quatro "fases":

 Requisitos
 Design
 Implementação
 Testes de verificação

OBS.: Essa generalização foi utilizada como guia para organização do treinamento e também para sua melhor
compreensão.
WATERFALL MODEL

 Assim como a água flui em apenas uma direção em uma cachoeira, uma vez que uma fase no modelo waterfall é
completada, não se pode voltar àquela fase.
 O modelo waterfall em cinco fases genéricas:
1. Iniciação, aquisição
2. Desenvolvimento
3. implementação
4. Avaliação, operações
5. Manutenção e Desativação
 Do ponto de vista da segurança, é importante garantir que os requisitos de segurança façam parte da fase de
requisitos. A incorporação de quaisquer requisitos de segurança perdidos em um momento posterior resultará
em custos adicionais e atrasos no projeto.
AGILE

 Com o objetivo de minimizar as taxas de falhas de projeto de

desenvolvimento de software, desenvolvendo o software em repetições
múltiplas (iterações) e pequenos intervalos de tempo (chamados timeboxes).
FASES DE UM ATAQUE
MOTIVOS, MEIOS E OPORTUNIDADES!
SOFTWARE LIFE CYCLE STAKEHOLDERS
CUSTO DO CYBERCRIME (254 EMPRESAS)
Como a maioria dos incidentes é ocultada, e as vítimas não são susceptíveis de divulgar suas perdas, não
existe uma maneira precisa de dizer o tamanho do dano causado pelo cibercrime realmente.
(Mercuri, 2003)
PRINCIPAIS PROBLEMAS (254 EMPRESAS)
CONCEITOS DE SOFTWARE SEGURO

 É fundamental reconhecer que o software é tão seguro quanto o seu elo

mais fraco. Hoje, o software raramente é implementado como um
aplicativo de negócios autônomo.
 Muitas vezes, é complexo, executado em sistemas host que estão
interligados a vários outros sistemas em uma rede. Uma fraqueza
(vulnerabilidade) em qualquer uma das camadas pode tornar todos os
controles (salvaguardas e contramedidas) inúteis.
 As pessoas geralmente são muito ruins na estimativa de riscos. Nossos
cérebros foram otimizados para tomar decisões rápidas para sobreviver
na savana e não alcançaram o moderno ambiente de TI. Portanto,
tendemos a minimizar certos riscos e a exagerar os outros
(Kahneman, 2002).
CONCEITOS DE SOFTWARE SEGURO

O aplicativo, o host e a rede devem ser

protegidos adequadamente e
apropriadamente.
CONCEITOS DE SOFTWARE SEGURO

Algumas das principais razões pelas quais existe uma prevalência de software inseguro podem ser atribuídas ao
seguinte:

 Restrições do triângulo de ferro

 Segurança como uma reflexão tardia
 Segurança versus usabilidade
CONCEITOS DE SOFTWARE SEGURO
As restrições em cronograma, escopo e orçamento (os componentes do triângulo de ferro, como mostrado na Figura ) são muitas
vezes os motivos pelos quais os requisitos de segurança são deixados de fora do software.
QUANDO ENVOLVER SEGURANÇA NO DESENVOLVIMENTO DE SUA
APLICAÇÃO?
CONCEITOS DE SOFTWARE SEGURO

 A segurança do software deve ser equilibrada com a usabilidade e o

desempenho.
 Um produto de software que seja seguro irá adicionar à qualidade
desse software, mas o inverso nem sempre é necessariamente
verdadeiro.
 Os fornecedores geralmente oferecem a presença de
funcionalidades de segurança em seus produtos para se diferenciar
de seus concorrentes e, embora isso seja verdade, deve ser
entendido que a simples presença de funcionalidades de segurança
no software do fornecedor não o torna seguro. Isso ocorre porque a
funcionalidade de segurança pode não estar configurada para
funcionar em seu ambiente operacional, ou quando for, pode ser
implementada incorretamente.
CONCEITOS DE SOFTWARE SEGURO
PARTE 2
- REQUERIMENTOS DE SEGURANÇA PARA SOFTWARE
REQUERIMENTOS DE SEGURANÇA
DECOMPOSIÇÃO DE POLÍTICAS DE SEGURANÇA
 PCI/DSS - REQUISITO DE SEGURANÇA DE SOFTWARE

 PCI DSS Requirement 6 and Its Subrequirements

6 Develop and maintain secure systems and applications.
6.1 Ensure that all system components and software have the latest vendor-supplied security patches
installed. Install critical security patches within 1 month of release.
6.2 Establish a process to identify newly discovered security vulnerabilities (e.g., alert subscriptions) and
update configuration standards to address new vulnerability issues.
6.3 Develop software applications in accordance with industry best practices (e.g., input validation, secure
error handling, secure authentication, secure cryptography, secure communications, logging, etc.), and
incorporate information security throughout the software development life cycle.
6.4 Follow change control procedures for all changes to system components.
6.5 Develop all Web applications based on secure coding guidelines (such as OWASP) to cover common
coding vulnerabilities in software development.
6.6 For public-facing Web applications, address new threats and vulnerabilities on an ongoing basis and ensure
these applications are protected against known attacks by either reviewing these applications annually or
upon change, using manual or automated security assessment tools or methods, or by installing a Web
application firewall in front of the public-facingWeb application.
CLASSIFICAÇÃO DE INFORMAÇÃO
PARTE 3
- DESIGN SEGURO DE APLICAÇÕES
DESIGN SEGURO DE APLICAÇÕES

▪ As maiores preocupações de segurança na fase de design incluem:

1. Gestão de credencial

2. Gestão de senhas

3. Gestão de certificados

4. Projeto de trilhas de auditoria

5. Bloqueio de recursos

6. Tipo de dado, formato, extensão e cumprimento

7. Segurança do banco de dados

CRIPTOGRAFIA

A criptografia pode ser usada para implementar confidencialidade, integridade, autenticação e

não repúdio, usando diferentes técnicas, como criptografia e assinaturas digitais.
STRIDE
 STRIDE é um modelo de classificação de ameaças desenvolvido pela Microsoft para pensar em ameaças à segurança do
computador.Ele fornece um mnemônico para ameaças de segurança em seis categorias.As categorias de ameaças são:
QUESTIONÁRIO STRIDE
 Spoofing: Um atacante pode representar outro usuário ou identidade?

 Adulteração: Os dados podem ser adulterados enquanto estiverem em trânsito

ou em armazenamento ou arquivos?

 Repúdio: O atacante (usuário ou processo) pode negar o ataque?

 Divulgação de informação: A informação pode ser divulgada a usuários não

autorizados?

 Negação de serviço: A negação de serviço é uma possibilidade?

 Elevação de privilégio: O atacante pode ignorar a implementação de privilégios

mínimos e executar o software em privilégios elevados ou administrativos?
MODELAGEM DE AMEAÇAS

 O processo de modelagem de ameaças:

1. Identificar ativos
2. Criar umaVisão Geral da Arquitetura
3. Decompor o aplicativo
4. Identificar ameaças
5. Documentar as ameaças
6. Avalie as ameaças
MODELAGEM DE AMEÇAS
PARTE 4
- IMPLEMENTANDO CÓDIGO SEGURO
IMPLEMENTANDO CÓDIGO SEGURO
 Os hackers bem-sucedidos hoje são identificados como indivíduos que têm uma
compreensão completa da programação. Portanto, é imperativo que os
desenvolvedores de software que escrevem código também devem ter uma
compreensão completa de como seu código pode ser explorado, para que possam
efetivamente proteger seus softwares e dados.

 Ao escrever código, é importante saber quais construções você deve usar e quais
você deve evitar. Especialmente quando se trabalha com uma equipe, pode
economizar muito tempo se todo mundo na equipe escolher construções de
programação seguras. Geralmente, isso é especificado em um padrão de codificação
seguro. Felizmente, você não precisa escrever esse padrão de codificação a partir do
zero, já que muitos já estão disponíveis para as linguagens de programação mais
comuns.
 THE TEN MOST CRITICAL
WEB APPLICATION SECURITY RISKS

 A1:2017 - Injection
 A2:2017 - Broken Authentication
 A3:2017 - Sensitive Data Exposure
 A4:2017 - XML External Entities (XXE)
 A5:2017 - Broken Access Control
 A6:2017 - Security Misconfiguration
 A7:2017 - Cross-Site Scripting (XSS)
 A8:2017 - Insecure Deserialization
 A9:2017 - Using Components with KnownVulnerabilities
 A10:2017 - Insufficient Logging & Monitoring
 THE TEN MOST CRITICAL
MOBILE APPLICATION SECURITY RISKS

 M1: Weak Server Side Controls

 M2: Insecure Data Storage
 M3: Insufficient Transport Layer Protection
 M4: Unintended Data Leakage
 M5: Poor Authorization and Authentication
 M6: Broken Cryptography
 M7: Client Side Injection
 M8: Security DecisionsVia Untrusted Inputs
 M9: Improper Session Handling
 M10: Lack of Binary Protections
TOP 20 INFORMATION SECURITY CONTROLS
PARTE 5
- TESTES DE VERIFICAÇÃO
DEFEITOS DE SOFTWARE - CATEGORIAS
TESTE DE SOFTWARE
CODE REVIEW

Ao fazer uma revisão, você precisa procurar tudo:

 Comportamento estranho
 Validações de segurança ausentes
 Verificações de segurança já instaladas
 Complexidade
 Diferenças entre 2 funções / métodos / classes.
 Comparação e condições (se / se não)
 Expressões regulares / correspondência de padrões de caracteres

Você provavelmente vai acabar vendo função / classe / método que você não conhece. Para resolver este problema, você precisa

 Google
 Teste seu comportamento
TESTES DE SEGURANÇA PARA SOFTWARE
REFERÊNCIAS TÉCNICAS UTILIZADAS E RECOMENDADAS

URL: https://www.owasp.org
FIM!

 Dúvidas, críticas ou sugestões?