Guia de Boas Práticas para Eventos de Segurança em OT

Em ambientes industriais, um incidente pode começar muito antes de alguém perceber que existe um problema.

Uma autenticação incomum. Uma alteração na lógica de um equipamento. Uma mudança de configuração. Um novo software. Uma conexão inesperada. Uma tentativa de movimentação lateral.

Individualmente, esses eventos podem parecer pouco relevantes.

Quando registrados, preservados e analisados no contexto correto, porém, podem ajudar a reconstruir o caminho percorrido por um atacante e o impacto potencial sobre a operação.

É justamente essa a função do event logging.

O guia internacional Best Practices for Event Logging and Threat Detection, publicado em agosto de 2024 pelo ASD’s ACSC em colaboração com CISA, FBI, NSA e outros parceiros internacionais, estabeleceu uma referência para organizações estruturarem programas de registro de eventos capazes de apoiar detecção, investigação e resposta a ameaças. A orientação contempla explicitamente redes de Tecnologia Operacional.

Em 2026, a discussão continua relevante, mas precisa avançar.

O desafio não é registrar tudo. É registrar aquilo que permite entender o que aconteceu e identificar quando uma atividade pode representar risco para a operação.

Logging Não É Apenas Armazenar Dados

Esse é um dos primeiros conceitos que eu mudaria no artigo original.

Um programa de logging não deveria ser medido simplesmente pela quantidade de eventos armazenados.

Segundo o guia conjunto, uma estratégia eficaz deve ajudar defensores a identificar eventos que possam indicar incidentes, revelar o alcance de um comprometimento, monitorar atividades relevantes e tomar decisões com base em alertas e análises priorizadas. O documento também chama atenção para a necessidade de reduzir ruído desnecessário, inclusive pelos custos de armazenamento e consulta.

Isso significa que coletar milhões de registros sem saber o que procurar pode gerar uma falsa sensação de visibilidade.

Em OT, a pergunta precisa ser:

“Quais eventos precisamos enxergar para perceber uma mudança relevante na nossa operação?”

O que Realmente Deveria Ser Registrado em OT?

Essa discussão ganhou ainda mais força depois da publicação do guia original.

Em janeiro de 2025, CISA, NSA, FBI e outras agências publicaram o Secure by Demand: Priority Considerations for Operational Technology Owners and Operators when Selecting Digital Products.

O documento trata logging como um requisito que proprietários e operadores deveriam avaliar antes mesmo da aquisição de um produto OT. Entre os eventos recomendados estão autenticações bem e malsucedidas, reinicializações, alterações de configuração, atualizações de firmware, mudanças na lógica de engenharia, erros, exceções e modificações ou exclusões dos próprios logs.

Essa evolução é importante.

Logging deixa de ser apenas uma configuração feita posteriormente pela equipe de segurança e passa a fazer parte da própria capacidade de segurança esperada de um produto OT.

Além disso, os registros precisam oferecer contexto suficiente para uma investigação. A orientação de 2025 recomenda elementos como timestamp, origem, porta, conta afetada, identificador de correlação e descrição do evento.

Um log sem contexto pode mostrar que alguma coisa aconteceu. Um bom log ajuda a entender o quê, quando, onde e por quem.

Mudanças na Operação Merecem Atenção Especial

Em ambientes industriais, alguns dos registros mais importantes não são necessariamente aqueles associados a um malware conhecido.

Mudanças também importam.

Uma alteração na lógica de engenharia.

Uma nova configuração.

Uma atualização de firmware.

Uma mudança de usuário.

Um equipamento reiniciado fora de uma janela prevista.

Uma nova comunicação entre ativos.

O Secure by Demand destaca justamente a importância de registrar alterações em dispositivos, incluindo mudanças de lógica de engenharia, firmware e configurações.

Isso é particularmente importante porque um atacante não precisa necessariamente instalar um malware sofisticado para produzir impacto.

Ele pode tentar utilizar funcionalidades legítimas, credenciais válidas ou ferramentas já existentes no ambiente.

Foi justamente o aumento do uso de técnicas Living off the Land (LOTL) uma das razões citadas pelas agências para a publicação do guia de logging de 2024.

