XVI STPC 2022 Ciberataques Subesta Es 1666750013

DETECÇÃO DE CYBER ATAQUES
EM REDES DE SUBESTAÇÕES
Objetivos
 Exibir possíveis vetores de ataque em subestações
 Descrever o Funcionamento de um IDS projetado para subestações
 Elencar vantagens de monitoramento funcional da rede
 Simular ataque CrashOverride e como seria a detecção por um IDS
 Simular exploração de CVE conhecido e como seria a detecção por um IDS

NIST
Framework de Cyber Segurança
https://www.nist.gov/cyberframework
 Usado em muitas normas de segurança nacionais

Múltiplas camadas,
(Complementa o NERC CIP)
cada uma monitorada
por violações
 Suposição global: não há 100% de proteção,
ataques sempre podem acontecer
 Segurança cibernética vista como um processo:
Identificar ativos e vetores de ataque (NERC CIP-002)

Proteger-se primeiro contra os vetores com maior risco (NERC
CIP-003,4,5,6,7)
Detectar ataques/ameaças à medida que ocorrem (NERC
CIP008)
Responder ao detectar ameaças, minimizar danos e aprender
(CIP 008)
Recuperar serviços afetados (NERC CIP-009)
Vetores
de Ataque
Subestações:
Como as
imaginamos
Vetores
de Ataque
Possíveis meios
de ataque em
Subestações
IDS
Sistema de Detecção de Intrusões
 O princípio tradicional “Defense in Depht”

 O que provavelmente temos na realidade?
 Monitoramento é uma peça importante na defesa em princípio de profundidade

Intrusion Detection Systems (IDS) – Sistemas de Detecção de Intrusões
IDS
Princípio Operativo
 PASSIVO
 Mirror-Port do switch da subestação ou Network

TAP
 Nenhuma interferência na comunicação do Station
e Process Bus
 Sem bloqueios de comunicação (IDS)
 Apenas alarmes
 Integração nos sistemas SIEM

 Usando o protocolo syslog e plug-ins
 Integração em sistemas de tickets / ordens de
serviço
 Usando plug-ins e funções de exportação
 Integração em sistemas SCADA usando saídas
binárias
 Maneira fácil de colocar o status do IDS na sala de
controle
ONS & IDS
Procedimento Operativo
 Procedimentos de
Operação
 Sub-Módulo 5.13
Concessionárias
devem Implantar
100% até
novembro de
2024
ONS & IDS
Procedimento Operativo
 A história mostra ataques muitas vezes preparados muito tempo

antes
 Dado o tempo suficiente, os atacantes sempre podem penetrar
à rede.
 A detecção permite responder antes que o dano seja feito
 Dispositivos comprometidos comportan-se de forma diferente
ou falham
 Recomenda-se o uso de IDSs baseados em Whitelisting
 IDSs baseados em aprendizagem ou Inteligência Artificial não são
recomendados
 Procedimento Operativo ONS:
IDS
e a IEC 61850
 Possibilidades avançadas para subestações IEC 61850
 A função de cada dispositivo é conhecida através do SCL
 Toda a Comunicação é descrita através dos arquivos SCL
 Roles ou “permissões” automaticamente aplicados para IEDs
 Lista de permissões editável e auditável pode ser definida de

forma automática
 Cada mensagem é avaliada em relação ao modelo do sistema ao

vivo - Princípio de lista de permissões (whitelist)
IDS
Inspeção Profunda de Alarmes
 DEEP PACKAGE INSPECTION

IDS
Manutenção
 Monitoramento Funcional da rede da subestação

 Uma vez que o conteúdo espelhado do tráfego da subestação estiver disponível para um sensor IDS,
pode-se explorar ainda mais o layer de aplicação das mensagens de forma a detectar e alarmar até
mesmo falhas funcionais na rede, como por exemplo a análise de bits de qualidade de mensagens,
indicando por exemplo que um IED está publicando certo tráfego com indicação de falha de
sincronismo de tempo, ou com qualidade indicando overflow de uma medição, entre outras
possibilidades
IDS
Registro da Rede
 Capacidade de “oscilografar” a rede antes e depois de cada alarme detectado
 Gravações em formato *.pcap

 Permite análises post morten de qualquer tentativa
de intrusão na rede por qualquer ferramenta
externa, colaborando com os requisitos de
Monitoramento e Resposta a Incidentes
mencionados no procedimento operativo do ONS
IDS
Manutenção
 Deve-se prever a Manutenção da rede e

dos dispositivos de rede
 Protocolos proprietários de fabricantes,

como por exemplo a linguagem própria
utilizada para descarregar ajustes em IEDs
através de um software proprietário, ou a
conexão temporal de certos
equipamentos na rede, podem ser
permitidas nas regras do IDS de forma
temporária, conforme a ativação de um
modo chamado “Manutenção”, onde
certas regras e permissões são ativas
apenas enquanto este modo estiver sob
execução, retornando ao status normal
quando o período de manutenção
terminar
CrashOverride
Simulação de Ataque
 Também chamado de CrashOverride ou Industroyer, o

ataque ocorrido em 17 de dezembro de 2016 deu-se
pela forma de um malware modular na Subestação
Severnaya da empresa UKRENERGO, na Ucrânia. É o
primeiro malware conhecido projetado
especificamente para atacar redes elétricas. Ao mesmo
tempo, é o quarto de cinco malwares revelados
publicamente para atingir sistemas de controle
industrial, com a seguinte estrutura sofisticada:
 Conforme visto na figura ao lado, o malware é uma
estrutura modular que consiste em um backdoor inicial,
um módulo inicializador e vários módulos de suporte e
payload
CrashOverride
 Simulou-se apenas a
parte de intrusão na
subestação, onde
normalmente há uma
conexão tipo MySQL do
Centro de Controle
diretamente com a IHM,
esta conexão é
permitida nas regras do
firewall da subestação.
Tráfico normal MySQL

entre Centro de
Controle e a IHM na
porta Ethernet 3306
CrashOverride
 Ao simular esta conexão,

