O documento descreve o Security Development Lifecycle (SDL), um processo para integrar práticas de segurança no desenvolvimento de software. O SDL inclui fases como requisitos, design, implementação, verificação, lançamento e suporte. Na fase de design, boas práticas como redução da superfície de ataque e análise de riscos são definidas para melhorar a segurança.

1. Weber Ress
weber@weberress.com

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

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

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

5. SDL
 Integração do SDL ao processo de desenvolvimento

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

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

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

9. 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

10. 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.

11. 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

12. 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

13. 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)

14. 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

15. 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

16. 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
 1994 - Windows NT 3.5 – 10 milhões
 1996 - Windows NT 4.0 – 16 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

17. 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

18. Resultados - Servidores
Boletins de criticidade Importante e Crítico,
após lançamento do produto
Fonte: Microsoft Security Bulletin Search

19. 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).

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

21. 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

22. 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

23. 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

24. 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”

25. 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

26. 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

27. 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

28. 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.

29. 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.

30. 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()

31. 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.

32. 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.

33. 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

34. 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

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

36. SDL
 Integração do SDL ao processo de desenvolvimento

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

38. 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

39. 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

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

41. 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.

42. Design - Arquitetura
 Defesa em Profundidade
 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.

43. Design - Arquitetura
 Defesa em Profundidade
 Client-Server 3 camadas

44. Design - Arquitetura
 Defesa em Profundidade
 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.

45. Design - Arquitetura
 Defesa em Profundidade
 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.

46. Design - Arquitetura
 Defesa em Profundidade
 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.

47. 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 !

48. 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.

49. Design – Credenciais de Acesso
 Credenciais de Acesso
 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.

50. Design – Credenciais de Acesso
 Credenciais de Acesso
 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.

51. 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.