Avaliação de Cibersegurança em Sistemas de Controle Industriais – Industrial Control Systems (ICS)

Os sistemas de controle industrial (ICSs) são parte integrante de infraestruturas críticas, ajudando a facilitar as operações em setores vitais, como energia, óleo e gás, água, transporte, fabricação de produtos químicos. A crescente questão da segurança cibernética e seu impacto na ICS destaca os riscos fundamentais para a infraestrutura crítica de uma nação. Eficientemente abordar questões de segurança cibernética do ICS requer uma compreensão clara dos atuais desafios de segurança e contramedidas defensivas específicas.

O objetivo deste documento é fornecer orientação para assegurar sistemas de controle industrial (ICS), incluindo controle de supervisão e aquisição de dados (SCADA) sistemas de controle distribuído (DCS) e outros sistemas que executam funções de controle. Este artigo fornece uma visão geral do ICS, analisa topologias e arquiteturas de sistemas, identifica ameaças e vulnerabilidades a esses sistemas e fornece contramedidas de segurança recomendadas para mitigar riscos associados.

A gestão eficaz da Cibersegurança é essencial para todos organizações, independentemente do tamanho. Existem muitos padrões e documentos de orientação disponíveis para ajudar as organizações determinar um caminho a seguir.

Embora seja geralmente aceito que a segurança do ambiente de Tecnologia Operacional (OT) requer requisitos diferentes ou medidas adicionais do que a Tecnologia da Informação (IT) de maneira geral, também é verdade que as empresas podem ter dificuldade em implementar grande parte das recomendações por não ter a visibilidade do ambiente.

Os padrões e práticas são frequentemente baseados na suposição que os recursos de engenharia e operações estão disponíveis para definir, implementar e monitorar a tecnologia, os negócios processos e controles associados. Infelizmente, isso muitas vezes não é verdade.

É preciso entender seu risco de segurança cibernética e tomar medidas para reduzir esse risco, assim como fazem com outros riscos de negócio. A ausência de incidentes anteriores ou a crença de que a organização não é um alvo provável, não é justificação suficiente para ignorar este problema.

As indústrias podem estar sobre o risco de muitas ameaças, incluindo hackers amadores e profissionais, ativistas ambientais, funcionários descontentes ou contratados, erros humanos e até mesmo nação estados ou terroristas. Além disso, muitos incidentes de segurança cibernética são um resultado de acidentes ou ações não intencionais. Uma empresa não precisa ser um alvo específico para ser afetado.

A consequência para uma indústria pode variar tremendamente com base na natureza das operações e nas vulnerabilidades de cada uma. É essencial que as vulnerabilidades sejam reconhecidas que essas vulnerabilidades sejam mitigadas para minimizar a probabilidade de eventos com alto potencial destrutivo.

Visibilidade e Vulnerabilidades Comuns

A deficiência pode surgir de um problema técnico (como um erro de software), questões processuais (falta de política ou norma) ou pessoas (falta de treinamento).

Existe algumas normas e frameworks que podem auxiliar na Cibersegurança do ambiente industrial como, ISA/IEC 62443 (ISA99), NIST 800-82 e NERP CIP para o setor de energia.

A Sociedade Internacional de Automação (ISA) possui o padrão ISA/IEC 62443 (Segurança para Automação Industrial e Control Systems) que fornece orientações detalhadas sobre como criar um sistema de gerenciamento de segurança cibernética para ambientes OT.

A realização de uma avaliação de segurança cibernética é um passo importante em um ciclo de vida de TI industrial porque pode abordar de forma proativa quaisquer deficiências e vulnerabilidades. A intenção e propósito é identificar a segurança pontos fracos e seguir com recomendações úteis que irão prontamente suprir as lacunas antes qualquer violação de segurança pode ocorrer. Uma das técnicas envolvidas, conhecida como vulnerabilidade do sistema avaliação, é descobrir se os sistemas contêm alguma vulnerabilidade que é suscetível a um ataque cibernético malicioso.

A questão é se uma avaliação de segurança cibernética para automação industrial deve incluir a penetração testando como uma extensão da avaliação de vulnerabilidade do sistema.

Antes de prosseguirmos, é importante fazer uma distinção clara entre avaliar normas, avaliação de vulnerabilidade do sistema e testes de penetração.

Avaliação de normas

A ISA/IEC 62443 possui uma série de documentos como podemos ver na imagem abaixo, porem o ISA/IEC 62443-2-4 possui os controles necessários para avaliação.

A IEC 62443 2-4 foi publicada para fornecer segurança requisitos especificamente para fornecedores de serviços de ICS e proprietários de ativos.

Uma avaliação dessa norma ajuda a entender melhor esses requisitos, identificar potenciais lacunas e encontrar maneiras pragmáticas e rápidas de melhorar a postura de segurança cibernética, incluindo pessoas, processos e tecnologia.

A norma ISA/IEC 62443 possui 12 capítulos onde pode-se ver todos os itens de cibersegurança no detalhe, conforme imagem abaixo:

Backup and Restore é o item com mais problemas, pois um PLC não possui Logs, sistemas de Backup, auditoria de quem faz alterações. Qualquer perda de configuração ou mesmo um erro na configuração causa um grande problema. Abaixo uma imagem de como pode ser feito o Backup de PLC.

Um outro item com muita preocupação é Remote Access, uma vez que consultores constamente precisam dar manutenções em Controllers estes não são confiáveis e muitas vezes podem trazer malwares ou mesmo atacar diretamente a planta e seus controladores.

Ter a visibilidade e maturidade do processo conforme a imagem abaixo é muito importante para melhor maturiadade do ambiente.

