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

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

2. Cenário atual no Brasil Volume de ataques Tipos de ataques Fonte: Cert.Br - Dados Abr a Jun/2013 Fonte: www.cert.br/stats/incidentes/ 2013: até Jun.

3. Vulnerabilidades mundiais Quantidade x Plataforma Quantidade x Browsers Fonte: Symantec – ISTR 18 - 2013 Fonte: Symantec – ISTR 18 - 2013

4. Vulnerabilidades x causas Quantidade x so móvel Causas dos ataques Fonte: Symantec – ISTR 18 - 2013 Fonte: Symantec – ISTR 18 - 2013

5. Ataques mundiais Por Indústria Por porte Fonte: Symantec – ISTR 18 - 2013 Fonte: www.whitehatsec.com/home/resource/stats.html

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

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

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

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

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

11. Modelagem de negócio • O que 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

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

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

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

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

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

17. Referências e exemplos da CC • Referências: • CommonCriteria portal • CommonCriteria – parte 1 (modelo geral) • CommonCriteria – parte 2 (funcionalidades) • CommonCriteria – parte 3 (garantias) • Exemplos de uso: • Especificação dos Requisitos de Segurança do Lotus Notes da EMPRESA X • ProtectionProfile – Controlled Access - NSA • Windows 2000 – SecurityTarget

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

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

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

21. 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”. GartnerGroup • “É 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.” ForresterResearch • Fonte: • Microsoft – TechEd 2005 - José Antonio das Neves Neto

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

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

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

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

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

27. 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: • SingleSign-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

28. Resumo do processo seguro

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

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

31. 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 + Importantesdivulgados após lançamento do produto

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