Sensores industriais de IoT levam um mesmo número a ser usado para várias finalidades. No campo, concentrações de gases e estados dos equipamentos orientam a interrupção do trabalho ou a inspeção da ventilação. Na gestão e no gerenciamento de carbono, os mesmos registros servem para tendências de longo prazo, eficiência energética e evidências de atividades de redução. Um único dispositivo e uma única rede tornam-se entradas comuns para Safety e Carbon.

Essa arquitetura é eficiente, mas torna-se perigosa quando mistura responsabilidades. A detecção para segurança e o monitoramento ambiental e de carbono podem exigir tempos de resposta, faixas de medição, critérios de instalação, calibração, certificações e comportamentos em caso de falha diferentes. A presença de um sensor para análise de carbono não permite presumir o atendimento às exigências legais ou locais de segurança. Da mesma forma, um valor instantâneo destinado a um alarme de segurança não basta para calcular o desempenho de carbono de longo prazo. A cibersegurança deve conectar as duas finalidades, preservando seus limites funcionais.

Primeiro equívoco: segurança é um problema de vazamento de dados da equipe de TI

As consequências de um incidente de segurança em sensores industriais não se limitam ao vazamento de dados pessoais. Se um invasor elevar o limiar de alarme, uma concentração perigosa poderá parecer normal; se interferir no sinal de controle da ventilação, o ambiente físico poderá mudar. Em sentido oposto, alarmes falsos repetidos podem gerar evacuações e paradas desnecessárias e dessensibilizar os trabalhadores ao alarme verdadeiro. É por isso que o NIST SP 800-82 considera conjuntamente desempenho, confiabilidade e segurança física na proteção de OT.

No lado de Carbon, os valores medidos, o tempo, o estado do dispositivo e os coeficientes de correção ficam comprometidos. A redução pode ser superestimada ou subestimada, lacunas de dados podem ficar sem explicação e relatórios já emitidos podem precisar de nova análise. Assim, a mesma vulnerabilidade surge de um lado como risco físico imediato e, do outro, como risco acumulado de alegações de longo prazo.

As diferenças entre as duas áreas também são importantes. Safety pode ser muito sensível a atrasos de segundos e falsos negativos, enquanto Carbon é sensível à completude, à linhagem e à reprodutibilidade de todo o período. Avaliar os dois objetivos com um único KPI de segurança pode ocultar os riscos centrais. Os controles comuns devem ser operados em conjunto, mas os indicadores de desempenho e critérios de aceitação precisam ser separados por finalidade.

Como o comprometimento de uma conta produz dois resultados

Suponha que uma empresa de manutenção remota use a mesma conta nos gateways de várias fazendas. Se essa conta for comprometida, o invasor poderá alterar configurações de sensores e apagar logs. No fluxo de Safety, mudanças no limiar de alarme ou na interligação com relés podem atrasar a resposta dos trabalhadores. No fluxo de Carbon, alterações na frequência de amostragem e nos valores de correção mudam a tendência antes e depois da intervenção.

A recuperação também é diferente. Para a segurança no local, a prioridade é isolar o dispositivo, verificar a atmosfera com equipamento independente e restabelecer uma condição operacional segura. Para os dados de carbono, é necessário identificar os períodos, dispositivos, resultados de cálculo e relatórios externos afetados. Recuperar a segurança não restaura automaticamente a confiança nos dados históricos. Da mesma forma, restaurar registros antigos não permite afirmar que o estado atual dos gases no local é seguro.

A tabela de resposta a incidentes deve, portanto, conter duas perguntas simultâneas: “as pessoas e os equipamentos estão seguros agora?” e “as evidências de carbono de quais períodos foram afetadas?”. As equipes responsáveis, critérios de isolamento, medição alternativa, retenção de dados, notificação externa e aprovadores da retomada devem ser definidos antecipadamente.

Oito controles que devem ser preservados em comum

O primeiro é a identificação de ativos. Sensores, gateways, firmware, módulos de comunicação, serviços em nuvem e notebooks de manutenção devem ser inventariados, com indicação de seu uso em Safety, Carbon ou ambos. As metas básicas de desempenho da CISA também recomendam a atualização periódica do inventário de ativos de TI e OT. Um dispositivo ausente do inventário não pode ter seus patches, sua calibração, seus certificados nem seu fim de suporte gerenciados.