foi corretamente
adicionada também uma
permissão para este tipo
de comunicação no IDS
CrashOverride
Tráfego Socks
 Entretanto, há um detectado na
subsequente spoofing ou porta 3306
hijacking da conexão do
Centro de Controle com a
IHM usando a porta de
destino 3306 (permitida
pelo firewall) para o
roteamento de qualquer
protocolo usando um
proxy Socks. Como o
firewall não detecta nada
anormal, os payloads do
CrashOverride podem ser
executados na rede da
subestação.
CrashOverride
 Neste caso o IDS verifica Tráfego Socks

as mensagens a nível de detectado na
aplicação (não verifica porta 3306
apenas MAC de
fonte/destino + IP de
fonte e destino + VLAN +
Porta Ethernet) e detecta
o tráfego tipo Socks no
layer de aplicação, onde
corretamente alarma a
intrusão, mesmo que a
mesma porta Ethernet
usada na permissão do
IDS anteriormente.
 Alarme de intrusão
emitido pelo IDS
CVE
Common Vulnerability Exposure
 Os documentos públicos onde os próprios  Foi simulada a ação maliciosa do
fabricantes expõem suas vulnerabilidades oscilógrafo da subestação
conhecidas são chamados Advisory Letters e (possivelmente infectado) enviando
Common Vulnerability Exposures (CVE). tráfego na porta 50000 de todos os
 Isto permite aos donos de ciber ativos conhecer IEDs da subestação para explorar a
suas vulnerabilidades e tomar ações corretivas vulnerabilidade associada aos IEDs
como por exemplo atualizações de firmware que Siemens Siprotec 4 o IDS além de
possam corrigir detectar corretamente o ataque, ele
o atribui a este tipo de
 Como os CVE são documentos públicos, o vulnerabilidade, a qual é mencionada
grande senão está no fato de que os hackers em seu respectivo CVE anunciado
também têm acesso à estas vulnerabilidades pelo próprio fabricante.
expostas e podem explorá-las.
CVE
Exploração de Vulnerabilidade
 O IDS nesta simulação Oscilógrafo infectado Exploração de vulnerabilidade
também é capaz de atacando IEDS explorando conhecida é alarmada
detectar padrões CVE conhecido
conhecidos como a
exploração de um CVE.
Neste exemplo é
simulado um ataque em
uma porta especial de
um IED de um dos
maiores fabricantes a
nível mundial, este
ataque que causaria o
denial-of-service do
mesmo, onde a
recuperação dos serviços
do IED seria feita apenas
com o reboot manual do
dispositivo, e esta
vulnerabilidade é
corrigida com uma
atualização de firmware.
Conclusões
 Engenheiros de TI e de TO devem colaborar para a
 Embora existam muitos
mecanismos de defesa aplicação de Cyber Segurança em Subestações
conhecidos, existem múltiplas
formas de ataque possíveis nas
subestações de energia, mas
nem todo sistema de defesa ou
monitoramento se adequa em
um ambiente de subestações. A
escolha de um sistema
adequado à legislação vigente
que ao mesmo tempo
proporcione a colaboração entre
os engenheiros e técnicos de
subestações e os responsáveis
pela segurança de TI é
fundamental para este
ambiente.
 O que não pode ser 100%
protegido, deve ser
monitorado!
XVI STPC - SEMINÁRIO TÉCNICO DE PROTEÇÃO E CONTROLE
24 a 27 de outubro de 2022
Windsor Barra Hotel - Rio de Janeiro - RJ
Detecção de Cyber Ataques em redes de Subestações
João Márcio Jorge

