Segurança em Aplicações 4. Processo Desenvolvimento Seguro Márcio Aurélio Ribeiro Moreira marcio.moreira@pitagoras.com.br http://si.lopesgazzani.br/docentes/marcio/

Cenário atual Volume de ataques Tipos de ataques de 2010 Fonte: www.cert.br/stats/incidentes/ Fonte: www.cert.br/stats/incidentes/2010-jan-dec/total.html

Quantidade de vulnerabilidades Por Indústria Por porte Fonte: www.whitehatsec.com/home/resource/stats.html Fonte: www.whitehatsec.com/home/resource/stats.html

Qualificação dos ataques Camadas exploradas Tipos de ataques Fonte: www.sans.org/top-cyber-security-risks/trends.php Fonte: www.whitehatsec.com/home/resource/stats.html

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: http://taosecurity.blogspot.com/2009/05/ insider-threat-myth-documentation.html Fonte: www.nist.org/news.php?extend.254

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

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

Ciclo de vida de vulnerabilidades Fonte: Pascal Meunier, Overview of Secure Programming, 2004, http:cerias.purdue.edu

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

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 15408 (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

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

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.

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

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

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

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

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

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

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 2005 - José Antonio das Neves Neto

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

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

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

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

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

Mercado de Serviços de Diretórios Ambientes Ambientes livres de ataques Desenvolvimento, testes, homologação e produção Redes, wireless, servidores, acesso remoto, e-mail, 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

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

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)

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

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

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