O segundo é o uso de contas exclusivas e privilégio mínimo. Senhas padrão do fabricante devem ser alteradas, e contas compartilhadas entre fazendas, empresas e dispositivos devem ser evitadas. As permissões para alterar limiares de segurança, coeficientes de correção de carbono, ler dados e implantar firmware devem ser separadas. Mudanças de alto risco exigem múltiplas aprovações e autenticação forte, e o uso de contas de emergência deve gerar imediatamente um alerta.

O terceiro é a segmentação de rede. PCs de escritório, Wi-Fi de visitantes, rede de sensores, rede de controle quando houver funções de controle de segurança e conexão com a nuvem não devem ficar na mesma rede plana. Apenas rotas e portas necessárias devem ser permitidas, e o acesso remoto deve ser controlado por um ponto intermediário, janela aprovada e registro da sessão. A segmentação reduz até onde uma invasão pode se propagar para outras fazendas e controladores.

O quarto é a atualização segura. A origem e a integridade dos arquivos de atualização devem ser verificadas, e somente partes autorizadas podem instalá-los. A compatibilidade e o consumo de recursos são testados antes da implantação, e deve ser possível retornar a uma versão segura em caso de falha. Em dispositivos que afetam Safety, em vez de impor atualização sem interrupção durante a operação, as mudanças devem ocorrer com parada programada e monitoramento alternativo. O fim do suporte e o canal de avisos de vulnerabilidade também devem ser verificados na fase de compra.

O quinto é a proteção de dados e logs. Proteja os dados em trânsito e em repouso e envie históricos de configuração, calibração, permissões, atualizações e reinicializações a um repositório central ou separado. Se o dispositivo de campo for comprometido, seus logs locais também poderão ser apagados. Os horários dos logs devem ser sincronizados a uma referência comum, e o próprio erro de tempo deve ser registrado como um estado.

O sexto é a consciência do estado de segurança. O dispositivo deve informar não apenas se está “online”, mas também se executa firmware aprovado, se a configuração corresponde à referência, se o certificado está válido e se o envio de logs funciona normalmente. O NIST IR 8259A inclui entre suas capacidades essenciais que o dispositivo IoT relate seu próprio estado de cibersegurança e permita acesso apenas a entidades autorizadas.

O sétimo é o backup e teste de recuperação. Configurações de gateway, lista de dispositivos, informações operacionais de certificados, regras, modelos e esquemas de dados devem ser copiados periodicamente, e sua recuperação deve ser testada. O NIST SP 1339 enfatiza a integração do backup de OT ao gerenciamento de mudanças e sua análise em exercícios de recuperação. Se o backup permanecer sempre conectado à rede de produção com as mesmas credenciais, aumenta o risco de danos simultâneos; por isso, devem-se considerar isolamento e controle de acesso.

O oitavo é a responsabilidade da cadeia de suprimentos. O contrato deve definir quem, entre fabricante do sensor, instalador, operadora de telecomunicações, plataforma e entidade verificadora, responde pela notificação de vulnerabilidades, aplicação de patches, desativação de contas, fornecimento de logs e resposta a incidentes. A IEC 62443-2-4 trata dos processos seguros de integração e manutenção dos prestadores de serviços de sistemas de automação e controle industrial. Mais do que exigir apenas o nome de uma norma, é preciso confirmar o escopo real do serviço e suas evidências.

A separação por finalidade também deve aparecer na arquitetura técnica

Sempre que possível, o alarme de segurança deve manter localmente as funções de campo necessárias, de modo que uma falha da nuvem não interrompa o próprio alarme. Alterações na camada de segurança devem ficar restritas a procedimentos e permissões validados. A análise de carbono lê uma cópia dos dados brutos para agregações de longo prazo, mas não recebe permissão para mudar configurações de segurança. Mesmo que uma mesma tela mostre os dois resultados, não é necessário unificar também as permissões de backend e os caminhos de falha.