OMICRON
RESUMO
Múltiplas camadas de proteção são necessárias para garantir a segurança cibernética de subestações de energia.
São necessárias medidas para detectar ameaças na subestação para permitir uma resposta rápida e minimizar as
consequências. Este documento descreverá um dos requisitos de segurança de Subestações IEC 61850 e uma
nova abordagem para detecção ameaças nessas redes. Em seguida, uma abordagem desenvolvida
especificamente para a subestações IEC 61850 será descrito.
Este trabalho exemplifica algumas possibilidades e traz resultados a través da simulação de ataques muito
conhecidos em uma subestação europeia, como ataques a subestações da Ucrânia ou explorando vulnerabilidades
conhecidas de IEDs (Dispositivos Eletrônicos Inteligentes). Toda esta simulação é aplicada a uma subestação IEC
61850, onde um dispositivo IDS desenvolvido para sistemas IEC 61850 detecta e alarma todos os eventos de
intrusões que poderiam ser reportados para sistemas SOC (Security Operation Centers) de diversas formas.
As subestações possuem potenciais vetores de ataques cibernéticos. Se um invasor for capaz de influenciar uma
ou mais subestações, isso pode ter consequências graves para o sistema elétrico. Portanto, medidas eficazes de
segurança cibernética devem ser implementadas, não só nos centros de controle, mas também em subestações.
Para subestações IEC 61850, uma abordagem para detecção de intrusão está disponível, a qual baseia sua
configuração atrelada ao poder da linguagem de programação SCL (Substation Configuration Language) dos IEDs.
A experiência com a simulação de ataques em uma subestação explorada neste trabalho exibe os eventos
detectados no idioma dos engenheiros de PAC (Proteção, Automação e Controle) e, assim, oferece a vantagem de
que engenheiros de PAC e de TI possam trabalhar juntos para encontrar a causa dos eventos como por exemplo o
ramsonware que afetou a empresa brasileira de energia Light em 2020.
PALAVRAS-CHAVE
Cyber Segurança, Segurança Cibernética, Detecção de Intrusões, IDS, Intrusion Detection System
(João Márcio Jorge*) Rua Octaviano Gozzano, n˚ 325 – Andar 9 – CEP 18.048-100 – Sorocaba, SP – Brasil
Tel: (+55 15) 99605-0749 – E-mail: joao.jorge@omicronenergy.com
1.0 - INTRODUÇÃO
Sabendo-se de inúmeras vulnerabilidades críticas nas áreas de tecnologia da informação (TI) e tecnologia
operacional (TO), e de que nenhum sistema está 100% protegido, as empresas de energia devem adotar
estratégias voltadas para o “Princípio de Defensa em Profundidade” que protejam ambas as áreas de atuação
com eficiência, criando múltiplas camadas de proteção. Existe uma clara convergência entre os mundos de TI e
de TO para subestações de energia, porque ao passo que as empresas de energia modernizam sua infraestrutura
de rede e ativos que possuem interfaces de comunicação, elas estão integrando TI e TO buscando a melhor
eficiência para a entrega de energia elétrica de qualidade.
Os cyber ataques contra sistemas de energia podem ter impactos digitais e físicos. Comunicações eletrônicas mal
protegidas podem expor dados pessoais de clientes e negócios confidenciais. As interrupções de serviço causadas
por ameaças cibernéticas também podem ter impactos financeiros no provedor de energia e impactos mais
profundos nos clientes que dependem de infraestrutura crítica. A falta de proteção contra esses tipos de ataques
também pode prejudicar a reputação da marca e resultar em multas e perda do status de conformidade com as
inúmeras regulamentações que regem o setor [1], como por exemplo no Brasil tempos a Rotina Operacional
presente no submódulo 5.13 do ONS (Operador Nacional do Sistema), a qual estabelece os controles mínimos de
segurança cibernética a serem implementados pelos agentes dentro do Ambiente Regulado Cibernético (ARCiber),
o qual cita a possibilidade de aplicação de dispositivos IDSs (Sistemas de Detecção de Intrusões) baseados no
princípio de whitelisting (lista branca) como um dos recursos apropriados para a adequação de toda a infraestrutura
de segurança de uma subestação (RO-CB.BR.01 Revisão 01, de vigência a partir de 1 de agosto de 2022) [2].
2.0 - VETORES DE ATAQUE EM SUBESTAÇÕES
Um ataque cibernético, para fins didáticos deste artigo, é um evento em que um adversário modifica, degrada ou
desativa um serviço de pelo menos um dispositivo de proteção, automação ou controle dentro da subestação.
Para conseguir tal feitio, um invasor pode usar um dos caminhos de ataque (vetor de ataque) [3] descritos na
Figura 1:
FIGURA 1 - Vetores de Ataque em Subestações
Um hacker poderia penetrar à rede as subestação pela conexão do centro de controle, como aconteceu no primeiro
ataque cibernético à rede elétrica na Ucrânia, onde o firmware dos dispositivos gateway foi modificado (causando
sua destruição) [4], ou através de conexão via acesso remoto, como aconteceu no segundo ataque cibernético na
Ucrânia em 2016 [5] e no ataque cibernético 'TRITON' em PLCs de infraestrutura crítica [6].
Outro ponto de entrada é através dos PCs de engenharia, conectados diretamente aos equipamentos da
subestação ou à rede da subestação. Quando um engenheiro de proteção conecta seu PC a um relé para modificar
as configurações (de proteção), um malware no PC poderia se instalar no relé, como aconteceu com os PLCs no
famoso ataque cibernético ‘Stuxnet’ de 2010 [7].
Os laptops usados para testar o sistema IEC 61850 geralmente são conectados diretamente ao barramento da
estação, o que também é um vetor para infectar IEDs. Por esse motivo, estão disponíveis novas ferramentas de
teste IEC 61850 que fornecem uma separação cibernética entre o PC de teste e a rede da subestação. Desta
maneira os próprios dispositivos de teste se tornam um vetor potencial de ataque. Por isso, é importante que os
fornecedores de equipamentos de teste invistam na proteção de seus dispositivos para garantir que esse vetor de
ataque não seja atraente para um invasor explorar.
O local de armazenamento das configurações e documentos de teste também pode ser um vetor de infecção. O
servidor virtual ou local de armazenamento de arquivos, portanto, também pertence ao perímetro crítico e não
deve estar localizado na zona de TI do escritório. Portanto, faz sentido introduzir uma solução de gerenciamento
de dados separada, isolada e protegida para esses dados e arquivos.
3.0 - DISPOSITIVO IDS PROJETADO PARA SUBESTAÇÕES
Os IDSs são sensores para a detecção de intrusão que usam sua tecnologia de forma apenas passiva de modo
que apenas alarmam caso detectem algo anormal na rede, os quais na maioria dos casos são conectados à portas
espelho (mirror ports) dos switches distribuídos na rede de uma subestação. Sabendo-se que os ataques
importantes como os mencionados no capítulo de Vetores de Ataque são planejados com muita anterioridade e
que os atacantes perduram escaneando a rede por um período relevante de tempo, o alarme inicial seria suficiente
para que o responsável pela Governança de Segurança da Informação [2] tenha tempo para analisar o alarme e
tomar alguma ação, caso necessário.
Primeiramente serão elencados dois dispositivos IDSs naturalmente advindos do mundo de TI.
O primeiro deles seria baseado em assinatura, de forma similar a um antivírus com uma “lista negra” de tudo o que
seria detectado como malicioso; O problema deste tipo de dispositivo é que ele não é capaz de detectar ataques
tipo “zero day” ou aqueles ainda não reconhecidos por seu servidor. Outro impedimento seria que o próprio ONS
[2] determina que “o ARCiber não deve ser diretamente acessível através da internet mesmo que protegido por
um ou mais firewalls”, o que na grande maioria dos casos impediria o uso deste tipo de IDS.
O segundo deles seria baseado em aprendizado, onde o IDS estaria em modo passivo aprendendo e/ou
“escutando” por certo período de tempo todo o tráfego da subestação, e logo após este período de aprendizagem
ele entra em funcionamento. O grande porém do uso desta abordagem para subestações é que nem todo o tipo
de comunicação de uma subestação acontece com frequência, há eventos que podem ocorrer a cada ano ou até
com frequência maior, o que por consequência faria com que este tipo de IDS gerasse uma grande quantidade de
falsos alarmes.
O IDS selecionado para análise neste trabalho possui tecnologia projetada para o funcionamento em ambientes
de subestações de energia, com approach principalmente dedicado para subestações que trabalham com
tecnologias da norma IEC 61850, abordando também demais protocolos advindos de outras normas.
Para as subestações IEC 61850, todo o sistema de automação, incluindo todos os IEDs, seus modelos de dados
e seus serviços de comunicação, é descrito em um formato padronizado – a linguagem de programação SCL.
Essas informações permitem que uma abordagem diferente seja usada para detectar intrusões: o sistema de
monitoramento pode criar um modelo do sistema de automação da subestação e pode comparar cada pacote na
rede com esse modelo. Mesmo as variáveis contidas nas mensagens comunicadas (protocolos GOOSE, MMS,
SV, PTP, etc) podem ser avaliadas em relação às expectativas derivadas do modelo do sistema. Este modelo de
sistema é criado automaticamente através de arquivos SCL e compreende, portanto, uma lista branca (whitelisting),
pois todos os pacotes que não correspondem ao modelo do sistema acionarão um alarme. Entende-se que este
seria o approach correto para subestações, corroborado por [2].
FIGURA 3 - Modelo sistêmico de um IDS a partir de

