Design Best Pratices SDL

Weber Ress
weber@weberress.com

SDL
 Security Development Lifecycle
 SD3+C
 Security by Design
 Security by Default
 Security in Deployment
 Communications

SDL

 Processo de desenvolvimento clássico
 Processo espiral
 Existência de código executável desde o início do
desenvolvimento

SDL

 Atividades em conjunto com o processo de
desenvolvimento clássico

SDL

 Integração do SDL ao processo de desenvolvimento

SDL - Fases
 Requerimentos
 Design
 Implementação
 Verificação
 Release
 Suporte e Serviço

Requerimentos
 É alocado um Security Advisor para a equipe de
desenvolvimento.
 Ponto focal entre a equipe de desenvolvimento e a
área de segurança.
 Responsável por analisar os requisitos do sistema,
diagramas e schedule, incluindo os no projeto os
requisitos de segurança necessários.

Design
 Arquitetura de Segurança / Design Guidelines
 Documentação da superfície de ataque
 Modelagem de Ameaças (Threat Modeling)

Design
 Arquitetura de Segurança / Design Guidelines
 Definição da estrutura geral do software na
perspectiva da segurança.
 Identificação e padronização de técnicas de design
seguro como layering (camadas), uso de linguagem
com tipagem forte, uso de mínimos privilégios no
sistema operacional, etc.
 Security Patterns

Design
 Documentação da superfície de ataque
 Documentar as interfaces que são suscetíveis a
ataques.
 Apenas expor as funcionalidades do software que
são necessárias para a maioria dos usuários;
Não expor TODAS as funcionalidades.
 Reduzir a quantidade de funcionalidades
expostas aos usuários reduz a superfície de
ataque.

Design
 Identificar através de diagramas de componentes as
ameaças a cada componente e interface do sistema.
 Identificar no diagrama de componentes as
ameaças
 Identificar e analisar os riscos
 Identificar formas de mitigar os riscos
encontrados.
 Application Threat Modeling

Implementação
 Padrões de codificação seguro
 Padrões para testes de segurança
 Ferramentas para testes
 Fuzzing Tools (validação de INPUT de dados p/
API’s, interfaces e componentes)
 Scanning de código estático (busca de buffer
overflow, estouro de inteiros, variáveis não-
inicializadas)
 Code Review

Verificação
 O software encontra-se em versão beta.
 Security Push
 Treinamento
 Analisar a fase de implementação.
 Corrigir os erros encontrados.
 Processo cíclico, de acordo com o cronograma de
desenvolvimento (build’s beta)

Release
• “Do ponto de vista da segurança, este software está
pronto para ser entregue ao cliente ?”
• Análise de segurança por uma equipe neutra.
• Encontrar as últimas vulnerabilidades presentes no
software.
• Corrigir as vulnerabilidades / assumir os riscos

Suporte e Serviço
 “Não é possível desenvolver um software 100%
seguro”
 Uma problema de segurança SERÁ encontrado
após o software ter sido entregue ao cliente.
 Transparência
 Elaborar um processo de resposta a incidentes
 Blogs, boletim de segurança, patchs, service
packs

Resultados
 Inovação x Segurança
 Mais recursos = Mais código = Mais erros
SLOC = Source Lines of Code
 1993 - Windows NT 3.1 – 6 milhões
 2000 - Windows 2000 – 29 milhões
 2001 - Windows XP -40 milhões
 2005 - Windows Vista Beta 2 – 50 milhões
 Windows 2000: Novo paradigma (Internet Full)
 Maior Uso = Maior grau de exposição = Maior
Superfície de Ataque

Resultados - Desktop
Bugs críticos de Segurança x
Boletim de Segurança

35 35
22 21
18

Professional Service Pack 1 Service Pack 2

Fonte: Microsoft Security Bulletin Search

Resultados - Servidores
Boletins de criticidade Importante e Crítico,
após lançamento do produto

Fonte: Microsoft Security Bulletin Search

Security Development
Lifecycle
 Processo viável de ser integrado a um processo de
desenvolvimento existente.
 Considerar a segurança como parte do projeto do
software, não como uma premissa a ser cumprida
posteriormente.
 Facilmente adaptável para exigências regulatórias de
segurança em software (SOX, PCI).

Fase 0 – Educação e Consciência
 Desenvolver com segurança envolve conhecimento
específico e consciência

 Nivelamento do conhecimento na equipe.

 Aprofundamento em demandas específicas

 Curso anual de segurança em desenvolvimento
 Sugestão de conteúdo:
 Visão geral sobre o Trustworthy Computing
