INSTITUTO POLITÉCNICO DE BEJA

Escola Superior de Tecnologia e Gestão

Mestrado em Engenharia de Segurança

Informática

Cibersegurança em Infraestruturas
Crı́ticas
Standards que regulamentam os sistemas SCADA

Eduardo Durães - 21085

Jose Francci Neto - 20656

2021
 INSTITUTO POLITÉCNICO DE BEJA

Escola Superior de Tecnologia e Gestão

Mestrado em Engenharia de Segurança Informática

Cibersegurança em Infraestruturas
Crı́ticas
Standards que regulamentam os sistemas SCADA

Elaborado por:

Eduardo Durães - 21085

Jose Francci Neto - 20656

Docentes:
Daniel José Graça Peceguina Franco, IPBeja

2021
Índice

Índice i

Índice de Figuras iii

1 Introdução 1
1.1 Sobre ISA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Comite ISA 112 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Sistema SCADA 5
2.1 Rede CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1 Os 4 Pilares Principais da CAN . . . . . . . . . . . . . . . . . 8
2.1.2 Tipos de mensagens . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.3 Envio e recebimento de mensagens . . . . . . . . . . . . . . . 10
2.1.4 Controles de segurança . . . . . . . . . . . . . . . . . . . . . . 11
2.1.5 Ataques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Conclusão 15

Bibliografia 17

i
Índice de Figuras

1.1 ISA112 SCADA-Systems SCADA-lifecycle-diagram rev2020-06-15.pdf . . 3

1.2 ISA112 SCADA-Systems SCADA-model-architecture rev2020-05-28.pdf . 4

2.1 Exemplo de interface do supervisório SCADA. . . . . . . . . . . . . . . . 5

2.2 Tı́pico sistema SCADA.[1] . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Conector CAN de 16 pinos . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Formato de um pacote de mensagem CAN: standard (em cima) e esten-
dido (em baixo) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5 Hierarquia de chaves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.6 Componentes conectados e controlados na rede CAN . . . . . . . . . . . 14

iii
1. Introdução

Um padrão é um conjunto de caracterı́sticas descreve um produto, processo, serviço,

interface ou material. Os padrões não apenas tornam a vida mais fácil, eles a tornam
mais segura e aumentam a lucratividade das empresas. Por exemplo, os constru-
tores economizam dinheiro porque os materiais de construção estão disponı́veis em
tamanhos padrão. Ao mesmo tempo, os códigos elétricos que os construtores devem
seguir salvam vidas.1

1.1 Sobre ISA

A International Society of Automation (ISA) é uma associação profissional sem fins
lucrativos que define o padrão para aqueles que aplicam engenharia e tecnologia
para melhorar o gerenciamento, a segurança e a segurança cibernética de sistemas
modernos de automação e controle usados em toda a indústria e infraestrutura
crı́tica. 2
Fundada em 1945, a ISA desenvolve padrões globais amplamente usados; certifica
profissionais da indústria; oferece educação e treinamento; publica livros e artigos
técnicos; hospeda conferências e exposições; e fornece programas de networking e
desenvolvimento de carreira para seus 40.000 membros e 400.000 clientes em todo o
mundo.

1.2 Comite ISA 112

SCADA (Supervisory Control And Data Acquisition) que em sua tradução livre
significa Sistema de Supervisão e Aquisição de Dados, é um sistema que usa um
software para monitorar, supervisionar e controlar as variáveis e os dispositivos de
um processo.
1
https://www.isa.org/standards-and-publications/isa-standards
2
https://www.isa.org/about-isa

1
1. Introdução

Estabelecido em 2016, o comitê ISA112 para Sistema SCADA está desenvolvendo

ativamente uma série de padrões ISA e relatórios técnicos para sistemas de controle
de supervisão e aquisição de dados (SCADA). 3
A norma ainda está em criação e a proposta desta norma é tratar das boas
práticas relacionadas ao desenho, implementação, operação e manutenção de siste-
mas de Supervisão e Controle. Ela será aplicável a qualquer tipo de indústria e terá
uma aderência muito boa ao setor de saneamento.
O comitê será responsável pelo desenvolvimento de padrões e relatórios técnicos
destinados a melhorar a confiabilidade geral do projeto, instalação, integração e
operação da infraestrutura de dutos, água e esgoto, energia, óleo e gás e outras
indústrias de controle de supervisão e aquisição de dados (SCADA). Os padrões e
relatórios técnicos fornecerão orientação para a implementação de sistemas SCADA
eficazes e confiáveis, documentando as melhores práticas em uma variedade de
indústrias.
O plano de trabalho do comitê ISA112 é o seguinte: 4