FIGURA 2 - Arquitetura de subestação com IDS Whitelist
4.0 - INSPEÇÃO PROFUNDA DE ALARMES
O IDS objeto desde estudo, propõe a análise em profundidade de cada alarme que for detectado fora da lista
branca para todos os protocolos comuns em subestações, o que em outras palavras seria a análise a nível de
aplicação de cada mensagem, deixando de forma explícita quem envia, para que destino, qual a porta utilizada,
entre outros fatores, mas principalmente o conteúdo do payload da mensagem, por exemplo, caso seja detectado
um comando em um IED, de forma transparente isto estaria explícito no alarme, de forma gráfica e de forma textual,
como na figura a seguir:
FIGURA 4 - Detecção de Alarmes por IDS

Além de tudo isso, os engenheiros de PAC estão acostumados a trabalhar com registros de eventos de IEDs
através de oscilografias. De forma análoga, o IDS em questão gravaria também uma “oscilografia de rede” em
formato *.pcap momentos antes e depois de cada incidente, a qual permitiria análises post morten de qualquer
tentativa de intrusão na rede por qualquer ferramenta externa, colaborando com os requisitos de Monitoramento e
Resposta a Incidentes mencionados no procedimento operativo do ONS [2].
FIGURA 5 - Captura de tráfego por IDS com gravação *.pcap
Conclui-se que este formato de apresentação de alarmes está mais orientado para entendimento dos técnicos e
engenheiros de subestações, permitindo análise entendimento mais claros dos eventos transcorridos na rede.
5.0 - RECONSTRUÇÃO PARCIAL DE ATAQUE NA UCRÂNIA
Para o cenário de simulação, uma pequena subestação fictícia chamada ITAIPU com 10 IEDs, 2 RTUs, um
oscilógrafo e uma IHM foi simulada em laboratório com base em um arquivo SCL. O switch da subestação simulada
possuía uma de suas portas de comunicação configurada como porta espelho de todas as demais portas de
comunicação, e esta porta espelho estava diretamente conectada ao sensor IDS em questão.
Também chamado de CrashOverride ou Industroyer, o ataque ocorrido em 17 de dezembro de 2016 deu-se pela
forma de um malware modular na Subestação Severnaya da empresa UKRENERGO. É o primeiro malware
conhecido projetado especificamente para atacar redes elétricas. Ao mesmo tempo, é o quarto de cinco malwares
revelados publicamente para atingir sistemas de controle industrial, com a seguinte estrutura sofisticada:
FIGURA 6 - Diagrama de Blocos do CrashOverride

Conforme visto na figura acima, o malware é uma estrutura modular que consiste em um backdoor inicial, um
módulo inicializador e vários módulos de suporte e payload [9] e [10].
Neste caso, simulou-se apenas a parte de intrusão na subestação, onde normalmente há uma conexão tipo MySQL
do Centro de Controle diretamente com a IHM, esta conexão é permitida nas regras do firewall da subestação. Ao
simular esta conexão, foi adicionada também uma permissão para este tipo de comunicação no IDS.
FIGURA 7 - Tráfico MySQL entre Centro de Controle e a IHM
FIGURA 8 - Permissão MySQL adicionada para a porta 3306
Entretanto, há um subsequente spoofing ou hijacking da conexão do Centro de Controle com a IHM usando a porta
de destino 3306 (permitida pelo firewall) para o roteamento de qualquer protocolo usando um proxy Socks. Como
o firewall não detecta nada anormal, os payloads do CrashOverride podem ser executados na rede da subestação.
Neste caso o IDS verifica as mensagens a nível de aplicação (não verifica apenas MAC de fonte/destino + IP de
fonte e destino + VLAN + Porta Ethernet) e detecta o tráfego tipo Socks no layer de aplicação, onde corretamente
alarma a intrusão, mesmo que a mesma porta Ethernet usada na permissão da Figura anterior tenha sido utilizada.
FIGURA 9 - Tráfego Socks detectado na porta 3306
Desta forma o modelo de detecção do IDS usando a camada de aplicação das mensagens seria o seguinte:
FIGURA 10 - Modelo sistêmico de lista branca
6.0 - EXPLORAÇÃO DE CVE
Os documentos públicos onde os próprios fabricantes expõem suas vulnerabilidades conhecidas são chamados
Advisory Letters e Common Vulnerability Exposures (CVE). Isto permite aos donos de ciber ativos conhecer suas
vulnerabilidades e tomar ações corretivas como por exemplo atualizações de firmware que possam corrigir tais
vulnerabilidades. Em um ambiente de subestações, não é trivial sacar de operação um IED apenas para uma
atualização de firmware, o que por consequência pode permitir ciber ativos estarem operando com vulnerabilidades
por um tempo relevante. Como os CVE são documentos públicos, o grande senão está no fato de que os hackers
também têm acesso à estas vulnerabilidades expostas e podem explorá-las.
O IDS desde estudo além de alarmar, é capaz de detectar padrões conhecidos como a exploração de um CVE.
Neste exemplo é simulado um ataque em uma porta especial de um IED de um dos maiores fabricantes a nível
mundial, este ataque que causaria o denial-of-service do mesmo, onde a recuperação dos serviços do IED seria
feita apenas com o reboot manual do dispositivo, e esta vulnerabilidade é corrigida com uma atualização de
firmware.
FIGURA 11 - Simulação de ataque usando CVE conhecido
Neste caso foi simulada a ação maliciosa do oscilógrafo da subestação (possivelmente infectado) enviando tráfego
na porta 50000 de todos os IEDs da subestação para explorar a vulnerabilidade associada aos IEDs Siemens
Siprotec 4, onde na figura acima o IDS além de detectar corretamente o ataque, ele o atribui a este tipo de
vulnerabilidade, a qual é mencionada em seu respectivo CVE [8] anunciado pelo próprio fabricante.
7.0 - MONITORAMENTO FUNCIONAL E MODO MANUTENÇÃO
Protocolos proprietários de fabricantes, como por exemplo a linguagem própria utilizada para descarregar ajustes
em IEDs através de um software proprietário, ou a conexão temporal de certos equipamentos na rede, podem ser
permitidas nas regras do IDS de forma temporária, conforme a ativação de um modo chamado “Manutenção”, onde
certas regras e permissões são ativas apenas enquanto este modo estiver sob execução, retornando ao status
normal quando o período de manutenção terminar, como na seguinte figura:
FIGURA 12 - Modo Manutenção

