Dss 3

432 views
335 views

Published on

segurança

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
432
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Dss 3

  1. 1. Weber Ressweber@weberress.com
  2. 2. SDL Security Development Lifecycle SD3+C  Security by Design  Security by Default  Security in Deployment  Communications
  3. 3. SDL Processo de desenvolvimento clássico Processo espiral Existência de código executável desde o início do desenvolvimento
  4. 4. SDL Atividades em conjunto com o processo de desenvolvimento clássico
  5. 5. SDL Integração do SDL ao processo de desenvolvimento
  6. 6. SDL - Fases Requerimentos Design Implementação Verificação Release Suporte e Serviço
  7. 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. 8. Design Arquitetura de Segurança / Design Guidelines Documentação da superfície de ataque Modelagem de Ameaças (Threat Modeling)
  9. 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. 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. 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. 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. 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. 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. 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. 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. 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. 18. Resultados - ServidoresBoletins de criticidade Importante e Crítico,após lançamento do produto Fonte: Microsoft Security Bulletin Search
  19. 19. Security DevelopmentLifecycle 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. 20. SDL - Fases Requerimentos Design Implementação Verificação Release Suporte e Serviço
  21. 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. 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. 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. 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. 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. 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. 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. 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. 29. Fase 4 – Relacionamento comClientes  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. 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. 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. 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. 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. 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. 35. SDL Security Development Lifecycle SD3+C  Security by Design  Security by Default  Security in Deployment  Communications
  36. 36. SDL Integração do SDL ao processo de desenvolvimento
  37. 37. SDL - Fases Requerimentos Design Implementação Verificação Release Suporte e Serviço
  38. 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. 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. 40. Questões de Design Arquitetura do Software Acesso ao banco de dados Armazenamento de credenciais de acesso
  41. 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. 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. 43. Design - Arquitetura Defesa em Profundidade  Client-Server 3 camadas
  44. 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. 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. 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. 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. 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. 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. 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. 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.

×