Instituto Politécnico de Beja

Escola Superior de Tecnologia e Gestão

Mestrado em Engenharia de Segurança Informática

Análise Crítica ao Standard IEEE C37.1™-2007

João Parra

Beja

2021
 Instituto Politécnico de Beja

Escola Superior de Tecnologia e Gestão

Mestrado em Engenharia de Segurança Informática

Análise Crítica ao Standard IEEE C37.1™-2007

Análise Crítica Focando a Segurança ao Standard IEEE C37.1™-2007 para SCADA and
Automation Systems

Elaborado por: João Parra

Docente: Daniel Franco

Beja
Análise Crítica ao Standard IEEE C37.1™-2007

Índice
Introdução ............................................................................................................... 1

Análise Crítica ao Standard IEEE C37.1™-2007 ................................................ 2

2.1. Definições e Conceitos ..................................................................................... 2

Supervisory Control and Data Acquisition (SCADA) ............................................ 2

2.2. Standard IEEE C37.1™-2007 ......................................................................... 2

2.3. Análise Crítica ao Standard IEEE C37.1™-2007 Focando a sua Segurança

3

Conclusão .............................................................................................................. 10

i
Análise Crítica ao Standard IEEE C37.1™-2007

Introdução
Foi solicitado pelo professor Daniel Franco, que fosse feita uma análise crítica, focando
a segurança, a um dos standards para os sistemas Supervisory Control and Data
Acquisition (SCADA).

Esta análise é o “Trabalho de Investigação Teórica” da unidade curricular Cibersegurança

em Infraestruturas Críticas e faz parte da sua avaliação. Para este trabalho foi escolhido o
standard IEEE C37.1™-2007 para SCADA and Automation Systems.

Para um melhor enquadramento desta análise vão ser utilizadas as definições, os

acrónimos e as abreviaturas do documento IEEE C37.1™-2007 assim como, este vai ser
o único documento referenciado neste trabalho.

A introdução e a análise crítica são os únicos artigos deste documento. Também não
fazem parte deste documento o resumo e o abstract.

1
Análise Crítica ao Standard IEEE C37.1™-2007

Análise Crítica ao Standard IEEE C37.1™-2007

2.1. Definições e Conceitos
Supervisory Control and Data Acquisition (SCADA) é um sistema forte de controlo
desenhado para colher, analisar e monitorizar informação de equipamentos industriais.
Os sistemas SCADA colhem a informação em tempo real ajudando os operadores a
aceder aos dados acionáveis e gerir centenas de equipamentos.

Os sistemas SCADA são utilizados para adquirir informação e gerir os equipamentos de

grandes indústrias automatizadas e essencialmente em infraestruturas críticas como as
redes de energia e as linhas de água.

Os sistemas SCADA modernos são baseados em infraestruturas na nuvem (cloud-based)

fazendo parte da já imensa Industrial Internet of Things (IIoT), fornecendo uma
conetividade segura, o armazenamento de dados sem limite e uma compreensão precisa
e profunda de todos os ativos existentes. Estes sistemas, independentemente das suas
dimensões, oferecem uma tecnologia em stack que permite a sua implementação numa
fração de tempo reduzida e, também, para facilitar o desdobramento das operações.

O que é um IEEE Standard e para que serve? É um documento, elaborado pelo Institute
of Electrical and Electronics Engineers Standards Association (IEEE SA), com o
propósito de promover a inovação tecnológica e a excelência para o benefício da
humanidade.

Um documento IEEE Standard contém padrões globais numa série de indústrias, como:
potência e energia, sistemas de inteligência artificial, internet das coisas, tecnologia de
consumo e produtos eletrónicos de consumo, biomedicina, etc.

2.2. Standard IEEE C37.1™-2007

