Três empresas de distribuição de energia sofreram um ataque cibernético no oeste da Ucrânia em 23 de dezembro de 2015. Como as informações forenses são extensas do ponto de vista técnico, é uma oportunidade de colocar ISA/ IEC-62443-3-3: Segurança para sistemas de automação e controle industrial Parte 3-3: Requisitos de segurança do sistema e níveis de segurança testado com um exemplo da vida real. Várias fontes foram usadas para este propósito, geralmente fornecendo informações excepcionalmente detalhadas. Esta postagem do blog:

  • Revise a cinemática do ataque usando os relatórios disponíveis e suposições razoáveis ​​com base em nossa experiência em cenários de ataque cibernético e em sistemas e vulnerabilidades de tecnologia operacional típica (OT).
  • Apresenta uma metodologia para avaliar o nível de segurança: alcançado (SL-A) por um dos distribuidores ucranianos (correspondente ao melhor caso documentado)
  • Aplicar esta metodologia; apresenta e discute a estimativa SL-A; revisar este SL-A de acordo com o requisito fundamental (FR); e deriva conclusões e conclusões
  • Avalie o nível de segurança (SL-T) que deve ser direcionado para detectar e impedir ataques semelhantes

Cinemática do ataque cibernético

Embora o ataque em si tenha sido desencadeado em 23 de dezembro de 2015, foi cuidadosamente planejado. Redes e sistemas foram comprometidos oito meses antes. Levar este período de tempo em consideração é essencial para uma compreensão adequada das formas e meios a serem usados ​​para detectar e, eventualmente, prevenir um ataque semelhante.

Nossa análise do ataque cibernético é tríplice:

  1. Intrusão inicial da rede de tecnologia da informação (TI) por meio de spear phishing
  2. Coleta de inteligência em redes e sistemas de TI e OT usando malware flexível BlackEnergy: varreduras de rede, saltos de um sistema para outro, identificação de vulnerabilidades de dispositivos, design de ataques e instalação de mais malwares e backdoors
  3. Ataque que durou minutos 10 em dezembro 23.

Etapa 1: malware no correio!

Na primavera de 2015, uma variante do malware BlackEnergy foi ativada quando um funcionário da Prykarpattya Oblenergo abriu um anexo do Excel de um e-mail. BlackEnergy é um "pacote" de malware que foi notícia pela primeira vez em 2014, quando foi amplamente usado para se infiltrar em serviços públicos de energia. Seu objetivo era reunir informações sobre infraestrutura e redes e ajudar na preparação para futuros ataques cibernéticos.

O diagrama na Figura 1 é uma visão simplificada das arquiteturas de rede (ou seja, Internet, TI, OT) e ajudará a representar cada etapa do ataque cibernético. O hacker é mostrado como o "cara do chapéu preto" no canto superior direito. O hacker usou a conexão de TI do utilitário com a Internet como canal para preparar e, por fim, desencadear o ataque cibernético.

Podemos ver que a empresa tinha os próprios firewalls configurados, um entre a rede de TI e a Internet e o segundo entre a rede de TI e OT (industrial). A rede OT incluía um controle de supervisão de sistema de gerenciamento de aquisição e distribuição de dados (DMS) com servidores e estações de trabalho e um conjunto de gateways usados ​​para enviar ordens do DMS para unidades terminais remotas que controlavam os comutadores e outros equipamentos em subestações elétricas. Dispositivos adicionais também foram conectados à rede (por exemplo, estações de trabalho de engenharia e servidores históricos), mas não são relevantes para a cinemática do ataque.

Nesta etapa, o hacker conseguiu comprometer um laptop de escritório graças ao anexo de e-mail BlackEnergy. Isso é difícil de evitar, enquanto as pessoas estão abrindo anexos de e-mail com aparência legítima.

Figura 1 Diagrama simplificado da arquitetura de um dos sistemas de controle.

Figura 2 Segunda etapa do ataque a um dos sistemas de controle.

Etapa 2: preparação de ataques, verificações de rede e ameaças persistentes avançadas (APT)

Durante vários meses no verão de 2015, o malware BlackEnergy foi controlado remotamente para coletar dados, saltar de host para host, detectar vulnerabilidades e até mesmo alcançar a rede OT e realizar atividades de “reconhecimento” semelhantes.

A análise de dados forense nesta fase está incompleta, porque o hacker executou uma limpeza e removeu vários discos durante o ataque real. No entanto, a análise anterior da BlackEnergy, bem como as considerações razoáveis ​​do processo padrão usado para ataques cibernéticos, tornam a próxima reconstituição provável com razoável confiança.