Por isso, detectar apenas arquivos maliciosos é insuficiente.

É necessário conseguir enxergar também uso anormal de ferramentas e funcionalidades legítimas.

Centralizar Ajuda, mas Nem Todo Log OT Pode Ser Tratado da Mesma Forma

O guia internacional estabelece quatro elementos centrais para boas práticas de logging:

política de registro aprovada pela organização; acesso e correlação centralizados; armazenamento seguro e integridade dos logs; e uma estratégia de detecção voltada às ameaças relevantes.

Centralização pode facilitar correlação e investigação.

Mas em OT existe uma particularidade importante.

Nem todo equipamento possui capacidade para produzir logs detalhados e nem todo ambiente permite que grandes volumes de telemetria sejam transportados sem avaliação prévia.

A orientação Secure by Demand reconhece que restrições de processamento em tempo real e largura de banda historicamente limitaram logging e telemetria em produtos legados de OT. Também observa que, mesmo quando não é seguro agregar registros pela rede, manter logging local habilitado ainda pode preservar evidências úteis para resposta a incidentes.

Portanto, a estratégia não deveria ser:

“Mandar todos os logs para o SIEM.”

Deveria ser:

“Como coletar e preservar as evidências necessárias sem comprometer a operação?”

Integridade dos Logs É Parte da Defesa

Logs também podem se tornar alvo.

Se um atacante conseguir apagar ou modificar os registros das próprias atividades, a investigação fica significativamente mais difícil.

Por isso, o guia recomenda armazenamento seguro, proteção da integridade e controles sobre acesso aos registros. A própria CISA orienta organizações a proteger logs contra acesso não autorizado e exclusão, restringindo e monitorando quem consegue acessá-los.

Isso significa que a arquitetura precisa considerar não apenas como gerar os logs, mas também:

quem pode acessá-los;

quem pode alterá-los;

onde são armazenados;

quanto tempo permanecem disponíveis;

e o que acontece caso o sistema de origem seja comprometido.

O registro precisa continuar sendo confiável justamente quando mais se precisa dele.

Tempo Também É um Dado de Segurança

Eu acrescentaria esse ponto à versão de 2026.

Para reconstruir um incidente, eventos registrados por diferentes dispositivos precisam conseguir formar uma sequência coerente.

Um acesso pode acontecer em um sistema.

Uma alteração, segundos depois, em outro.

Uma comunicação anormal pode surgir em um terceiro.

Se as referências de tempo forem inconsistentes, correlacionar esses acontecimentos se torna muito mais difícil.

Por isso, timestamp não é apenas um detalhe técnico do registro. Ele participa diretamente da capacidade de reconstruir uma sequência de eventos.

A orientação Secure by Demand inclui timestamp entre os elementos que devem acompanhar registros de eventos.

Em ambientes distribuídos, tempo consistente ajuda a transformar registros isolados em uma linha de investigação.

Correlação entre IT e OT Precisa Ter um Objetivo

Eu também mudaria a antiga seção sobre “integração de TI e OT”.

Não é necessário juntar todos os logs simplesmente porque existem dois ambientes.

A correlação precisa responder a hipóteses de ataque.

Imagine uma sequência:

credencial comprometida → VPN → jump host → estação de engenharia → alteração de configuração em um sistema OT.

Cada evento isoladamente pode aparecer em uma fonte diferente.

É a correlação entre identidade, acesso remoto, infraestrutura e atividade operacional que ajuda a revelar o caminho.

Portanto, IT e OT precisam compartilhar informações quando elas ajudam a responder:

“Como essa atividade chegou até a operação?”

Essa abordagem também evita transformar um SOC em um depósito de eventos sem contexto.

Visibilidade de Rede e Event Logging São Complementares

Outro ponto que eu acrescentaria é a diferença entre logging e visibilidade.

Nem todo ativo OT produz os logs necessários.

E um log mostra principalmente aquilo que determinado sistema decidiu registrar.

Por isso, event logging precisa ser combinado com outras fontes de visibilidade, como informações de ativos e, quando apropriado, observação das comunicações da rede.

