Como Proteger Redes Industriais: Últimos CVEs da CISA, ISA 99 e Boas Práticas em cybersegurança industrial

A automação industrial construiu uma cultura técnica sólida em torno de uma palavra: disponibilidade. Tudo gira em volta de manter a planta rodando. Redundância de CLP, UPS, instrumento calibrado, plano de manutenção, análise de causa raiz. É engenharia consolidada, com décadas de amadurecimento.

No mesmo chão de fábrica, a cibersegurança nunca entrou nessa conta. Não é falta de competência técnica, é falta de cultura: a ameaça cibernética simplesmente não faz parte do repertório mental de quem projeta, comissiona e mantém sistema de controle. Quando a máquina se comporta de forma estranha, a primeira hipótese é sensor, cabo, ruído, fonte. Ataque é a última, quando é cogitado. Esse atraso de diagnóstico, medido em dias, amplia o tempo de permanência do atacante na rede.

Não é que falte norma para tratar isso. A resposta está consolidada há quase vinte anos na série ISA/IEC 62443, a ISA 99, nome do comitê que originou a série e forma como ainda é chamada na indústria. O problema é que ela quase nunca chega ao chão de fábrica.

A ISA e a série 62443

A ISA (International Society of Automation) é a entidade técnica responsável por normas amplamente adotadas na automação, como a simbologia de P&ID e a ISA-88 de controle de batelada. Dentro dela, o comitê ISA99 foi criado para tratar especificamente de segurança em sistemas de automação e controle industrial.

O trabalho desse comitê, desenvolvido em conjunto com a IEC, resultou na série internacional ISA/IEC 62443, hoje a principal referência global de cibersegurança para IACS (Industrial Automation and Control Systems). Quando alguém fala “ISA 99” num contexto de cibersegurança, é a essa série que está se referindo: o nome do comitê permaneceu como referência à série.

A diferença em relação a uma ISO 27001 não está no grau de rigor, mas na ordem das prioridades.

Em TI, a tríade começa pela confidencialidade: o pior cenário é o dado vazar. Em OT, começa pela disponibilidade e pela segurança física (safety): o pior cenário é a perda de controle do processo, com risco a pessoas e ao meio ambiente. Um servidor de e-mail fora do ar é um incômodo; um sistema de supervisão fora do ar numa estação de tratamento de água é um problema de operação e de segurança pública. Essa inversão muda tudo, inclusive a resposta certa a um incidente, porque desligar o ativo infectado pode ser pior que conviver com ele por algumas horas sob monitoramento.

Além disso, a 62443 foi escrita assumindo a realidade material da planta, algo que norma genérica de segurança da informação ignora:

• Equipamento com ciclo de vida de 15 a 20 anos, contra cerca de três de um notebook corporativo
• Sistema legado que não aceita atualização sem revalidar o processo inteiro
• Protocolo industrial concebido quando a ameaça era ruído elétrico, não atacante
• Janela de parada escassa, às vezes anual, para aplicar qualquer mudança
• Uma cadeia de engenharia, manutenção, operação, TI e integrador terceirizado, todos com acesso legítimo

A série não é um documento único. São quatro blocos, e cada parte responde a uma pergunta diferente, de terminologia (1-1) a requisito técnico de componente (4-2).

Os quatro blocos

1. Geral. Alinha terminologia, conceitos e métricas. É onde se define o que é zona, conduto, ameaça, risco e, principalmente, Security Level: a escala de SL 1 a SL 4 que gradua a capacidade de resistência esperada, de proteção contra violação casual (SL 1) até ataque de agente estatal com recursos extensos (SL 4). Definir o SL-alvo de cada zona é a decisão de projeto mais importante da norma, porque é ela que dimensiona todo o resto.

2. Políticas e Procedimentos. O bloco do fator humano e organizacional. A parte 2-1 descreve como montar um CSMS (Cyber Security Management System): política, governança, análise de risco, responsabilidade, treinamento, auditoria. A parte 2-4 é a que quase ninguém usa e deveria: ela lista os requisitos que você pode exigir contratualmente de provedor de serviço e integrador.

