Segurança em Aplicações 4. Processo Desenvolvimento Seguro

Apresentação em tema: "Segurança em Aplicações 4. Processo Desenvolvimento Seguro"— Transcrição da apresentação:

1 Segurança em Aplicações 4. Processo Desenvolvimento Seguro
Márcio Aurélio Ribeiro Moreira

2 Cenário atual Volume de ataques Tipos de ataques de 2010
Fonte: Fonte:

3 Quantidade de vulnerabilidades
Por Indústria Por porte Fonte: Fonte:

4 Qualificação dos ataques
Camadas exploradas Tipos de ataques Fonte: Fonte:

5 Impactos gerados pelos ataques
Prejuízos com fraudes Fontes dos ataques Us$2,8M de custos de resposta Us$70M de custos de resposta, sendo Us$406K devido a acesso não autorizado Fonte: CSI/FBI citado por: insider-threat-myth-documentation.html Fonte:

6 Alvos e ferramentas de segurança
Produto: Devemos desenvolver com segurança e Garantir a segurança da aplicação desenvolvida Processo: Para isto precisamos de um processo seguro Pessoas: As pessoas precisam pensar, usar e multiplicar os princípios de segurança Ferramentas & Ambientes: Devem atender as premissas de segurança

7 Processo de desenvolvimento seguro
Princípios: Segurança por projeto O software deve se projetado, arquitetado e implementado para ser resistente aos ataques Segurança por default Considerar o ambiente de produção inseguro Usar privilégios mínimos e só disponibilizar o necessário Segurança no desenvolvimento e produção Ferramentas e guias de segurança devem ser disponibilizados aos usuários finais e administradores da aplicação Comunicações Em caso de descoberta de vulnerabilidades comunicar claramente o cliente quais ações a serem tomadas

8 Ciclo de vida de vulnerabilidades
Fonte: Pascal Meunier, Overview of Secure Programming, 2004,

9 Modelagem de negócio O que fazer? Como fazer?
Identificar diretivas estratégicas de segurança Identificar necessidades de segurança Revisar o processo de negócio sob a ótica da segurança Faça uma modelagem de ameaças e riscos no nível de negócio Classifique os processos de negócio quanto à segurança Como fazer? Acrescentar as atividades acima nas atividades do processo de modelagem

10 Requisitos Os requisitos de segurança e privacidade devem ser definidos e especificados Classifique as informações quanto à segurança Deixe claro o que os casos de uso e os atores podem e não podem fazer em termos de segurança Os papéis e responsabilidades de segurança devem ser especificados A norma internacional ISO/IEC (Common Criteria): É usada para definir os requisitos de uma aplicação Mas, também é utilizada para avaliar a segurança de uma aplicação pronta

11 Common Criteria – Conceitos 1
TOE - Target Of Evaluation: Sistema a ser avaliado PP - Protection Profile: Padrão de segurança (definido pelo mercado) que um tipo de aplicação precisa ter SFR - Security Functional Requirements: Especificação dos requisitos funcionais de segurança ST - Security Target: Propriedades de segurança de cada elemento do TOE avaliado contra os SFR

12 Common Criteria – Conceitos 2
SAR - Security Assurance Requirements: Que medidas tomadas no desenvolvimento e na avaliação para garantir os requisitos de segurança da aplicação EAL – Evaluation Assurance Level: Nível de segurança do ST e do TOE (sistema). Valores de 1 a 7, especificados pelo PP. Padrão ISO: 1 a 4, Exemplo: Windows 2000 (EAL4). Os níveis de 5 a 7 são muito rígidos, normalmente usados por agências de segurança governamental.

13 Como usar a CC no desenvolvimento?
Use padrões (PP) como guia Especifique os requisitos de segurança (SFR) Especifique como garantir a segurança (SAR) Mantenha todos ambientes com no mínimo EAL3 Analise e projete a implementação dos SFR Use boas práticas de programação Teste a implementação dos SFR usando os SAR Gere evidências de aderências à norma Se o TOE for crítico, utilize entidades certificadoras para avaliar a segurança

14 Como usar a CC em aplicações prontas?
Levante o padrão (PP) aplicável Levante os SFR da aplicação e dos ambientes (desenvolvimento e produção) Teste se os SFR foram implementados adequadamente Utilizando os níveis de EAL1 a EAL3 Os níveis superiores requerem testes durante o desenvolvimento Realize testes de penetração e de ataques que forem aplicáveis Verifique as evidências apresentadas dos SAR

15 Referências e exemplos da CC
Common Criteria portal Common Criteria – parte 1 (modelo geral) Common Criteria – parte 2 (funcionalidades) Common Criteria – parte 3 (garantias) Exemplos de uso: Especificação dos Requisitos de Segurança do Lotus Notes da EMPRESA X Protection Profile – Controlled Access - NSA Windows 2000 – Security Target

16 Análise & Projeto Faça a modelagem de ameaças a nível de componentes
(ativo  ameaça  risco) & requisitos  projeto Defina e revise a segurança da arquitetura Crie guias de análise e projeto seguros Crie e use padrões de projeto seguro Camadas, parâmetros fortemente tipados, menor privilégio e minimize as áreas de exposição Documente as áreas de exposição Defina critérios para eliminar vulnerabilidades

