OT Patch Management e para ambientes isolados: o fluxo de trabalho completo para a aplicação de patches offline

• A gestão de patches na área de OT não é a mesma que a gestão de patches na área de TI com um calendário mais alargado. As dependências de segurança , as configurações certificadas pelos fornecedores, os longos ciclos de vida dos ativos e a tolerância quase nula para reinicializações não planeadas alteram praticamente todas as etapas do processo.
• As redes isoladas (air-gapped) perdem a cobertura automática das atualizações de segurança, mas não a necessidade de as receber. Os terminais que não conseguem estabelecer ligação à central desaparecem dos serviços de análise e atualização baseados na nuvem, a menos que um repositório offline e uma gestão no local restabeleçam essa visibilidade dentro da zona isolada.
• A gravidade do CVSS, por si só, nunca deve determinar a prioridade de aplicação de patches de OT. A maturidade da exploração , a acessibilidade da rede, a criticidade dos ativos e as consequências para a segurança operacional devem ser tidas em conta na decisão, a par da pontuação; caso contrário, duas vulnerabilidades com classificações semelhantes podem receber uma resposta errada.
• Os suportes removíveis são um ponto de controlo, não uma comodidade. Cada pacote de correções e o dispositivo que o transporta devem ser tratados como não fiáveis até que a verificação da origem, as verificações de assinatura e de hash e a inspeção de malware autorizem a sua transferência.
• MetaDefender O Endpoint™ aplica a gestão de vulnerabilidades e de correções, a proteção de suportes removíveis e a defesa contra BadUSB através de um único agente de terminal, com visibilidade centralizada a partir do My OPSWAT™ Central Management, mas a governação, os testes e a aprovação dos fornecedores continuam a ser da responsabilidade da organização.

Os terminais que não conseguem aceder à Internet ficam excluídos da verificação de vulnerabilidades baseada na nuvem, dos repositórios de atualizações e da sincronização de políticas, o que significa que também desaparecem dos relatórios de conformidade, a menos que algo restaure essa cobertura localmente. A aplicação manual de correções, baseada em folhas de cálculo, pode servir de substituto durante algum tempo, mas deixa de funcionar em grande escala: as transferências informais de ficheiros « USB » não ficam documentadas, os resultados da implementação não são registados e cada auditoria transforma-se num exercício de reconstrução.

Um repositório de patches offline, uma gestão centralizada no local e um percurso de transferência controlado recriam a cobertura que a automatização na nuvem proporciona num ambiente ligado, sem adicionar uma ligação ativa que enfraqueceria a própria barreira física.

• A aquisição e a validação inicial ocorrem fora do ambiente de produção, numa zona com acesso à Internet para obter as atualizações dos fornecedores e executar as verificações iniciais de assinatura e hash.
• O repositório de patches offline reúne atualizações aprovadas do sistema operativo e de aplicações de terceiros, com controlo de versões, acompanhamento de substituições e registos de sincronização mantidos dentro da rede isolada.
• A gestão centralizada no local distribui políticas, programa implementações, recolhe informações sobre o estado dos terminais e elabora relatórios sem depender de serviços na nuvem, fornecedores de identidade externos ou licenciamento do tipo «call-home».
• A aplicação e a implementação finais das políticas permanecem sob o controlo local da equipa de operações (OT), pelo que uma fonte externa comprometida ou com atrasos nunca poderá aplicar uma alteração diretamente em produção.

Um fluxo de trabalho repetível de aplicação de correções offline divide-se em seis etapas, cada uma das quais gera uma decisão, um artefacto e um registo de aprovação definidos, para que o processo permaneça auditável do início ao fim.

1. Inventário e deteção. Manter um inventário de ativos que inclua as versões de hardware e software, a zona de rede, a função de segurança e o estado do suporte; em seguida, cruzar esses dados com os avisos dos fornecedores e as análises de vulnerabilidades offline para identificar as atualizações aplicáveis.

2. Priorizar o risco. Avalie cada correção candidata com base na vulnerabilidade, exposição, importância do ativo e consequências para a segurança — e não apenas na pontuação de gravidade — e confirme a compatibilidade do firmware, do sistema operativo e do suporte do fornecedor antes de a incluir no fluxo de trabalho.

3. Validar e aprovar o pacote. Verificar a autenticidade da fonte, as assinaturas digitais e os hashes criptográficos, proceder à verificação de malware num ambiente de teste isolado e realizar testes representativos antes da aprovação formal da alteração.

4. Transferência e preparação. Transfira o pacote aprovado através de suportes removíveis controlados, volte a verificá-lo após a transferência e prepare-o localmente antes do período de implementação.

5. Implemente por fases. Aplique a correção durante um intervalo de manutenção autorizado, com seleção definida dos terminais, configurações de instalação silenciosa (quando suportadas), controlos de reinicialização e condições de interrupção.