Tal como podemos ler no Abstract do documento em análise, este é um standard IEEE
que define a norma do processo de integração de uma subestação como o processo de
projeto que é a base para a automação da subestação. Esta norma define ainda, os
requisitos funcionais e ambientais que são fornecidos para todos os IEDs localizados no
sistema. Em anexo constam alguns informativos que podem servir como tutoriais. Estes
informativos abrangem um leque de problemas comuns, relacionados com os sistemas
SCADA, sem atender aos seus requisitos. Dos anexos faz também parte informação
relacionada com os SCADA masters.
2
Análise Crítica ao Standard IEEE C37.1™-2007

Pela leitura do Abstract podemos verificar que este standard não vai focar a parte de
segurança no que diz respeito às estrutures de cloud-based, WAN ou LAN.

2.3. Análise Crítica ao Standard IEEE C37.1™-2007 Focando a sua

Segurança
No início do Standard IEEE C37.1™-2007, antes do artigo 1, há um aviso importante que
determina, logo à partida, que esta norma “não se destina a garantir proteção, segurança,
longevidade ou proteção ambiental em todas as circunstâncias” e que, “cabe a quem vai
utilizar esta norma a responsabilidade por determinar as práticas ou requisitos
regulatórios de proteção, segurança, meio ambiente e longevidade adequados”.

No primeiro artigo o âmbito, o objetivo e a utilização determinam a aplicação do standard

a “fornecer as bases para as definições, as especificações, a performance analítica na
aplicação de sistemas de automatização SCADA em subestações de rede energética”, “a
funcionar como um guia de especificações para os engenheiros responsáveis pelo design
dos sistemas de automatização SCADA” e “para ser utilizado pelos designers no design,
aquisição e implementação de todo os sistemas ou partes do mesmo”. Não há nenhuma
indicação para a segurança na comunicação dos dados ou das infraestruturas de rede no
sistema SCADA.

O segundo artigo remete para outras normas indispensáveis para a aplicação da norma
em análise. As que podem auxiliar na normalização dos sistemas de informação são as
seguintes:

− IEC 61850, Communication Networks and Systems in Substations;

− IEEE Std 487™, IEEE Recommended Practice for the Protection of Wire-Line
Communication Facilities Serving Electric Supply Locations;
− IEEE Std 1379™, IEEE Recommended Practice for Data Communications
between Intelligent Electronic Devices and Remote Terminal Units in a
Substation;
− IEEE Std 1613™, IEEE Standard Environmental and Testing Requirements for
Communications Networking Devices Installed in Electric Power Substations;
− IEEE Std 1615™, IEEE Recommended Practice for Network Communication in
Electric Power Substations.

As definições, acrónimos e abreviaturas estão explanados no 3º artigo.

3
Análise Crítica ao Standard IEEE C37.1™-2007

Do artigo 4º ao 9º, não há qualquer menção focando as normas de segurança, para as

estruturas de comunicação de dados, a aplicar aos sistemas de automatização SCADA,
tanto para os mastesr stations como para as subestações IEDs.

No artigo 4.2 explica a arquitetura e as funções para um Master station (control centre) e
uma figura onde essa arquitetura está representada, mas “sem quaisquer elementos de
network security”. Descreve a arquitetura como sendo do tipo distributed “composta por
software e hardware, com uma comunicação em tempo real com as subestações através
de uma LAN dedicada” com “funções de arquitetura aberta”. Indica quais os standards a
seguir para o sistema operativo, tanto dos servidores como dos postos de trabalho, e de
outros “produtos relacionados com as aplicações para computadores”. Menciona ainda
elementos de hardware que fazem parte desta arquitetura como as interfaces, as
workstations, os servers assim como, as funções desempenhadas por cada um destes
equipamentos na infraestrutura. O artigo não alude a qualquer tipo de segurança para as
“arquiteturas distribuídas”, para as “LANs dedicadas”, para os sistemas operativos dos
servidores e das estações de trabalho e para as “aplicações de computadores”.