(Computação Confiável)
 Introdução ao SDL
 Conceitos básicos de Design Seguro:
 Redução de Superfície de Ataque
 Defesa em Profundidade
 Mínimos Privilégios
 Secure Defaults

 Sugestão de conteúdo:
 Modelagem de Ameaças
 Design voltado para modelo de ameaças
 Codificação para modelo de ameaças

 Testes em um modelo de ameaças

 Introdução a testes Fuzz
 Best Pratices em codificação segura
 Buffer Overflow

 Problemas aritméticos (divisão por zero, dízimas)

 Cross-Site Scripting

 SQL Injection

 Criptografia

Fase 1 – Kick-off
 Determinar se o software que será desenvolvido
será atendido pelo SDL.
 Definir o Security Advisor
 Definir o processo de comunicação entre a equipe
de segurança e a equipe de desenvolvimento
 Validar se o sistema de controle de bugs utilizado
possui campos para bugs de segurança e
privacidade.
 Definir o “BUG BAR”

Fase 2 – Design Best Pratices
 Definir as boas práticas de segurança.
 Embasamento em normas ISO, RFCs e boas
práticas de mercado.
 Complexidade X Segurança
 Software muito complexo apresenta mais problemas
de segurança.
 Manter o projeto do software simples. Código perfeito
é impossível de ser obtido.
 ASA e ASR
 ASA = Attack Surface Analysis
 ASR = Attack Surface Reduction

 ASA - Attack Surface Analysis
 ASR – Attack Surface Reduction
 Definem a redução da exposição de código que seja
acessível por usuários não confiáveis.
 Código = recursos, serviços, funções, etc.
 Redução da quantidade de código que é executado
por default.
 Restringir o escopo de quem pode acessar o código.
 Restringir o escopo do código que identifica quem
pode acessá-lo (perfis).
 Reduzir o privilégio do código

 Script
 a) “Esta funcionalidade é realmente importante ?”
 b) “Quem precisa acessar esta funcionalidade ? De
onde esta funcionalidade será acessada ?”
 c) Reduzir privilégios

Fase 3 – Análise de Risco
 Mapeamento do nível de risco para o software a
partir dos modelos de ameaças
 Alto Risco = Altos Custos de Suporte e
Desenvolvimento
 Risco = Probabilidade X Severidade X Relevância
 Identificar as ameaças ao software
 Determinar os riscos relacionados a cada ameaça.
 Planejar medidas de mitigação para cada risco.

Fase 4 – Relacionamento com
Clientes
 Disponibilizar ferramentas, documentação e melhores
práticas para os clientes.
 Ferramentas úteis para automatização de
configurações de segurança.
 Ex: IIS LockDown, SQL 2005 Surface Analysis
 Documentação clara e transparente sobre os recursos
de segurança e controles.
 Transparência com o cliente.

Fase 5 – Codificação Segura
 Conhecimento sobre como construir um código de
forma segura
 Utilizar a última versão do compilador disponível.
 Utilizar os recursos de segurança presentes no
compilador
 /GS – Checagem contra problemas de buffer
 /NXCOMPAT – Tornar o executável compatível com o DEP
(Data Execution Protection) do Windows 2003.
 Utilizar ferramentas para análise de código-fonte.
 Não utilizar funções banidas
 sscanf_s() no lugar de scanf()

Fase 6 – Testes de Segurança
 Fuzz Testing
 Teste em massa de input de dados mal-formados/mal-
formatados.
 Penetration Test
 Teste com objetivo de obter acesso privilegiado ao software
a partir de um acesso não-privilegiado.

 Foco
 80% do tempo em Fuzz Testing.
 20% em Penetration Test.

Fase 7 – Security Push
 Task-Force para encontrar e resolver os bugs de
segurança antes da entrega do software.

 Somente após a fase de implementação. Produto
completo.

 Não substitui o SDL; faz parte dele.

Fase 8 – Final Security Review
 “Do ponto de vista da segurança, este software está
pronto para ser entregue ao cliente ?”

 Análise de segurança por uma equipe neutra.

 Encontrar as últimas vulnerabilidades presentes no
software.

 Corrigir as vulnerabilidades / assumir os riscos

Fase 9 – Resposta a Incidentes
 Transparência
 Elaborar um processo de resposta a incidentes
 Blogs, boletim de segurança, patchs, service
packs

 “Manter a calma”
 Assumir os erros e aprender com eles.
 Situações de Emergência X Situações Críticas
 Afeta privacidade e/ou disponibilidade ? = Emergência

Design Best Pratices
 Definir as boas práticas de segurança.
 Embasamento em normas ISO, RFCs e boas
práticas de mercado.
 Complexidade X Segurança
 Software muito complexo apresenta mais problemas
