Category: General

Sem dúvida, este é um incidente que atraiu muita atenção em todo o mundo. Na comunidade daqueles que se dedicam à Segurança Cibernética Industrial sabemos que na Ucrânia eles dedicam uma abundante de recursos para a proteção da Infraestrutura Crítica, e especialmente no setor de Energia, talvez porque já estiveram nas notícias em outros episódios do passado. Desde dezembro do ano passado, eles teriam sido pegos em um grande incidente.

Todos nos perguntamos o que aconteceu? Como tal coisa poderia ter acontecido em um país em que uma abundante de recursos são dedicados à proteção de infraestruturas críticas? As estatísticas de incidentes e ataques a Sistemas de Controle (IACS, Sistemas de Controle de Automação Industrial) estão aumentando ano após ano, e em todas as partes do mundo, como na América, Europa, Ásia, etc. Tanto em sua quantidade, quanto na técnica de penetração e nos danos que esses incidentes estão causando às suas vítimas. Isso será apenas uma razão para análise em um de nossos próximos artigos. Em geral, os ataques à Infraestrutura crítica gerados em redes de TI, ou melhor, redes TCP/IP, muito difíceis de causar danos significativos ou ter consequências no mundo físico e na população. Em 23 de dezembro de 2015, na parte ocidental da Ucrânia, incluindo a capital Ivano-Frankivsk, mais de 700.000 residentes e 200.000 indústrias sofreram uma prolongada queda de energia como resultado de um ataque cibernético.

A análise deste, caso é especialmente valiosa, para entender qual foi o impacto deste incidente que envolveu sistemas de controle e cibersegurança industrial na totalidade. A parte ocidental da Ucrânia é operada por várias empresas privadas de transporte e distribuição de energia. Neste território, as fontes de Energia vêm principalmente de Usinas de Geração Térmica. A Ucrânia também tem Usinas Nucleares, mas não nesta região do país. Talvez alguém possa até pensar que o golpe veio do lado menos esperado.

O sistema elétrico interligado de um dos países, com supostamente a infraestrutura crítica bem protegida, foi seriamente afetado.

Em 23 de dezembro de 2015, um dia normal de trabalho no inverno rigoroso, às 16:00 hs. um grande número de usuários e indústrias não tinha mais o fornecimento de eletricidade. A situação começou a se recuperar a partir das 19h.m. Sabemos que faz muito tempo, especialmente para os habitantes e industriais. Não só pelo número de horas, mas também pelo imenso número de usuários e uma grande região afetada. O dano econômico foi enorme. No entanto, do ponto de vista do tempo de resposta, e devido à magnitude do incidente, a equipe de resposta respondeu rapidamente.

A maioria das empresas de energia em todas as partes do mundo não poderia responder da mesma forma em tão pouco tempo. Quando a maioria teria ficado totalmente surpresa, a equipe de resposta sabia como lidar com a situação de forma eficaz. As notícias do incidente começaram a se espalhar pela mídia mundial. Antes do final do ano, já era o incidente de cibersegurança industrial mais ressonante do ano. As agências de pesquisa de Cibersegurança Industrial ficaram surpresas e, em simultâneo, interessadas em colaborar com a pesquisa. O que aconteceu? E como isso aconteceu? Enquanto a análise e a perícia continuam, até hoje, várias questões já são muito claras.

1. O ‘malware’ BlackEnergy infectou vários computadores na rede de TI. BlackEnergy (também conhecido como DarkEnergy) é um ‘malware’ que existe desde 2008 e cada um de seus módulos tem sofrido mutação ao longo do tempo. Neste incidente, a terceira variante do BlackEnergy foi usada como vetor de ataque e deu aos atacantes acessos aos computadores das empresas de distribuição de energia, e a capacidade de se comunicar remotamente com eles. Não foi detectado que esse ‘malware’ tenha chegado às estações operacionais dos Sistemas de Controle. No entanto, é certo que os intrusos conseguiram obter e roubar informações do Sistema Elétrico Interconectado.