A finalidade também deve estar indicada no modelo de dados. Separar measurement_purpose, safety_status, carbon_quality_status e calibration_context permite explicar para qual decisão o mesmo valor é adequado. Isso reduz erros como calcular uma média de carbono com valores acima da faixa de um dispositivo de segurança ou reutilizar o valor de um sensor de baixa concentração destinado a carbono como alarme de segurança.

Também são necessários meios físicos de contingência. Devem estar disponíveis detector portátil independente, procedimento manual no local, alarme local e cadeia de comunicação para uso quando houver suspeita sobre a rede ou a plataforma. Para os dados de carbono, uma fila em quarentena, originais somente leitura e a capacidade de suspender a emissão de relatórios servem como meios de resposta. A resiliência depende de permitir uma intervenção humana segura quando a automação falha.

O KPI não termina na taxa de aplicação de patches

Entre os KPIs comuns de segurança podem estar a taxa de identificação dos dispositivos gerenciados, a eliminação de contas padrão, a proporção de firmware ainda suportado, a cobertura de logs, o tempo de tratamento de vulnerabilidades de alto risco e a taxa de sucesso da recuperação de backups. Para Safety, acrescentam-se a disponibilidade do caminho de alarme, o número de alterações não autorizadas de limiares e o tempo de transição para monitoramento alternativo. Para Carbon, acrescentam-se o tempo para identificar o período afetado, o número de falhas na verificação de integridade, as retenções e correções de dados e a completude da linhagem.

Números altos não garantem automaticamente segurança física nem desempenho de carbono. Mesmo com uma taxa de patches de 100%, haverá risco se um firmware incorreto for implantado em massa. O KPI é um sinal que pergunta se o controle funciona; não substitui a avaliação de riscos nem os testes no local. Em particular, “0 incidentes” não prova que não existiram incidentes não detectados, portanto a cobertura dos logs e os exercícios de resposta também devem ser considerados.

Lista de verificação para execução

  • Foi indicado se cada sensor e dado é usado por Safety, Carbon ou ambos?

  • Evita-se confundir uma medição de carbono com o atendimento aos requisitos de certificação e alarme de segurança?

  • As permissões de configuração de segurança e análise de carbono estão separadas, com dupla aprovação para mudanças de alto risco?

  • Foram definidos os limites entre a rede de sensores, a rede de controle de segurança, a rede administrativa e a rede de suporte remoto?

  • As contas padrão dos fabricantes e as contas compartilhadas dos fornecedores foram eliminadas?

  • Existem verificação da origem do firmware, testes prévios, rollback e resposta ao fim do suporte?

  • O estado online e o estado de segurança do dispositivo são monitorados separadamente?

  • A recuperação de Safety e a avaliação do impacto nos dados de Carbon seguem procedimentos distintos?

  • Existem meios de contingência como detecção independente, procedimentos manuais e suspensão da publicação de dados?

  • Os contratos com fornecedores especificam responsabilidades por notificação de vulnerabilidades, patches, logs e incidentes?

  • O backup foi realmente restaurado e o reinício seguro também foi testado?

  • Os KPIs por finalidade medem de fato o risco no local e a qualidade das evidências?

Conclusão: proteger em conjunto a base comum e separar a responsabilidade pelas decisões

A cibersegurança de sensores industriais de IoT não é um recurso adicional entre Safety e Carbon. Se contas, firmware, horário, configurações, rede e logs forem comprometidos, de um lado se abalam as decisões sobre pessoas e equipamentos e, do outro, a confiança no desempenho de redução. Por isso, gestão de ativos, privilégio mínimo, segmentação, atualização segura, logs e backups devem operar como uma base comum.

No entanto, as duas finalidades não devem ser fundidas. O procedimento para confirmar o estado seguro atual é diferente daquele que avalia o impacto sobre dados históricos de carbono. As exigências de certificação, faixa e resposta dos dispositivos também podem ser distintas. Ao proteger conjuntamente a infraestrutura comum e separar as decisões e os limites de falha de cada finalidade, a cibersegurança torna-se uma capacidade operacional que protege ao mesmo tempo segurança física e carbono.

Fontes