Conforme mostrado na Figura 2, durante a etapa dois, uma grande quantidade de atividade de rede ocorreu. O malware controlado remotamente varreu a rede de TI, detectou uma conexão aberta de um sistema de TI para uma plataforma de monitoramento de OT, realizou varreduras de rede de OT, coletou informações de componentes de OT e, finalmente, instalou componentes de malware prontos para disparar em ambos como em sistemas OT.

Essa fase durou semanas, talvez meses, e permitiu o desenvolvimento de exploits personalizados. UMA  explorar  é um pequeno software projetado e desenvolvido para explorar uma vulnerabilidade específica. Ele é incorporado como uma carga útil em malware que é configurado para entregar a carga útil para execução em um alvo. Na realidade, esse esforço foi um tanto limitado. O único código de malware original desenvolvido foi o que foi necessário para cancelar os gateways como parte da etapa três. E isso realmente não foi um "esforço" significativo, já que os gateways há muito foram sinalizados como dispositivos vulneráveis.

Etapa 3: acionar o ciberataque

À tarde, dois dias antes do Natal, como indicado por um operador, o mouse passou pela interface homem-máquina (HMI) e começou a desligar os interruptores remotamente.

Quando o operador local tentou recuperar o controle da interface de monitoramento, ele foi desconectado e não pôde efetuar login novamente porque a senha havia sido alterada (Figura 3).

Todo o ataque durou apenas alguns minutos. O hacker usou malware pré-instalado para assumir o controle remoto da IHM e desligar a maioria dos switches de rede. Malware adicional, em particular o exploit desenvolvido de forma personalizada, foi usado para evitar que a operadora recuperasse o controle da rede, excluindo muitos discos (usando KillDisk) e sobrescrevendo o firmware do gateway Ethernet serial com código aleatório, para o que os dispositivos transformam em pedaços irrecuperáveis ​​de lixo.

Atividades adicionais de “bônus” incluíam a realização de um ataque de negação de serviço distribuído no call center, impedindo que os clientes entrassem em contato com o distribuidor e desconectassem a fonte de alimentação ininterrupta para desligar o centro de controle (Figura 4) .

Obviamente, essa etapa teve como objetivo desconectar a energia de centenas de milhares de assinantes no oeste da Ucrânia conectados à rede. No entanto, a maior parte do esforço foi gasta para garantir que a energia não fosse reconectada - todo o malware específico foi desenvolvido para esse propósito. Uma vez ativado, a única maneira de o operador evitar esse problema era parar o ataque enquanto ele estava em andamento.

Mas o ataque foi rápido demais para permitir qualquer reação; na verdade, em um ambiente de infraestrutura crítica, as ações do operador podem causar problemas de segurança. Portanto, apenas ações predefinidas são permitidas e os operadores devem seguir as diretrizes para realizar qualquer ação. No caso de uma situação operacional imprevista, eles não têm poderes para tomar decisões no terreno. Esta foi exatamente a situação no caso da Ucrânia. As ações "óbvias" poderiam ter interrompido o ataque (como puxar o cabo que conecta o OT à rede de TI), mas não se pode esperar que operadores não treinados tomem tais medidas disruptivas por sua própria iniciativa em uma situação estressante em que haja erros eles são perfeitamente possíveis.

Figura 3 Terceira etapa (1) do ataque a um dos sistemas de controle.

Figura 4 Terceiro pagamento (2) do ataque a um dos sistemas de controle.

Aprendizagem

Em retrospecto, depois de conhecermos todos os detalhes sobre o ataque cibernético, parece fácil detectar, dadas as atividades de rede e os níveis de atividade razoavelmente significativos que ocorrem em vários sistemas.

Mas é realmente um desafio descobrir exatamente o que está acontecendo em uma rede, especialmente se você não tem ideia do que é a atividade "normal" da rede. Uma vez que as conexões da Internet e da rede OT são permitidas, é difícil detectar sinais de ataques cibernéticos devido ao volume de tráfego. O monitoramento contínuo é necessário com a capacidade de identificar os poucos pacotes suspeitos no meio de todos os pacotes "bons". Provas múltiplas do conceito de tal detecção foram realizadas usando TI correlacionada e detecção de OT e foram apresentadas nas conferências GovWare 2016 em Cingapura, no Exera Cybersecurity days 2016 em Paris e na SEE Cybersecurity week 2016 em Rennes, França.

Existem outros meios e o uso de ISA/ IEC-62443-3-3 para analisar a segurança do distribuidor ucraniano ajuda a identificar todos os controles ausentes que poderiam ter impedido o ataque cibernético.

Metodologia para estimar o SL-A

