Para proteger infraestruturas críticas contra invasores, a abordagem recomendada é a de pensar como eles. Ativos de Tecnologia Operacional (TO) vulneráveis são uma ótima oportunidade para agentes mal-intencionados. Quando os patches são lançados ao público, as vulnerabilidades geralmente são divulgadas pelo National Vulnerability Database (NVD). Se os agentes invadirem a rede de OT, será que passariam semanas ou meses tentando encontrar uma vulnerabilidade de dia zero? Ou realizariam um reconhecimento da rede de OT para identificar vulnerabilidades anunciadas publicamente e explorá-las? Se os proprietários de ativos de OT não corrigirem as vulnerabilidades da OT, os agentes mal-intencionados tirarão proveito delas – é uma questão de quem as encontra primeiro.

No entanto, ao contrário da TI, todos os patches ausentes não podem ser instalados nos ativos de OT. Há vários motivos para isso:

1. Os patches de ICS ou de Sistema Operacional (OS) não podem ser implementados devido a hardware não compatível.
2. O fornecedor de ICS não aprovou os patches do OS
3. Os patches não são aprovados pelos proprietários dos ativos – ou seja, o patch travou o ativo de OT durante os testes

Nessas situações, os patches não podem ser instalados ou precisam aguardar até o próximo desligamento. E as vulnerabilidades estarão presentes até o próximo desligamento ou para sempre. Se, por algum motivo, o patch não puder ser implementado, outros controles precisarão ser aplicados para reduzir o risco a um nível aceitável. Tais controles incluem, mas não estão limitados a:

1. Desconectar o ativo de OT da rede LAN ou DMZ comercial
2. Restringir a permissão do usuário ao ativo de OT
3. Lista de permissões para aplicativos ou linha de base de aplicativos para executar apenas os serviços necessários e bloquear todos os outros

Além disso, a aplicação de patches no ambiente de OT é uma abordagem cara. Se o risco puder ser reduzido a um nível aceitável aplicando controles alternativos – o que significa que se os invasores puderem ser impedidos de alcançar os ativos vulneráveis – então o custo ou esforço de correção e aplicação de controles alternativos precisa ser comparado para decidir qual é a melhor abordagem. Não é viável corrigir todos os ativos de OT, portanto, recomenda-se corrigir de forma inteligente.

7 melhores práticas de gestão de patches de OT

Melhores práticas de gestão de patches de OT

1. Manter um inventário abrangente e perene
2. Atribuir criticidade ao ativo de OT
3. Buscar novos patches e vulnerabilidades de OT
4. Priorizar a implementação de patches
5. Avaliar e reduzir o risco de patches dispensados
6. Corrigir como parte do processo de gestão de mudanças
7. Criar uma política de gerenciamento de patches

Os ambientes de OT têm muita diversidade em termos de sistemas com os quais os proprietários de ativos de OT precisam trabalhar. E o trabalho se torna mais difícil quando Sistemas de Controle Industrial (ICS), como DCS, SIS, PLC, etc., são instalados de vários fornecedores no ambiente de OT. É por isso que uma abordagem eficaz de gerenciamento de patches é importante para identificar vulnerabilidades e reduzir o risco a um nível aceitável antes que os invasores as encontrem. A seção a seguir discutirá as 7 melhores abordagens para um processo de gerenciamento de patches tranquilo.

1. Manter um inventário abrangente e perene

Um inventário abrangente de todos os softwares, firmwares e hardwares dentro do ambiente de OT, incluindo todos os ativos desde a zona desmilitarizada industrial (nível 3,5) até a zona de célula/área (nível 2-0) no modelo ISA/IEC-62443 Purdue, é uma parte crítica de qualquer processo de gerenciamento de patches de OT. Assim que houver uma imagem clara do que está presente, será mais fácil comparar as vulnerabilidades conhecidas com o inventário para descobrir rapidamente quais patches são importantes para o ambiente de OT.

Para manter um inventário abrangente, é importante criar um banco de dados de todos os ativos e mantê-los organizados de acordo com aplicações de software, tipo de dispositivo, sistema operacional, versão do software e sistema operacional para todos os computadores, dispositivos de rede e sistemas de controle industrial presentes na organização. Seria arriscado ignorar vulnerabilidades porque um dispositivo ou software não estava visível no sistema de gerenciamento de inventário.

Consolidar Inventário

• Incluir todos os softwares, firmwares e hardwares
• Cobrir todos os níveis de OT, ou seja, Nível 3,5 a 0
• Organizar de acordo com seus tipos

Inventário de referência

• Monitorar todos os aplicativos de OT em todos os terminais
• Desativação de softwares raramente usados ou não usados

Atualizar inventário

• Usar uma ferramenta automatizada
• Inventário atualizado de forma contínua