Um dos módulos da BlackEnergy, conhecido como KillDisk, foi usado para negar acesso a computadores corporativos como uma das várias medidas de distração e atraso no mesmo dia do incidente. Relatórios anteriores, eles revelaram, que no mês de março tentativas de entrar nas companhias elétricas com a segunda versão da BlackEnergy teriam sido detectadas. No mês de julho, o alerta desses ataques teria sido secado. Deveria ter sido tomada como um aviso e não como uma ação que já estava controlada.

2. Um ataque afetou em simultâneo, o sistema de telefonia de várias das empresas. Outro ataque simultâneo afetou o sistema de comunicação e telefonia de várias empresas de energia, possivelmente uma negação de serviço (DoS), impediu que o help desk das empresas de transporte de energia recebesse as reclamações dos usuários afetados. Esta situação já está dando evidências claras de que o incidente foi absolutamente planejado. As quedas de energia começaram há algum tempo antes que as empresas se conscientizassem do que realmente estava acontecendo.

Um dos provedores chegou a colocar mensagens em seus sites informando aos seus visitantes que a empresa estava tendo problemas com o fornecimento de energia em vários locais, mas não poderia precisar de uma hora de restauração. A situação era crítica e eles não sabiam o que estava acontecendo. Os golpes vieram de todos os lados.

3. Vários sistemas de controle da subestação foram comprometidos. Quando as equipes de resposta foram restabelecer os sistemas de controle de cada uma das subseções de energia, perceberam que os Sistemas de Controle de Campo, PLCs e RTUs também haviam sido comprometidos. Posteriormente, verificou-se que o firmware dos dispositivos estava corrompido ou modificado, e suas configurações haviam sido alteradas. Os sistemas de controle de 16 subestações foram encontrados nessas condições. Outra evidência clara de que o incidente ocorreu não foi coincidência. As empresas de distribuição de energia elétrica do oeste da Ucrânia foram vítimas de um ataque intencional, com alta motivação e conhecimento técnico dos Sistemas de Controle.

4. As Estações Operacionais de alguns Sistemas SCADA foram acessadas remotamente. Um operador, minutos antes de fazer sua mudança de turno, contou como de repente um fantasma assumiu o controle de sua estação de trabalho, e começou a agir nas subestações. Em apenas alguns segundos ele testemunhou como o suposto fantasma deixou um grande número de usuários e indústrias sem energia. Esse fantasma conseguiu contornar os processos de verificação e confirmação das ações do operador. O Operador não tinha tempo ou possibilidade de fazer nada para impedi-lo. Não foi um fantasma! O acesso remoto através de links VPN foi violado.

Eles estavam operando o SCADA do lado de fora e os Piratas informáticos estavam no controle do sistema. Os operados não podiam mais observar o que estava acontecendo. Suas chaves de acesso não funcionaram. As mesmas medidas de segurança do próprio sistema impediram que os Operadores pudessem acessar. Um operador do Sistema de Controle localizado em Prykarpattyaoblenergo, enquanto ele estava realizando sua papelada para terminar seu turno de trabalho, de repente observou como o cursor de sua Estação de Operação do Sistema, de repente mudou para um canto da tela. Rapidamente o cursor começou a realizar uma série de ações na tela e manobras nas subestações.

O operador do Fantasma selecionou uma subestação, foi diretamente até ela sem perder tempo, sabendo exatamente onde deveria coçar, selecionou a subestação, deu a ordem para desligar. O Sistema SCADA possui uma sequência de confirmação, como é típico para sistemas SCADA do tipo Elétrico (Select Before Operate, e outros), deu a ordem para desligar, confirmou a sequência, como um especialista e assim por diante com as 30 subestações desse operador. Os diagramas de uma linha e diferentes telas não são fáceis de entender, e você deve ter um conhecimento das Redes Elétricas. O operador tentou parar esse processo, mas não conseguiu fazer nada. O pior já começara, mesmo antes deste incidente.

O número de usuários sofria as consequências da queda de energia antes mesmo do incidente com o operador. Isso não foi tudo. Ao mesmo tempo, incidentes semelhantes estavam acontecendo em outros centros de controle de outras empresas de energia. O número de sub-estações que estavam sendo colocadas fora de serviço estava se multiplicando rapidamente. Pouco mais de três meses após o incidente ocorreu e após conhecer apenas alguns dos resultados das investigações que eram conhecidas, através das diferentes agências de investigação, não há dúvida de que foi um Ataque Cibernético… Planejado, elaborado e executado com grande eficácia. Talvez os responsáveis pensem que o dano que causariam seria muito maior.