3. Sistema. O bloco de arquitetura. A parte 3-2 define a metodologia de análise de risco e a segmentação em zonas e condutos. A parte 3-3 lista os requisitos técnicos do sistema, organizados nos sete requisitos fundamentais (FR) que a última seção deste post detalha.

4. Componentes. O bloco que responsabiliza o fabricante. A parte 4-1 define o ciclo de desenvolvimento seguro (security by design) que o fornecedor deve seguir; a 4-2 define o requisito técnico que o componente (CLP, IHM, RTU, gateway) precisa atender. É o que permite comparar equipamento por capacidade de segurança em vez de só por preço e tempo de ciclo.

O mapa das partes

Parte	Pergunta que responde	Aplicação prática
62443-1-1	Quais são os conceitos, termos e modelos?	Base para entender zona, conduto, ameaça e Security Level
62443-2-1	Como criar o programa de segurança do proprietário do ativo?	CSMS: política, governança, risco, pessoas, auditoria
62443-2-4	O que exigir de quem presta serviço na minha planta?	Cláusula de segurança em contrato de integração, manutenção e suporte
62443-3-2	Como tratar risco na arquitetura?	Segmentação em zonas e condutos, análise de ameaça, definição do SL-alvo
62443-3-3	Quais controles o sistema deve ter?	Os 7 FR: autenticação, uso, integridade, confidencialidade, fluxo, resposta, disponibilidade
62443-4-1	Como desenvolver produto de forma segura?	Processo de desenvolvimento exigido do fabricante
62443-4-2	Quais requisitos técnicos o componente deve atender?	Critério de seleção de CLP, IHM, RTU e gateway

O ponto central é que nenhuma das quatro partes se resume a comprar um firewall: o firewall é consequência de uma decisão de arquitetura, não o ponto de partida.

A vulnerabilidade que não tem CVE

A maioria das plantas tem um inventário de falhas técnicas, mas raramente um inventário das falhas de comportamento, que são as que transformam uma CVE em parada de linha.

Duas das consequências mais recorrentes dessa ausência de cultura aparecem em praticamente todo incidente industrial que vira notícia. Não são as únicas, mas são as mais fáceis de reconhecer, e nenhuma delas é sofisticada. Uma é a rede plana: corporativo e automação na mesma rede, sem segmentação, porque segmentar exige esforço e a operação sempre funcionou dessa forma. Outra é o acesso remoto desenfreado: cada fornecedor, cada integrador, cada técnico com seu próprio túnel para dentro da planta, aberto por conveniência operacional e nunca mais revisado. A lista completa de comportamentos que sustentam esses dois problemas, e que pesam tanto quanto, vem logo abaixo.

Rede plana

A rede OT nasceu isolada e cresceu conectada, sem ninguém redesenhar o perímetro. O resultado é o que se encontra na maioria das plantas: CLP, IHM, servidor de engenharia, SCADA, impressora do escritório e notebook de visitante conversando no mesmo domínio de broadcast, muitas vezes com rota direta para a internet.

O isolamento físico (air-gap) citado como justificativa deixou de existir com a primeira integração de dados de produção ao ERP — sem substituto: em vez de uma DMZ industrial ou de um conduto controlado, abriu-se uma regra de firewall e um cabo.

Sem segmentação, a superfície de ataque da planta inteira passa a ser a do elo mais fraco, que normalmente é uma estação Windows desatualizada rodando software de engenharia. Um phishing aberto no administrativo pode alcançar o controlador no mesmo dia, porque nada no caminho foi projetado para impedir movimentação lateral.

Acesso remoto sem controle

O acesso remoto é um vetor de risco criado pela própria indústria. Manutenção remota é legítima e economiza viagem, mas a forma como ela costuma ser implementada não segue nenhum critério de engenharia.

Software de acesso remoto instalado pelo técnico direto na estação de engenharia, sem passar por TI, sem registro, sem aprovação, contornando o perímetro, fora do firewall. VPN de integrador criada para um comissionamento de três semanas e ativa há seis anos. Credencial de fornecedor compartilhada por uma equipe inteira. Acesso permanente onde a necessidade era temporária.

O agravante é que esse acesso quase sempre desemboca na estação que tem o software de programação instalado: Studio 5000, TIA Portal, EcoStruxure. Quem chega ali não precisa de exploit: dispõe da ferramenta oficial do fabricante, com a credencial correta, para ler e reescrever a lógica do controlador.

