Segurança em IoT industrial é o trabalho de proteger os sensores, controladores, gateways e plataformas em nuvem que conectam equipamentos físicos a redes, para que as leituras sejam confiáveis e ninguém consiga alterar um processo físico sem permissão. Ela abrange o chão de fábrica e o sistema de controle tanto quanto os serviços em nuvem para onde os dados da planta agora seguem.

Conectar equipamentos à nuvem vale a pena, e também muda quem consegue alcançar esses equipamentos. Um responsável de OT ou de TI que planeja essa conexão precisa de uma visão clara do que os atacantes fazem em ambientes industriais, de quais fraquezas eles exploram e de quais controles fazem diferença. Este artigo passa por cada um desses pontos, das redes SCADA até a plataforma em nuvem.

O essencial

  • Os incidentes industriais mais comuns começam na TI, por phishing, credenciais de acesso remoto roubadas ou ransomware, e chegam à operação porque as redes não são separadas.
  • Os sistemas SCADA são vulneráveis por causa de protocolos antigos sem autenticação, redes planas, contas compartilhadas e softwares que não podem receber patches rapidamente.
  • Proteger um sistema SCADA começa por um inventário de ativos e pela segmentação da rede e, depois, passa pelo controle do acesso remoto, das contas e dos backups.
  • A IEC 62443 e a NIST SP 800-82 são os principais frameworks; no lado da nuvem, o que mais importa é o acesso individual por pessoa, chaves com escopo definido e um registro de acessos.

Quais são as maiores ameaças à segurança da IoT industrial?

Os incidentes industriais ganham atenção quando são dramáticos, mas as ameaças que causam mais danos são corriqueiras. Cada ameaça à segurança da IoT industrial descrita abaixo tem um precedente real.

O ransomware que começa na TI é o problema mais frequente. Em maio de 2021, um ransomware atingiu os sistemas corporativos da Colonial Pipeline, nos Estados Unidos. Não houve relatos de que os sistemas de controle do oleoduto tenham sido criptografados, mas mesmo assim a empresa interrompeu a operação do oleoduto por vários dias por precaução, porque não tinha certeza de que o ataque não se espalharia e não conseguia faturar normalmente. Seguiu-se a falta de combustível ao longo da Costa Leste dos EUA, tudo a partir de um incidente na TI do escritório.

Logo atrás vem o acesso remoto roubado ou fraco. Fornecedores e integradores muitas vezes precisam acessar os equipamentos, e uma ferramenta de área de trabalho remota ou uma conta de VPN com senha compartilhada vira também o caminho mais fácil para um atacante.

Credenciais padrão em dispositivos conectados são outra porta de entrada comum. Em 2016, a botnet Mirai assumiu o controle de centenas de milhares de câmeras, roteadores e outros dispositivos IoT simplesmente testando nomes de usuário e senhas padrão de fábrica e depois os usou em ataques massivos de negação de serviço. Gateways e sensores industriais entregues com logins padrão carregam o mesmo risco.

Ataques direcionados a sistemas de controle são mais raros e mais graves. O Stuxnet, descoberto em 2010, manipulou CLPs da Siemens para danificar centrífugas de enriquecimento de urânio no Irã enquanto mostrava valores normais aos operadores. O Triton, encontrado em 2017 em uma planta petroquímica na Arábia Saudita, atacou um sistema instrumentado de segurança Triconex da Schneider Electric, a camada que deveria desligar um processo com segurança.

Por fim, há a ameaça interna e o acidente: um terceirizado com mais acesso do que precisa ou um engenheiro que conecta um notebook à rede de controle para “só dar uma conferida rápida”.

Os dispositivos conectados acrescentam mais uma categoria: o acesso físico. Um gateway instalado em um armário externo destrancado, ou um sensor cuja porta de configuração pode ser alcançada com uma chave de fenda, pode ser resetado, trocado ou usado como porta de entrada para a rede. Locais remotos, como estações de bombeamento e subestações, são visitados raramente, então uma adulteração ali pode passar despercebida por semanas, a menos que sensores de porta ou chaves fim de curso nos armários a reportem.

Vulnerabilidades comuns de segurança em sistemas SCADA

A segurança de sistemas SCADA é difícil por razões estruturais, e não porque os operadores sejam descuidados. As fraquezas comuns se repetem em vários setores.

Protocolos sem autenticação são a fraqueza mais antiga. O Modbus clássico e o DNP3 original foram projetados para redes seriais fechadas; qualquer dispositivo que alcance um controlador pode enviar a ele um comando válido. Existem variantes seguras, mas equipamentos mais antigos muitas vezes não conseguem usá-las.