Na Figura 8 pode-se observar que quando se adiciona uma permissão, existe a opção de tê-la ativa apenas quando
o modo Manutenção estiver ativo “Allow during maintenance only”.
Uma vez que o conteúdo espelhado do tráfego da subestação estiver disponível para um sensor IDS, pode-se
explorar ainda mais o layer de aplicação das mensagens de forma a detectar e alarmar até mesmo falhas funcionais
na rede, como por exemplo a análise de bits de qualidade de mensagens, indicando por exemplo que um IED está
publicando certo tráfego com indicação de falha de sincronismo de tempo, ou com qualidade indicando overflow
de uma medição, entre outras possibilidades:
FIGURA 13 - Exemplos de Monitoramento Funcional
8.0 - CONCLUSÔES
Embora existam muitos mecanismos de defesa conhecidos, existem múltiplas formas de ataque possíveis nas
subestações de energia, mas nem todo sistema de defesa ou monitoramento se adequa em um ambiente de
subestações. A escolha de um sistema adequado à legislação vigente que ao mesmo tempo proporcione a
colaboração entre os engenheiros e técnicos de subestações e os responsáveis pela segurança de TI é
fundamental para este ambiente. Na américa latina, os principais países apenas começaram a tratar com
relevância o tema de ciber segurança para subestações, lançando as primeiras regulamentações básicas,
entretanto a conscientização e a colaboração entre as empresas de energia, fabricantes e órgãos
regulamentadores é importante para alcançar-se o ponto ótimo e factível da aplicação de ações e políticas de ciber
segurança no ambiente operativo em questão.
10
9.0 - REFERÊNCIAS BIBLIOGRÁFICAS
[1] Fortinet, Whitepaper “Protecting the Power and Utilities Industry with the Fortinet Security Fabric” (Maio
de 2021, Código 516655-A-0-EN).
[2] ONS, Manual de Procedimentos da Operação, Módulo 5 - Submódulo 5.13. Rotina Operacional, Controles
mínimos de segurança cibernética para o Ambiente Regulado, RO-CB.BR.01 Revisão 01, agosto de 2022;
[3] CKW, Experiences in Design and Commissioning of a Secure Substation Network Architecture,
Centralschweizer Kraftwerke (CKW) AG, Luzern, Switzerland (stefan.mattmann@ckw.ch);
[4] ‘Analysis of the Cyber Attack on the Ukrainian Power Grid’, SANS, E-ISAC, https://ics.sans.org/media/E-
ISAC_SANS_Ukraine_DUC_5.pdf.
[5] ‘WIN32/INDUSTROYER - A new threat for industrial control systems’, https://www.welivesecurity.com/wp-
content/uploads/2017/06/Win32_Industroyer.pdf
[6] ‘Threat Research - Attackers Deploy New ICS Attack Framework “TRITON” and Cause Operational
Disruption to Critical Infrastructure’, https://www.fireeye.com/blog/threat-research/2017/12/attackers-deploy-new-
ics-attack-framework-triton.html.
[7] D. Kushner: ‘The Real Story of Stuxnet, How Kaspersky Lab tracked down the malware that stymied Iran’s
nuclear-fuel enrichment program’, IEEE Spectrum, February 2013;
[8] Siemens Security Advisory SSA-974843: Denial-of-Service Vulnerability in SIPROTEC 4 and SIPROTEC
Compact Relay Families, Version 1.0, 2020-02-11;
[9] Dragos, Analysis of the Threat to Electric Grid Operations.pdf, Version 2.20170613;
[10] ESET, Win32_Industroyer_Anton Cherepanov.pdf, Version 2017-06-12;
10.0 - DADOS BIOGRÁFICOS
João Márcio Jorge, Engenheiro Eletricista formado pela UFJF com mais de 8 anos de experiência em
testes e funcionais e comissionamento em subestações de energia, pós-graduado em Proteção de
Sistemas Elétricos pela Unicsul e discente de pós-graduação em Cyber Segurança pelo Instituto
Daryus. Entusiasta da norma IEC 61850 e especialista regional pela OMICRON Electronics Latino
América.
Manual de Procedimentos da Operação
Módulo 5 - Submódulo 5.13
Rotina Operacional
Controles mínimos de segurança cibernética para o Ambiente Regulado

