OT Sentinel
Inventário dos ativos da planta, detecção de anomalia contra baseline e escalada do alerta direto para incidente regulatório RN 964.
O OT Sentinel cadastra plantas (subestação, PCH, distribuidora, cooperativa, usina) e o inventário de ativos industriais de cada uma: PLC, RTU, IED, HMI, servidor SCADA, historian, gateway e switch, com fabricante, modelo, firmware, protocolos falados (Modbus, DNP3, IEC 61850, OPC UA, EtherNet/IP), nível Purdue e criticidade. Sobre esse inventário roda uma análise determinística que levanta alertas com score de risco de 0 a 100.
A rede OT é tratada como isolada por decisão de projeto: o backend não abre conexão com a planta, não faz sniffing e não tem guard de SSRF porque não sai da rede. A ingestão é sob demanda. Você aponta uma captura já enviada, o pedido reserva crédito (hold), entra numa fila isolada, o worker roda a análise sobre inventário mais baseline, faz upsert dos alertas por fingerprint e só então captura o crédito. Falha em qualquer fase libera a reserva, e um beat ceifa corrida presa há mais de 15 minutos devolvendo o crédito.
O produto não termina no alerta. Um alerta confirmado vira incidente regulatório no RN964 Cockpit com afeta_ot=true mais item de plano de ação, reusando o motor regulatório em vez de duplicá-lo. A rota exige Idempotency-Key e segura um lock na linha do alerta durante toda a escalada, para que um retry de rede não abra dois incidentes regulatórios.
Capacidades em operação
Cada item corresponde a funcionalidade que existe no código e é alcançável por um usuário com o escopo correto.
-
Inventário de plantas e ativos industriais
Criar, listar, ver e editar plantas e ativos, isolado por tenant sob RLS. Nao ha remocao: o ativo so sai da analise marcado como inativo por PATCH, e a planta, uma vez criada, nao pode ser apagada. Vocabulario fechado no schema: nove tipos de ativo, cinco protocolos industriais, nivel Purdue de 0 a 5, quatro faixas de criticidade. Valor fora do vocabulario vira 422 antes de tocar o banco. Vocabulário fechado no schema: nove tipos de ativo, cinco protocolos industriais, nível Purdue de 0 a 5, quatro faixas de criticidade. Valor fora do vocabulário vira 422 antes de tocar o banco.
-
Baseline por ativo
Uma baseline por ativo, gravada por PUT idempotente (ON CONFLICT por tenant+ativo). O conteúdo declara o comportamento normal: protocolos esperados e lista de ativos conhecidos.
-
Quatro detecções determinísticas
Firmware vulnerável por catálogo declarativo de fabricante; tráfego cruzando zona (ativo Purdue 0-1 falando protocolo de campo e OPC UA sem ser gateway); protocolo fora da baseline; dispositivo ausente da lista de conhecidos. O motor é no-raise: ativo malformado é ignorado e registrado, nunca derruba a corrida.
-
Score de risco reproduzível
Peso por tipo de alerta (comando não autorizado 90, tráfego cruzando zona 80, firmware 75, protocolo anômalo 60, scan interno 55, novo dispositivo 40) multiplicado pela severidade. Mesma entrada, mesmo número, sempre.
-
Ingestão com crédito reservado
Hold antes de enfileirar, capture só no sucesso, release em qualquer falha. Idempotency-Key obrigatória na rota (retry não cobra duas vezes) e rate-limit por IP e tenant.
-
Dedup por fingerprint
sha256 de ativo|tipo|localização. O mesmo achado numa segunda corrida atualiza last_seen_at, severidade e score em vez de criar uma linha nova. A fila de alertas não infla com repetição.
-
Triagem com transição validada
new vai para reviewed, confirmed ou dismissed; reviewed vai para confirmed ou dismissed; confirmed e dismissed são terminais. Reabrir um alerta descartado dá 422 com o motivo. Transição para o mesmo estado é no-op.
-
Escalada para o RN964 Cockpit
Cria incidente regulatório com afeta_ot=true e, opcionalmente, item de plano de ação, reusando o serviço RN964. A gravidade cai da severidade do alerta se não for informada. A referência do incidente é gravada de volta no alerta e o alerta vai para confirmed.
-
Evidência redigida antes de gravar
Endereços IP viram <ip> e o trecho é truncado em 256 caracteres no motor, antes da persistência. O que fica no banco e aparece na tela é o padrão, não o endereço da planta.
-
Auditoria append-only
Criação de site e ativo, upsert de baseline, pedido de ingestão, alerta levantado acima do limiar, mudança de status e escalada gravam em audit_log na mesma transação da escrita.
Entregáveis
- Inventário navegável de plantas e ativos industriais, com fabricante, firmware, protocolos e nível Purdue
- Lista de alertas com tipo, severidade, score de risco, evidência redigida e status de triagem
- Histórico de corridas de ingestão com estatísticas por tipo e por severidade
- Incidente RN 964 criado a partir do alerta, com o id do incidente gravado de volta no alerta; do lado do incidente, o alerta aparece apenas no texto da descricao
- Trilha de auditoria gravada em audit_log a cada criacao, triagem e escalada — hoje disponivel no banco, sem tela nem rota de consulta
O que este módulo não faz
Não captura pacote. Não há sniffing, SPAN, TAP nem leitura de PCAP: capture_ref é apenas um ponteiro para um arquivo já enviado, e nenhum código do repositório abre esse arquivo. Os alertas comando_nao_autorizado e scan_interno só nascem se um agente externo escrever eventos em ot_ingest_runs.stats._capture_meta; nenhum código do repositório escreve essa chave (ela só é lida e depois removida), então hoje esses dois tipos nunca disparam. A baseline não é aprendida: comportamento_normal é um JSON que o operador envia por PUT, não uma derivação de tráfego observado. O catálogo de firmware vulnerável tem cinco entradas declarativas (Siemens, Schneider, Allen-Bradley, Rockwell, GE) e não consulta base de CVE. As duas tarefas de IA (otsentinel_anomaly, que explica um alerta, e otsentinel_summary, que resume a corrida) estão escritas e registradas no gateway, mas nenhuma rota as chama e o cliente do front não as expõe: não há como acioná-las. A ingestão é sempre sob demanda; monitoramento contínuo por appliance não existe.
Declaramos o limite porque software de segurança que promete tudo não é auditável. Se o que falta aqui é o que você precisa, o serviço consultivo cobre — ou dizemos que não cobre.
Conecta com
- RN964 Cockpit (incidente regulatório e plano de ação)
- Billing (hold, capture e release de créditos)
- Outbox transacional e fila isolada de scanning
- Gateway de IA da plataforma (tarefas registradas, sem chamador)
Controle de acesso
O acesso é concedido por escopo, não por perfil genérico. Quem só precisa ler não recebe permissão de escrita, e a barreira é o banco de dados, não a interface.
- otsentinel:site:read
- otsentinel:site:write
- otsentinel:asset:read
- otsentinel:asset:write
- otsentinel:baseline:read
- otsentinel:baseline:write
- otsentinel:ingest:read
- otsentinel:ingest:write
- otsentinel:alert:read
- otsentinel:alert:write
Quer ver funcionando?
Demonstração com dado do seu ambiente, não com base de exemplo. É a única forma de saber se serve.