As redes planas pioram isso. Em muitas plantas, a rede do escritório, os servidores SCADA e os CLPs ficam em uma única rede sem firewall entre eles, então um único notebook infectado consegue alcançar tudo.

Contas compartilhadas em IHMs e estações de engenharia fazem com que todo operador entre como “operador”, o que torna impossível saber quem fez o quê.

A aplicação de patches é lenta. Os servidores SCADA muitas vezes rodam sistemas operacionais antigos porque o software SCADA ou um driver só é certificado para aquela versão, e uma planta não pode reiniciar um processo em andamento todo mês.

A exposição à internet é uma constatação recorrente. Mecanismos de busca que varrem a internet, como o Shodan, encontram com frequência IHMs, CLPs e gateways de acesso remoto acessíveis diretamente de qualquer lugar.

Mídias removíveis e notebooks de engenharia são um caminho mais discreto. As estações de engenharia guardam o software capaz de reprogramar todos os controladores da planta, e muitas vezes são as máquinas às quais os terceirizados se conectam com os próprios notebooks e pendrives. Acredita-se que o Stuxnet tenha chegado à sua rede-alvo isolada por mídia removível, e é por isso que muitas plantas hoje verificam os dispositivos USB em um quiosque antes de permitir que cheguem perto de um sistema de controle.

O ataque de dezembro de 2015 a distribuidoras de energia elétrica da Ucrânia usou várias dessas fraquezas ao mesmo tempo. Os atacantes entraram por e-mails de phishing nas redes de escritório, coletaram credenciais, avançaram para o ambiente de controle e abriram disjuntores remotamente, cortando a energia de cerca de 225.000 clientes por várias horas.

Como proteger um sistema SCADA?

Nenhum produto sozinho protege um sistema SCADA. As etapas abaixo seguem a ordem que a maioria dos frameworks recomenda, porque cada uma facilita a seguinte.

  1. Monte um inventário de ativos. Liste todos os controladores, servidores, estações de trabalho, gateways e conexões de rede, com as versões de firmware.
  2. Segmente a rede. Separe a rede corporativa da rede de controle, com uma DMZ (uma zona intermediária) entre elas para tudo o que os dois lados precisam, como uma cópia do historian. Permita apenas o tráfego necessário, no sentido em que ele é necessário.
  3. Elimine a exposição direta à internet. Nada na rede de controle deve ser acessível pela internet. Os dados que vão para serviços em nuvem devem sair por conexões de saída a partir de um gateway na DMZ.
  4. Controle o acesso remoto. Use um único ponto de entrada gerenciado, com autenticação multifator, contas individuais para fornecedores e acesso ativado só quando necessário.
  5. Dê a cada pessoa a sua própria conta. Substitua logins compartilhados por contas pessoais com o menor privilégio que cada função exige.
  6. Aplique patches onde der e compense onde não der. Teste as atualizações em um sistema reserva; onde uma máquina não puder receber patches, restrinja o que pode se comunicar com ela.
  7. Monitore a rede. Ferramentas de detecção de intrusão industrial aprendem o tráfego normal entre controladores e sinalizam novos dispositivos ou comandos incomuns.
  8. Faça backup e ensaie a recuperação. Mantenha cópias offline dos programas dos CLPs, das configurações do SCADA e das imagens dos servidores, e teste a restauração delas.

A cibersegurança de sistemas SCADA também depende das pessoas. Operadores e engenheiros devem saber como reportar um e-mail suspeito ou um pendrive encontrado no estacionamento, e o plano de resposta a incidentes deve dizer quem decide se o processo continua rodando.

Com orçamento limitado, a ordem importa mais do que a completude. Uma planta que tem um inventário, um firewall entre as redes de escritório e de controle, nenhuma exposição direta à internet e contas pessoais com acesso remoto multifator eliminou os caminhos usados na maioria dos incidentes descritos acima. Monitoramento de rede e níveis formais de segurança valem a pena depois disso, e não no lugar disso.

Normas de segurança para IoT industrial

Dois frameworks dominam as normas de segurança para IoT industrial. A IEC 62443 é uma série de normas internacionais para a segurança de sistemas de automação e controle industrial. Ela introduz zonas (grupos de ativos com as mesmas necessidades de segurança) e conduítes (as conexões controladas entre elas), define níveis de segurança de 1 a 4 contra atacantes cada vez mais capazes e tem partes separadas para proprietários de ativos, integradores de sistemas e fornecedores de produtos.

