Gestão de Patches e Vulnerabilidades

Gestão de Patches e Vulnerabilidades
Marcelo Martins
linkedin.com/in/marcelomartins

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

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

§  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

§  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

Vulnerabilidades
Ameaças
(agentes)
Controles
Risco
Ativos
Impactoexploram reduzem
potencializam o Risco
e causam Impacto
afetam
mitigam
estão presentes são implantados

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

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

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

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

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

Monitorar vulnerabilidades
§  Algumas ferramentas (entre muitas)

§  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

§  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

Estabelecer prioridades
Probabilidad
e
Severidade

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

Risco
Aceitável
Risco
Controlável
Risco
Inaceitável

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

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

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

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

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

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

Implantar correçãoReduziroRisco
• 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.
TransferiroRisco
• 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.
AceitaroRisco
• 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.

§  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)

§  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

§  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

§  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

§  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

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)

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

§  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

§  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

§  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

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

§  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

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

§  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

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

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.

Gestão de Patches e Vulnerabilidades

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Gestão de Patches e Vulnerabilidades

Semelhante a Gestão de Patches e Vulnerabilidades (20)

Gestão de Patches e Vulnerabilidades