O artigo 4.3 fala das funções do sistema de controlo para as arquiteturas dos Remote site
(substation). Este artigo faz a ponte entre os legacy RTUs e os recentes IEDs e indica
quais são os principais elementos que compõe a arquitetura das subestações. A “figura 2”
representada neste artigo mostra a “combinação entre as funções e os elementos que o
designer pode precisar, para a construção de um sistema para uma subestação
automatizada”, sem “mostrar quaisquer elementos para o network security” (“not show
any network security”). O artigo assinala ainda que a conexão entre as subestações e os
subsistemas restantes (EMS, outros utilizadores e estações de trabalho dos engenheiros),
faz-se com uma WAN “utilizando um router e uma firewall”, sem nunca descrever quais
os passos a seguir para aplicar políticas de segurança tanto para o router como para a
firewall. Neste artigo já é traçada a ideia de que os dados vão ser guardados num servidor
de “base de dados” contendo uma ligação separada para um servidor com uma “base de
dados para guardar o histórico de todos os dados”, aqui podemos considerar que estamos
perante uma política de segurança evitando perder os dados, mas não para a segurança
desses dados (roubo ou ramsom). Para uma melhor precisão na contagem das horas estes
equipamentos podem utilizar interfaces de GPS, denominadas IRIG-B, placas que podem
ser instaladas nos slots dos dispositivos que não se encontrem conectados a uma rede de
dados. Nas topologias de rede mais recentes, mais concretamente subestações IEDs,
4
Análise Crítica ao Standard IEEE C37.1™-2007

podem ser usados servidores NTP, SNTP ou o standard IEEE 1588 (used for “precision
time protocol (PTP) in power system applications”). Ainda neste artigo, relativamente ao
diagrama do “Example substation automation system architecture without security
shown”, há um paragrafo narrando que no diagrama “não está representada a
comunicação de mensagens cifradas para as ligações internas e externas, embora os
routers possam enviar/receber autenticações externas cifradas”. Já há aqui uma
preocupação com a proteção da autenticação, mas só da autenticação, o que é muito pouco
para um sistema SCADA moderno.

O artigo 5, que trata de normalizar a conceção do design, foca mais aspetos para a
estrutura da comunicação dos dados do que os restantes artigos. No que respeita ao design
das subestações indica que, “após o designer ter definido os requisitos de funcionalidade
do sistema”, tem de “decidir quais os protocolos de comunicação que vai usar (internos e
externos às subestações), os IEDs, o tipo arquitetura, as políticas de segurança e a sua
disponibilidade”.

Os critérios de peso para a escolha dos componentes de hardware e software a acrescentar

ao sistema, são explicados no artigo 5.3, Humane Machine Interface (HMI). Os critérios
para os HMI são apenas auxiliares para a decisão do designer e não evidenciam as
funcionalidades de segurança. A explicação nestes critérios vai mais ao encontro de
generalidades do que propriamente especificidades, como por exemplo no que diz
respeito ao software os critérios a presentados são:

a) “Operating system software;”

b) “Application software that includes any application loaded on the computer;”
c) “Configuration file(s) for the settings, displays, and database of the HMI
application.”

“Note that the HMI computer may have other applications that also have
configuration files, but the specification of these applications and files are not
included in this standard.”.

No artigo 5.4, “Software, firmware, and hardware issues” realça um aspeto importante,
considerada uma política de segurança para os sistemas de informação, que é “a aplicação
dos remendos de segurança (patches) e as atualizações de segurança em todos os
softwares e firmwares de todos os HMIs ao longo do ciclo de vida dos sistemas”.

5
Análise Crítica ao Standard IEEE C37.1™-2007