17 Implementação Use padrões de codificação e testes
Isto evita a introdução de novas vulnerabilidades Use ferramentas de testes de segurança Existem ferramentas que testam até a entrada de dados inválidos para as APIs e interfaces de rede Use ferramentas de varredura estática de código Algumas ferramentas podem detectar fluxos de código que resultam em vulnerabilidades Faça revisões Treine os desenvolvedores para fazer revisões e eliminar vulnerabilidades

18 Equipe de Implementação
Inclua nos treinamentos os padrões de segurança Faça treinamentos por perfil: gerente de projeto, arquiteto, analista, desenvolvedor, testador, etc. Apoie iniciativas de melhorias de padrões Tenha um especialista em segurança na equipe Disponibilize o conhecimento existente Escrevendo código seguro Modelagem de ameaças Padrões de projeto Guias de melhores práticas

19 Um pequeno descuido  Blaster
Duas linhas de código C no RPCSS (CERT Blaster): while (*pwszTemp != L'\\') *pwszServerName++ = *pwszTemp++; Levaram a: >15 milhões de computadores infectados 3.3M de chamados de suporte em Set/2003 (volume normal relacionado a vírus é de 350K) Muita repercussão negativa “Isto aumentará o nível de frustração ao ponto que várias organizações irão contemplar seriamente alternativas à Microsoft”. Gartner Group “É realmente recomendado ter cautela aqui. Os esforços [de segurança da Microsoft] foram sinceros, mas não estou certo se foram sinceros o suficiente.” Forrester Research Fonte: Microsoft – TechEd José Antonio das Neves Neto

20 Testes Revise código legado Faça testes de segurança nos componentes
Faça testes de segurança da interface com usuário Faça testes de ataque e penetração no sistema How to Break Software Security – Addison Wesley 2003 Faça testes de abuso dos SRF e SAR Faça testes que cubram código novo, código alterado e código antigo Revise o modelo de ameaças (técnicas e negócio) Teste todo o modelo de ameaças Prepare o plano de resposta a ataques

21 Custo de correções de falhas
% Fase Fonte: Research for IBM, publicado por Corsaire Limited em 2004

22 Distribuição Crie baselines de distribuições seguras
Atualize as bases de distribuição somente através de ferramentas seguras Planeje a integridade dos meios físicos Disponibilize chaves hash de verificação Inclua verificações de segurança no ambiente antes de instalar o produto Prepare material orientando o cliente e o usuário sobre procedimentos de segurança

23 Gestão de configuração e mudança
Os elementos de segurança devem ser planejados, validados, verificados e corrigidos durante as mudanças Revisar os requisitos das mudanças em face dos elementos de segurança Garantir atualização da modelagem de ameaças Garantir atualização da implementação dos novos elementos de segurança

24 Gerência de projetos O gerente de projeto deve garantir a segurança durante o desenvolvimento Deve garantir a execução das revisões e dos demais elementos do processo seguro Deve validar os SFR, SAR e outras questões de segurança com o cliente Executar a revisão final de segurança

25 Mercado de Serviços de Diretórios
Ambientes Ambientes livres de ataques Desenvolvimento, testes, homologação e produção Redes, wireless, servidores, acesso remoto, , impressão, atualização de SO, etc. Cuidar da segurança física Planejar os procedimentos de atualização Use: Single Sign-On, políticas de grupos e processos de gestão de usuários e perfis Mercado de Serviços de Diretórios Fonte: Microsoft TechEd 2005

26 Resumo do processo seguro
Modelagem de Negócios Identifique as diretrizes estratégicas de segurança Identifique as necessidades de segurança Revise o processo de negócio sob a ótica de segurança Requisitos Levante os requisitos de segurança e de garantia de segurança Defina os papéis e responsabilidades de segurança Combine os critérios de aceite de segurança Análise & Projeto Analise as ameaças no nível de componentes Defina e revise a arquitetura de segurança Prepare os guias de segurança e treine a equipe Implementação Use padrões seguros de codificação Faça revisões cruzadas Teste a segurança das unidades e de varredura de código Testes Faça testes de segurança Faça testes externos Prepare o plano de resposta a ataques Distribuição & Ambiente Resolva os problemas críticos Crie baslines de distribuições seguras em ambientes seguros Prepare procedimentos de uso e administração seguros Gestão de Projetos, Configuração & Mudanças Faça análise de impacto de segurança das mudanças Garanta a atualização dos artefatos de segurança Avalie as lições aprendidas e refine o processo

27 Fatores críticos de sucesso
Aplicação obrigatória do processo Capacitação dos desenvolvedores Definição das métricas de segurança Estabeleça indicadores, métricas, objetivos e metas Política de segurança Grupo de segurança Especialista em segurança na equipe Execução das revisões (parcial e final)

28 Complexidade x Vulnerabilidades
Fonte: CERT/CC Fonte: Microsoft Webserver market share Apache: 67%, MS-IIS: 25% (Fev/03) Com SSL: Apache: 54%, MS-IIS: 35% (Set/02) Fonte: CGI International

29 Resultados da aplicação do processo
Microsoft Security Bulletin Search: 1 vulnerabilidade no IIS 6 em dois anos 1 vulnerabilidade no SQL 2000 em dois anos Boletins Críticos + Importantes divulgados após lançamento do produto

30 Processos em ascensão Microsoft Oracle IBM SUN
SDL - Secure Development Life Oracle SDP - Secure Development Process Oracle Software Security Assurance Process IBM CLASP - Comprehensive, Lightweight Application Security Process SUN