ISA/ IEC-62443-3-3 lista os requisitos do sistema 51 (SR) estruturados em sete requisitos fundamentais (FR). Cada SR pode ser reforçado por um ou mais aprimoramentos de requisitos (RE) selecionados com base nos níveis de segurança específicos (SL-Ts). Portanto, a avaliação dos níveis de segurança alcançados (SL-As) pode ser realizada:

  • Para cada SR, verifique se os requisitos básicos e as possíveis melhorias são atendidos
  • Para cada FR, o SL-A é o nível máximo atingido em todos os SRs
  • A avaliação geral SL-A é o nível máximo atingido em todas as FR

A tabela 1 resume o resultado da avaliação em um RF que possui poucos SRs para fins de ilustração.

A matriz da tabela 1 é extraída diretamente do apêndice ISA/ IEC-62443-3-3 que resume os requisitos. Em relação ao caso Prykarpattya Oblenergo e para cada requisito (básico ou ER), identificamos três casos possíveis:

  • As informações disponíveis são suficientes para considerar o requisito atendido: ✔
  • As informações disponíveis são suficientes para descobrir que o requisito foi perdido: ✘
  • Não é possível avaliar se o requisito foi ou não cumprido  😕

Tabela 1 Resultado da avaliação SL-A para o FR5.

Depois de concluída, a tabela 1 corresponde à avaliação real do FR5 para o caso em questão (Ucrânia), o que leva a um SL-A do 2. Isso significa que a segmentação de rede ("restringir o fluxo de dados") foi implementada pelo menos para os requisitos básicos e para algumas melhorias nos requisitos.

Aplicação ao caso da Ucrânia

Essa análise foi realizada em todos os SRs e foram identificadas duas situações:

  • O SR pode não ser aplicável (por exemplo, requisitos para comunicação sem fio na ausência de tais meios).
  • Podemos não ter evidência direta de que o SR foi cumprido ou perdido, mas a dedução com base em instalações semelhantes típicas e outras entradas permite especulações razoáveis ​​sobre se o requisito foi ou não cumprido.

Por exemplo, podemos considerar a falta de "backup", porque os discos não puderam ser restaurados várias semanas após o ataque. Considerando SR 5.2 RE (1), é razoável considerar que a conexão de shell seguro (SSH) através do firewall foi uma exceção e todo o outro tráfego foi negado. O hacker não teria passado pelo fardo de capturar a senha se houvesse maneiras mais diretas de acessar a rede OT.

Do 51 SR, quatro foram considerados "não aplicáveis" (1.6, 1.8, 1.9 e 2.2) e o 25 não pôde ser determinado (" ? "). Este é um número grande, o que significa que apenas metade dos RSs puderam realmente ser avaliados. Na verdade, isso favorece um SL-A mais alto, porque apenas os RS avaliados são levados em consideração e, por padrão, consideramos o RS como potencialmente atendido.

Outra decisão foi tomada em termos de apresentação dos dados. Em vez de apresentar as informações com um requisito (básico e ER) por linha, como na Tabela 1, optamos por ter uma linha por RS e listar o aumento de ER nas várias colunas. A Tabela 2 ilustra a mesma avaliação do FR5 usando este modo de exibição.

Tabela 2 Estimação de SL-A (FR5).

Tabela 3 Estimativa geral dos sete FR.

Finalmente, uma visão mais sintetizada sem texto RE foi usada para apresentar a imagem geral de todos os FRs, que de outra forma abrangeria várias páginas. As SLs gerais estimadas são reagrupadas na Tabela 3.

Os resultados representados na Tabela 3 são muito ruins. Além disso, metade dos requisitos não puderam ser avaliados e, portanto, esta opinião é provavelmente otimista.

No lado direito, os SL-As estimados são listados para os sete FRs. Podemos ver que os SL-As são zero, exceto para:

  • FR5 (fluxo de dados restrito): Principalmente devido ao firewall IT-IACS e controle de fluxo rígido. Atender a este requisito significa que o tráfego entre zonas na rede OT deve ser filtrado. O exemplo do ataque ucraniano demonstra que este requisito pode ser revisado em futuras atualizações do padrão:
    • A conformidade com o SR 5.2 não requer um para definir zonas. Como no caso ucraniano, todos os sistemas do AT podiam interagir entre si. Observe que as recomendações sobre definições de zona estão disponíveis em ISA/ IEC-62443-3-2 a ser usado antes de aplicar ISA/ IEC-62443-3-3.
    • O requisito para filtragem de tráfego de zona cruzada é definido para SL = 1. O retorno sobre o investimento é questionável, pois o custo e o risco da filtragem de tráfego são altos, e a eficácia é questionável, conforme demonstrado pelo caso de Ucrânia. Pode fazer mais sentido exigir detecção assim que SL-T = 1 for o alvo e exigir filtragem / prevenção ativa para SLs mais altos.
  • FR6 (resposta oportuna a eventos): a própria existência de informações forenses detalhadas é o resultado de um registro mínimo em vigor.