O artigo 5.5, “Security Requirementes”, tal como o nome indica, é o que mais auxilia o
designer na conceção da segurança transmissão/receção dos dados, na autenticação e nos
níveis de acesso aos dados, mas unicamente “para o designer ficar familiarizado com os
conceitos de segurança” e não como aplicá-los no entanto, como referido acima, já mostra
ao designer que tem de ter em conta, quando da conceção do sistema, aspetos de
segurança como “o controlo de acessos, o controlo de usabilidade, a integridade dos
dados, a confidencialidade dos dados, a restrição do fluxo de dados, a rápida resposta a
um evento e a disponibilidade continua da rede”. Para a implementação destas políticas
o documento IEEE Std C37.1™-2007, aconselha “a leitura de bibliografia de outras fontes
para melhor emprego dos conceitos de segurança”. É sugerido ao designer, neste artigo,
que consiga “equilibrar a segurança com a operacionalidade do sistema” e “que estes
requisitos sejam aplicados à segurança física e às vulnerabilidades dos sistemas
eletrónicos”, exemplificando que a segurança física pode ser configurada “nos acessos
físicos ao sistema de rede automatizado como aos restantes dispositivos, e ao
equipamento ativo da rede e à sua cablagem”, enquanto que a segurança dos
“equipamentos eletrónicos inclui itens como a cifra dos dados, a cifra da autenticação, a
deteção de intrusões na rede de dados, firewalls e deteção de acesso a um IED,
estabelecendo desta forma um perímetro de segurança”. Não mostrando quais a técnicas
de cifra ou as formas de configurar a cifra das mensagens, informa que estas “técnicas
estão disponíveis para cifrar as bases de dados das subestações, as redes de comunicação
do IED, os links para o SCADA, as WAN corporativas, os portos de manutenção dos IED
e outras entidades que sejam consideradas para o estabelecimento de práticas de
segurança”.

No 5.6, “Selection of Achitecture”, descreve as caraterísticas e funcionalidades dos

dispositivos que podem fazer parte do sistema como “a seleção das interfaces para as
comunicações externas, a seleção das interfaces para as comunicações internas, as
interfaces serial, as interfaces network-based, os adaptadores de rede e os standards de
rede”.

A escolha de protocolos de comunicação é descrita no artigo 6.7. O que este texto elucida
é se “um protocolo standard já estiver a ser utilizado numa subestação” o designer deve
escolher um IED que “conheça esse mesmo protocolo e que permita a sua conexão ao
canal de comunicações ou à rede”. Este texto dá também as opções de avaliação para

6
Análise Crítica ao Standard IEEE C37.1™-2007

quando “um protocolo proprietário já se encontra instalado na subestação e outros IEDs

tenham de ser adicionados”.

O artigo 5.8, “Maintaining Availability”, mais especificamente no 5.8.1, define os

“requisitos de disponibilidade para cada uma das funções do sistema”, apresentados numa
coluna das tabelas 1 a 6, do IEEE Std C37.1™-2007, para os requisitos de performance.
No 5.8 temos ainda a descrição para “identificar os componentes críticos, limitar o risco
de falha, estimar o tempo possível para a paragem de uma funcionalidade, providenciar
alternativas de suporte à indisponibilidade de uma funcionalidade, operacionalidade de
outras funções em paralelo e a utilização diversificada de funções para melhorar a
disponibilidade”.

O cuidado no artigo 6, é exclusivamente com a fonte de energia das subestações. No 6.3.3,

podemos ver que o standard se preocupa com a disponibilidade de energia elétrica como
forma de manter a disponibilidade das funções do sistema. Para que isto seja possível é
proposto ao designer um sistema misto onde exita sempre uma fonte de energia alternativa
e, se possível, que haja redundância da fonte de energia alternativa. Para a instalação de
fontes de energia alternativas o standard especifica as seguintes considerações:

a) “Duration of backup power operation without battery charging (usually not less
than 4 h but normally at least 24 h)”;
b) “Longevity of the battery source as estimated by its shelf life on charge”;
c) “Temperature range over which the battery will maintain required voltage and
current capabilities”;
d) “Replacement interval for backup batteries”;
e) “Precautions for possible corrosive material spill/seepage and explosive gas
accumulation”;
f) “Recovery time of the backup battery after a full discharge”;
g) “Alarming for failure of either power supply”.

