Gestão de Patches e Vulnerabilidades

by Marcelo Martins

Slide 1

Slide 1 text

Gestão de Patches e Vulnerabilidades Marcelo Martins exploitedbunker.com

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

A Importância do Processo

Slide 8

Slide 8 text

A Importância do Processo

Slide 9

Slide 9 text

A Importância do Processo

Slide 10

Slide 10 text

A Importância do Processo

Slide 11

Slide 11 text

A Importância do Processo

Slide 12

Slide 12 text

A Importância do Processo

Slide 13

Slide 13 text

A Importância do Processo

Slide 14

Slide 14 text

A Importância do Processo

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Relacionamento Gestão de Riscos Gestão de Segurança da Informação Gestão de Vulnerabilidades

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

Monitorar vulnerabilidades

Slide 23

Slide 23 text

Monitorar vulnerabilidades §  Algumas ferramentas (entre muitas)

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Estabelecer prioridades Probabilidad e Severidade

Slide 28

Slide 28 text

Estabelecer prioridades Quantificação do Risco Expectativa de Perdas Custo do Controle Fator de Exposição

Slide 29

Slide 29 text

Estabelecer prioridades Risco Aceitável Risco Controlável Risco Inaceitável

Slide 30

Slide 30 text

Estabelecer prioridades Ativos Processo ou Sistema Objetivo de Negócio Faturamento e-Commerce E-mail

Slide 31

Slide 31 text

Estabelecer prioridades

Slide 32

Slide 32 text

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

Testar correção Desenvolvimento Homologação Produção

Slide 38

Slide 38 text

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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.

Slide 41

Slide 41 text

Implantar correção

Slide 42

Slide 42 text

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)

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

Slide 48

Slide 48 text

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)

Slide 49

Slide 49 text

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

Slide 52

Slide 52 text

§  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

Slide 53

Slide 53 text

Slide 54

Slide 54 text

§  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

Slide 55

Slide 55 text

§  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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

§  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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

§  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

Slide 60

Slide 60 text

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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.