Muitas unidades dentro das mesmas organizações acabam usando várias versões do mesmo software do sistema de controle. Várias versões de software do sistema de controle complicam as tarefas de correção porque dificultam entender se o ativo ou software vulnerável está presente na organização. Por exemplo, quando o ICS Advisory  ICSA-20-205-01 foi lançado com a CVSS v3 10.0, que é a pontuação CVSS mais alta, e o ativo vulnerável era um sistema de segurança, muitas organizações de OT enfrentaram dificuldades para perceber se essa vulnerabilidade existia em qualquer uma de suas unidades devido à falta de inventário de OT detalhado, como versões de software, detalhes do sistema operacional, versões de aplicativos, detalhes do modelo de comunicação do sistema de segurança, etc. e presença de várias versões em diferentes unidades. Manter uma versão mais recente do software IACS em todas as unidades tornará o processo de correção tranquilo.

Todos os aplicativos de OT em todos os terminais precisam ser monitorados. Se um aplicativo de OT raramente for usado/não for usado, recomenda-se desativá-lo. Não há necessidade de corrigir o que não está presente no ambiente de OT. Em um ambiente de OT típico, há muitos pacotes de software altamente vulneráveis, como Adobe Flash players e leitores de documentos que não têm motivos para estarem presentes. Tomando isso como exemplo, desinstalar o Flash resultará em muito menos coisas para corrigir! Esta abordagem de endurecimento do sistema é conhecida como “inventário de referência”. Um inventário de referência preciso facilitará a descoberta de patches e a abordagem de gerenciamento.

Ter uma versão consolidada do software do Sistema de Controle Industrial (ICS) é importante; no entanto, é mais importante ter um inventário perene. Se o inventário consolidado não for atualizado regularmente, isso não será bom para o gerenciamento de patches do IACS. Além disso, é melhor usar uma ferramenta automatizada como o PAS Cyber Integrity™ para ter um inventário atualizado e perene, pois o rastreamento manual de inventário é propenso a erros.

2. Atribuir criticidade ao ativo de OT

Para atribuir criticidade ao ativo de OT, um sistema para atribuir pontuações de criticidade precisa ser estabelecido. Isso pode já existir devido à regulamentação do sistema de segurança. A criticidade precisa ser atribuída considerando o impacto nos negócios, ou seja, o impacto da perda de acessibilidade, confiabilidade, integridade, etc. na segurança, lucratividade, etc. Por exemplo, se houver uma estação de trabalho para configurar e monitorar um sistema de segurança, a criticidade não deve ser atribuída com base no custo dessa estação de trabalho. O custo dessa estação de trabalho seria inferior a US$ 1000; no entanto, o custo de não poder acessar, monitorar ou fazer alterações no sistema de segurança pode levar a um incidente catastrófico que poderia custar milhões de dólares. A maneira mais fácil de atribuir criticidade considerando o impacto nos negócios seria calculando o Objetivo do Tempo de Recuperação (RTO – por quanto tempo o ativo pode ficar inativo sem impactar os negócios) e o Objetivo do Ponto de Recuperação (RPO – por quanto tempo os dados podem ficar perdidos sem impactar os negócios). RTO e RPO mais baixos representam ativos críticos mais altos.

Além do mais, isso pode afetar adversamente a imagem da marca e o relacionamento com os clientes, e também deve ser considerado ao calcular o impacto nos negócios. Às vezes, é difícil atribuir um valor em dólares às relações com os clientes e ao impacto da imagem da marca; no entanto, uma abordagem qualitativa de avaliação de risco seria recomendada para considerar o risco de impacto nos negócios nestes cenários.

Considerar o custo de manutenção e substituição também faz parte da avaliação de criticidade. Ao contrário dos ativos de TI, como notebooks, dispositivos de rede, etc., sai caro e demorado manter e substituir ativos de ICS, como DCS, SIS, etc., pois eles estão relacionados à segurança e continuidade dos negócios. Por exemplo, a substituição de um servidor de engenharia DCS requer sincronização com os controladores DCS. Não sincronizar o arquivo de configuração crítica pode acabar em inativação de uma unidade. Nem é preciso dizer que nenhuma alteração pode ser feita no sistema de controle ao substituir o servidor de engenharia DCS.

3. Buscar novos patches e vulnerabilidades de OT

Os proprietários de ativos de OT devem procurar ativamente por novos patches e vulnerabilidades. A organização pode se inscrever para receber anúncios de patches pelos respectivos fornecedores de ICS. Receber notificações de lançamento de patches de vários fornecedores pode ser difícil de gerenciar. Inscrever-se para receber o anúncio de vulnerabilidade US-CERT/ICS-CERT ajudará na obtenção de notificações imediatas sobre as vulnerabilidades anunciadas recentemente.