A resposta eficiente na Recuperação do Incidente pela equipe de Resposta fez com que as perdas não aumentavam. O que teria acontecido se o incidente continuasse durante toda a noite? Os responsáveis não eram oportunistas. Eles sabiam perfeitamente o que estavam fazendo e tinham isso absolutamente premeditado. Eram estratégicos, detalhistas e planejados há meses. Múltiplos ataques orquestrados com o sincronismo como uma coreografia autêntica. Quando a maioria das pessoas responsabiliza o ‘malware’, é claro que por trás deste incidente havia logística e motivação significativas. Diante desses fatos, o ‘malware’ pode ter sido uma distração para esconder os verdadeiros vetores do ataque.

Na verdade, nenhum ‘malware’ foi encontrado nos sistemas de controle ou nas Estações de Operação SCADA. As proteções instaladas nos sistemas para impedir a entrada da rede corporativa têm se mostrado eficazes. No entanto, o grupo ativista diante dessa situação não desistiu e procurou outras formas de entrar nos sistemas de controle. As diferentes perspectivas dos ataques. Quando alguns acreditam que todos esses danos foram causados por um pirata informático ou um grupo de piratas informáticos da IT Redes, sabemos que atingir o baixo nível de controle, isso não é possível.

Alterações no firmware e na configuração e programação dos Sistemas de Controle não são possíveis de fazer simplesmente acessando a Sala de Operação da Sala SCADA, como um dos operadores relacionados, ou através do BlackEnergy Malware encontrado nas redes de TI. Especialmente em uma SCADA Elétrica com redes de vários anos, onde acessar o firmware de dispositivos de campo, fazer modificações sem isso despertando suspeitas sem gerar eventos, não é possível.

Não há dúvida de que houve uma tarefa de inteligência, houve planejamento, e ainda mais, havia um conhecimento não só da Rede Elétrica da região, mas também da SCADA, PLCs, RTUs, comunicações e suas vulnerabilidades. Sabe-se também que a perda do sistema SCADA, em um sistema bem concebido, não gera a queda no fornecimento de energia. Para isso, devem ser alcançados PLCs e RTUs.

Embora tecnicamente viável em condições laboratoriais, é altamente improvável, se não impossível, que os sistemas de controle nas subestações tenham sido alterados pelo uso de BlackEnergy. Para fazer as alterações encontradas nos PLCs e nas RTUs de campo nas Subseções é necessário acesso direto e, em muitos casos, conhecimentos muito específicos e ‘softwares’ específicos. Além disso, essas mudanças não são possíveis de fazer em poucos minutos, leva muitas horas para alterar os Sistemas de Controle de forma semelhante e ainda mais para passar despercebido.

Alterações no firmware e configuração não são as mesmas que fazer alterações no nível de monitoramento e operação do SCADA do que no nível de controle. Acreditamos que outros incidentes e eventos ainda não divulgados ocorreram. É razoável que a confusão seja gerada pela falta de conhecimento da comunidade global. De fato, na maioria dos incidentes que causaram danos reais à infraestrutura física, a capacidade dos atacantes foi subestimada, como foi o caso da Indústria Siderúrgica alemã, assumindo que o acesso foi feito a partir da Rede Corporativa ou da Internet, que tem sido falsa em 90% dos incidentes, ou simplesmente a partir de um acesso, VPN.

A intervenção no Sistema de Telefonia também não foi a causa dos apagões maciços. Isso serviu para atrasar a equipe de resposta na detecção e conscientização do problema. Isso também foi uma distração. Um relatório do Centro de Pesquisa da Indústria de Energia descreve os sistemas SCADA da Ucrânia como tecnologicamente desatualizados e devem ser renovados. Portanto, ter acesso remoto a PLCs e RTUs torna ainda mais improvável, se não impossível. Ainda mais quando nenhuma evidência de BlackEnergy 3 foi encontrada nos sistemas de controle.

