Gestão de Patches e Vulnerabilidades

Como criar um processo de gestão de patches e vulnerabilidades e manter a organização segura.

Transcript

1. Gestão de Patches e Vulnerabilidades Marcelo Martins exploitedbunker.com
2. Agenda §  A Importância do Processo §  Relacionamento §  com Gestão de Riscos §  com Teste de Invasão §  Implantando Gestão de Patches e Vulnerabilidades §  Estabelecendo Métricas §  Planejando o Futuro §  Conclusão
3. A Importância do Processo §  Ativos §  1 – Processos (ou subprocessos) e atividades do negócio, por exemplo: §  Processos cuja interrupção, mesmo que parcial, torna impossível cumprir a missão da organização §  Processos que contêm procedimentos secretos ou processos envolvendo tecnologia proprietária §  Processos que, se modificados, podem afetar significativamente o cumprimento da missão da organização §  Processos necessários para que a organização fique em conformidade com requisitos contratuais, legais ou regulatórios Fonte: NBR ISO/IEC 27005:2008 B.1
4. A Importância do Processo §  Ativos §  2 – Informação §  Informação vital para o cumprimento da missão de uma organização ou para o desempenho de seu negócio §  Informação de caráter pessoal, da forma em que é definida nas leis nacionais referentes à privacidade §  Informação estratégica necessária para o alcance dos objetivos determinados pelo direcionamento estratégico §  Informação de alto custo, cuja coleta, armazenamento, processamento e transmissão demanda um longo tempo ou incorre em um alto custo de aquisição Fonte: NBR ISO/IEC 27005:2008 B.1
5. A Importância do Processo §  Vulnerabilidades: São falhas de software ou de configuração que enfraquecem a segurança de um ativo §  Ex: Usadas para ganhar acesso em um sistema §  Controles ou correções §  Patches de software §  Ajustes de configuração §  Remoção do software ou serviço afetado §  Ameaças: Exploram vulnerabilidades e causam dano ao ativo §  Ex: exploit scripts, worms, vírus, rootkits e Trojan horses
6. A Importância do Processo Vulnerabilidades Ameaças (agentes) Controles Risco Ativos Impacto exploram reduzem potencializam o Risco e causam Impacto afetam mitigam estão presentes são implantados
7. A Importância do Processo
8. A Importância do Processo
9. A Importância do Processo
10. A Importância do Processo
11. A Importância do Processo
12. A Importância do Processo
13. A Importância do Processo
14. A Importância do Processo
15. A Importância do Processo Quanto mais usamos… menos precisamos usar… Gestão de Vulnerabilidades Gestão de Mudanças Gestão de Configurações Gestão de Incidentes Gestão de Continuidade de Negócios
16. Agenda §  A Importância do Processo §  Relacionamento §  com Gestão de Riscos §  com Teste de Invasão §  Implantando Gestão de Patches e Vulnerabilidades §  Estabelecendo Métricas §  Planejando o Futuro §  Conclusão
17. Relacionamento Gestão de Riscos Gestão de Segurança da Informação Gestão de Vulnerabilidades
18. Relacionamento Análise de Vulnerabilidades Pre-engagement Interactions Intelligence Gathering Threat Modeling Vulnerability Analysis Reporting Teste de Invasão Pre-engagement Interactions Intelligence Gathering Threat Modeling Vulnerability Analysis Exploitation Post Exploitation Reporting
19. Relacionamento Análise de Vulnerabilidades Geralmente tem o escopo um pouco maior do que o Teste de Invasão Previsível, pois a adm. de redes é informada do uso das ferramentas Pode conter muitos falsos positivos Produz um relatório com recomendações para redução do risco Teste de Invasão Escopo mais reduzido para explorar vetores específicos (serviços ou ativos) Pode ser imprevisível, para testar a equipe de segurança Mais confiável por ter a evidência da invasão (root!) Teste de Invasão = Proof of Concept contra vulnerabilidades Produz um resultado binário: Invadiu ou não invadiu
20. Agenda §  A Importância do Processo §  Relacionamento §  com Gestão de Riscos §  com Teste de Invasão §  Implantando Gestão de Patches e Vulnerabilidades §  Estabelecendo Métricas §  Planejando o Futuro §  Conclusão
21. Implantando Gestão de Patches e Vulnerabilidades Monitorar vulnerabilidades Estabelecer prioridades Gerir conhecimento Testar correção Implantar correção Verificar implantação Melhorar o processo
22. Monitorar vulnerabilidades
23. Monitorar vulnerabilidades §  Algumas ferramentas (entre muitas)
24. Monitorar vulnerabilidades §  Algumas fontes de alertas §  NIST NVD §  nvd.nist.gov §  CVE §  cve.mitre.org §  US-CERT §  us-cert.gov §  CERT.BR §  cert.br §  Site do fabricante e listas de e-mail
25. Monitorar vulnerabilidades §  Definição de Escopo §  Evitar a situação onde a Organização tenha conhecimento de uma vulnerabilidade grave. Se há o conhecimento e a Organização não corrige, não está praticando due diligence §  Se algum incidente estiver relacionado a uma falha conhecida e não corrigida pela Organização, pode levar a uma ação contra danos na Justiça Análise de vulnerabilidade sem correção tem pouco valor Pouca análise e muita correção é melhor do que muita análise e pouca correção
26. Implantando Gestão de Patches e Vulnerabilidades Monitorar vulnerabilidades Estabelecer prioridades Gerir conhecimento Testar correção Implantar correção Verificar implantação Melhorar o processo
27. Estabelecer prioridades Probabilidad e Severidade
28. Estabelecer prioridades Quantificação do Risco Expectativa de Perdas Custo do Controle Fator de Exposição
29. Estabelecer prioridades Risco Aceitável Risco Controlável Risco Inaceitável
30. Estabelecer prioridades Ativos Processo ou Sistema Objetivo de Negócio Faturamento e-Commerce E-mail
31. Estabelecer prioridades
32. Implantando Gestão de Patches e Vulnerabilidades Monitorar vulnerabilidades Estabelecer prioridades Gerir conhecimento Testar correção Implantar correção Verificar implantação Melhorar o processo
33. Gerir conhecimento §  Mantendo um banco de dados §  Bancos de dados mantidos manualmente (knowledge base) devem conter instruções sobre como remover as vulnerabilidades através da instalação de patches ou de workarounds §  Relacionando recursos §  Apesar de a criação do banco de dados ser recomendada, restrições de recursos podem limitar a organização a apenas listar sites ou URLs para cada patch
34. Implantando Gestão de Patches e Vulnerabilidades Monitorar vulnerabilidades Estabelecer prioridades Gerir conhecimento Testar correção Implantar correção Verificar implantação Melhorar o processo
35. Testar correção §  Muitos fabricantes fornecem algum mecanismo de autenticação §  O patch deve ser verificado quanto a sua autenticidade, usando PGP ou certificados digitais §  O antivírus deve ser usado em todos os patches antes da instalação §  Antes disso, deve ser verificado que o antivírus e seu banco de assinaturas estão atualizados §  Patches e modificações de configuração devem ser testados no ambiente de homologação, já que podem trazer resultados inesperados §  Alguns patches são extremamente complicados e afetam grande parte do sistema ao substituir arquivos e alterar configurações de segurança
36. Testar correção §  A capacidade de desinstalação ou “undo” deve ser seriamente considerada §  Ainda assim, mesmo quando essa opção existe, muitas vezes o processo de desinstalação não consegue retornar o sistema ao estado anterior
37. Testar correção Desenvolvimento Homologação Produção
38. Implantando Gestão de Patches e Vulnerabilidades Monitorar vulnerabilidades Estabelecer prioridades Gerir conhecimento Testar correção Implantar correção Verificar implantação Melhorar o processo
39. Implantar correção Tratamento de riscos Modificar o risco Implantar controles Evitar o risco Cancelar a operação Compartilhar o risco Fazer um acordo ou seguro Aceitar o risco Conviver e confiar na sorte
40. Implantar correção Reduzir o Risco • Não existe “risco zero”. • Cancelar a operação evita o risco mas pode não ser a melhor opção. • O objetivo da Organização geralmente é trazer retorno ao acionista, com poucos riscos. Transferir o Risco • Fazer um seguro não transfere o risco. Transfere apenas o risco de perda financeira. • Um plano de saúde não reduz o risco de morte. Muito menos um seguro de vida. • O custo do controle é o custo do seguro. Aceitar o Risco • Pode não ser tão ruim. Depende dos fatores e dos custos. • Um técnico de futebol, por melhor que seja, chega no estádio com cerca de 50/50 de chances de ganhar a partida. • O risco é inerente ao negócio.
41. Implantar correção
42. Implantar correção §  Determinar o significado real da ameaça ou vulnerabilidade e quais sistemas estão vulneráveis ou expostos, com foco nos que são essenciais para a operação §  Determinar os riscos envolvidos em aplicar a correção e se a correção afeta a funcionalidade de outras aplicações ou serviços (também deve ser tratado na Gestão de Mudanças)
43. Implantar correção §  Backups recentes §  Antes de realizar qualquer modificação no ativos é importante garantir que há um backup recente. Assim, qualquer falha na modificação pode ser mais facilmente restaurada §  Muitos ativos §  Aplicar patches em milhares de ativos é um desafio. Soluções automáticas de distribuição de patches (EPM – Enterprise Patch Management) podem ser a resposta
44. Implantar correção §  Atrasar a correção é algo a ser considerado com muito cuidado §  Nível de ameaça §  Ativos acessíveis pela Internet, muitos sistemas a serem corrigidos §  Risco de exploração §  Se a vulnerabilidade é facilmente explorada, a correção (ou patch virtual) deve ser aplicada imediatamente §  Consequências da exploração §  Sistemas críticos ou que contenham informações sensíveis devem ser corrigidos o mais rapidamente possível
45. Implantar correção §  Possíveis problemas §  O agente de instalação pode reduzir a performance ou estabilidade dos sistemas §  Os patches instalados podem causar problemas inesperados com outros softwares §  O usuário pode perder informações quando a aplicação ou agente de EPM reiniciar o sistema para instalar um patch §  O agente do EPM pode ser ele mesmo um risco adicional de segurança §  Um usuário móvel pode ter problemas quando o EPM tentar instalar uma grande quantidade de patches assim que ocorrer o logon
46. Implantar correção §  Determinar a causa-raiz de problemas §  Muitas vulnerabilidades são o resultado de má configuração do sistema e políticas de usuário ou de processos de gestão de mudanças inadequados §  Eliminar a causa-raiz requer melhoria nas políticas e processos usados para provisionar, configurar e alterar sistemas e administrar usuários
47. Implantando Gestão de Patches e Vulnerabilidades Monitorar vulnerabilidades Estabelecer prioridades Gerir conhecimento Testar correção Implantar correção Verificar implantação Melhorar o processo
48. Verificar correção §  Verificar que os arquivos e configurações foram alterados conforme a documentação do fabricante §  Usar um scanner de vulnerabilidades §  Verificar se os patches foram realmente instalados através da revisão dos logs §  Usar procedimentos de exploração para verificar que a vulnerabilidade foi corrigida (penetration test)
49. Implantando Gestão de Patches e Vulnerabilidades Monitorar vulnerabilidades Estabelecer prioridades Gerir conhecimento Testar correção Implantar correção Verificar implantação Melhorar o processo
50. Melhorar o processo §  Treinamento §  Empregar soluções automatizadas para gestão de patches (Enterprise patch management) §  Lições aprendidas §  Falhas de implantação §  Lentidão de processamento e banda §  Permissões de usuário §  Melhor horário
51. Agenda §  A Importância do Processo §  Relacionamento §  com Gestão de Riscos §  com Teste de Invasão §  Implantando Gestão de Patches e Vulnerabilidades §  Estabelecendo Métricas §  Planejando o Futuro §  Conclusão
52. §  Toda organização deve consistentemente medir a efetividade do programa de gestão de vulnerabilidades e aplicar as ações corretivas necessárias §  Sem essa medição, até a mais bem desenhada arquitetura de segurança pode ser suscetível a invasões ou outras violações Estabelecendo Métricas Métrica (Exemplo) Unidade Taxa de vulnerabilidade Vulnerabilidades/Host Taxa de patches não aplicados Patches/Host Taxa de serviços de rede Serviços/Host Tempo de resposta para identificação de vulnerabilidade e patch Tempo Tempo de resposta de patch (ativos críticos) Tempo
53. Agenda §  A Importância do Processo §  Relacionamento §  com Gestão de Riscos §  com Teste de Invasão §  Implantando Gestão de Patches e Vulnerabilidades §  Estabelecendo Métricas §  Planejando o Futuro §  Conclusão
54. §  Agir antes da infecção §  Para qualquer vulnerabilidade que venha a ser explorada por um código malicioso, a monitoração e implantação dos patches custa muito menos do que responder a uma infecção por código malicioso §  Enterprise Patch Management (EPM) §  Como os patches são constantemente lançados, a implantação manual de patches se torna extremamente cara a menos que o ambiente seja composto de apenas alguns pacotes de software (e assim reduzindo o número total de patches necessários) Planejando o processo
55. §  Enterprise patch management §  Empresas médias e grandes devem usar EPM §  Até mesmo empresas pequenas deveriam migrar para alguma solução automatizada §  Implantação manual se torna ineficiente conforme o número de patches cresce e os atacantes desenvolvem código malicioso mais rapidamente §  Apenas ativos com configuração única e appliances devem continuar a ser corrigidos manualmente Planejando o processo
56. Planejando o futuro §  Tipo de EPM §  Há dois tipos principais de EPM §  Que usam agentes §  Que não usam agentes §  Alguns produtos possuem as duas características e permitem que o administrador escolha a mais eficiente para o seu ambiente
57. §  Novas aquisições §  Use produtos menos complicados. Mais código, mais funcionalidades e serviços significam mais bugs, vulnerabilidades e patches §  Se possível atrase a implantação de novas versões principais de sistema operacional e aplicativos até que a experiência de outros usuários possa ser avaliada §  Considere softwares validados por testes independentes. Para ter mais garantias, o código-fonte do software deve ser validado §  Apenas use versões do software que sejam suportadas no momento. Softwares obsoletos tem falhas que podem ser corrigidas apenas em versões atualizadas Planejando o futuro
58. Planejando o futuro §  Padronização §  Uma configuração padrão geralmente inclui o seguinte §  Tipo e modelo dos equipamentos §  Versão de sistema operacional e nível de patch §  A maioria das aplicações instaladas (versões e nível de patch) §  Configurações de segurança para o sistema operacional e aplicações §  Configurações padronizadas podem ser mantidas de forma centralizada e as alterações podem ser propagadas para todos os ativos
59. §  Correção pós-incidente §  Corrigir uma vulnerabilidade após uma violação de segurança é muito mais complicado §  É necessário corrigir a vulnerabilidade que foi explorada §  Isso não eliminará rootkits, backdoors, ou quaisquer outras alterações que possam ter sido feitas pelo atacante §  Por exemplo, a worm Code Red II colocou backdoors em sistemas comprometidos e depois a worm Nimda explorou esses mesmos backdoors §  Um sistema violado deve ser reformatado e reinstalado ou restaurado a partir de um backup seguro e confiável Planejando o futuro
60. Agenda §  A Importância do Processo §  Relacionamento §  com Gestão de Riscos §  com Teste de Invasão §  Implantando Gestão de Patches e Vulnerabilidades §  Estabelecendo Métricas §  Planejando o Futuro §  Conclusão
61. Conclusão §  Deve haver um processo de Gestão de Vulnerabilidades §  Pouca análise e muita correção §  A administração de redes deve se manter informada das vulnerabilidades §  O ambiente deve ser padronizado e documentado §  Modificações no ambiente devem passar pela Gestão de Mudanças §  Qualquer modificação deve ser testada no ambiente de homologação §  Um processo automatizado de instalação de patches pode ter o melhor custo/benefício
62. Referências §  NIST §  SP 800-40 §  Creating a Patch and Vulnerability Management Program §  SP 800-115 §  Technical Guide to Information Security Testing and Assessment §  CVE §  http://measurablesecurity.mitre.org/directory/areas/ vulnerabilitymanagement.html §  ISO/IEC 29147:2014 §  gives guidelines for the disclosure of potential vulnerabilities in products and online services. It details the methods a vendor should use to address issues related to vulnerability disclosure. §  ISO/IEC 30111:2013 §  gives guidelines for how to process and resolve potential vulnerability information in a product or online service.