neste artigo escrito por um fornecedor de uma solução de monitoramento de segurança, o principal argumento (muitas vezes ecoado em outras publicações e várias feiras) era que remendar sistemas OT é difícil. O autor argumenta que, como é difícil, devemos recorrer a outros métodos para melhorar a segurança. Sua teoria é ativar uma tecnologia de alerta como a dele e emparelhar os alarmes pendentes com uma equipe de resposta a incidentes de segurança. Em outras palavras, apenas aceitar remendar é difícil, desistir e despejar mais dinheiro para aprender mais cedo (talvez?) e respondendo mais vigorosamente.
no entanto, esta conclusão (remendar é difícil, então não se preocupe) está com defeito por alguns motivos. Sem mencionar que ele também encobre um fator muito grande que complica significativamente qualquer resposta ou remediação que deva ser considerada.
a primeira razão pela qual este é um conselho perigoso é que você simplesmente não pode ignorar o patch. Você deve fazer o que puder, quando puder, e quando remendar não é uma opção, você se move para o plano B, C E D. Não fazer nada significa que todos e quaisquer incidentes cibernéticos que cheguem ao seu ambiente produzirão o máximo de danos. Isso soa muito como a defesa m&m de 20 anos atrás. Esta é a ideia de que sua solução de segurança deve ser dura e crocante por fora, mas macia e mastigável por dentro.
a segunda razão pela qual este conselho está com defeito é a suposição de que a equipe de segurança do OT (para resposta a incidentes ou patches) é fácil de encontrar e implantar! Isso não é verdade-na verdade, um dos incidentes de segurança do ICS mencionados no artigo aponta que, embora um patch estivesse disponível e pronto para instalação, não havia especialistas do ICS disponíveis para supervisionar a instalação do patch! Se não podemos liberar nossos especialistas em segurança para implantar proteção conhecida antes do evento como parte de um programa proativo de gerenciamento de patches, por que achamos que podemos encontrar o orçamento para uma equipe completa de resposta a incidentes após o fato de que é tarde demais?
finalmente, a peça que falta neste argumento é que os desafios para o gerenciamento de patches OT/ICS são ainda mais exacerbados pela quantidade e complexidade de ativos e arquitetura em uma rede OT. Para ser claro, quando um novo patch ou vulnerabilidade é liberado, a capacidade da maioria das organizações de entender quantos ativos estão em escopo e Onde Estão é um desafio. Mas esse mesmo nível de percepção e perfis de ativos será exigido de qualquer equipe de resposta a incidentes para ser eficaz. Mesmo seu conselho para ignorar a prática de remendar não pode deixar você evitar ter que construir um inventário robusto e contextual (a base para remendar!) como base do seu programa de segurança cibernética OT.
então, o que devemos fazer? Em primeiro lugar, devemos tentar corrigir. Há três coisas que um programa de gerenciamento de patch ICS maduro deve incluir para ter sucesso:
- em tempo Real, contextual de inventário
- Automação de remediação (ambos os arquivos de patch e ad-hoc proteções)
- a Identificação e a aplicação dos controles de compensação
contextual em tempo Real de inventário para o gerenciamento de patch
Mais VT ambientes de usar o scan baseado em aplicação de patch ferramentas como o WSUS/SCCM, que são bastante padrão, mas não demasiado perspicaz para nos mostrar o que os ativos que têm e como eles estão configurados. O que é realmente necessário são perfis de ativos robustos com seu contexto operacional incluído. O que quero dizer com isto? IP do ativo, modelo, sistema operacional, etc. é uma lista muito superficial do que pode estar no escopo do patch mais recente. O que é mais valioso é o contexto operacional, como criticidade de ativos para operações seguras, localização de ativos, proprietário de ativos, etc. para contextualizar adequadamente nosso risco emergente, porque nem todos os ativos de OT são criados iguais. Então, por que não Primeiro proteger os sistemas críticos ou identificar sistemas de teste adequados (que refletem sistemas críticos de campo) e reduzir estrategicamente o risco?
e enquanto estamos construindo esses perfis de ativos, precisamos incluir o máximo de informações possível sobre os ativos além do IP, Endereço Mac e versão do sistema operacional. Informações como software instalado, usuários / Conta, portas, Serviços, configurações de registro, controles de menos privilégios, AV, lista de permissões e status de backup etc. Esses tipos de fontes de informação aumentam significativamente nossa capacidade de priorizar e traçar estratégias com precisão nossas ações quando novos riscos emergem. Quer provas? Dê uma olhada no fluxo de análise usual oferecido abaixo. Onde você obterá os dados para responder às perguntas nas várias etapas? Conhecimento Tribal? Instinto? Por que não dados?
Automatizar a correção para a correção de software
Outro software de aplicação de patches desafio é a implantação e a preparação para implantar patches (ou controles de compensação) para os pontos de extremidade. Uma das tarefas mais demoradas no gerenciamento de patches OT é o trabalho de preparação. Normalmente, inclui a identificação de sistemas de destino, a configuração da implantação do patch, a solução de problemas quando eles falham ou a varredura primeiro, o envio do patch e a nova varredura para determinar o sucesso.
mas e se, por exemplo, na próxima vez que um risco como o BlueKeep aparecer, você puder pré-carregar seus arquivos nos sistemas de destino para se preparar para as próximas etapas? Você e sua equipe de segurança OT menor e mais ágil podem planejar estrategicamente quais sistemas industriais você atualizou o patch para o primeiro, segundo e terceiro com base em vários fatores em seus perfis de ativos robustos, como localização de ativos ou criticidade.
dando um passo adiante, imagine se a tecnologia de gerenciamento de patches não exigisse uma varredura primeiro, mas já tivesse mapeado o patch para ativos no escopo e à medida que você os instalou (remotamente para baixo risco ou pessoalmente para alto risco), essas tarefas verificaram seu sucesso e refletiram esse progresso em seu painel global?
para todos os seus ativos de alto risco que você não pode ou não deseja Corrigir agora, pode criar uma alteração de porta, serviço ou usuário/conta como um controle de compensação ad-hoc. Portanto, para uma vulnerabilidade como o BlueKeep, você pode desativar a área de trabalho remota ou a conta de convidado. Essa abordagem reduz imediata e significativamente o risco atual e também permite mais tempo para se preparar para o eventual patch. Isso me leva às ações de “retrocesso” do que fazer ao remendar não é um controle de compensação de opções.
quais são os controles de compensação?
controles de compensação são simplesmente ações e configurações de segurança que você pode e deve implantar em vez de (ou melhor, bem como) patching. Eles são normalmente implantados proativamente (sempre que possível), mas podem ser implantados em um evento ou como medidas temporárias de proteção, como desativar a área de trabalho remota enquanto você faz o patch para o BlueKeep, que eu expando no estudo de caso no final deste blog.
Identifique e aplique controles de compensação no OT security
os controles de compensação assumem muitas formas da lista de permissões do aplicativo e mantêm o antivírus atualizado. Mas, neste caso, quero me concentrar no gerenciamento de endpoint ICS como um componente-chave de suporte do gerenciamento de patch OT.
os controles de compensação podem e devem ser usados tanto proativa quanto situacionalmente. Não seria surpresa para ninguém no OT cyber security descobrir contas de administração inativas e software desnecessário ou não utilizado instalado em endpoints. Também não é segredo que os princípios de endurecimento do sistema de melhores práticas não são tão universais quanto gostaríamos.
para realmente proteger nossos sistemas de OT, também precisamos endurecer nossos bens valiosos. Um perfil de ativos robusto e em tempo real permite que as organizações industriais eliminem com precisão e eficiência as frutas baixas (ou seja, usuários inativos, software desnecessário e parâmetros de endurecimento do sistema) para reduzir significativamente a superfície de ataque.
no evento infeliz, temos uma ameaça emergente (como BlueKeep) adicionando controles de compensação temporários é factível. Um estudo de caso rápido para destacar meu ponto:
- a vulnerabilidade BlueKeep é liberada.
- a equipe central desativa imediatamente a área de trabalho remota em todos os ativos de campo e a equipe de campo de E-mails que exigem solicitações específicas em uma base sistema a sistema para que o serviço de área de trabalho remota seja ativado durante o período de risco.
- a equipe Central pré-carrega arquivos de patch em todos os ativos no escopo – sem ação, apenas prepare.
- a equipe central se reúne para decidir o plano de ação mais razoável por criticidade de ativos, localização, presença ou ausência de controles de compensação (ou seja, um risco crítico em um ativo de alto impacto que falhou em seu último backup vai para o topo da lista. Um ativo de baixo impacto com lista de permissões em vigor e um bom backup completo recente provavelmente pode esperar).
- o lançamento de patches começa e o progresso é atualizado ao vivo nos relatórios globais.
- quando necessário, os técnicos do OT estão no console supervisionando a implantação do patch.
- o cronograma e a comunicação dessa necessidade são totalmente planejados e priorizados pelos dados utilizados pela equipe central.
é assim que o gerenciamento de patches OT deve ser tratado. E mais e mais organizações estão começando a colocar esse tipo de programa em prática.
seja proativo com controles de compensação
ICS patch management é difícil, Sim, mas simplesmente desistir de tentar também não é uma boa resposta. Com um pouco de previsão, é fácil fornecer as três ferramentas mais poderosas para controles de correção e/ou compensação mais fáceis e eficazes. O Insight mostra o que você tem, como ele está configurado e como é importante para você. Contexto permite priorizar (primeira tentativa de patch-second permite que você saiba como e onde aplicar controles de compensação). A ação permite corrigir, proteger, desviar, etc. Confiar apenas no monitoramento é admitir que você espera fogo e comprar mais Detectores de fumaça pode minimizar os danos. Qual abordagem você acha que sua organização preferiria?