O NVD libera mais de 350 vulnerabilidades por semana. É difícil identificar se todas as vulnerabilidades e patches se aplicam à organização de OT. Uma ferramenta automatizada como o modelo de ativos do PAS Vulnerability Management, que é atualizado diariamente para adicionar as vulnerabilidades anunciadas pelo NVD, seria útil para comparar o inventário detalhado com as vulnerabilidades anunciadas para identificar as vulnerabilidades e os patches aplicáveis. A identificação de vulnerabilidades de maneira passiva fornece uma enorme vantagem para os proprietários de ativos de OT, e isso pode ser alcançado usando essas ferramentas que comparam o inventário de OT atual com o Banco de Dados CVE do NIST e avisos ICS-CERT para combinar quais ativos são afetados e se há um patch disponível.

Depois que uma vulnerabilidade é identificada, é preciso verificar se ela pode ser mitigada de forma mais inteligente. Por exemplo, se a vulnerabilidade do Google Chrome for encontrada em 10 servidores de OT antes da aplicação do patch, a pergunta seria: será que o Google Chrome é necessário em todos os 10 servidores de OT? Desinstalá-lo de alguns dos servidores de OT não só eliminaria vulnerabilidades como também economizaria tempo durante correções no futuro.

4. Priorizar a implementação de patches

Não é possível implementar todos os patches em todos os ativos de OT ao mesmo tempo. Além disso, não é possível corrigir um por um. Recomenda-se priorizar a implementação de patches especialmente projetados para o ambiente de OT. A  pontuação CVSS é calculada usando vários fatores, como vetor de acesso, complexidade de acesso, autenticação, integridade, disponibilidade, etc.Trata-se de um bom ponto de partida para decidir o que corrigir. No entanto, se houver uma vulnerabilidade crítica (pontuação CVSS superior a 9,0) no ativo de treinamento (pouco crítico) e uma alta vulnerabilidade (pontuação CVSS entre 7,0 e 8,9) no sistema de segurança crítico que está monitorando um gás venenoso, recomenda-se corrigir o sistema de segurança primeiro, embora a pontuação CVSS seja menor, pois a exploração dessa vulnerabilidade custará mais à organização, já que terá um impacto direto nas pessoas, no meio ambiente e na fábrica.

Porém, pode haver alguns sistemas de segurança instalados para o processo não crítico, como o monitoramento da pressão da tubulação no abastecimento de água. Em outras palavras, nem todos os sistemas de segurança estarão monitorando gases venenosos e, assim, nem todos os sistemas de segurança terão a mesma criticidade atribuída. Os sistemas de segurança que são críticos para a unidade precisarão ser priorizados nas correções.

O gerenciamento eficaz e eficiente de patches é uma abordagem baseada em riscos. Se a perda de dois ativos terá o mesmo impacto no negócio, em outras palavras, se dois ativos estiverem tendo a mesma criticidade, a probabilidade de explorar essa vulnerabilidade pode ser considerada para priorizar a implementação do patch. Por exemplo, se houver um servidor crítico presente na DMZ (Nível 3,5) voltado para a rede externa e outro servidor crítico presente no Nível 2 desconectado da LAN comercial, com lacuna de ar/ilhado e protegido fisicamente, primeiro o servidor de DMZ deve ser priorizado para o patch. Isso ocorre porque a probabilidade de acessar o servidor de Nível 2 e explorar a vulnerabilidade será menor do que a probabilidade de acessar e explorar o servidor de nível DMZ.

5. Avaliar e reduzir o risco de patches dispensados

Ao contrário da TI, onde todos os patches do sistema operacional (OS) Windows podem ser instalados, a instalação de todos os patches do OS pode travar um servidor ou estação de trabalho de OT crítica. Isso terá um impacto direto na operação da unidade, pois o acesso ou o monitoramento de ativos críticos serão descontinuados. Como resultado, os patches MS aprovados pelo fornecedor de ICS precisam ser testados em uma configuração de teste não crítica pelas organizações de OT antes de serem enviados para as estações de trabalho de produção.

Se os patches não puderem ser instalados nos ativos de OT, controles alternativos precisam ser aplicados para reduzir o risco a um nível aceitável. Entendendo que risco é a multiplicação de impacto e probabilidade, o impacto nos negócios ou a criticidade do ativo de OT não podem ser alterados. Entretanto, a probabilidade pode ser reduzida aplicando controles alternativos. No mínimo, os seguintes controles precisam ser aplicados:

1. Proteção de limite: proteção de limite, como segregação de rede, zoneamento, controle de acesso, etc. para evitar invasão física e digital.
2. Segmentação de rede: a segmentação de rede, zoneamento, etc. evitará violação, disseminação de malware e assim por diante.
3. Gerenciamento de incidentes e eventos de segurança: a solução SIEM pode agregar dados e detectar ameaças potenciais.
4. Monitoramento de integridade: ter uma ferramenta automatizada para monitorar a integridade crítica do arquivo de configuração de ICS e relatar alterações.

   
   6. Corrigir como parte do processo de gestão de mudanças

Normas industriais como IEC-62443 recomendam ter um processo de gestão de mudanças. Como parte desse processo, recomenda-se ter uma referência, registro, revisão, documentação e plano de reversão. Entendendo que a implementação de patches no ambiente de OT consiste em uma mudança no ambiente, recomenda-se seguir o mesmo processo de gestão de mudanças ao implementar patches.

1. Patches de referência: obter uma referência de todos os sistemas de OT no ambiente fornecerá um ponto de partida para comparar quaisquer mudanças no futuro. Considerando a abordagem de gerenciamento de patches, a referência deve fornecer os patches que devem ser instalados quando um novo sistema for empregado. Entende-se que a referência precisa ser atualizada regularmente à medida que novos patches são liberados.
2. Registro de patches instalados: os proprietários de ativos de OT precisam garantir que a referência e as mudanças sejam registradas. É crucial registrar o status atual do patch; em outras palavras, a lista de todos os patches atualmente instalados em cada ativo. À medida que os novos patches são implementados, eles também precisam ser registrados. Se algum patch não estiver instalado, os controles alternativos aplicados para patches dispensados também precisam ser registrados. Isso ajudaria a auditar se quaisquer patches que não são aprovados por fornecedores ou não são testados forem enviados para os ativos de OT.
3. Revise os patches instalados: as mudanças no ambiente de OT precisam ser testadas e revisadas regularmente antes e depois das mudanças. Com isso dito, os patches precisam ser testados e revisados antes e depois das instalações dos patches.
4. Documente o processo de correção: recomenda-se ter um processo de gestão de mudanças documentado. Este processo não deve ser feito por último, mas sim em paralelo, conforme as mudanças vão sendo feitas para se referir a ele para solução de problemas futuros e pesquisa, se necessário.
5. Tenha um plano de reversão: às vezes, o patch aprovado pelo fornecedor/fornecido e testado pelo usuário final pode travar o ativo de OT crítico porque o ambiente de testes pode ser diferente do ambiente de produção. É sempre recomendável ter um plano de reversão com backups testados completos antes de corrigir ativos de OT críticos.

    

7. Criar uma política de gerenciamento de patches

À medida que a organização amadurece, ela precisa ter uma política documentada que deve ser seguida por seus funcionários e que seja atualizada quando necessário. Uma política e o processo de gerenciamento de patches bem definidos são algumas das melhores práticas para uma abordagem eficiente de gerenciamento de patches. Uma política de gerenciamento de patches ajuda a orientar a equipe sobre o processo de gerenciamento de patches de OT aceitável. Não é necessário definir tal processo do zero porque normas como IEC-62443 estão disponíveis. A ANSI/ISA-TR62443-2-3-2015, que fala sobre Gerenciamento de Patches no ambiente de IACS, é um ponto de partida muito bom para criar um processo de patches sistemático.

A política de gerenciamento de patches deve incluir pelo menos:

1. Política para definir uma programação de varredura
2. Política para categorizar e separar patches
3. Política para priorizar e implementar patches
4. Política para patches dispensados

   Conclusão

Para concluir, o gerenciamento eficaz de patches é necessário porque os invasores explorarão vulnerabilidades de patches ausentes se invadirem uma rede de OT de infraestruturas críticas. Ao mesmo tempo, todos os patches não podem ser instalados na rede de OT por várias restrições. Conhecer o inventário a fundo e combiná-lo com vulnerabilidades conhecidas é um bom ponto de partida. Entretanto, a única solução para mitigar vulnerabilidades é não implementar patches. Entendendo que nem todos os patches podem ser instalados devido à aprovação dos fornecedores ou hardwares não compatíveis, o risco precisa ser avaliado e reduzido a um nível aceitável aplicando outros mecanismos de endurecimento, como proteção de limite e segmentação de rede. Em outras palavras, se os patches não puderem ser instalados, a probabilidade de que os invasores possam encontrar as vulnerabilidades precisa ser reduzida aplicando controles apropriados.

As correções são uma mudança no ambiente de OT e o gerenciamento de patches precisa seguir a melhor abordagem de gestão de mudanças, como referência, registro, revisão, documentação e plano de reversão. Para alcançar uma maturidade maior, é necessário criar e seguir uma política e um processo de gerenciamento de patches para as abordagens, como manter um inventário abrangente e avaliar e reduzir o risco de patches dispensados.

Texto original:  https://gca.isa.org/blog/the-top-7-operational-technology-patch-management-best-practices