6. Verificar, reverter e elaborar um relatório. Confirmar o estado da instalação, a integridade do serviço e o comportamento das funções de segurança; executar uma reversão previamente testada caso os critérios de aceitação não sejam cumpridos; e registar o resultado, as exceções e as provas para análise de auditoria.

Uma matriz de prioridades que pondera a probabilidade de um ataque cibernético em relação às consequências operacionais proporciona às equipas uma forma coerente de orientar as decisões, em vez de tratarem todas as detecções de gravidade elevada da mesma forma.

Quando uma correção é adiada em vez de aplicada, a exceção necessita de um responsável, uma justificação técnica, uma data de validade e controlos compensatórios, que devem ser revistos sempre que se verifiquem alterações na atividade de exploração de vulnerabilidades ou nas orientações do fornecedor. As exceções permanentes e não revistas são a primeira lacuna que os auditores identificam.

Um pacote de correções e o suporte removível que o contém devem ser tratados como não fiáveis até que a política os verifique. Uma cadeia de custódia que privilegia a inspeção estabelece a proveniência, a integridade e a segurança do conteúdo antes de um ficheiro se tornar acessível dentro da rede OT.

• Verificação da fonte. Obtenha atualizações apenas a partir de portais de fornecedores ou canais de distribuição autenticados e registe a fonte, a hora da obtenção, a versão do pacote e a identidade da pessoa que o descarregou.
• Validação de assinaturas e hash. Verifique as assinaturas digitais, a validade dos certificados e os hash criptográficos publicados pelos fornecedores antes da transferência. Uma assinatura válida comprova a autenticidade; por si só, não prova que o pacote seja seguro para um ambiente OT específico.
• Inspeção de malware. Analise o pacote completo, incluindo arquivos aninhados, instaladores, scripts e controladores, num ambiente de teste isolado, com ações definidas de quarentena e rejeição para resultados suspeitos.
• Proteção contra suportes removíveis e BadUSB. Exigir a autorização do dispositivo e a verificação prévia do acesso, para que as unidades infetadas e os dispositivos falsificados — incluindo ataques BadUSB que se fazem passar por um teclado — sejam bloqueados antes de poderem executar qualquer ação num terminal OT.
• Registos da cadeia de custódia. Registe a identidade do suporte, o responsável pela custódia, os hashes, os resultados das inspeções, as aprovações, a hora da transferência e o destino, para que cada transferência possa ser reconstituída durante uma auditoria.

A implementação de uma correção validada continua a ser uma alteração operacional, e uma implementação bem-sucedida tem de preservar o controlo dos processos, a segurança e a capacidade de recuperação, tal como corrige uma vulnerabilidade.

• Crie um ambiente de teste representativo. Reproduza o hardware essencial, as versões do sistema operativo, as aplicações e as comunicações, sempre que possível, e documente os casos em que o ambiente de teste e o de produção apresentam diferenças inevitáveis.
• Confirme a compatibilidade antes da implementação. Analise as orientações do fabricante do equipamento, a certificação da aplicação e as dependências dos controladores, e exija uma aprovação adicional quando uma correção não se enquadrar na configuração suportada pelo fabricante.
• Organize a implementação em fases. Comece por ativos representativos e de menor impacto, avalie o resultado e expanda gradualmente, em vez de aplicar a atualização em todo o ambiente de uma só vez, com critérios de pausa definidos e autoridade para interromper a implementação em caso de emergência.
• Controlar a instalação e os reinícios. Utilizar a instalação sem distrações, sempre que tal for possível, e suprimir ou coordenar os reinícios de acordo com as orientações do fornecedor, o projeto de redundância e a aprovação da unidade.
• Verifique o bom funcionamento e, em seguida, conclua o ciclo. Verifique o arranque do serviço, a lógica de controlo, os alarmes e as funções de segurança em relação a critérios de aceitação mensuráveis e mantenha um plano de reversão testado, incluindo cópias de segurança da configuração e suportes de recuperação, pronto antes do início da implementação.

Os terminais com vida útil prolongada, que utilizam versões antigas de sistemas operativos e aplicações de engenharia especializadas, muitas vezes não são abrangidos pelas ferramentas de aplicação de correções de TI convencionais, pelo que necessitam de um procedimento específico, em vez de serem totalmente excluídos do programa.