Se foi o caso de Shamoon e Dragonfly em outros incidentes que aconteceram no passado. No entanto, desta vez estamos diante de um fato único. PLCs e RTUs foram inscritos e modificações foram feitas a eles. Até mesmo mudanças de firmware. Como é possível que um “poder” na Segurança Cibernética seja vítima de tal ataque? Como é possível que ele estivesse tão vulnerável? O que você tem feito todo esse tempo para proteger seus sistemas de controle? Da Ucrânia, eles rapidamente apontaram os russos como responsáveis pelo ataque. No entanto, devido ao tipo e nível de sofisticação do trabalho realizado, o incidente deve ter sido causado por diversos atores e/ou participantes.

Eles poderiam até ter conseguido a colaboração de partes completamente desconectadas ou desinteressadas que por alguns dólares conseguem fazer qualquer coisa, sem medir as consequências. Os Estados Unidos da América reconhecem que os sistemas de controle da Ucrânia são mais seguros do que os seus. No entanto, para os atacantes parecia um trabalho fácil. Falhas nas medidas de segurança. O acesso remoto SCADA Systems VPN tinha um único fator de autenticação, quando deveria ter um mínimo de dois. O apagão levou um total de 6 horas. No entanto, mesmo após três meses do que aconteceu, os sistemas de controle não estão totalmente operacionais. Várias das subestações continuam a ser operadas manualmente.

Restaurar sistemas de controle onde nada pode ser subestimado não é mais fácil. É necessário recuperar, testar e verificar o sistema em um nível de detalhes leva semanas. Eles não podem nem confiar em ‘backups’. Ainda assim, eles não podem deixar os sistemas como eram antes do incidente. Você quer mudar tudo! Caso contrário, a mesma coisa vai acontecer novamente.

Primeira Fase: Durante as pesquisas, não foram encontradas evidências de que o ‘malware’ BlackEnergy3 havia chegado aos sistemas de controle. Pelo contrário, tudo parece indicar que as medidas de proteção para evitar invasões da área corporativa aos sistemas de controle foram eficazes. Os ataques teriam começado vários meses antes nas redes de TI. Os atacantes não desistiram e procuraram outras formas de entrar nos sistemas de controle. Esses ataques em áreas de TI, foram executados através do envio de e-mails, com documentos do Word pedindo permissão para executar macros.

Esses macros teriam o ‘malware’. Mesmo tendo acesso aos computadores dos perfis do administrador, eles não conseguiram chegar aos sistemas de controle. Os diferentes firewalls e registros mostraram que todas as tentativas de entrada foram bloqueadas. O que faltava era uma análise adequada a tempo? Os atacantes tinham duas opções. Procure vulnerabilidades em firewalls e barreiras para a entrada de sistemas de controle das redes de TI ou procure formas alternativas de entrada. Os atacantes acabaram optando pela segunda opção. Eles devem obter um ou mais acesso direto aos sistemas de controle das múltiplas empresas de distribuição de energia.

Fase Dois: Os atacantes começaram a procurar formas alternativas de entrada. Eles conseguiram entrar no servidor de domínio e roubaram as credenciais de ‘login’ através das VPNs de vários SKAs. Dado que eles conseguiram entrar na Rede de Sistemas SCADA, eles começaram a tecer sua estratégia. Eles reconfiguraram o NOS em dois dos Sistemas de Controle. Além de deixarem os moradores sem energia, conseguiram cegar os operadores, mas não conseguiram fazer esse movimento nos outros sistemas. Em alguns sistemas eles simplesmente conseguiram liberar as telas dos operadores. Foi o suficiente para que eles não pudessem observar o que estava acontecendo no campo. As diferenças tecnológicas dos diferentes sistemas de controle, estavam proporcionando diferentes oportunidades de renda.

As empresas utilizaram diferentes DMS (Sistemas de Gerenciamento de Distribuição). Eles conseguiram modificar o firmware em vários equipamentos e dispositivos de comunicação de rede. Além disso, eles mudaram o firmware em vários Sistemas de Controle, pelo menos em um mínimo de 16 sub-estações. É a primeira vez que esse caso é detectado, onde os atores conseguem fazer uma mudança de firmware nos Sistemas de Controle. Do ponto de vista de um ataque, era tudo engenharia. Dado que todas essas mudanças foram alcançadas, eles estavam prontos para executar seu ataque.

