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@uniminas.br http://si.uniminas.br/~marcio/ Pós-SI – 4ª Turma – 2008

2. 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 Unidade 4 – Processo de Desenvolvimento Seguro – Slide 2

3. Segurança nas corporações • Principais causas de ataques: • Vulnerabilidades no software • Falhas de administração do ambiente • Dados do Zone-h de 11/4/2005 Unidade 4 – Processo de Desenvolvimento Seguro – Slide 3

4. Processo de desenvolvimento seguro • Princípios: • Segurança pelo 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 Unidade 4 – Processo de Desenvolvimento Seguro – Slide 4

5. Ciclo de vida de vulnerabilidades Fonte: Pascal Meunier, Overview of Secure Programming, 2004, http:cerias.purdue.edu Unidade 4 – Processo de Desenvolvimento Seguro – Slide 5

6. 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 Unidade 4 – Processo de Desenvolvimento Seguro – Slide 6

7. 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 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 Unidade 4 – Processo de Desenvolvimento Seguro – Slide 7

8. 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 Unidade 4 – Processo de Desenvolvimento Seguro – Slide 8

9. 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. Unidade 4 – Processo de Desenvolvimento Seguro – Slide 9

10. 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 Unidade 4 – Processo de Desenvolvimento Seguro – Slide 10

11. 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 Unidade 4 – Processo de Desenvolvimento Seguro – Slide 11

12. Referências e exemplos da CC • Referências: • Common Criteria portal • Common Criteria – parte 1 • Common Criteria – parte 2 • Common Criteria – parte 3 • 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 Unidade 4 – Processo de Desenvolvimento Seguro – Slide 12

13. 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 Unidade 4 – Processo de Desenvolvimento Seguro – Slide 13

14. 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 Unidade 4 – Processo de Desenvolvimento Seguro – Slide 14

15. 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. • Apóie 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 Unidade 4 – Processo de Desenvolvimento Seguro – Slide 15

16. Um pequeno descuido  Blaster • Duas linhas de código C no RPCSS: • 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 Unidade 4 – Processo de Desenvolvimento Seguro – Slide 16

17. 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 Unidade 4 – Processo de Desenvolvimento Seguro – Slide 17

18. Custo de correções de falhas % Fase Fonte: Research by @Stake for IBM, publicado por Corsaire Limited em 2004 Unidade 4 – Processo de Desenvolvimento Seguro – Slide 18

19. 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 Unidade 4 – Processo de Desenvolvimento Seguro – Slide 19

20. 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 Unidade 4 – Processo de Desenvolvimento Seguro – Slide 20

21. 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 Unidade 4 – Processo de Desenvolvimento Seguro – Slide 21

22. 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 Unidade 4 – Processo de Desenvolvimento Seguro – Slide 22

23. 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) Unidade 4 – Processo de Desenvolvimento Seguro – Slide 23

24. 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 Unidade 4 – Processo de Desenvolvimento Seguro – Slide 24

25. 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 Unidade 4 – Processo de Desenvolvimento Seguro – Slide 25

26. 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 Unidade 4 – Processo de Desenvolvimento Seguro – Slide 26