Essa necessidade permanece muito atual. Em junho de 2026, o NCCoE do NIST iniciou um projeto específico para Asset Management and Visibility for OT Environments, abordando descoberta de ativos, inventário, configurações e gestão de mudanças. O NIST destaca que uma visão abrangente dos ativos é fundamental para capacidades como avaliação de riscos, segmentação, gestão de vulnerabilidades e resposta a incidentes.

Em outras palavras:

logging mostra eventos.

visibilidade ajuda a entender onde esses eventos estão acontecendo.

Juntos, eles fornecem contexto melhor para investigação.

Mais Logs Não Significam Mais Segurança

Esse talvez seja o ponto central para atualizar o artigo.

É possível aumentar drasticamente o volume de dados coletados e piorar a capacidade de análise.

Quanto mais eventos irrelevantes chegam às equipes, maior o risco de uma atividade importante desaparecer no meio do ruído.

O próprio guia internacional coloca a redução de alert noise entre os objetivos de uma solução eficaz de logging e defende priorização de alertas e análises para permitir decisões mais ágeis e informadas.

Portanto, a estratégia precisa partir das ameaças e dos riscos relevantes.

Quais atividades queremos detectar?

Quais fontes conseguem evidenciá-las?

Quais ativos são críticos?

Quais alterações deveriam gerar investigação?

Quais sequências de eventos representam um possível caminho de ataque?

Só depois disso faz sentido decidir quais dados coletar.

Logging precisa começar pela estratégia de detecção, não pela capacidade de armazenamento.

Logs Precisam Servir à Resposta a Incidentes

Existe outra diferença importante entre possuir logs e estar preparado.

Durante um incidente, a equipe precisa conseguir utilizá-los rapidamente para responder perguntas concretas:

Qual foi o primeiro acesso identificado?

Quais credenciais foram utilizadas?

Quais sistemas foram alcançados?

Houve alteração de configuração ou lógica?

Quais ativos se comunicaram com o sistema comprometido?

A atividade chegou a uma função crítica?

Qual é o alcance provável do comprometimento?

O guia conjunto destaca justamente o papel do logging na revelação do escopo e da extensão de um incidente.

Isso significa que a qualidade de uma estratégia de logging deveria ser testada durante exercícios e investigações.

Se a organização não consegue reconstruir o incidente usando seus próprios registros, existe uma lacuna de visibilidade.

Logging Também Deve Ser um Critério de Aquisição

Essa é uma das mudanças mais relevantes em relação ao artigo antigo.

Em vez de tentar resolver logging somente depois que um equipamento entrou na operação, organizações podem começar a exigir essa capacidade durante a aquisição.

A orientação conjunta Secure by Demand recomenda que compradores de tecnologia OT avaliem se o produto oferece, em sua configuração básica, registros de segurança e segurança física, preferencialmente utilizando formatos abertos. O documento também defende que logging não deveria ser tratado como um recurso adicional pago.

Isso permite incluir perguntas como:

O produto registra autenticações?

Registra mudanças de configuração?

Registra alterações na lógica?

Registra atualizações de firmware?

Permite exportar registros?

Os formatos são interoperáveis?

Os logs podem ser protegidos contra alteração?

O fabricante documenta quais eventos são registrados?

Essas perguntas transformam logging em requisito de arquitetura e aquisição, e não apenas em responsabilidade posterior do SOC.

De Registro de Eventos para Capacidade de Investigação

Em 2026, uma estratégia madura de event logging em OT não deveria buscar “visibilidade total”.

Esse objetivo é pouco realista.

Ela deveria buscar visibilidade suficiente sobre os eventos que realmente ajudam a detectar, compreender e responder aos cenários de risco relevantes para aquela operação.

Isso envolve uma cadeia:

definir o que precisa ser detectado → identificar as fontes necessárias → registrar → preservar → correlacionar → analisar → investigar → responder.

Para a Cyrex Security, logs ganham valor quando deixam de ser apenas registros técnicos e passam a funcionar como evidências capazes de conectar uma atividade digital às suas possíveis consequências operacionais.

Porque a pergunta mais importante não é:

“Estamos coletando logs?”

É:

“Se algo acontecer hoje, nossos registros permitirão entender como o atacante entrou, até onde chegou e o que fez dentro da nossa operação?”