Cibernético
Código Revisão Item Vigência
RO-CB.BR.01 01 4.1.11. 01/08/2022
.
MOTIVO DA REVISÃO
- Revisão textual ao longo do documento.
LISTA DE DISTRIBUIÇÃO
CNOS COSR-SE COSR-NE COSR-NCO COSR-S

Agentes de
- - - -
Operação
Manual de Procedimentos da Operação - Módulo 5 - Submódulo 5.13
Rotina Operacional Código Revisão Item Vigência
Controles mínimos de segurança cibernética para o

RO-CB.BR.01 01 4.1.11. 01/08/2022
Ambiente Regulado Cibernético
ÍNDICE
1. OBJETIVO.........................................................................................................................................2
2. REFERÊNCIAS ...................................................................................................................................2
3. CONCEITOS ......................................................................................................................................2
4. CONSIDERAÇÕES GERAIS .................................................................................................................2
4.1. ARQUITETURA TECNOLÓGICA PARA O AMBIENTE........................................................................2
4.2. GOVERNANÇA DE SEGURANÇA DA INFORMAÇÃO........................................................................3
4.3. INVENTÁRIO DE ATIVOS ................................................................................................................3
4.4. GESTÃO DE VULNERABILIDADES ...................................................................................................4
4.5. GESTÃO DE ACESSOS .....................................................................................................................4
4.6. MONITORAMENTO E RESPOSTA A INCIDENTES ............................................................................5
5. ORIENTAÇÕES TÉCNICAS COMPLEMENTARES ..................................................................................5
5.1. TRATAMENTO DE EXCEÇÕES .........................................................................................................5
5.2. ADOÇÃO DE CONTROLES COMPLEMENTARES ..............................................................................6
6. ANEXOS ...........................................................................................................................................7
7. REFERÊNCIA BIBLIOGRÁFICA ............................................................................................................7
Referência: 1/8

RO-CB.BR.01 01 4.1.11. 01/08/2022
1. OBJETIVO
Estabelecer os controles mínimos de segurança cibernética a serem implementados pelos agentes e pelo
ONS no Ambiente Regulado Cibernético (ARCiber).
2. REFERÊNCIAS
Módulo 2.16 dos Procedimentos de Rede – Requisitos operacionais para centros de operação e instalações
da rede de operação.
3. CONCEITOS
3.1. ARCiber – Ambiente Regulado Cibernético é o conjunto de redes e equipamentos que estão
considerados no escopo desta Rotina Operacional. O ARCiber é composto por:
a) Centros de operação dos agentes;
b) Equipamentos que participam da infraestrutura de envio ou recebimento de dados e voz para
ambientes operativos do ONS ou para centros de operação de outros agentes;
c) Ambiente operativo do ONS.
3.2. Patch – Atualização de software fornecida pelo fabricante que corrige falhas e vulnerabilidades.
3.3. MFA – Múltiplos Fatores de Autenticação. Técnica de autenticação que garante mais confiabilidade
ao exigir que os usuários apresentem mais de uma confirmação. Fatores comumente usados incluem
tokens OTP e dispositivos biométricos.
3.4. OTP – One Time Password. Método de autenticação de múltiplos fatores que se constitui de uma
senha de uso único, que é válida somente para uma sessão de login ou transação.
3.5. VPN – Virtual Private Network. Conexão estabelecida sobre uma infraestrutura pública ou
compartilhada, usando tecnologias de tunelamento e criptografia para manter seguros os dados
trafegados.
3.6. Antimalware – Ferramenta de software cujo objetivo é proteger o dispositivo contra infecções por
vírus e outros softwares maliciosos.
3.7. Ambiente Operativo do ONS - Toda a infraestrutura computacional e de telecomunicações de Tempo

Real e histórico, que atende à sala de controle e outras áreas interessadas do ONS, e que está
protegida pelos Firewalls operativos.
3.8. Incidente de Segurança Cibernética - é composto por um ou mais eventos de segurança cibernética
indesejados ou inesperados, que podem levar ao comprometimento dos ativos do ARCiber ou
prejudicar as operações do ONS ou do agente.
4. CONSIDERAÇÕES GERAIS
4.1. ARQUITETURA TECNOLÓGICA PARA O AMBIENTE
4.1.1. As redes devem ser segregadas em zonas de segurança, de acordo com a sua função. O agente deve
definir uma arquitetura que segmente as redes minimamente em:
a) Zona de Supervisão (nível 2 da norma ISA-95 e Purdue Reference Model);
Referência: 2/8

RO-CB.BR.01 01 4.1.11. 01/08/2022
b) Zona DMZ Operativa (nível 3 da norma ISA-95 e Purdue Reference Model);

c) Zona Corporativa (nível 4 da norma ISA-95 e Purdue Reference Model).
4.1.2. O ARCiber não deve ser diretamente acessível através da internet mesmo que protegido por um ou
mais firewalls, bem como seus ativos:
a) Não devem ser visíveis nem ser acessíveis a partir da internet, exceto nos casos previstos em 4.1.3.
b) Não devem ser capazes de se conectar com a internet.
4.1.3. O acesso ao ARCiber a partir de redes externas à organização (como, por exemplo, a internet)
somente deve ser permitido para o desempenho de atividades autorizadas. Este acesso deve ser
realizado por meio de Rede Privada Virtual (VPN), ou tecnologia similar, através de um gateway ou
serviço que ofereça controles de segurança.
4.1.4. Soluções Antimalware devem ser implementadas no ARCiber e mantidas atualizadas.