Control-Plane vs Data-Plane

Mas há outro problema aqui: ao contrário das redes de TI, no ICS há uma separação entre os protocolos Data-Plane e Control-Plane:

Data-Plane: usado para passar parâmetros e registros entre os aplicativos HMI SCADA e o I/O. Os protocolos padrão HMI e SCADA (como Modbus, Profinet, DNP3) são usados aqui e são totalmente documentados porque os fornecedores permitem a integração com todos os tipos de soluções de software.

Plano de Controle: inclui todas as atividades de engenharia, ou seja, reprogramar o controlador, upload/download do firmware, etc. Esses são protocolos de engenharia exclusivos – por quê? Porque quando os fornecedores de automação os projetaram, eles criaram um software específico para desenvolvê-los. O pensamento era que você só deveria usar o software do fornecedor para projetar esses dispositivos. Portanto, esses protocolos não são apenas proprietários, são normalmente não documentados e não nomeados. Isso dificulta monitorá-los.

Hoje sabemos que algumas ferramentas foram desenvolvidas explorando esses protocolos – a maioria deles para fins de pesquisa, mas não apenas. Então nós temos que monitorá-los e explorá-los para um

Além disso, se você comparar com as redes de TI, as atividades de engenharia executadas nos protocolos do Plano de Controle = atividades privilegiadas. Você nunca permitiria que uma atividade privilegiada fosse monitorada em uma rede de TI – por que permitir isso em sua rede OT/ICS? Portanto Avaliar as vulnerabilidades de Control-Plane é extremamente fundamental.

Avaliação de vulnerabilidade do sistema

Em uma avaliação de vulnerabilidade, os dados são coletados do sistema e comparados com problemas documentados para deduzir se o sistema é vulnerável a quaisquer explorações conhecidas. Quando dizemos “questões documentadas”, estamos referindo-se a vulnerabilidades ou deficiências de sistemas que foram descobertas e, portanto, conhecidas e, portanto, eles foram documentados e, provavelmente, disponibilizados ao público para conscientização. A maioria da época, a publicação de vulnerabilidades também teria incluído medidas corretivas para abordar a fraqueza.

Estas vulnerabilidades são de todo o sistema inclusive PLCs e HMI. Abaixo um exemplo de PLC com vulnerabilidade de Control-Plane reconhecida.

Teste de penetração ICS

O teste de penetração ICS, no entanto, dá mais um passo para simular a exploração no sistema encontrado vulnerabilidade para confirmar se uma violação de segurança ou um dano catastrófico pode realmente ser infligido no sistema se fosse um verdadeiro ataque cibernético.

A exploração por envolver técnicas são freqüentemente invasivas e potencialmente resultam em mudanças nas configurações do sistema, o que uma tentativa mal-intencionada pode ter uma meta final de tornar a funcionalidade do sistema incapaz de executar a sua original pretende ou reduzindo sua capacidade ou até mesmo em alguns casos desabilitando-a totalmente, como em um sistema total de downshutdown. Deve ser feita de maneira cautelosa, pois normalmente industrias não possuem ambiente de homologação.

Outra técnica de exploração mais sofisticada pode ser extrair dados críticos, como informações confidenciais, mas deixando o sistema intacto e ainda operando como se nada de desagradável aconteceu.

Como o teste de penetração tem uma conclusão para a investigação é um benefício adicional para descobrir exaustivamente a realidade de ameaça de segurança cibernética aos seus sistemas.

Muitos, no entanto, podem não estar cientes de que um teste de penetração pode ter o potencial de desestabilizar sistema. Em certos casos, o impacto no sistema é irreversível, de modo que ele não pode mais ser restaurado de volta ao seu estado original. Em alguma outra situação, o impacto da desestabilização pode até propagar o efeito a montante ou a jusante, afetando outros sistemas interconectados. Em industrial sistemas de controle – esse impacto tem um risco muito alto de desestabilizar os processos de potencialmente resultante de uma reação química volátil que representa perigo à segurança humana e também à meio Ambiente.

Então, perguntamos: O teste de penetração é recomendado para uma avaliação de segurança cibernética no ICS? Se for com a finalidade de confirmar uma vulnerabilidade encontrada – que, por exemplo, já tem um CVE registrado para ele, e, portanto, as correções e patch provavelmente também estão disponíveis – por que a necessidade de provar a sua mais explorabilidade?

Conclusão

No panorama do ICS de hoje, muitas plantas ainda precisam ser avaliadas para verificar a integridade da segurança de suas sistemas, processos e operações. O ambiente ICS é muito sensível a paradas e portanto uma verificação de processos e normas, alinhado com uma ampla avaliação de vulnerabilidade inicialmente se faz necessário.

Para eles, a urgência pode ser a realização de uma avaliação de segurança imediata e ampla, porque os resultados das primeiras avaliações são geralmente esporádicos e abrangentes.

Muitas vezes também, lacunas de segurança tendem a ser inter-relacionados de uma maneira que uma vulnerabilidade do sistema primário pode derivar fraquezas. Portanto, uma fraqueza inerente coletiva pode ser tratada quando um único patch do sistema é aplicado. É assim que os service packs únicos funcionam em comparação com os hotfixes individuais.

Corrigido estes GAPs e ainda permanecendo vulnerabilidades um teste mais profundo caso necessário.

O melhor para o ambiente ICS é seguir as normas e manter um bom sistema de detecção e resposta a incidentes, com visibilidade constante do ambiente e detecção de vulnerabilidades de todo o ambiente principalmente os protocolos Control-Plane.