• 2016 Criação do comitê

• 2017-2019 - Desenvolvimento de ı́ndice, diagramas e rascunho de conteúdo

• 2020 - Lançamento dos primeiros rascunhos dos diagramas ISA112 SCADA

Management Lifecycle e ISA112 SCADA Model Architecture

• 2021 - Conclusão do primeiro rascunho interno dos principais padrões SCADA

ISA112

• 2021-2022 - Rodadas de comentários e edição interno

• Outono 2023 - Data prevista para a publicação do primeiro documento de

padrões ISA112

• 2024-2026 - Desenvolvimento de relatórios técnicos ISA112 SCADA

Atualmente foi publicado apenas o ISA112 SCADA System Lifecycle – DRAFT

(figura 1.1 5 ) e o ISA112 SCADA System Model Architecture Diagram – DRAFT
(figura 1.2 6 ).

3
https://www.isa.org/standards-and-publications/isa-standards/
isa-standards-committees/isa112
4
https://www.isa.org/standards-and-publications/isa-standards/
isa-standards-committees/isa112
5
https://www.isa.org/getmedia/ac809e6d-27ed-4305-b207-9813b04f43b4/ISA112_

2
 1.2. Comite ISA 112

ISA112 SCADA System Lifecycle – DRAFT (subject to change)

ISA112 – SCADA Systems Standards Committee – International Society of Automation (ISA) – www.isa.org/isa112/

0 CONTINUOUS WORK PROCESSES

a b c d Management Of Change e f
Long Term Planning Security1 Documentation Verification Audit
(MOC)

New System ENTRY ENTRY

Major Changes
Regulatory Changes Change To System
1 SCADA SYSTEM 2 DESIGN 3 SYSTEM 4 HARDWARE BUILD
STANDARDS DEVELOPMENT / FABRICATION
a a Project Charter / Design Brief a Sign-Off on Functional Design a Start Purchasing Process
SCADA Philosophy
b Define Requirements b Procure Software b Submittals & Shop Drawings

DEVELOP SCHEDULE/RESOURCING
b Packages / Licenses
SCADA Availability / Reliability c Get Existing Documentation
Guidelines c Setup Development Environment
d Verify Existing
c Equipment / Documentation d Create Detailed Data Tags
SCADA Platform Selection
e Preliminary Design Work e Application Development
d
Safety Standards f Conceptual Architecture/Design f Modeling and Simulation
g Proof of Concept g Server Configuration c
Buy Parts / Components
e
Security1 Standards,
Guidelines and Procedures
h Preliminary Architecture / Design h Workstation Configuration d Build Panels, Racks and Cabinets
i Confirm P&ID and i e
f Network Configuration Build Supporting Equipment
Facility Layout Drawings
Network / Architecture Guide
j Security1 Configuration
j Develop Signals List
g Equipment I/O
REVIEW k Review Draft HMI Displays
k Process Control Narrative /
Interface Standard and Draft Code / Configurations
Functional Design Documents
h Packaged Equipment I/O l Master l Software f Hardware
Alarm Database (ISA18.2)
Interface Standard Factory Acceptance Test (FAT) Factory Acceptance Test (FAT)
m Test and Simulation Strategy
i m Integrated System
Panel Design Standard n Develop Preliminary Operation / Factory Integration Test (FIT)
Maintenance Philosophy
n Write Operational Maintenance
J Field Wiring / Wire Labelling o Detailed Network Design Procedures
Standard
p Vendor Package Interface /
o Develop Software
k Integration Design Training Materials
Data Point Tagging Standard
q Final Architecture
l Equipment Tagging / Naming r Detailed Hardware & I/O Design
Standards
s Detailed Software Specification
m HMI Philosophy and HMI Style t Detailed Reliability Design
Guides (ISA101)
u Detailed Safety Design
n
Alarm Philosophy (ISA18.2)
v Detailed Security1 Design

o w Complete Drawing/Spec Package

Event Processing Logging and
Messaging Guideline

p
Programming / Configuration Continuous
Guides Improvement
q
Programming / Alarm /
Configuration Templates

Data Collection / Data Storage /