a) Soluções de application whitelisting podem ser implementadas como alternativa ou
complemento às soluções Antimalware.
4.2. GOVERNANÇA DE SEGURANÇA DA INFORMAÇÃO
4.2.1. Deve ser nomeado pelo menos um gestor e um suplente, responsáveis pela segurança cibernética do
ARCiber e atuar como ponto de contato externo.
4.2.2. Deve ser estabelecida política que defina papéis e responsabilidades em relação à segurança
cibernética do ARCiber.
4.3. INVENTÁRIO DE ATIVOS
4.3.1. Todos os ativos, softwares e hardwares, conectados ao ARCiber devem ser inventariados
minimamente a cada 24 meses e considerar minimamente:
a) Tipo de dispositivo;
b) Fabricante do equipamento;
c) Função;
d) Endereço IP ou MAC Address;
e) Protocolo de aplicação e/ou porta de serviço;
f) Versão do firmware e/ou sistema operacional quando aplicável.
4.3.2. O inventário dos ativos deve ser armazenado de forma segura, com políticas de armazenamento bem
definidas, com acesso restrito às pessoas que necessitem das informações para o exercício de suas
funções.
4.3.3. Padrões de configuração segura (hardening) devem ser criados conforme política de segurança do
agente para os sistemas operacionais, firmwares, banco de dados e demais versões de softwares
existentes no ARCiber:
a) Mecanismos de monitoramento da conformidade destes padrões no ARCiber produtivo,
automatizados ou manuais, devem ser implementados.
Referência: 3/8

RO-CB.BR.01 01 4.1.11. 01/08/2022
4.4. GESTÃO DE VULNERABILIDADES
4.4.1. A política de segurança da organização deverá contemplar a gestão de pacotes de correção de

segurança (patches) para todas as tecnologias conectadas ao ARCiber, contemplando no mínimo:
a) Cronograma de implementação das correções;
b) Mapeamento dos ativos inventariados para as atualizações disponibilizadas pelos fabricantes.
4.4.2. Novos ativos somente deverão ser conectados ao ARCiber após a aplicação de todos os pacotes de
correção de segurança disponíveis.
a) Caso o novo equipamento esteja substituindo um equipamento existente que tenha apresentado
defeito, a aplicação dos pacotes de correção de segurança poderá ser postergada, mas com prazo
pré-definido.
4.5. GESTÃO DE ACESSOS
4.5.1. Deve existir uma política de gestão de acessos e identidades, que contemple minimamente os
requisitos descritos a seguir.
4.5.1.1. Credenciais de acesso devem ser individuais e aprovadas pela alçada competente. Para os casos em
que não seja possível implementar credenciais individuais, deve-se:
a) Gerar e manter uma lista das pessoas autorizadas a usar as contas compartilhadas.
b) Implementar os controles previstos em 4.5.1.6.
4.5.1.2. Política de senhas que contemple: tamanho mínimo, complexidade, necessidade de ser diferente
da senha padrão do fabricante, ações a serem tomadas caso um número máximo de tentativas de
acesso malsucedidas seja atingido, e critérios para a gestão de mudanças (prazo, ocorrência de
incidentes, etc).
a) A política de senhas pode ser implementada por controles tecnológicos ou por procedimento.
Caso as características de senha previstas na política não possam ser implementadas em
determinados ativos devido à restrição tecnológica, deve-se implementar o nível máximo
suportado pelo ativo.
4.5.1.3. Na construção dos perfis de acesso deve-se seguir o princípio de minimização (somente deve-se
conceder o acesso mínimo necessário).
4.5.1.4. Prazo máximo para cancelamento/remoção de credenciais de usuários desligados e de credenciais

sem uso após um determinado tempo.
4.5.1.5. Credenciais de acesso privilegiadas devem estar sujeitas a controles específicos, incluindo:
a) Nível de aprovação adequado, com revisão periódica pelo gestor do ARCiber;
b) Uso exclusivo durante a execução de tarefas administrativas;
c) Monitoramento através de trilhas de auditoria;
d) Utilização de múltiplos fatores de autenticação como, por exemplo, tokens OTP (One Time
Password) ou reconhecimento biométrico.
Referência: 4/8

RO-CB.BR.01 01 4.1.11. 01/08/2022
4.5.1.6. As características especiais das credenciais de acesso padrão embarcadas (locais) nos sistemas
operacionais e softwares devem ser consideradas na política de gestão de acessos e identidades:
a) O acesso à senha de contas embarcadas deve ser restrito a um número limitado de pessoas;
b) Cada ativo que possua credencial embarcada deve possuir uma senha distinta. Uma mesma senha
não deve ser atribuída a mais de um ativo.
4.6. MONITORAMENTO E RESPOSTA A INCIDENTES
4.6.1. Os ativos do ARCiber devem estar configurados para gerar logs de segurança apropriados para
suportar investigações e a reconstrução de possíveis incidentes de segurança. Esses logs devem ser
armazenados por prazo definido nas políticas de segurança cibernética da organização.
4.6.2. Os dispositivos de segurança como Firewalls, IDS/IPS, Antimalware e subsistemas de autenticação

devem estar configurados para gerar alertas caso identifiquem atividades suspeitas:
a) As regras para geração de alertas devem ser revisadas periodicamente;
b) Todos os alertas devem ser reportados imediatamente à equipe responsável definida na política
de segurança do agente;
c) Os alertas gerados devem ser analisados e respondidos no prazo definido pela política de
segurança do agente.
4.6.3. Devem ser estabelecidos mecanismos para identificação e resposta a incidentes cibernéticos
tempestivamente.
4.6.4. Deve ser implementado um plano de resposta a incidentes cibernéticos, contemplando

minimamente os seguintes requisitos:
a) Identificação dos cenários de risco cibernéticos aplicáveis ao ARCiber e estratégias de tratamento
para cada cenário;
b) Classificação do impacto;
c) Equipes envolvidas, com os seus respectivos papéis e responsabilidades antes, durante e depois
da crise;
d) Critérios para ativação do plano de resposta a incidentes cibernéticos.
4.6.5. Testes de ativação dos planos de resposta a incidentes cibernéticos devem ser realizados
periodicamente, em ciclos definidos na política de segurança cibernética da organização, cobrindo
minimamente as listas de ativação (Call Tree) e revisão dos procedimentos descritos. Os exercícios
deverão gerar documentos de lições aprendidas e as respectivas ações corretivas e de melhorias.
4.6.6. Incidentes cibernéticos que afetem ativos do ARCiber devem ser informados ao ONS.
5. ORIENTAÇÕES TÉCNICAS COMPLEMENTARES
5.1. TRATAMENTO DE EXCEÇÕES
5.1.1. Os casos em que requisitos não possam ser implementados devem ser tratados com uma exceção.
Cada exceção gerada deve ser criada:
a) Documentada detalhadamente, incluindo a data em que ela foi identificada, o motivo pelo qual
Referência: 5/8

