Weber Ress

Transcrição

1 Weber Ress

2 SDL Security Development Lifecycle SD 3 +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ãoinicializadas) 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 Windows NT milhões Windows NT milhões Windows NT milhões Windows milhões Windows XP -40 milhões 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 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 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/malformatados. 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 SD 3 +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.