5 INSTALLATION 6 COMMISSIONING 7 OPERATE Continuous
r
Historian Guide /DEPLOYMENT / STARTUP Improvement
a Installation / Deployment Plan a Commissioning Plan a In Service
s SCADA to Business Integration /
Data Sharing Philosophy b Process / Mechanical b Equipment Pre-Check b Maintain
Installation Complete
t c I/O Check c Periodic Testing
Data Reporting Standards c Hardware Install / Deployment
d Loop Checks d Out of Service
u d Electrical Installation Complete Prerequisite Tests2 e
CAD / Drawing Standards e Vendor / Service Provider
e Network Support
Setup Final Configuration f Site Acceptance Test (SAT)
v f Warranty Support /
Documentation Standards f Configure Instruments / g Site Integration Test (SIT) Warranty Management
Field Sensors
h Security1 Verification g Spare Parts Management
w
MOC Procedures Document g Configure Controlled Devices i Loop Tuning h Training: Refresher, New Staff
h Confirm Calibration j Operational Readiness
x i Configuration Management
SCADA Work Procedures Documentation
k Training j Calibration Management
y i Software Deployment
l Burn in Period / Performance Test
Approved Equipment List k Monitor Performance
m As Built Documentation l Operational Tuning
z Equipment Specification
Templates n Update Operating / Maintenance m Alarm Management Program
Procedures
n Decommission / Retirement
o Update Facility Documentation

ISA112 Lifecycle Diagram

Notes
1) Security includes physical security, operational security and cybersecurity. Current Working Draft
2) Prerequisite tests typically include both cold and hot commissioning or dry / wet commissioning as applicable. Revised June 15, 2020

Note: This is an interim working draft from the ISA112 SCADA Systems standards committee, as of 2020-06-15. This diagram is still subject to change.

Figura 1.1: ISA112 SCADA-Systems SCADA-lifecycle-diagram rev2020-06-15.pdf

SCADA-Systems_SCADA-lifecycle-diagram_rev2020-06-15.pdf
6
https://www.isa.org/getmedia/626ce8b5-4d89-4924-98e4-082bc1c1982c/ISA112_
SCADA-Systems_SCADA-model-architecture_rev2020-05-28.pdf

3
1. Introdução

ISA112 SCADA System Model Architecture Diagram – DRAFT (subject to change)

ISA112 – SCADA Systems Standards Committee – International Society of Automation (ISA) – www.isa.org/isa112/

K External Applications External Network

Level 5*
J Enterprise Network Enterprise Network
(Note 5) Level 4
I DMZ / Process Information Network Process Information Network

Level 3

Supervisory Controllers
H Control Network Control Network

Purdue Reference Model

G HMI Alarms & Events Historian Applications
Databases
Level 2
F Drivers Communication Servers

E Backhaul networks Wide Area Network

D Controller Network Level 1

Site n

C Local Controllers

B Field Sensor networks

Level 0
A Field Devices
Notes:
1 Letters are used to avoid potential conflict with ISA-95 and other “Layer” models.
2 Routers and Firewalls between layers are not shown.
3 Other system-specific servers, applications ,and workstations are not shown.
4 Communications for any remote-hosted external applications (Cloud) with lower levels must be done using extreme care.
5 The use of direct-connections for remote applications is strongly discouraged. Refer to ISA/IEC-62443 for guidance on an appropriate zone/conduit implementation. Current Working Draft
* We show a Purdue Level 5. The true Purdue Model only has levels 0-4 because it did not anticipate external applications. Revision May 28, 2020

Note: This is an interim working draft from the ISA112 SCADA Systems standards committee, as of 2020-06-15. This diagram is still subject to change.

Figura 1.2: ISA112 SCADA-Systems SCADA-model-architecture rev2020-05-

28.pdf

4
2. Sistema SCADA

Software SCADA pode ser dividido em dois tipos, proprietário ou aberto. Compa-
nhias desenvolvem software proprietário para comunicação com seu próprio hard-
ware. Estes sistemas são vendidos como soluções “turn key”. O principal problema
desses sistemas é a grande dependência do fornecedor do sistema. Sistemas aber-
tos ganharam popularidade devido à interoperabilidade que trazem para o sistema.
Interoperabilidade é a habilidade de equipamentos de fabricantes diferentes serem
utilizados no mesmo sistema.[1]
Apesar de não haver um padrão definido de comunicação do sistema SCADA
ele á é amplamente utilizado na indústria, e tem um papel indispensável na era
da informação e IoT. Com isso os sistemas supervisórios, como também são cha-
mados, tornam-se ferramentas indispensáveis para o desenvolvimento tecnológico.
Na figura2.1 podemos visualizar a tela de ums sistema supervisório utilizado por
operadores de transmissão e distribuição de energia eléctrica.