RO-CB.BR.01 01 4.1.11. 01/08/2022
ela precisa ser tratada como exceção, os itens desta RO que deixarão de ser atendidos e os
impactos esperados;
b) Aprovada pelo gestor responsável pela segurança cibernética do ARCiber;
5.2. ADOÇÃO DE CONTROLES COMPLEMENTARES

Cabe a cada organização adotar controles:
a) Complementares nos ativos que integram o ARCiber, conforme suas próprias políticas, diretrizes
e avaliações de risco.
b) De segurança cibernética nos ativos que não integram o ARCiber, conforme suas próprias
políticas, diretrizes e avaliações de risco.
Referência: 6/8

RO-CB.BR.01 01 4.1.11. 01/08/2022
6. ANEXOS
ANEXO 1 – DISPOSIÇÕES TRANSITÓRIAS
PRAZO PARA IMPLANTAÇÃO ITENS DA ROTINA

4.1.2
4.1.3
4.2.1
4.2.2
Até 18 (dezoito) meses após a entrada em vigor do presente documento 4.3.1
4.3.2
4.3.3
4.6.1
4.1.1
4.1.4
4.4.1
4.4.2
4.5.1
Até 27 (vinte e sete) meses após a entrada em vigor do presente documento 4.6.2
4.6.3
4.6.4
4.6.5
4.6.6
7. REFERÊNCIA BIBLIOGRÁFICA
7.1. ANSI/ISA-95.00.01-2010 (IEC 6224-1 Mod) Enterprise-Control System Integration – Part 1: Models
and Terminology. 5.2 Functional Hierarchy;
7.2. Purdue Reference Model for CIM.
Referência: 7/8

XVI STPC 2022 Ciberataques Subesta Es 1666750013

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

XVI STPC 2022 Ciberataques Subesta Es 1666750013

Enviado por

Direitos autorais:

Formatos disponíveis

DETECÇÃO DE CYBER ATAQUES

 Exibir possíveis vetores de ataque em subestações

 Descrever o Funcionamento de um IDS projetado para subestações

 Elencar vantagens de monitoramento funcional da rede

 Simular ataque CrashOverride e como seria a detecção por um IDS

 Simular exploração de CVE conhecido e como seria a detecção por um IDS

 Usado em muitas normas de segurança nacionais

 Segurança cibernética vista como um processo:

Identificar ativos e vetores de ataque (NERC CIP-002)

 O princípio tradicional “Defense in Depht”

 Monitoramento é uma peça importante na defesa em princípio de profundidade

 Mirror-Port do switch da subestação ou Network

 Integração nos sistemas SIEM

 A história mostra ataques muitas vezes preparados muito tempo

 Possibilidades avançadas para subestações IEC 61850

 A função de cada dispositivo é conhecida através do SCL

 Toda a Comunicação é descrita através dos arquivos SCL

 Roles ou “permissões” automaticamente aplicados para IEDs

 Lista de permissões editável e auditável pode ser definida de

 Cada mensagem é avaliada em relação ao modelo do sistema ao

 DEEP PACKAGE INSPECTION

 Monitoramento Funcional da rede da subestação

 Capacidade de “oscilografar” a rede antes e depois de cada alarme detectado

 Gravações em formato *.pcap

 Deve-se prever a Manutenção da rede e

 Protocolos proprietários de fabricantes,

 Também chamado de CrashOverride ou Industroyer, o

Tráfico normal MySQL

 Ao simular esta conexão,

 Neste caso o IDS verifica Tráfego Socks

Detecção de Cyber Ataques em redes de Subestações

João Márcio Jorge

2.0 - VETORES DE ATAQUE EM SUBESTAÇÕES

FIGURA 1 - Vetores de Ataque em Subestações

3.0 - DISPOSITIVO IDS PROJETADO PARA SUBESTAÇÕES

FIGURA 3 - Modelo sistêmico de um IDS a partir de

4.0 - INSPEÇÃO PROFUNDA DE ALARMES

FIGURA 4 - Detecção de Alarmes por IDS

FIGURA 5 - Captura de tráfego por IDS com gravação *.pcap

5.0 - RECONSTRUÇÃO PARCIAL DE ATAQUE NA UCRÂNIA

FIGURA 6 - Diagrama de Blocos do CrashOverride

FIGURA 7 - Tráfico MySQL entre Centro de Controle e a IHM

FIGURA 8 - Permissão MySQL adicionada para a porta 3306

FIGURA 9 - Tráfego Socks detectado na porta 3306

FIGURA 10 - Modelo sistêmico de lista branca

6.0 - EXPLORAÇÃO DE CVE

FIGURA 11 - Simulação de ataque usando CVE conhecido

7.0 - MONITORAMENTO FUNCIONAL E MODO MANUTENÇÃO

FIGURA 12 - Modo Manutenção

FIGURA 13 - Exemplos de Monitoramento Funcional

9.0 - REFERÊNCIAS BIBLIOGRÁFICAS

10.0 - DADOS BIOGRÁFICOS

Controles mínimos de segurança cibernética para o Ambiente Regulado

Código Revisão Item Vigência

RO-CB.BR.01 01 4.1.11. 01/08/2022

- Revisão textual ao longo do documento.

CNOS COSR-SE COSR-NE COSR-NCO COSR-S

Controles mínimos de segurança cibernética para o

Controles mínimos de segurança cibernética para o

3.7. Ambiente Operativo do ONS - Toda a infraestrutura computacional e de telecomunicações de Tempo

4.1. ARQUITETURA TECNOLÓGICA PARA O AMBIENTE

Controles mínimos de segurança cibernética para o

b) Zona DMZ Operativa (nível 3 da norma ISA-95 e Purdue Reference Model);