A NIST SP 800-82, publicada pelo National Institute of Standards and Technology dos EUA, é um guia de segurança para tecnologia operacional. A Revisão 3, lançada em setembro de 2023, ampliou o escopo dos sistemas de controle industrial para a OT em geral e mapeia suas recomendações para o NIST Cybersecurity Framework.

A regulamentação também está avançando. Na União Europeia, a Diretiva NIS2 abrange energia, água, indústria e outros setores, e os estados-membros são obrigados a aplicá-la a partir de outubro de 2024. O Cyber Resilience Act da UE acrescenta requisitos de segurança para produtos com elementos digitais, com a maioria das obrigações valendo a partir de dezembro de 2027, o que vai afetar sensores e gateways conectados vendidos na UE.

Também ajuda saber como elas se relacionam com a ISO/IEC 27001, a norma amplamente usada para sistemas de gestão da segurança da informação. A ISO/IEC 27001 descreve como uma organização gerencia o risco de segurança em geral, enquanto a IEC 62443 acrescenta os requisitos técnicos e organizacionais específicos de sistemas de controle. Muitas empresas industriais usam as duas: a 27001 para a empresa e a TI, a 62443 para as plantas.

Boas práticas de segurança em IoT industrial

O lado de nuvem de uma conexão de IoT industrial exige a mesma disciplina que o lado da planta. Algumas boas práticas de segurança em IoT industrial valem para qualquer plataforma. Os dados devem sair da planta por conexões de saída criptografadas, iniciadas pelo gateway, de modo que nenhuma porta fique aberta para conexões de entrada. As redes de sensores sem fio trazem a própria proteção: o LoRaWAN, por exemplo, criptografa cada mensagem com chaves de sessão AES-128, o que só ajuda se as chaves usadas para provisionar os sensores forem tratadas com cuidado. Cada gateway e cada conexão precisam de credenciais próprias, em vez de uma única credencial compartilhada entre locais. Essas chaves de provisionamento devem ser armazenadas criptografadas e visíveis só para as pessoas que precisam delas. O firmware do gateway merece a mesma atenção com patches que o de um CLP, porque o gateway fica exatamente na fronteira entre a planta e a internet.

No lado da plataforma, os controles de acesso do Kilo funcionam por pessoa e por página, como Editar, Ver ou Sem acesso, para que um terceirizado possa acompanhar dashboards sem conseguir mexer em regras ou conectores. As chaves de API têm escopo por área, com permissões separadas de leitura e escrita, podem ter data de expiração e param de funcionar imediatamente quando são rotacionadas. A Trilha de auditoria registra convites, alterações de permissão e remoções, para que você possa mostrar quem teve acesso e quando.

Perguntas frequentes sobre segurança em IoT industrial

Qual é a diferença entre segurança em IoT industrial e segurança de TI?

Em TI, a confidencialidade normalmente vem primeiro; em sistemas industriais, vêm primeiro a disponibilidade e a segurança operacional, porque parar um processo pode ser perigoso ou caro. Equipamentos industriais também costumam ficar em serviço por 10 a 15 anos, e às vezes por mais de 20, muito mais do que a TI de escritório, então a segurança precisa contornar dispositivos que não podem ser substituídos rapidamente.

Quem é responsável pela cibersegurança de um sistema SCADA?

O proprietário do ativo, a organização que opera a planta, é quem responde por ela. A IEC 62443 distribui o trabalho: fornecedores de produtos constroem dispositivos seguros, integradores os configuram com segurança e o proprietário do ativo opera e mantém o sistema com segurança ao longo de toda a vida útil.

O que é zero trust na segurança de IoT industrial?

Zero trust é uma abordagem, descrita na NIST SP 800-207, em que nenhum usuário ou dispositivo é considerado confiável por causa da sua localização na rede. Cada requisição é autenticada e autorizada. Nas plantas, ela costuma ser aplicada de forma gradual, começando pelo acesso remoto e pela fronteira entre TI e OT.

Antes de conectar qualquer coisa de uma linha de produção, experimente o modelo de acesso com um sinal inofensivo. Coloque um sensor de temperatura em uma sala técnica da fábrica no plano gratuito do Kilo, que não pede dados de pagamento, convide um colega apenas com acesso Ver e crie uma chave de API com escopo de leitura e data de expiração. Depois, rotacione essa chave e confira se um script que usa o valor antigo para de funcionar.