Os comportamentos que sustentam os dois

Rede plana e acesso remoto sem controle não são decisões técnicas isoladas. São sintomas de um conjunto de crenças que se repete de planta em planta:

Crença	O que ela produz
Atribuição da segurança exclusivamente à TI	Engenharia, operação e manutenção não se sentem responsáveis pelo risco de OT, e são justamente eles que controlam o acesso
Prioridade absoluta à disponibilidade	Patch, teste, revisão de arquitetura e plano de resposta ficam adiados indefinidamente
Aversão a alteração em sistema operacional	Sistema exposto, desatualizado e mal configurado operando sem que ninguém tenha olhado
Terceirização da responsabilidade de segurança	Fornecedor com acesso amplo, sem supervisão, sem registro, sem cláusula de segurança no contrato
Percepção de que empresas pequenas não são alvo	Ignora que a varredura é automatizada e não escolhe alvo, escolhe porta aberta
Confiança na obscuridade dos protocolos industriais	Confia em obscuridade que deixou de existir quando as ferramentas de análise ficaram públicas
Segurança como custo	Verba zero ou residual, herdada da TI corporativa, enquanto se investe em eficiência

E, na operação, o reflexo disso aparece como procedimento sendo contornado por conveniência: firewall desativado para “testar”, MFA desabilitado porque atrasa, cartão de acesso compartilhado, pen drive pessoal na estação de engenharia. A causa raramente é má-fé: em geral é alguém tentando cumprir a meta de produção diante de um procedimento cuja razão nunca foi explicada.

Fora dessa lista, há um item ainda mais caro: não existe plano de resposta. Quando o incidente acontece, não há procedimento escrito dizendo ao operador o que fazer, quem avisar, o que isolar e como manter o processo em manual. Improvisa-se, e improviso em processo industrial é o que a engenharia de segurança passou um século tentando eliminar.

Vulnerabilidades recentes publicadas pela CISA

A CISA, agência americana de cibersegurança e infraestrutura, mantém os ICS Advisories, boletins que documentam falhas encontradas e exploradas em automação industrial, energia, água, manufatura e saúde, sempre com CVE, produto e versão afetada.

Em abril de 2026, CISA, FBI, NSA, EPA e DOE publicaram o alerta conjunto AA26-097A, sobre uma campanha de atores ligados ao Irã contra CLPs expostos à internet em serviços públicos municipais, saneamento e energia nos Estados Unidos.

Segundo o alerta, os atores varreram a internet em busca de controladores respondendo nas portas industriais 44818 (CIP/EtherNet-IP), 2222, 102 (S7comm/ISO-TSAP) e 502 (Modbus), e encontraram CompactLogix, Micro850, Modicon M340 e S7-1200 mal configurados e alcançáveis de fora. A partir daí, usaram o software oficial de programação de cada fabricante, hospedado em infraestrutura alugada, para se conectar e exfiltrar os arquivos de projeto.

Em seguida, modificaram e apagaram lógica (inclusive Add-On Instructions) e manipularam dados nas telas de IHM e SCADA. Em uma das vítimas, foi carregado um projeto que preservava a lógica Ladder de operação, mas sobrescrevia as instruções responsáveis pelos parâmetros seguros de processo: a lógica de parada e de alarme foi desabilitada com a planta aparentemente normal para o operador.

O detalhe que conecta esse caso ao restante deste post: nenhuma etapa usou exploit ou falha de software. Bastou um controlador alcançável e uma credencial fraca, que é exatamente o cenário das seções sobre rede plana e acesso remoto sem controle. E a manipulação da lógica de parada mostra, na prática, a diferença entre segurança de dados e segurança de processo: o alvo não foi o dado, foi o processo físico.

A tabela abaixo reúne, em ordem cronológica, os advisories mais relevantes do período.