A tabela 4 mostra uma análise detalhada de alguns dos SRs mais significativos.

Tabela 4 Análise específica para alguns dos SRs mais significativos.

Aprendizagem

No início, olhando para os relatórios sobre as várias verificações de segurança da operadora ucraniana, parecia que eles haviam prestado muita atenção às questões de segurança cibernética. Em efeito:

  • Senhas não óbvias foram usadas
  • Um firewall com restrição estrita de fluxo de dados estava em vigor
  • Um registro significativo foi feito

Mas, como a avaliação SL-A demonstrou, a maioria dos níveis de segurança FR eram nulos, porque pelo menos um dos RSs não foi abordado. Não adianta configurar controles de segurança avançados quando faltam alguns princípios básicos. O elo mais fraco reduz a eficácia geral da segurança. O fato de que os controles de segurança avançados são inúteis se outros controles de segurança básicos estiverem ausentes é melhor ilustrado pela configuração do firewall com um único link SSH que requer autenticação de senha não óbvia. Isso costuma ser uma limitação operacional dolorosa, pois permitir o acesso direto ao protocolo de desktop remoto (RDP) para vários sistemas ou conexões de rede virtual (VNC) teria sido mais fácil de usar. Infelizmente, essas restrições adicionais não aumentaram a segurança, porque:

  • A falta de monitoramento da rede de TI permitiu varreduras extensas na rede, pesquisas de vulnerabilidades e a descoberta do link SSH permitido.
  • A falta de autenticação sólida (dois fatores) ou aprovação local (OT) de conexões remotas permitiu a conexão frequente da rede de TI à rede OT sem detecção por vários meses.
  • A falta de detecção de intrusões na rede OT permitiu uma varredura extensiva da rede OT, detecção de vulnerabilidades e restrições de transferência de código móvel (malware, explorações).

Ao implementar controles de segurança, é essencial aplicar os requisitos de maneira consistente em todos os aspectos da segurança: detecção, prevenção e reação. É melhor usar um padrão bem projetado como ISA/ IEC-62443-3-3. Não aponte para SL-T = 2 ou 3 em algumas FRs se a SL-A permanecer zero em outras FRs, pois isso provavelmente seria inútil.

Qual SL seria necessário para impedir o ataque?

Observando os problemas listados acima, parece que elevar o SL-A para o nível 2 teria permitido que a atividade fosse detectada durante a segunda etapa, evitando assim ataques cibernéticos. Havia muito tempo disponível para a reação pós-detecção. Controles adicionais, como autenticação forte / local, antimalware e os requisitos do SL 2, teriam evitado a cinemática específica do ataque.

O fato de configurar o SL-T no nível 2 seria suficiente para detectar e impedir o ataque com várias camadas de defesa pode parecer surpreendente para o leitor, pois esse (sem dúvida) foi um ataque cibernético patrocinado pelo Estado, que Normalmente, é necessário SL-T = 3 ou mesmo 4 para impedir.

Na realidade, é provável que o hacker tenha conseguido igualar SL-A = 2 desenvolvendo exploits mais avançados e usando vetores de ataque diferentes da internet, como mídia móvel ou equipamento móvel introduzido por funcionários desonestos ou terceiros. No entanto, essas etapas adicionais são mais complexas e caras e, por não serem necessárias, foram usados ​​meios menos avançados.

Para resumir as conclusões deste ciberataque usando o guia ISA/ IEC-62443-3-3:

Como primeiro passo obrigatório, as empresas de distribuição de energia devem apontar para SL-T = 2, garantindo que pelo menos os requisitos mínimos de detecção (SR 6.2) sejam atendidos.

Para ter várias camadas de defesa, prevenção, detecção e tempo para reações em antecipação aos ataques mais sofisticados, é melhor apontar para SL-T = 3.

Em ambos os casos, é essencial estabelecer controles de segurança de forma consistente para garantir que todos os FRs tenham alcançado o mesmo SL-A antes de atingir um SL-T mais alto. Caso contrário, os esforços são inúteis, como mostra o exemplo em questão.


Publicado em ISA Intercâmbio: Link

Sobre o autor: Maximillian Kon Gerente WiseGroup Em segurança cibernética Instrutor Qualificado ISA Membro dos Grupos ISA
CEO e diretor administrativo