Figura 2.1: Exemplo de interface do supervisório SCADA.

5
2. Sistema SCADA

Os sistemas SCADA também podem ser utilizados para outros fins diferentes da
indústria, como por exemplo a automação residencial, onde o usuário pode controlar
ou visualizar o estado de lâmpadas e outros dispositivos utilizando de softwares que
controlam o mesmo como Alexa, Cortana e Google Assistente. 1
Um sistema SCADA trata-se de um software, que por meio da sua comunicação
com um determinado dispositivo, exibe informações ao usuário e envia comandos do
usuário para o dispositivo. Ele se divide em alguns componentes como:

• Os sensores são dispositivos conectados aos equipamentos controlados e mo-

nitorados pelos sistemas SCADA que convertem parâmetros fı́sicos, tais como
nı́vel de água, temperatura e velocidade para sinais analógicos e digitais legı́veis
pela estação remota.

• Os atuadores são utilizados para atuar sobre o sistema, ligando e desligando

determinados equipamentos ou abrindo e fechando válvulas.

• As estações remotas é onde o processo de aquisição dos dados se inicia.

Para isso são utilizados os PLC’s (Programmable Logic Controllers) ou as
RTU’s (Remote Terminal Units). Eles que permitem a comunicação entre
a estação central de monitoração e os equipamentos monitorados. Através
destes dispositivos é possı́vel a obtenção dos dados informados pelos sensores,
execução de seus cálculos e apresentação de saı́das.

• Uma rede de comunicação é a plataforma responsável pelo fluxo de in-

formações entre as estações remotas as estações de monitoramento central.

• As estações de monitoração são as unidades principais dos sistemas SCADA,

sendo responsáveis por recolher a informação gerada pelas estações remotas e
agir em conformidade com os eventos detectados.

A figura2.2 demonstra dispositivos que compões basicamente uma arquitetura

SCADA.
Pressão, vazão, temperatura, nı́vel, tensão, peso, humidade e corrente são exem-
plos de algumas variáveis de processo que podem ser visualizadas e controladas por
meio do sistema SCADA.
1
https://iconics.com/News/Press-Releases/2019/ICONICS-Introduces-Voice-Machine-
Interface-for-Amazon-Alexa-Microsoft-Cortana-Google-Assistant

6
 2.1. Rede CAN

Figura 2.2: Tı́pico sistema SCADA.[1]

2.1 Rede CAN

Controller Area Network (CAN) é o sistema de comunicação muito conhecido do
mundo automotivo. É um meio de conectar todos os sistemas eletrônicos de um
carro para permitir que eles se comuniquem entre s e está descrito nos padrões da
ISO 11898-1 e ISO 11898-2.
As CANs baseiam-se no conceito do uso de mensagens geradas por broadcast
contendo um dispositivo central controlador de mensagens. É também um padrão
de barramento que possibilita a comunicação de microcontroladores e dispositivos
entre si sem a necessidade de um computador host. Em resumo:

• A camada fı́sica usa transmissão diferencial em um fio de par trançado.

• Uma arbitragem bit a bit não destrutiva é usada para controlar o acesso ao
barramento.

• As mensagens são pequenas (no máximo oito bytes de dados) e são protegidas
por um checksum.

• Não há endereço explı́cito nas mensagens, em vez disso cada mensagem carrega
um valor numérico que controla sua prioridade no barramento e também pode
servir como uma identificação do conteúdo da mensagem.

7
2. Sistema SCADA

• Há um esquema de tratamento de erros elaborado que resulta em mensagens

retransmitidas quando não são recebidas corretamente.

• Existem meios eficazes para isolar falhas e remover nós com falha do barra-
mento.

À medida que a informatização dentro de um carro aumenta, também aumenta o

número de diferentes sistemas eletrônicos. As informações registradas e processadas
por cada um são frequentemente utilizadas por um ou mais outros - daı́ a necessi-
dade de um meio padronizado de passar informações rapidamente entre eles. Esse
requisito levou ao desenvolvimento do CAN.
No mundo dos diagnósticos automotivos é possı́vel acessar a rede CAN, e se
comunicar com vários sistemas integrados, por meio da porta de diagnóstico OBDII
/ EOBD de 16 pinos (figura 2.32 ), inclusive isto é obrigatório em todos os carros em
2008.