Data	Advisory	Produto e versão	Falha	Consequência
11/04/2024	ICSA-24-102-01	SIMATIC S7-1500 TM MFP e CPU MFP (subsistema GNU/Linux)	Centenas de CVEs herdadas do kernel e do OpenSSL: use-after-free, escrita fora de limites, vazamento de memória (CVSS v3 até 7,8)	Escalada local de privilégio, DoS e vazamento de informação em módulo dentro da zona de controle
12/03/2026	ICSA-26-071-06	Ignition anterior a 8.3.0	CVE-2025-13913, desserialização de dado não confiável (CVSS v3 6,3)	Execução de código com a permissão da conta de serviço do SCADA
07/04/2026	AA26-097A	CompactLogix, Micro850, Modicon M340, S7-1200 expostos	Campanha ativa de atores ligados ao Irã nas portas 44818, 2222, 102 e 502, sem exploit, via software oficial de programação	Exfiltração de projeto, alteração e exclusão de lógica, desativação de shutdown e alarme com operador sem notificação
09/04/2026	ICSA-25-345-10 (Update A)	OpenPLC v3	CSRF, inicialização padrão insegura, senha em texto claro e falta de autorização (CVSS v3 8,9)	Controle do CLP a partir de sessão legítima e credencial lida em claro
14/05/2026	ICSA-26-134-15	Família S7-1500, ET 200SP, Drive Controller: servidor web	CVE-2026-25786/25787/25789, XSS em nome de estação, de technology object e de arquivo de firmware (CVSS v3 até 9,1 crítico; a última, via engenharia social no firmware, é 7,1 alto)	Script roda na sessão de usuário privilegiado e opera o CLP com a autorização dele
09/07/2026	ICSA-26-190-01	OpenPLC v3	CVE-2026-14480, escrita arbitrária de arquivo na interface legada de upload (CVSS v3 9,9 crítico)	Execução de código nativo disparada quando o operador compila e inicia o programa
14/07/2026	ICSA-25-352-01 (Update A)	Ignition Gateway 8.1.x e 8.3.x	CVE-2025-13911, execução com privilégio desnecessário (CVSS v3 6,4)	Código em nível SYSTEM no host Windows do Gateway
01/09/2026	ICSA-26-244-04	FactoryTalk Activation Manager V5.02 e anteriores	CVE-2026-16675, console com privilégio SYSTEM aberto pelo instalador (CVSS v3 7,8)	Escalada de privilégio local durante instalação ou reparo
03/09/2026	ICSA-26-246-06	Ignition 8.1.53 e anteriores	CVE-2026-77393, configuração “Create Project Role(s)” entregue em branco (CVSS v3 8,8)	Qualquer usuário autenticado cria projeto e executa script no Gateway
22/09/2026	ICSA-26-265-09	OpenPLC Runtime v3 (fim de vida)	CVE-2026-88020, XSS por parâmetro de rota sem codificação (CVSS v3 6,1)	Roubo de cookie de sessão e requisições que alteram o estado do CLP e o processo físico
22/10/2026	ICSA-26-295-14	~157 variantes de S7-1500, ET 200SP/pro, Drive Controller, Software Controller	CVE-2026-63350 a 63357, eval injection e XSS via arquivo de trace importado (CVSS v3 9,6 crítico)	Código na sessão do usuário autorizado e operação do CLP, sem patch disponível, só mitigação
27/10/2026	ICSA-26-300-01	EPICS Base 7.0.10 e anteriores	CVE-2026-114595, integer overflow no processamento de requisição de rede	Corrupção de memória, DoS e potencial execução remota de código
29/10/2026	ICSA-26-300-02	GENESIS, GENESIS64, ICONICS Suite, Hyper Historian, AnalytiX, MobileHMI, IoTWorX, MC Works64	CVE-2023-4863 (escrita fora de limites via libwebp) e CVE-2026-16436/16437/16438, resposta de challenge igual e fixa para todos os usuários (CVSS v3 até 8,2)	Execução de código, desbloqueio remoto do sistema e operação não autorizada. MC Works64, GENESIS32 e BizViz sem correção prevista

A própria ICSA-26-300-01 da tabela acima, vista direto na fonte: CVSS-B 9.3, vetor completo de rede, sem interação do usuário.

A coluna de falhas expõe um padrão: interface web exposta, validação de entrada ruim, privilégio mal atribuído, configuração padrão insegura, componente de terceiro desatualizado, produto em fim de vida ainda em operação. É a mesma lista de sempre da engenharia de software, com a diferença de que aqui o resultado de um erro é mecânico.