Terceira Fase: dado que um número suficiente de vetores de ataque e cavalos de Troia foram implantados, o que eles tinham que fazer para que o ataque fosse eficaz e tivesse um grande impacto, era agir de forma coordenada. E assim o fizeram. O serviço de fornecimento de eletricidade foi restaurado quase inteiramente manualmente. A equipe de resposta observou ser a única maneira de recuperar o serviço de energia. (Não se sabia o que estava acontecendo até depois de várias semanas e meses de análise dos sistemas.) Eles tiveram que fazê-lo manualmente sem a ajuda de sistemas de controle. Neste caso foi possível, no entanto, nas redes elétricas mais modernas isso não seria possível e restaurar o serviço eles devem recuperar os sistemas de controle primeiro.

Sabemos que na Ucrânia eles investem muitos recursos para proteger sua infraestrutura crítica. No entanto, mesmo sendo um país preparado como cibersegurança, eles foram vítimas de um dos ataques mais temidos. Isso também mostra que a estratégia defensiva deve ser implementada em múltiplas camadas. Não basta proteger uma única entrada. É como fingir proteger nossa casa vigiando apenas a porta de serviço.

Para que um sistema de Defesa Cibernética Industrial seja eficaz, tanto a Detecção Abrangente quanto a Proteção Abrangente devem ser implementadas. Todas as portas, todas as janelas, até a entrada do cão ou gato, a lareira e a garagem devem ser monitoradas e protegidas. Não basta proteger as redes de dados TCP/IP, como está sendo feito na maioria dos casos. Um sistema abrangente de defesa cibernética deve ser implementado. Caso contrário, todo o esforço pode ser em vão.

Vamos estar alerta à medida que mais informações estão sendo reveladas. Como no caso Stuxnet, levou um tempo para saber tudo o que realmente aconteceu. Isso não será exceção.

Lição #1: os atacantes exigiram um mínimo de 6 meses de reconhecimento, pesquisa e orquestração para realizar seu ataque. Com as ferramentas certas, e há livre uso, as atividades desse grupo teriam sido detectadas.

Lição #2: as conexões remotas dos Sistemas SCADA e/ou Sistemas de Controle devem ter pelo menos dois fatores de autenticação.

Lição #3: as fontes de alimentação e os sistemas de controle são tão críticos quanto o próprio Sistema de Controle. Estes devem ser seguros e confiáveis.

Lição #4: Control System Firmware Updates também são um vetor de ataque válido e muito crítico, que a maioria dos atores da comunidade ainda não tem em mente.

Lição #5: um sistema de detecção abrangente, bem como proteção abrangente devem ser implementados. Não basta proteger apenas alguns dos pontos de entrada.

Lição #6: Um estudo abrangente sobre identificação de vulnerabilidades e avaliação de riscos para a Segurança Cibernética Industrial deve ser conduzido antes de implementar medidas de proteção. Se não o fizer, corre um alto risco de subestimar atacantes. Seja intencional ou não.

Lição #7: Todas as informações, documentação e detalhes que descrevem o funcionamento da Rede Elétrica e a arquitetura dos Sistemas de Controle devem ser protegidos. Ele pode fornecer às partes interessadas atacantes as informações necessárias para identificar vulnerabilidades nos Sistemas de Controle. Quando foi a última vez que você realizou uma revisão do seu Plano de Resposta a Incidentes em sua fábrica ou processos em sua empresa? Você tem um plano de resposta? Seu povo está mentalmente e psicologicamente preparado para responder a essas categorias de incidentes? Ou você seria totalmente pego de surpresa com as calças abaixadas? Sua organização poderia responder a algo semelhante? Você concluiu uma avaliação de risco de cibersegurança industrial? Você está ciente que pode acontecer em seus processos? Qual é o estado atual de suas Defesas Cibernéticas? Está seguindo alguma metodologia? Qual deles? É o certo?

Em suma, mesmo que você não esteja na indústria elétrica, este incidente é uma oportunidade ótima para observar, aprender e analisar qual é a sua situação atual. Para todos esses provedores de Sistemas e Serviços de Processos Críticos, é vital aprender com esses casos.

Gostaria de deixar suas opiniões e comentários aqui em baixo neste local? Escreva-nos em support@wiseplant.com