Figura 2.3: Conector CAN de 16 pinos

2.1.1 Os 4 Pilares Principais da CAN

Baseada nesses pilares as redes CANs trabalham com uma topologia fı́sica em estrela
e lógica em barramento, enviando suas mensagens em broadcast.

1º Implementação de Hardware:

O meio de transmissão para as redes CAN influencia diretamente no funcionamento

e no envio correto das mensagens, uma vez que estas precisam ser confiáveis e em
alta velocidade.
2
https://www.mundodaeletrica.com/como-seu-carro-se-comunica-rede-can-obd2/

8
 2.1. Rede CAN

A topologia fı́sica da rede também precisa ser analisada com cuidado. O compri-
mento de cada ramo do ”Chicote Elétrico”deve seguir a norma CAN, do contrário,
a propagação das mensagens pode ser prejudicada.

2º Simples Transmissão:

As CANs devem funcionar mesmo caso haja falha no link, assim, uma CAN trans-
mitindo por 2 pares de cabo é capaz de operar normalmente somente com 1 par.

3º Controle de Erro:

O controle de erro do protocolo CAN é o mais interessante e principal caracterı́stica

desse tipo de rede. Como as CANs são utilizadas em sistemas sensı́veis a falha o
controle de erro é feito pelos próprios dispositivos.

4º Ótimo confinamento de falhas:

A falha de um dispositivo pode resultar no envio de mensagens de erro na rede,

assim, prejudicando a largura de banda.
Este mecanismo de controle de erros garante que as mensagens sinalizadoras
de eventos crı́ticos possam ser enviadas com sucesso garantindo a integridade do
sistemas. Apesar de as mensagens serem enviadas em broadcast, as colisões não são
destrutivas como nas redes Ethernet, sendo em todas as mensagens transmitidas
com um bit recessivo e outro dominante ao qual tem prioridade na transmissão.
Quando duas mensagens são enviadas no meio, a mensagem com maior prioridade
continua a ser transmitida enquanto a com o bit recessivo, de menor prioridade, é
abortada a transmissão pelo dispositivo originador do sinal.
As mensagens bloqueadas são retransmitidas pelo controlador central.

2.1.2 Tipos de mensagens

São 4 os tipos de mensagens trafegando nas redes CAN. São elas:
Mensagens enviadas quando o sistema esta num estado funcional: Data Frame
e Remote Frame.
Mensagens enviadas quando o sistema esta num estado caracterı́stico de erro:
Overload Frame e Error Frame.

9
2. Sistema SCADA

Data Frame

Tipo de mensagem enviada na rede para transportar informações correntes do sis-

temas, dados normais. Por exemplo; em sistemas automotivos serve para sinalizar
o estado da temperatura do óleo (sensor que deve enviar informações constantes).

Remote Frame

Mensagem enviada solicitando informação do sistema, ou seja, quando um disposi-

tivo precisa verificar se há água no reservatório do sistema de limpeza do pára-brisa
este envia uma mensagem para o controlador do reservatório solicitando o estado
atual do mesmo.

Overload Frame

Mensagem que serve para indicar um estado ocupado do sensor, ou seja, quando um
dispositivo envia uma mensagem de Remote Frame para um dispositivo ocupado é
retornado uma mensagem Overload indicando congestionamento do dispositivo.

Error Frame

Mensagem caracterı́stica quando um dispositivo indica que não foi possı́vel enviar
uma mensagem de controle por ser recessiva. Este tipo de mensagem também serve
para indicar que o dispositivo apresenta falhas. Para o sucesso das informações de
controle é necessário portanto que cada mensagem contenha um número de controle
diferente, assim, possibilitando, com a ajuda do bit recessivo/dominante, o envio
das mensagens crı́ticas.

2.1.3 Envio e recebimento de mensagens