Duas linhas da última coluna fecham com o mesmo aviso: sem patch disponível. Em OT isso é regra, não exceção. Quando não há correção, o que sobra é o que a 62443 descreve: segmentação, restrição de serviço, controle de acesso e monitoramento. Nesse cenário, a arquitetura passa a ser a mitigação.

Zonas e condutos

A parte mais importante da 62443 para a prática de planta é a 3-2.

Uma zona é um agrupamento de ativos que compartilham o mesmo requisito de segurança: a zona de robótica, a zona de processo, a zona de utilidades. Um conduto é o canal controlado por onde essas zonas conversam, e o único caminho permitido entre elas.

Dado de produção que precisa subir para o ERP é depositado na DMZ industrial. A rede corporativa nunca fala direto com a zona de controle.

O ganho é concreto e mensurável: quando alguém explora um RCE numa estação de engenharia, as regras do conduto impedem a movimentação lateral. O ataque fica contido em uma zona em vez de atravessar a planta. O impacto fica limitado a esse perímetro, e o tempo de detecção aumenta.

É o mesmo raciocínio da defesa em profundidade: a norma parte da premissa de que software e equipamento vão falhar, e por isso a segurança nunca pode depender de barreira única. Camada técnica (firmware assinado, firewall industrial, MFA), camada física (painel trancado, porta USB bloqueada) e camada processual (treinamento, auditoria de terceiro, plano de resposta).

O que implementar, na ordem

A parte 3-3 organiza os controles em sete requisitos fundamentais. Traduzindo para a prática de planta:

Frente	O que implementar
Identificação e autenticação	Conta individual por engenheiro e operador no SCADA, para rastrear quem alterou cada lógica. Fim do login genérico. Autenticar também dispositivo, não só pessoa
Controle de uso	Menor privilégio e papel definido. Quem opera não precisa de permissão para alterar programa. Acesso remoto só com MFA obrigatório, janela temporária aprovada e registrada; nenhuma VPN permanentemente ativa, nenhum software instalado fora da política
Integridade	Validar assinatura digital de firmware antes de aplicar. Hardening: desligar todo serviço, porta e protocolo fora de uso, começando pelo servidor web do CLP, origem de metade da tabela acima
Confidencialidade	OPC UA com criptografia ou TLS onde o equipamento suportar
Fluxo de dados restrito	Zonas, condutos e DMZ industrial. Tráfego direto TI↔OT bloqueado por projeto, não por regra pontual
Resposta a evento	Log habilitado em todo ativo crítico e centralizado fora da zona que ele monitora. Procedimento escrito para o operador: o que isolar, quem avisar, como seguir em manual
Disponibilidade	Backup versionado de programa de CLP, projeto de SCADA, configuração de rede e parâmetro de processo, com restauração testada, porque ter arquivo não é ter capacidade de recuperação

Os sete FR da tabela acima, reorganizados em seis frentes operacionais: a mesma lista, outro corte.

Antes de tudo isso, duas coisas sem as quais nada acima é executável: inventário de ativos (quantos controladores existem, em qual firmware, com qual integração e exposto a quê) e gestão de vulnerabilidade baseada em risco, que é o que transforma a tabela da CISA em plano de ação em vez de pânico.

E duas que pertencem ao contrato, não ao procedimento interno: controle de mídia removível, com quiosque de varredura obrigatório antes de qualquer USB tocar máquina, e homologação de integrador: a parte 2-4 existe exatamente para você exigir prática segura de quem vai comissionar a sua planta, com responsabilidade escrita.

Nada disso é tecnologia de ponta: é higiene básica que a indústria adiou por vinte anos, porque disponibilidade sempre pareceu mais urgente que segurança.

Na prática, esse trade-off não se confirma: o AA26-097A mostra que os atores não derrubaram dados, derrubaram a lógica de parada segura, atacando diretamente a disponibilidade e o safety, e conseguiram porque o controlador estava alcançável e a credencial era fraca. Cibersegurança em OT é confiabilidade operacional, não uma camada de conformidade em cima da operação. Uma planta que trata o tema como custo tende a pagar o preço em parada não programada, na melhor das hipóteses.