• Os terminais com sistemas operativos antigos necessitam de um inventário preciso da edição, da arquitetura e da configuração de referência aprovada pelo fornecedor antes de se selecionar qualquer atualização, com suporte a pacotes offline e capacidade de reversão integrada no processo.
• As aplicações de terceiros, tais como navegadores, ambientes de execução e ferramentas de acesso remoto, ficam frequentemente fora dos canais de atualização nativos do sistema operativo e necessitam de um mecanismo próprio de deteção de versões, resolução de dependências e suporte para instaladores offline.
• Os sistemas que não podem receber correções continuam a necessitar de documentação: deve indicar por que razão a aplicação de correções não é possível ou não é segura, quem é o responsável, uma data de revisão e um plano de substituição ou migração.
• Medidas de compensação, tais como a segmentação da rede, as listas de aplicações autorizadas e as restrições às suportes amovíveis, reduzem a exposição dos recursos que não podem ser atualizados, mas não eliminam a vulnerabilidade subjacente e requerem uma revisão periódica à medida que as condições de ameaça se alteram.

A recolha centralizada de evidências transforma a elaboração de relatórios de conformidade numa etapa de rotina do fluxo de trabalho de aplicação de correções, em vez de um exercício de reconstrução manual sempre que é agendada uma auditoria.

• Registos a conservar: âmbito dos ativos , estado de vulnerabilidade, aprovações, hash dos ficheiros, resultados das assinaturas, conclusões das inspeções, atividade dos suportes de dados, resultados da implementação, exceções e eventos de reversão, todos com marcas temporais atribuíveis.
• Métricas de cobertura: acompanhe a cobertura do inventário, a taxa de implementação de correções, as correções em atraso e as exceções, segmentadas por local e pelo nível de criticidade dos ativos, para que as percentagens agregadas não ocultem lacunas com consequências graves.
• Métricas de redução de risco: comparar os valores relativos ao tempo até à aplicação da correção e à janela de exposição com a taxa de reversão e o tempo de inatividade não planeado, de modo a que a aplicação mais rápida de correções nunca seja considerada um sucesso quando provoca instabilidade.
• Alinhamento com o quadro de referência: correlacione o inventário, a avaliação de riscos, o controlo de alterações e as práticas de monitorização com os objetivos relevantes da norma IEC 62443 e da norma NIST SP 800-82, Revisão 3, o guia atual sobre segurança das tecnologias operacionais (OT). O alinhamento com o quadro de referência apoia a realização de uma auditoria; por si só, não substitui a certificação nem garante a conformidade.

Os requisitos independentes do fornecedor devem orientar a avaliação antes de qualquer produto específico ser considerado: funcionamento verdadeiramente offline, gestão centralizada no local, ampla cobertura de terminais e aplicações, proteção de suportes periféricos e relatórios centralizados que produzam provas prontas para auditoria, sem dependência da nuvem.

• Capacidade de funcionamento offline comprovada, não presumida. Exija uma demonstração num ambiente isolado da Internet, em vez de partir do princípio de que um produto ligado à Internet funcionará da mesma forma offline.
• Endpoint e cobertura das aplicações. Verifique o suporte efetivo aos sistemas Windows, macOS, Linux e sistemas antigos instalados na organização, incluindo formatos de pacotes offline e visibilidade da reversão.
• Proteção de suportes periféricos. Certifique-se de que a plataforma autoriza os dispositivos, realiza análises antes do acesso aos ficheiros e protege contra o BadUSB, em vez de deixar o percurso de transferência a cargo de uma ferramenta separada e desligada.
• Relatórios e governação centralizados. Teste o acesso baseado em funções, o estado da implementação, os fluxos de trabalho de exceções e a exportação de dados de forma a simular cenários que incluam suportes rejeitados e instalações mal sucedidas, e não apenas execuções bem-sucedidas.

MetaDefender O Endpoint™ é a solução avançada de proteção de terminais d OPSWAT, destinada a proteger os terminais contra ameaças veiculadas por suportes periféricos, monitorizar a conformidade dos dispositivos, detetar vulnerabilidades e permitir a aplicação de correções, tanto em ambientes ligados à Internet como em ambientes isolados (air-gapped). Deteta vulnerabilidades em mais de 980 aplicações e sistemas operativos e permite a aplicação automática de correções para mais de 580 aplicações de terceiros e atualizações de sistemas operativos, com um processo de aplicação de correções sem distrações que evita interromper os ecrãs dos operadores durante um período de manutenção.

A proteção de suportes removíveis funciona com o Metascan™ Multiscanning e a tecnologia Deep CDR™: MetaDefender OEndpoint deteta automaticamente e bloqueia o acesso a unidades USB até que todos os ficheiros sejam analisados e confirmados como isentos de vírus, e protege contra ataques BadUSB, «rubber ducky» e outros ataques de falsificação de dispositivos, sem necessidade de executar primeiro o ficheiro no terminal.

A visibilidade centralizada é proporcionada pela solução « My » da OPSWAT™ Central Management, disponível no local ou na nuvem, que distribui políticas, recolhe informações sobre o estado da implementação e gera relatórios em todos os locais sem depender do acesso à Internet, permitindo assim que uma equipa de segurança execute o mesmo fluxo de trabalho offline em vários locais de OT isolados a partir de um único ponto.