Cada módulo (nó) conectado ao barramento é capaz de enviar e receber sinais, isso
permite que o módulo receba as entradas e os dados de que precisa para funcionar,
enquanto ignora as informações destinadas a outros módulos que compartilham a
rede. Quando um módulo transmite informações pela rede, as informações são
codificadas para que todos os outros módulos reconheçam de onde vieram.
O protocolo CAN requer um formato de frame padrão para os dados. Isso signi-
fica que para cada mensagem distinta enviada ou recebida por um módulo na rede,
há um bit de inı́cio chamado de bit ”inı́cio de frame”ou ”inı́cio da mensagem”(STF
- Start of frame), seguido por um código ”identificador”de 11 bits que informa que
tipo de dados a mensagem contém, seguido por um código de prioridade (RTR -

10
 2.1. Rede CAN

Remote Transmission Request) que diz a importância dos dados, seguido por 0 a 8
bytes de dados reais , seguido por mais alguns bits que verificam a informação (CRC
- Cyclic Redundancy Check), seguido por alguns bits de fim de mensagem e um bit
de ”fim de frame”. O formato padrão desta mensagem pode ser visto na figura 2.4,
descrito na tese do Antônio Pires [2].

Figura 2.4: Formato de um pacote de mensagem CAN: standard (em cima) e

estendido (em baixo)

2.1.4 Controles de segurança

A primeira dificuldade de se implementar uma proteção na rede CAN são suas li-
mitações da taxa máxima de transferência de dados, que é de 1 Mbps, e a carga
útil máxima (payload) de uma mensagem ser de 8 bytes. Devido a essas proprie-
dades, é difı́cil para o CAN usar diretamente as medidas de segurança que foram
desenvolvidas para produtos de consumo.
Ainda o sistema CAN, por trabalhar por broadcast, permite que um intruso, se
tiver acesso a rede CAN, poder injetar qualquer mensagem CAN, inclusive criando
um fluxo tão grande de mensagens prioritárias que resulte um um ataque de negação
de serviço ou extrair e manipular status de algum componente.
Para blocos maiores de dados, são comuns segurança ponta a ponta e padrões
de criptografia usado na Internet, como SSL. Elas pode ser aplicado a comunicações
CAN, também, mas apenas em combinação com um protocolo de transporte ponto a
ponto no topo do CAN. Porém é um grande desafio criar algo para mensagens muito
pequenas como, por exemplo, sensores que informam o status utilizando apenas
alguns bytes, ou mesmo de bit único, como destrancar uma porta.
Uma das formas de se proteger do ataque de spoofing (falsificação) é o próprio
componente identificar que ele está sendo alvo do ataque monitorando a rede em
busca de mensagens com seu ID CAN, uma implementação chamada de auto-
monitoramento. Se uma mensagem que ele não enviou for detectada, o dispositivo

11
2. Sistema SCADA

emite uma mensagem de emergência invalidando toda a ”sua”comunicação. Neste

caso o invasor precisaria desabilitar o nó em questão primeiro.
Para também dificultar os ataques a implementação do CAN pode permitir que
o ID de cada nó seja reatribuı́do a cada reinicialização do sistema. Para evitar a
duplicação acidental de IDs do nó, cada dispositivo deve monitorar a rede em busca
de IDs de mensagem CAN que ele mesmo transmite.
Outra forma de se implementar a segurança é através de chaves simétricas pré-
compartilhadas entre os nós. Neste caso há o desafio de como inserir esta chave nos
dispositivos e onde manter cópias dela. Outro desafio é como efetuar a atualização
/ modificação dinâmica da chave compartilhada. Neste caso se todos os dispositi-
vos necessitarem de atualizar continuamente a chave, os algoritmos de segurança
especı́ficos não precisam ser muito fortes.
O controle de chaves pode ser implementado através do CANcrypt3 . Este
padrão define a seguinte hierarquia de chaves, descrito na figura 2.5:

• Fabricante: somente essa chave permite uma redefinição de fábrica ou ativar

um possı́vel bootloader para reprogramar a memória flash no dispositivo.

• Integrador de sistema: permite restaurar uma configuração padrão do sis-

tema.

• Proprietário: capaz de substituir um único dispositivo dentro do sistema.

As chaves nunca podem ser lidas em um dispositivo que implementou o CAN-

crypt. Eles só podem ser apagados ou geradas novamente. Para apagar uma chave,
deve-se estabelecer uma conexão segura direta com um único dispositivo com base
em uma das chaves armazenadas. Uma vez que os dispositivos estão emparelhados,
pode-se apagar chaves do mesmo nı́vel hierárquico ou inferior apenas. Logo uma vez
que uma chave é gerada e salva, ela só pode ser apagada e regenerada se emparelhada
com base em uma chave do mesmo nı́vel de segurança ou superior.
Maiores detalhes de como estas chaves funcionam e podem ser trocadas pode ser
obtidas no trabalho do Olaf Pfeiffer e Christian Keydel [3].