de segurança.
 Manter o projeto do software simples. Código perfeito
é impossível de ser obtido.
 ASA e ASR
 ASA = Attack Surface Analysis
 ASR = Attack Surface Reduction

Design Best Pratices
 ASA - Attack Surface Analysis
 ASR – Attack Surface Reduction
 Definem a redução da exposição de código que seja
acessível por usuários não confiáveis.
 Código = recursos, serviços, funções, etc.
 Redução da quantidade de código que é executado
por default.
 Restringir o escopo de quem pode acessar o código.
 Restringir o escopo do código que identifica quem
pode acessá-lo (perfis).
 Reduzir o privilégio do código

Questões de Design
 Arquitetura do Software
 Acesso ao banco de dados
 Armazenamento de credenciais de acesso

Design - Arquitetura
 Objetivo: Proteger a informação, não o sistema.
 O alvo de um atacante é sempre o banco de dados,
não o sistema em si.
 Proteção em camadas, dificultando assim o acesso do
atacante ao banco de dados.

 Client-Server clássico
 Software cliente acessando diretamente banco de dados
 Problemas:

 O banco de dados estará diretamente conectado à rede
da estação cliente.
 Acesso direto ao banco de dados através de Excel.

 Client-Server 3 camadas

 Client-Server 3 camadas
 Software cliente acessa servidor de componentes.
 Servidor de componentes acessa o banco de dados.
 Vantagens:

 Isolamento do banco de dados com relação à rede dos
clientes.
 Reutilização de funções de acesso/negócios,etc
existentes nos componentes.
 Ponto único de manutenção e upgrade de funções.

 Desvantagem:

 A atualização de clientes é muito complexa e trabalhosa.

 Solução Web 2 camadas
 Cliente Web acessa servidor Web.
 Servidor Web acessa banco de dados.
 Problemas:

 O banco de dados estará diretamente conectado à rede
da estação cliente.
 Acesso direto ao banco de dados através de Excel.

 Firewall não resolve todos os problemas.

 Cliente Web acessa servidor Web.
 Servidor Web acessa servidor de componentes.
 Servidor de componentes acessa o banco de dados.
 Vantagens:

 Isolamento do banco de dados com relação à rede dos
clientes.
 Reutilização de funções de acesso/negócios,etc
existentes nos componentes.
 Ponto único de manutenção e upgrade de funções.

 Atualização de clientes é transparente. Aplicação Web.

Design – Banco de Dados
 Acesso claro, sem criptografia
 Acesso seguro, com criptografia (IPSEC, VPN).

 Questões
 O software não consegue garantir o controle de
acesso ao banco de dados ?
 Usar criptografia como controle adicional de acesso.
 Os dados são sensíveis ?
 Usar criptografia no armazenamento dos dados.
 O banco de dados suporta criptografia ?
 Use criptografia !

Design – Credenciais de Acesso
 Credenciais de Acesso
 Onde armazenar ?
 Normalmente é armazenado no próprio código-fonte
do software. Ex: (user=“XXX” ; password=“YYY”);
 O desenvolvedor deve ter acesso posterior às
credenciais de acesso ?
 Troca de senha
 Uso de ambiente de desenvolvimento, com massa de dados
não relevante.
 Avaliar o risco e confiança.

 DPAPI (Data Protection Application Programming Interface)
 Para criptografar uma senha qualquer, é necessário
trabalhar com a senha da chave de criptografia. 2
problemas.
 DPAPI utiliza os recursos de criptografia nativos do sistema
operacional para proteger a credencial de acesso do seu
sistema.
 Armazenamento no Registry.

 Single Sign-on
 Utilizar uma entidade externa para gerenciar o processo de
credenciais de acesso.
 Utilizar algum serviço de diretório, como o Active Directory.

 O controle de acesso é baseado em perfis, que são
atribuídos através de grupos no Active Directory.
 Vantagem: O desenvolvedor NÃO precisa se preocupar em
implementar diversos controles de segurança,
armazenamento de senhas, logs de acesso, etc. Utilizando o
Active Directory, todos estes serviço estão expostos para o
uso.

Design – Conclusão
 Na fase de Design é feita a concepção do software.
 Definir:
 Arquitetura
 Uso de credenciais de acesso

 Com o uso de modelos/patterns/templates, o tempo
de trabalho na fase de Design é baixo.
 O objetivo de implementar segurança na fase de
Design é garantir que o acesso às informações no
banco de dados seja feito somente por entidades
autorizadas.

Design Best Pratices SDL

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (19)

Similaire à Design Best Pratices SDL

Similaire à Design Best Pratices SDL (20)

Design Best Pratices SDL