Dss 3

Weber Ress

[email protected]

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

22

35

21

35

18

Bugs críticos de Segurança x

Boletim de Segurança

Professional Service Pack 1 Service Pack 2

Fonte: Microsoft Security Bulletin Search

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


Design

Implementação

Verificação

Release

Suporte e Serviço

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

Fase 0 – Educação e Consciência

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

Fase 0 – Educação e Consciência 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

Fase 2 – 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

Fase 2 – Design Best Pratices 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

SDL Security Development Lifecycle

SD3+C

Security by Design

Security by Default

Security in Deployment

Communications

SDL

Integração do SDL ao processo de desenvolvimento


Design

Implementação

Verificação

Release

Suporte e Serviço

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 Defesa em Profundidade

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 ao 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

Acesso ao banco de dados

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.

Documents

Dss 3