2.1.5 Ataques
Alguns tipos de ataques foram citados acima mas um dos que tiveram maior reper-
cussão, por ter sido apresentado na conferência Black Hat USA em 2015, foi como
3
https://cancrypt.net/

12
 2.1. Rede CAN

Figura 2.5: Hierarquia de chaves

Charlie Miller e Chris Valasek acessaram e manipularam todos componentes da rede

CAN de um carro remotamente utilizando um celular. 4
Ao se pensar neste tipo de redes imagina-se que os ataques possı́veis são apenas
os que tem acesso fı́sico a rede, porém devemos ter em mente que este tipo de acesso
pode ser feito através de uma ponte, que neste caso foi a conexão do carro a rede
de telefonia móvel.
O que acontece é que o sistema multimı́dia oferece um ponto de acesso wi-fi aos
passageiros roteando o mesmo a rede de celular, além de outros serviços on-demand
oferecidos pelo fabricante. A princı́pio o sistema de multimı́dia não está conectado
diretamente ao barramento CAN, porém há um componente intermediário que faz
isto, o controlador V850.
O software do controlador V850 foi projetado de forma que é possı́vel ouvir o bar-
ramento CAN mas não enviar comandos por ele. Mas os pesquisadores descobriram
uma forma de alterar o firmware do controlador V850 para sua versão customizada,
que permitia enviar estes comandos.
Depois dessa mudança, Miller e Valasek puderam enviar comandos através do
barramento CAN e manipular todos componentes do carro. Eles eram capazes de
controlar o volante, o motor, a transmissão, o sistema de freios5 , sem mencionar
limpador de para-brisa, ar condicionado, travas das portas e assim por diante como
4
http://illmatics.com/Remote%20Car%20Hacking.pdf
5
Os carros mais atuais oferecem o sistema de Park Assist, que consegue manobrar e estacionar
o carro sem o auxı́lio de uma pessoa. Ele manipula o sistema de freios, direção e motor para isto.

13
2. Sistema SCADA

os sistemas listados na figura 2.66 . Além disso, eles foram capazes de controlar tudo
isso de forma totalmente remota, através da rede celular.

Figura 2.6: Componentes conectados e controlados na rede CAN

6
http://www.getloupe.com/v/mu7745ht

14
3. Conclusão

Os sistemas SCADA estão convergindo cada vez mais para plataformas baseadas em
sistemas abertos e com a sua arquitetura fortemente apoiada em conectividade. No
princı́pio, esses sistemas eram fechados e sem conectividade externa, porém atual-
mente os modelos de sistemas SCADA baseiam-se em conectividade, principalmente
voltados à Internet, visando o aumento da eficiencia e da produtividade.
Mesmo em sistemas aparentemente fechados e não fabril, como as redes CAN, é
possı́vel haver alguma integracão com a internet que traz diversos problemas relaci-
onados com segurança.
Uma vez que um invasor tenha acesso direto ao barramento para um sistema
CAN, ele terá acesso de leitura a TODAS as comunicações na rede. Se ele tiver
acesso de gravação, então os ataques do tipo “negação de serviço” são fáceis e não
podem ser evitados, além de outros ataques como repassar informações erradas de
leituras, desativação da função de freio ou outro controle não autorizado por uma
mensagem falsificada na rede.
Mesmo implementando sistemas de proteção como a oferecida pelo CANcrypt,
que varia de uma simples autenticação a um emparelhamento mais seguro de dois
nós com autenticação e criptografia, o fabricante de um sistema que usa CAN pode
não ser totalmente capaz de proibir um acesso remoto.

15
Bibliografia

[1] G. Clarke, D. Reynder, e E. Wright, Pratical Modern SCADA. Elsevier, 2004.

(citado nas págs. iii, 5 e 7)

[2] A. J. M. Pires, “Comunicação de tempo-real em barramentos can baseados no

controlador sja1000,” Dissertação de mestrado, Faculdade de Engenharia da Uni-
versidade do Porto, 2005. (citado na pág. 11)

[3] C. K. Olaf Pfeiffer, “Scalable can security forcan, canopen and other protocols,”
International Conference on Communications, 2017. (citado na pág. 12)

17