O artigo 7, “Environmental Requirements”, tece considerações quanto à climatização dos

espaços físicos onde se encontram instalados os dispositivos das subestações. O artigo 8,
“Characteristics”, “define e discute as características gerais que são pedidas para os
equipamentos de aquisição de dados”. Nenhum destes artigos se debruça em aspetos de
segurança.

7
Análise Crítica ao Standard IEEE C37.1™-2007

As “especificações dos requisitos gerais que podem levar ao sucesso na implementação

do projeto” de sistemas SCADA automatizados, estão descritas no artigo 9, “General
Requirements”. Este artigo também não foca quaisquer aspetos de segurança relevantes.

Dos anexos do documento mais importantes de consultar, no que aos sistemas de

comunicação de dados diz respeito, são o A, o E e o H.

Estes anexos, tal como é indicado, são exclusivamente informativos e não apresentam
quaisquer soluções ou normas para o designer. São apenas auxiliares e mostram ao
designer como podem funcionar as coisas logo, também não têm normas que foquem a
segurança.

A realçar destes anexos, a menção de servidores redundantes para manter a

disponibilidade das funcionalidades do SCADA master station, a aproximação às
arquiteturas abertas para facilitar a conexão de equipamentos de tipos diferentes e a
indicação de um protocolo de comunicação para estes sistemas como DNP3. A
demonstração de utilização de sistemas operativos diferentes como o Linux para os
servidores aplicacionais e de bases de dados e o Windows para as monitorizações
gráficas, a importância das cópias de segurança e a importância de sistemas redundantes
para as copias de segurança.

Estes anexos mostram os diferentes tipos de bases de dados existentes e as suas

características, a necessidade de ter copias de segurança dessas bases de dados e como é
importante escolher o melhor tipo de armazenamento para as bases de dados, consoante
a sua funcionalidade.

Os fundamentos da comunicação são também tema dos anexos e explicam “que os IEDs
e as subestações automatizadas estão conectados por comunicações internas e externas às
subestações” e que através dessas conexões “são transmitidos dados e mensagens de
controlo entre os IEDs, formando assim um sistema de controlo”. As comunicações
referidas, independentemente do tipo de ativos que as fazem, “partilham protocolos
comuns como o Modbus, Modbus Plus e o DNP3”. São referidos os diversos tipos de
tipologias de rede. Quanto à segurança é referido que esta é necessária para evitar
“acessos indevidos como espionagem, substituição de bits, spoofing ou interferência de
ransom”, que “a maioria das vezes é impossível garantir a segurança total dos sistemas”

8
Análise Crítica ao Standard IEEE C37.1™-2007

e ainda “que as funções de segurança são aplicadas ao protocolo(s) usado(s) nos canais
de comunicação”.

9
Análise Crítica ao Standard IEEE C37.1™-2007

Conclusão
O Standard IEEE C37.1™-2007, para SCADA and Automation Systems, não foca a
segurança das comunicações de dados das subestações. Este standard é mais para o design
do projeto, deixando a segurança para um nível diferente e, é por essa razão que apresenta
ao designer diferentes standards para a normalização dos sistemas de informação.

O standard em causa preocupa-se com a disponibilidade ininterrupta das funcionalidades

do sistema sem focar a segurança do mesmo.

Todas as alusões à segurança, são apenas informativas e apenas para conhecimento do

designer enquanto elabora o projeto.

Assim sendo, para elaborar um projeto com sucesso para a implementação de um SCADA
and Automation Systems, não basta seguir este standard. Para que o projeto tenha sucesso
temos de seguir o conselho de “ler bibliografia de outras fontes para melhor emprego dos
conceitos de segurança” e dos standards próprios com normas e conceitos de segurança.

Assinado por : JOÃO CARLOS MODESTO PARRA

Num. de Identificação: BI069388784
Data: 2021.11.11 17:53:57+00'00'

10