Cookies de análise. Com sua permissão, usamos o Google Analytics, que grava cookies, para entender como o site é usado. Sem ela, nada é enviado ao Google. Saiba mais.
Guia técnico · segurança OT na prática
Cibersegurança OT (tecnologia operacional) é a proteção dos sistemas que monitoram e controlam processos físicos: CLPs (controladores lógicos programáveis), supervisórios SCADA (supervisão e aquisição de dados), redes industriais, servidores e estações de engenharia. Ela difere da segurança de TI em um ponto essencial — a prioridade é manter o processo disponível e as pessoas seguras — e por isso precisa ser projetada dentro da planta, não aplicada por cima dela.
Atualizado em · Equipe técnica Integra
Fundamentos
As boas práticas de TI continuam valendo — o que muda é a ordem das prioridades, o ciclo de vida dos ativos e o custo de errar. Cinco diferenças explicam a maior parte dos conflitos entre as duas disciplinas.
01
Na TI (tecnologia da informação), a confidencialidade do dado costuma liderar. Na OT, o topo da lista é manter o processo disponível e as pessoas seguras: um controle que derruba a produção pode causar mais dano que o incidente que tentava evitar.
02
Controladores e supervisórios operam por décadas, com sistemas operacionais que saem de suporte muito antes da troca do equipamento. A segurança precisa conviver com o legado, não fingir que ele não existe.
03
Boa parte dos protocolos industriais nasceu para redes isoladas: quem alcança a rede frequentemente consegue ler e escrever no controlador. A proteção vem da arquitetura ao redor, não do protocolo.
04
Patch, reinicialização e teste dependem de parada planejada. A rotina de atualização mensal da TI não se transfere para a planta sem análise de impacto e janela negociada.
05
Varredura agressiva de rede, agente pesado e bloqueio automático podem travar equipamentos que não foram projetados para esse tráfego. Controles de TI precisam ser validados no contexto OT antes de tocar a produção.
Essas diferenças não são desculpa para fazer menos segurança — são o motivo para fazer segurança projetada para o ambiente industrial. As referências que orientam esse projeto são a série ISA/IEC 62443 e o NIST SP 800-82, tratadas ao longo deste guia. Como as duas referências se aplicam →
Diagnóstico honesto
Antes de discutir ameaças sofisticadas, vale olhar para o que se repete em plantas brasileiras de todos os portes: exposições criadas por conveniência, urgência e falta de projeto.
O alvo inicial costuma ser a rede corporativa, mas o efeito chega à planta: servidores compartilhados, conexões diretas entre TI e OT e a decisão difícil de parar por precaução quando não se sabe até onde o ataque avançou. Sem segmentação e sem backup restaurável, a extensão da parada passa a depender da sorte, não do projeto.
Ferramentas de acesso instaladas caso a caso para suporte de fornecedor, sem inventário central, sem autenticação multifator (MFA) e sem registro de sessão. Cada uma é uma porta que a planta não enxerga — e que continua aberta depois que o suporte termina.
Quando escritório e chão de fábrica compartilham a mesma rede, um notebook infectado ou um dispositivo desconhecido alcança controladores que aceitam comandos sem autenticação. A segmentação em zonas e conduítes existe para conter esse movimento lateral.
Servidores SCADA e estações de engenharia com usuário compartilhado, sessão de administrador permanente, portas USB livres e serviços desnecessários ativos. São os computadores mais críticos da planta operando com menos controle que um notebook corporativo.
O backup existe, mas não passou por teste de restauração; programas de CLP vivem no notebook de alguém; não há cópia isolada do ambiente. O custo dessa lacuna só aparece no pior momento possível.
Não se protege o que não se conhece. Conversores esquecidos, conexões de fornecedor não documentadas e equipamentos fora do inventário são comuns em plantas com décadas de expansões — e cada um é superfície de ataque.
Arquitetura de segurança
A pergunta de arquitetura não é qual firewall comprar, e sim onde ficam as fronteiras da planta e quanto rigor cada uma exige. Três conceitos organizam essa resposta.
O modelo Purdue organiza a planta em níveis funcionais — do processo físico (nível 0) e controle (nível 1) à supervisão (nível 2), operações (nível 3) e sistemas corporativos (níveis 4 e 5) — e as arquiteturas derivadas dele (NIST SP 800-82, CPwE) acrescentam a IDMZ entre os domínios industrial e corporativo. Ele dá o vocabulário comum para discutir onde cada fluxo deve, e não deve, passar.
A IEC 62443-3-2 estrutura a análise: o sistema em avaliação é particionado em zonas — grupos de ativos com requisitos de segurança semelhantes — e conduítes, os canais de comunicação entre elas. Cada zona e conduíte recebe a própria avaliação de risco, em vez de um controle único aplicado à planta inteira.
O resultado da análise é o SL-T (Security Level Target): o nível de segurança alvo de cada zona e conduíte. Nem toda zona precisa do mesmo rigor — proteger a célula de envase e o historian com o mesmo investimento ignora o risco real de cada um. O SL-T orienta onde investir primeiro.
SL 1
Proteção contra violação casual ou coincidente, sem intenção de ataque.
SL 2
Proteção contra violação intencional com meios simples, poucos recursos, habilidades genéricas e baixa motivação.
SL 3
Proteção contra ataque com meios sofisticados, recursos moderados, habilidades específicas de sistemas industriais e motivação moderada.
SL 4
Proteção contra ataque com meios sofisticados, recursos amplos, habilidades específicas e alta motivação.
O modelo Purdue descreve funções; a IEC 62443 define zonas por risco. Na prática os dois se combinam: os níveis ajudam a enxergar a planta, e a análise de risco decide onde ficam as fronteiras reais — quase sempre com a IDMZ como a fronteira mais importante entre TI e OT.
Roteiro de evolução
Segurança OT não é um projeto único, é uma sequência de capacidades. A ordem importa: cada etapa cria a base que torna a seguinte viável — e começar pelo fim costuma desperdiçar investimento.
01
Levantar ativos, versões de firmware e software, conexões externas, acessos remotos e fluxos entre redes. Sem inventário, decisões de segurança são apostas.
Como enxergar a rede OT →02
Particionar a rede em zonas e conduítes conforme o risco, com IDMZ entre os domínios corporativo e industrial e regras explícitas para o tráfego que atravessa fronteiras.
Redes industriais e IEC 62443 →03
Reduzir superfície de ataque: contas e privilégios revisados, serviços e portas desnecessários desativados, mídias removíveis controladas e configurações documentadas.
Hardening industrial →04
Observar a rede industrial de forma passiva, estabelecer o comportamento normal e alarmar desvios: ativo novo, conexão nova, tráfego inesperado entre zonas.
Monitoramento de redes industriais →05
Tratar atualização como decisão de risco: priorizar o que é explorável e crítico, usar controles compensatórios quando não há janela e registrar o que ficou pendente — em vez de aplicar tudo ou não aplicar nada.
Patch management em OT →06
Definir RTO e RPO (objetivos de tempo de recuperação e de perda aceitável de dados) por sistema, manter cópia isolada e testar a restauração de verdade — incluindo programas de CLP e configurações de rede.
Backup e recuperação de desastres →07
Identidade individual em vez de usuário compartilhado, diretório segregado para o ambiente OT e acesso remoto de terceiros com aprovação, registro e prazo de expiração.
Active Directory em OT →E depois?
Maturidade não é chegar ao fim da lista: é revisar risco, inventário e controles a cada mudança relevante da planta. A triagem técnica ajuda a identificar em qual etapa sua operação está hoje.
Solicitar triagem técnica →Quem executa importa
O diagnóstico vira proteção quando se transforma em mudanças de rede, servidores e controle, com fases, janelas e critérios de validação definidos pelo risco operacional. Essa execução exige engenharia de automação.
Zonas, conduítes e IDMZ são decisões de projeto de rede e de arquitetura de sistema. Quando entram no início — no documento de arquitetura, na especificação funcional — custam uma fração do que custa o retrofit depois da partida.
Segmentar uma rede em produção, trocar switches, ativar firewall entre zonas: cada passo interage com intertravamentos, redundância e janelas de parada. Quem programa o CLP e comissiona o sistema sabe o que pode ser tocado, quando e com qual plano de retorno.
Regras de firewall, hardening e mudanças de rede passam por teste antes da janela de parada — como em uma entrega de automação bem conduzida: FAT (teste de aceitação em fábrica), plano de comissionamento, critério de aceite e rollback.
Controle sem dono degrada. Quando a segurança faz parte do escopo de automação — documentada no as-built, coberta pelo contrato de suporte — ela é mantida junto com o sistema, em vez de abandonada quando o projeto termina.
É por isso que este guia trata cibersegurança OT como disciplina de engenharia, não como produto de prateleira. A Integra atua como integradora de sistemas de automação desde 2016: segurança entra como requisito dos projetos de rede, controle e supervisão — dentro do escopo, com critério de aceite e documentação de handover.
Use a necessidade atual para escolher o próximo passo. O guia apoia a decisão; a avaliação dos sistemas e a execução exigem escopo, métodos de coleta e responsabilidades acordados com a planta.
O diagnóstico delimita ativos, documentação e riscos, registra lacunas e organiza um roadmap. É o caminho quando a planta ainda precisa definir prioridades antes de contratar mudanças.
Ver escopo do diagnóstico de cibersegurança OT →A engenharia de redes transforma requisitos em arquitetura, fluxos autorizados, plano de implantação, testes e documentação. Depende do diagnóstico e das janelas acordadas com a operação.
Ver engenharia de redes e segmentação →A referência de ISA/IEC 62443 e NIST SP 800-82 explica a aplicação dos conceitos e os limites do escopo. Diagnóstico, projeto e certificação formal são trabalhos diferentes.
Consultar as referências e seus limites →Referência rápida
Definições curtas para os termos que aparecem em análises de risco, propostas de segmentação e conversas entre TI, automação e gestão.
Respostas diretas
Base editorial
O guia organiza conceitos para decisão. Normas e guias oficiais permanecem como referência para requisitos de projeto, análise de risco e certificação.
Guide to Operational Technology (OT) Security, publicado em setembro de 2023: guia de referência para programas de segurança OT, topologias e controles.
Consultar fonte oficial ↗Security risk assessment for system design: define a partição do sistema em zonas e conduítes, a avaliação de risco por zona e a atribuição de SL-T.
Consultar fonte oficial ↗Visão geral da família de normas para segurança de sistemas de automação e controle industrial (IACS), mantida pela ISA e pela IEC.
Consultar fonte oficial ↗Conteúdo educativo. A aplicação de normas, níveis de segurança, requisitos legais e critérios de aceite depende do processo, da jurisdição, da análise de risco e do escopo contratado.
A triagem técnica levanta contexto, base instalada e o risco que preocupa hoje — antes de propor diagnóstico, arquitetura ou cronograma.
Ou ligue (44) 3305-7147 · WhatsApp (44) 99952-3947 Prazo-alvo de retorno inicial: 1 dia útil.
