Universidade Federal de Minas Gerais
Escola de Engenharia
Curso de Graduação em Engenharia de Controle e Automação
Implementação de um Sistema de Segurança preditiva em uma
planta industrial através de técnicas de controle supervisório
como estratégia para antecipação e mitigação de ataques
Marcone Márcio da Silva Faria
Orientador: Patrícia Nascimento Pena
Supervisor: Eng. Michel Rodrigo das Chagas Alves
Belo Horizonte, Fevereiro de 2025
Monografia
Implementação de um Sistema de Segurança preditiva em uma planta
industrial através de técnicas de controle supervisório como estratégia para
antecipação e mitigação de ataques
Monografia submetida à banca examinadora designada pelo Colegiado Didático do Curso de Graduação em Engenharia de Controle e Automação da
Universidade Federal de Minas Gerais, como parte dos requisitos para aprovação na atividade Projeto Final de Curso II.
Belo Horizonte, Fevereiro de 2025
i
Resumo
No Resumo, em uma única página, em no máximo dois parágrafos, você explicita os
seguintes itens: objetivos do projeto e descrição sucinta do local onde ele foi desenvolvido;
metodologia utilizada; e resultados alcançados. Leitores experientes decidem se prosseguirão para a leitura do texto completo após lerem o resumo, a conclusão e a introdução.
Por isso nestes lugares você deve colocar um esforço maior de convencimento. Além disso,
a linguagem utilizada deve ser acessível a leitores com pouca familiaridade com a área,
limitando-se o uso de jargões.
Este novo parágrafo serve para mostrar que ao pular uma ou mais linhas no texto
do arquivo .tex, o TEX entende que você está iniciando outro parágrafo. O comando
sloppypar força o texto a não ultrapassar as margens. Só deve ser usado se este problema
ocorrer.
iii
Abstract
Write a version of your “resumo” in English. Beware of literal translations and double
check the translation of technical terms.
v
Agradecimentos
Aqui vai o texto dos agradecimentos.
Sumário
Resumo
i
Abstract
iii
Agradecimentos
v
1 Introdução
1
1.1
Motivação e Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2
Objetivos do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.3
Local de Realização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.4
Estrutura da Monografia . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2 Conceitos Preliminares
5
2.1
Os Sistemas de Controle Industrial (ICS) . . . . . . . . . . . . . . . . . .
5
2.2
Arquitetura dos Sistemas de Controle . . . . . . . . . . . . . . . . . . . .
6
2.3
Princípios de Segurança em ICS . . . . . . . . . . . . . . . . . . . . . . .
7
2.4
Alfabetos, Palavras e Linguagens . . . . . . . . . . . . . . . . . . . . . .
8
2.5
Autômatos Finitos Determinísticos . . . . . . . . . . . . . . . . . . . . .
9
2.6
Teoria de Controle Supervisório . . . . . . . . . . . . . . . . . . . . . . .
11
2.7
Revisão de metodologias . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.8
Metodologia proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3 Descrição do Processo de Simualação
15
3.1
Descrição do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.2
Arquitetura de rede adotada . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.3
Entrega de eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.4
O controlador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
3.5
Processamento de ataques . . . . . . . . . . . . . . . . . . . . . . . . . .
24
4 Metodologia
4.1
27
O atacante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.1.1
27
Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vii
viii
SUMÁRIO
4.1.2
4.2
Fluxo dos ataques . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
O IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.2.1
Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.2.2
Funcionamento e operação . . . . . . . . . . . . . . . . . . . . . .
27
5 Resultados
29
5.1
Atividades do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
5.2
Requisitos do Sistema
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
5.3
Desenvolvimeto e Implementação . . . . . . . . . . . . . . . . . . . . . .
29
5.4
Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
5.5
Análise dos Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
6 Conclusões
31
6.1
Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
6.2
Propostas de Continuidade . . . . . . . . . . . . . . . . . . . . . . . . . .
31
Referências Bibliográficas
32
Capítulo 1
Introdução
O uso de sistemas de controle industriais (Industrial Control Systems - ICS) aliado a
tecnologias de comunicação em rede, como o Foundation Fieldbus por exemplo, vem se
tornado cada vez mais comum nas indústrias a medida que permite uma comunicação
bidirecional entre dispositivos de campo e sistemas de controle, o que resulta em maior
eficiência operacional, monitoramento remoto avançado e flexibilidade na integração de
dispositivos de diferentes fabricantes.
No entanto, o ganho em eficiência introduzido pelo ICS também traz à luz discussões
sobre problemas de segurança, revelando um aumento significativo nos desafios enfrentados pelos sistemas de controle industrial. A crescente sofisticação e diversificação dos
ataques cibernéticos direcionados a esses sistemas destacam a urgente necessidade de medidas proativas e abrangentes para proteger as infraestruturas críticas contra potenciais
danos operacionais, interrupções na produção e riscos à segurança pública. [1]
Além disso, os ataques podem acontecer em diferentes níveis de um ICS, em cada um
desses níveis existem informações e impactos distintos que um ataque pode causar ao corromper essas informações. A maioria dos ataques pode ser considerada como fraudes ou
ataques do tipo DoS (Denial of a service), em que um evento em específico é desabilitado,
comprometendo diretamente a integridade e a disponibilidade dos dados. [2]
A abordagem de segurança em sistemas a eventos discretos destaca a importância da
supervisão eficaz na mitigação de ataques em ambientes industriais. Em resumo, três
aspectos são fundamentais para a segurança nesse contexto: a compreensão dos sistemas
e a localização do ataque, a mensuração do impacto dos dados transmitidos durante o
ataque e as estratégias de defesa empregadas. Esses três pilares representam os elementos
essenciais para garantir a integridade e confiabilidade desses sistemas críticos na maior
parte das situações. [3]
A implementação de um Sistema de Detecção de Invasões (Intrusion Detection System - IDS) que emprega técnicas de controle supervisório, surge como uma resposta
estratégica a esse desafio. Este sistema é projetado para identificar atividades maliciosas
1
2
CAPÍTULO 1. INTRODUÇÃO
ou anômalas em sistemas de controle DES (Discrete Event System) em rede, monitorando continuamente o tráfego de rede, analisando-o em busca de padrões suspeitos ou
comportamentos incomuns que possam indicar uma potencial violação de segurança. [2]
Ao adotar abordagens de controle supervisório, é possível então monitorar continuamente os sistemas industriais em tempo real, detectando padrões incomuns ou comportamentos suspeitos. Essa supervisão constante permite uma resposta rápida e eficaz a
eventos adversos, além de facilitar a implementação de medidas preventivas para evitar
futuros ataques, agindo como uma espécie de sistema de segurança preditiva.
1.1
Motivação e Justificativa
A crescente integração de sistemas de controle industriais (ICS) com tecnologias de comunicação em rede tem trazido um avanço notável em termos de eficiência operacional
e flexibilidade para o setor industrial. Essa evolução permite monitoramento remoto e
integração de dispositivos de diferentes fabricantes, além de habilitar a comunicação bidirecional entre dispositivos de campo e sistemas de controle. No entanto, tal avanço
também implica em novos desafios, particularmente em termos de segurança, uma vez
que a complexidade e a interconectividade desses sistemas os tornam alvos atrativos para
ciberataques, como os de negação de serviço (DoS) e fraudes de dados. Estudos recentes
de Drias et al. (2015) [1] e Alves et al. (2022) [2] destacam a vulnerabilidade dos ICS e
enfatizam a necessidade urgente de proteger essas infraestruturas críticas contra impactos
que possam comprometer a operação industrial e a segurança pública.
Para enfrentar esse cenário, o projeto proposto tem como objetivo central a simulação
de ataques em uma simulação de uma planta industrial para identificar vulnerabilidades
no sistema e estruturar um sistema de detecção de invasões baseado em técnicas de controle supervisório. Esse sistema, fundamentado em princípios de segurança em sistemas
a eventos discretos (DES), propõe-se a monitorar continuamente o tráfego de rede da
planta industrial, identificando padrões suspeitos e comportamentos anômalos, conforme
sugere a abordagem de Rashidinejad et al. (2019) [3]. Enquanto a literatura recente
fornece diretrizes e estudos exploratórios na área de segurança em sistemas industriais, a
inovação deste projeto reside na aplicação prática dessas diretrizes em um cenário simulado, no qual se verifica o impacto e a eficácia de uma abordagem de segurança proativa,
combinando simulações de ataques e controle supervisório como método de detecção.
A contribuição específica deste projeto está em alinhar e adaptar os métodos de controle supervisório já existentes às necessidades de segurança de plantas industriais reais,
além de realizar simulações práticas para antecipar e mitigar ataques potenciais. O
desenvolvimento do sistema de detecção de invasões, especialmente focado em eventos
discretos, foi realizado com base nos estudos de Alves et al. (2022) [2], oferecendo um
1.2. OBJETIVOS DO PROJETO
3
diferencial significativo ao focar na detecção em tempo real e no monitoramento contínuo.
Com isso, este projeto pretende contribuir de forma relevante para a segurança de ICS,
integrando práticas de controle supervisório que possibilitem uma resposta rápida e eficaz
a potenciais ameaças, destacando-se no cenário acadêmico e industrial como uma solução
inovadora e necessária para a segurança cibernética no setor.
1.2
Objetivos do Projeto
O objetivo deste trabalho concentra-se em simular um conjunto pré-definido de ataques
em uma planta industrial, visando identificar vulnerabilidades no sistema. Por meio
da utilização de técnicas de controle supervisório, busca-se estruturar um sistema de
detecção de invasões, com o propósito de atuar como um sistema preditivo de ataques,
com o intuito de mitigar ou antecipar a ação desses ataques na planta, minimizando os
impactos relacionados à essas invasões.
1.3
Local de Realização
O Laboratório de Análise e Controle de Sistemas a Eventos Discretos (LACSED) é um
grupo de pesquisa da Universidade Federal de Minas Gerais (UFMG) que se dedica ao
desenvolvimento e aplicação de teorias de controle de sistemas de eventos discretos em problemas de engenharia. O grupo de pesquisa está registrado no CNPq (Conselho Nacional
de Pesquisa) desde 2012 e é composto por professores associados, alunos de pós-graduação
e alunos de graduação.
1.4
Estrutura da Monografia
O trabalho está dividido em quatro capítulos. Este capítulo apresentou uma introdução
ao projeto a ser descrito nesta monografia e o laboratório onde o trabalho foi realizado.
O Capítulo 2 descreve os princípios básicos de um sistema de controle industrial (ICS)
e abrange todos os conceitos necessários para um melhor entendimento do projeto, incluindo uma revisão sobre segurança cibernética em sistemas de automação e o papel de
sistemas de detecção de intrusões (IDS) em ambientes industriais. O Capítulo 3 aborda
a metodologia de desenvolvimento, seguida pela implementação dos mecanismos de supervisão e controle, detalhando as técnicas de controle supervisório e a simulação dos
ataques no sistema de testes. No Capítulo 4 tem-se a conclusão da monografia, com
algumas sugestões e dificuldades encontradas na realização do projeto, além de propostas
para aprimoramentos futuros e reflexões sobre o impacto e aplicabilidade dos resultados
obtidos.
4
CAPÍTULO 1. INTRODUÇÃO
Capítulo 2
Conceitos Preliminares
Este capítulo tem como objetivo abordar os fundamentos dos Sistemas de Controle Industrial (ICS) e sua arquitetura, com uma definição inicial do ICS e sua evolução na automação industrial, seguida pela análise dos diferentes níveis de operação e comunicação.
Em seguida, discorrem-se sobre os princípios de segurança, destacando vulnerabilidades
e tipos de ataques que podem comprometer esses sistemas. A seção inclui ainda uma revisão da literatura sobre sistemas de detecção de intrusões (IDS) e conceitos de sistemas
a evento discretos, oferecendo uma base teórica sólida para as discussões desenvolvidas
nos capítulos seguintes.
2.1
Os Sistemas de Controle Industrial (ICS)
Um sistema de controle Industrial (Industrial Control System) é composto por um conjunto de ativos e subsistemas interconectados, projetados para realizar três operações
principais: aquisição, controle e supervisão. Esses sistemas são fundamentais para o
monitoramento e controle de processos industriais, pois cada um desses componentes desempenha funções específicas que, quando integradas, permitem a operação eficiente e
segura de instalações industriais complexas. A operação de aquisição se refere à coleta de
dados brutos, como medições de sensores e informações operacionais, que são capturados
diretamente do campo de processo. O controle e a supervisão, por outro lado, incluem
a gestão das variáveis do processo e o monitoramento contínuo, garantindo que todas as
operações estejam alinhadas com as especificações de segurança e eficiência da planta. [1]
Dependendo da aplicação e a arquitetura específica do ICS, os dados coletados passam
por processamento e análise para fornecer uma visão completa do sistema em tempo real.
As informações são apresentadas em painéis de visualização, permitindo que os operadores
acompanhem o status atual dos processos e tomem decisões pertinentes. Dessa forma,
o ICS executa lógicas de controle tanto em dispositivos locais quanto remotos, o que
facilita respostas automatizadas rápidas e garante que os processos se mantenham em
5
6
CAPÍTULO 2. CONCEITOS PRELIMINARES
condições ideais de operação. Essas capacidades possibilitam o controle automatizado
e a supervisão à distância de grandes infraestruturas industriais, com alta precisão e
confiabilidade, melhorando a eficiência e a segurança das operações.
Os componentes de controle em um sistema de controle industrial (ICS) são essenciais
para a automação e supervisão de processos industriais, permitindo a coleta, processamento e atuação em dados operacionais, o que garante o funcionamento eficiente e seguro
dos sistemas. Entre os principais componentes de controle, destacam-se os sensores e atuadores, que desempenham papéis cruciais. Os sensores detectam variáveis físicas, como
temperatura, pressão, fluxo e nível, convertendo essas medições em sinais elétricos ou
digitais que são fundamentais para a aquisição de dados do processo. Já os atuadores são
responsáveis por executar ações baseadas nos comandos do sistema de controle, incluindo
válvulas, motores e bombas. Eles recebem sinais de controle e realizam ajustes nos processos, como abrir ou fechar uma válvula, garantindo que as condições operacionais sejam
mantidas.
Além disso, as redes de comunicação são fundamentais para a troca de dados entre
os diferentes componentes do ICS. Protocolos de comunicação, como Modbus, Profibus e
OPC UA, garantem que sensores, controladores e sistemas de supervisão se comuniquem
de forma eficaz. A infraestrutura de rede, que inclui cabeamento, switches e roteadores,
conecta todos os componentes do sistema, assegurando que a informação flua rapidamente
e de maneira confiável. Por fim, sistemas de armazenamento e análise de dados, como
bancos de dados e ferramentas de análise, são utilizados para armazenar dados históricos e
identificar tendências, anomalias e oportunidades de melhoria. A integração eficaz desses
componentes é crucial para otimizar a eficiência operacional e garantir a segurança em
ambientes industriais. [1]
2.2
Arquitetura dos Sistemas de Controle
A arquitetura de um Sistema de Controle Industrial é projetada com o objetivo de monitorar, controlar e supervisionar processos industriais, garantindo que as operações sejam
realizadas de forma segura e eficiente em setores estratégicos, como manufatura, energia
e infraestrutura crítica. Ela é constituída por uma série de dispositivos, redes e protocolos especializados, permitindo o controle preciso dos processos físicos e a integração com
sistemas corporativos.
Um ICS típico é composto de diversos componentes que trabalham em conjunto. Um
dos principais elementos é o Controlador, responsável por executar tarefas em tempo real.
Esse dispositivo realiza o controle direto de sensores e atuadores no ambiente industrial,
recebendo sinais, processando informações e enviando comandos para os atuadores, de
modo a controlar operações essenciais de forma autônoma e precisa. Outro componente
2.3. PRINCÍPIOS DE SEGURANÇA EM ICS
7
essencial é o Sistema de Controle de Supervisão e Aquisição de Dados (SCADA). Esse
sistema é responsável por monitorar e coletar dados da planta industrial, permitindo a
visualização em tempo real dos processos. O SCADA conecta-se ao controlador através de
redes industriais, capturando informações que são disponibilizadas aos operadores para
que possam supervisionar e gerenciar remotamente os processos. [1]
A rede é essencial para a comunicação entre sensores, atuadores e dispositivos de
controle em ambientes industriais. Ela utiliza protocolos industriais especializados, projetados para garantir a interoperabilidade entre dispositivos e a resiliência da comunicação
em condições desafiadoras. Para proteger a comunicação entre as operações industriais e
os sistemas corporativos, a arquitetura de um ICS inclui uma zona de demarcação (DMZ
- Demilitarized Zone), que age como uma barreira de segurança entre a rede de controle
e as demais redes da indústria. Essa camada é composta por firewalls, sistemas de detecção de intrusões (IDS) e gateways de segurança, permitindo uma troca segura de dados
entre os ambientes industrial e corporativo, limitando o acesso de agentes externos não
autorizados. [4]
Em suma, a arquitetura de um ICS é frequentemente segmentada em três principais
camadas: a camada de campo, a camada de controle e a camada corporativa. A camada
de campo abrange os dispositivos de nível operacional, incluindo sensores, atuadores e
controladores. A camada de controle, posicionada na região intermediária da arquitetura,
é responsável por conectar as operações de campo com os sistemas de monitoramento e supervisão. A camada corporativa representa a camada superior da arquitetura, englobando
as redes e sistemas que integram dados das operações industriais com a infraestrutura
corporativa. Esse nível permite análises em tempo real e embasa decisões estratégicas,
pois conecta-se à camada de controle para receber dados operacionais. Essa segmentação
em camadas, apesar de essencial para a organização e operação do ICS, requer a adoção
de estratégias de segurança rigorosas para proteger cada domínio de acordo com seu nível
de criticidade e exposição a potenciais ameaças. [1]
2.3
Princípios de Segurança em ICS
A segurança em Sistemas de Controle Industrial (ICS) é fundamentada em princípios
que buscam proteger a integridade, confidencialidade e disponibilidade dos sistemas operacionais críticos. Os dispositivos na camada de campo, como sensores e Controladores
Lógicos Programáveis (PLCs), são frequentemente vulneráveis a ataques devido à falta de
criptografia e autenticação. As comunicações entre essa camada e a camada de controle
são especialmente visadas por agentes mal-intencionados, que podem realizar ataques de
interceptação e injeção de dados. Assim, um dos princípios fundamentais de segurança
é garantir que os protocolos de comunicação utilizados nesta camada sejam adaptados
8
CAPÍTULO 2. CONCEITOS PRELIMINARES
para incluir mecanismos de segurança que protejam a integridade dos dados trocados,
impedindo que informações críticas sejam manipuladas ou acessadas indevidamente. [4]
A camada de controle, que conecta as operações de campo aos sistemas de supervisão, enfrenta riscos similares. Os protocolos de comunicação, embora eficazes para as
operações industriais, muitas vezes não foram concebidos com a segurança em mente,
tornando-se alvos fáceis para ataques. Portanto, é crucial adotar práticas que incluam
a implementação de firewalls e sistemas de detecção de intrusões (IDS) para monitorar
o tráfego e detectar atividades anômalas, além de estabelecer zonas de segurança que
limitem o acesso entre a camada de controle e outras áreas do ICS.
Por fim, a integração entre a camada corporativa e o ICS apresenta um cenário propício
para a exploração de vulnerabilidades. Essa conexão expõe o sistema a riscos cibernéticos,
como ataques de negação de serviço (DoS) e malware, que podem infiltrar-se na rede
corporativa e afetar os sistemas de controle. Portanto, um princípio de segurança crucial
é a segmentação de rede, que deve ser implementada para isolar a camada de controle
de acessos externos. O uso de controles de acesso rigorosos, além de autenticação multifatorial, pode contribuir significativamente para limitar a exposição do ICS a ameaças
externas. [1]
Segundo Macaulay e Singer (2011) [5], sistemas de controle industrial devem ser projetados desde o início com segurança em mente, incorporando práticas de segurança
cibernética durante todo o ciclo de vida do sistema. Isso inclui a seleção de hardware e
software que suportem robustez contra ataques, além da implementação de padrões de
codificação que minimizem vulnerabilidades. A segurança não deve ser uma reflexão tardia, mas sim uma consideração integral no desenvolvimento e na operação dos sistemas.
Adicionalmente, a monitorização contínua dos sistemas de controle é um princípio que
merece destaque. Os autores apontam que a implementação de ferramentas de monitoramento em tempo real é crucial para a detecção precoce de atividades suspeitas ou
anômalas. A capacidade de responder rapidamente a incidentes de segurança pode reduzir significativamente o impacto de um ataque, além de facilitar a análise forense após
um evento de segurança.
2.4
Alfabetos, Palavras e Linguagens
Um símbolo σ é uma entidade gráfica abstrata que pode representar números, letras e
outros elementos. Um alfabeto Σ é um conjunto finito de símbolos. Uma palavra s,
ou cadeia, é uma sequência finita de símbolos pertencentes a um alfabeto Σ. A palavra
vazia ε é a única palavra que não contém nenhum símbolo. O comprimento ou tamanho
de uma cadeia é o número de símbolos que ela contém, incluindo múltiplas ocorrências
do mesmo símbolo. O fechamento de Kleene, denotado por Σ∗ , é o conjunto de todas
9
2.5. AUTÔMATOS FINITOS DETERMINÍSTICOS
as palavras de comprimento finito formadas pelos elementos do alfabeto Σ, incluindo a
palavra vazia. [6]
Uma linguagem L é definida por um conjunto finito de eventos Σ. Um exemplo é
Σ = {a, b, g}. É possível definir a linguagem
L1 = {ε, a, abb}
(2.1)
que consiste em três palavras. Entretanto, outras linguagens podem ocorrer de diversas combinações.
Em relação à terminologia de strings. Se tuv = s com t, u, v ⊆ E ∗ , então:
• t é um prefixo de s;
• u é uma substring de s
• v é um sufixo de s
As operações básicas de conjuntos são união, intersecção, diferença e complementação,
todas elas são aplicáveis em linguagens, visto que elas são conjuntos. Além delas, há:
1. Concatenação: Seja La , Lb ⊆ Σ∗ , então a concatenação de La e Lb é La Lb .
2. Prefixo-fechamento: Seja L ⊆ Σ∗ , dessa forma, se uma linguagem L tem todos os
prefixos de L, ela é considerada prefixo-fechamento.
3. Projeção natural: Uma operação definida sobre dois alfabetos Σ e Σi , onde Σi ⊆ Σ.
Ela mapeia cadeias em Σ∗ em cadeias em Σ∗i , apagando as ocorrências em símbolos
em Σ \ Σi .
2.5
Autômatos Finitos Determinísticos
Uma linguagem regular pode ser representada por um autômato finito, que pode ser
determinístico ou não determinístico. Um Autômato Finito Determinístico (AFD) é um
grafo onde os nós são chamados de estados e os arcos de transições. Formalmente, ele é
denotado por G e pode ser definido pela quíntupla G = (Q, Σ, δ, q0 , Qm ) onde:
• Q representa um conjunto infinito e não vazio de estados;
• Σ representa o alfabeto;
• δ : Q × Σ → Q representa a função de transição de estados;
• q0 representa o estado inicial do autômato G, sendo que q0 ∈ Q;
10
CAPÍTULO 2. CONCEITOS PRELIMINARES
• Qm representa o conjunto de estados finais ou marcados, sendo que Qm ⊆ Q.
Um autômato é dito determinístico quando de qualquer estado existe uma transição de
saída relacionada a um evento. Se múltiplas transições são permitidas no mesmo evento,
o autômato é denominado como não determinístico. Um autômato pode ser representado
graficamente, como mostrado na Figura 2.1, utilizando um diagrama de transição de
estados. Cada estado é representado por um círculo, enquanto um estado marcado é
representado por um círculo duplo. Cada seta que conecta dois círculos representa uma
transição. As arestas rotuladas representam as transições entre os estados que disparam
os eventos de fato. O estado inicial é representado por uma seta que não se inicia em
nenhum estado, apontando para si.
Figura 2.1: Exemplo de autômato representado por um diagrama de transição de estado.
Um autômato G implementa dois tipos de linguagens: Linguagem Gerada (L(G)) e
Linguagem Marcada (Lm (G)).
A Linguagem Gerada por G = (X, E, f, Γ, x0 , Xm ) é definida como:
L(G) := {s ∈ E ∗ : f (x0 , s) está definido}
(2.2)
Já a Linguagem Marcada por G é
Lm (G) := {s ∈ L(G) : f (x0 , s) ∈ Xm }
(2.3)
A linguagem L(G) compreende todos os caminhos possíveis no diagrama de transição
de estados, iniciando-se a partir do estado inicial. Uma sequência pertence a L(G) se ela
corresponder a um caminho válido no diagrama de estados. L(G) é fechada em relação a
prefixos e contém todos os eventos ativos. Em contrapartida, Lm (G) é um subconjunto
de L(G), composto apenas pelos caminhos que terminam em um estado marcado. Nem
todos os estados precisam ser marcados, logo, Lm (G) não é necessariamente fechado por
prefixos. Frequentemente, Lm (G) é chamado de linguagem reconhecida pelo autômato.
[6]
Dois conceitos fundamentais devem ser destacados: os conceitos de acessibilidade e
coacessibilidade de um autômato.
2.6. TEORIA DE CONTROLE SUPERVISÓRIO
11
A acessibilidade de estados em um autômato refere-se à possibilidade de alcançar
todos os estados partindo do estado inicial. Quando aplicamos a operação de “remoção”
de estados inacessíveis, eliminamos todos os estados que não podem ser atingidos a partir
do estado inicial. Essa operação não altera a linguagem gerada pelo autômato, uma vez
que não existe um caminho que leve aos estados removidos a partir do estado inicial.
Por outro lado, a coacessibilidade de estados relaciona-se à capacidade de alcançar um
estado marcado a partir de outros estados. A operação de “remoção” de estados incoacessíveis preserva apenas os estados que podem alcançar um estado marcado. Embora essa
operação modifique a linguagem gerada pelo autômato, a linguagem marcada permanece
inalterada. Em resumo, os estados que não conseguem alcançar um estado marcado são
removidos, mas a linguagem reconhecida pelo autômato continua a mesma.
2.6
Teoria de Controle Supervisório
A Teoria de Controle Supervisório (TCS) [7] se apresenta como uma ferramenta essencial para gerenciar o comportamento de sistemas discretos, assegurando uma operação
segura, eficiente e alinhada a especificações pré-estabelecidas. Por meio de uma abordagem estruturada, a TCS fornece métodos formais para projetar controladores que sejam
robustos e confiáveis. Nesse contexto, o sistema a ser controlado é modelado como um
conjunto de autômatos finitos, onde cada autômato, chamado de planta, representa todos
os comportamentos possíveis, inclusive os indesejados para aquele subsistema. Já a especificação determina os comportamentos permitidos e restritos para a planta, garantindo
que ela funcione conforme o esperado.
O supervisor é um outro autômato finito que observa a planta e decide quais eventos
podem ocorrer ou devem ser bloqueados. Sua função principal é assegurar que a planta
opere dentro dos limites das especificações, evitando comportamentos indesejados e promovendo a segurança do sistema. Quando consideramos um supervisor, indicado por S,
que interage com um autômato G por meio de uma configuração de feedback, podemos
dividir o conjunto de eventos E em dois subconjuntos: Ec , o conjunto de eventos controláveis, que podem ser bloqueados pelo supervisor S, e Euc , o conjunto de eventos não
controláveis, que o supervisor não pode impedir de ocorrer.
Em geral, eventos não controláveis são associados a alterações nas leituras dos sensores, enquanto eventos controláveis estão ligados a ações de controle, como o acionamento
de um atuador.
Em um autômato finito determinístico (AFD) G, onde Euc ⊆ E, se K ⊆ L(G) e
K = ∅, existe um supervisor S que permite a G gerar apenas sequências em K se, e
somente se,
12
CAPÍTULO 2. CONCEITOS PRELIMINARES
KEuc ∩ L(G) ⊆ K
Essa condição em K é conhecida como condição de controlabilidade. Além disso, se
K e M são linguagens sobre o conjunto de eventos E, e Euc é um subconjunto específico
de E, então diz-se que K é controlável em relação a M e Euc se
K ∩ (M ∩ Euc ) ⊆ K
Por definição, a controlabilidade é uma característica do fecho de prefixos de uma
linguagem. Portanto, K é controlável se, e somente se, K for controlável. Em outras
palavras, um conjunto de eventos é considerado controlável se o supervisor puder agir
para impedir a ocorrência de determinados eventos indesejáveis, enquanto permite que
eventos desejáveis ocorram.
Em relação ao não bloqueio, existe um supervisor não bloqueante Snb para G tal que
Lm (Snb /G) = K
e L(Snb /G) = K
se, e somente se, a condição de controlabilidade e o fechamento da linguagem marcada
gerada por G forem atendidos, ou seja, o conjunto de todas as sequências possíveis que
podem ser formadas ao adicionar eventos extras às já presentes em Lm (G).
Um supervisor não bloqueante assegura que a planta atinja os estados desejados sem
impedir desnecessariamente a ocorrência de eventos que estejam de acordo com as especificações. Em essência, o não bloqueio garante que o sistema possa realizar todas as
operações necessárias para atender aos requisitos, ao mesmo tempo evitando bloqueios
desnecessários que poderiam prejudicar seu desempenho ou funcionalidade. [6]
2.7
Revisão de metodologias
No artigo "A Security Testbed for Networked DES Control Systems", Alves, Rudie e Pena
(2022) [2] propõem uma metodologia para construir um testbed de segurança voltado à
análise de sistemas de controle de Eventos Discretos (DES) em redes industriais. A
motivação central do estudo é a crescente complexidade dos sistemas DES interconectados
e a vulnerabilidade que eles apresentam a ataques cibernéticos. Com a digitalização
de processos industriais, os sistemas de controle de DES em rede se tornaram alvos
potenciais de invasões, ameaçando a segurança e a operação eficiente das infraestruturas
críticas. Os autores identificam a necessidade de um ambiente experimental onde esses
sistemas possam ser testados e analisados sob condições controladas, avaliando como
ataques cibernéticos podem impactar seu desempenho e segurança.
A metodologia descrita no artigo envolve a criação de um ambiente que combina si-
2.8. METODOLOGIA PROPOSTA
13
mulação e hardware real para emular um sistema de controle de DES. Esse ambiente
permite que pesquisadores e profissionais possam investigar não apenas as vulnerabilidades técnicas, mas também as consequências de falhas operacionais e de segurança no
contexto industrial. O testbed inclui uma arquitetura que replica a rede e a infraestrutura
de controle de uma planta industrial, onde componentes essenciais, como controladores
lógicos programáveis (PLCs) e sensores, estão conectados e comunicam entre si, simulado
de maneira fiel a um ambiente de operação real. Este método oferece uma visão prática
das interações entre os elementos de controle, possibilitando a identificação de pontos
críticos que podem ser explorados por invasores.
Além da arquitetura de hardware, também é implementado um conjunto de ferramentas de software para simular ataques e monitorar a resposta do sistema. Entre as
técnicas exploradas, incluem-se ataques de negação de serviço (DoS), interceptação e falsificação de dados, que foram aplicados para verificar a resiliência do sistema de controle
sob diferentes condições de ameaça. A metodologia inclui a coleta de dados durante as
simulações para analisar como o sistema reage e para observar padrões que possam indicar a presença de intrusões. Essa abordagem de coleta e análise de dados contribui para
a construção de uma base de dados que pode ser utilizada para o desenvolvimento de
algoritmos de detecção de intrusões mais eficazes.
Os resultados da pesquisa sugerem que a metodologia proposta é eficaz na identificação de vulnerabilidades em sistemas de controle de DES interconectados. Com o testbed
foi possível demonstrar que é possível replicar cenários de ataque em um ambiente controlado, permitindo que as falhas de segurança sejam identificadas e abordadas de maneira
proativa. Ao final, Alves, Rudie e Pena [2] destacam a importância desse tipo de abordagem para o fortalecimento da segurança em infraestruturas industriais e sugerem que
testbeds semelhantes poderiam ser aplicados em outros setores, reforçando a necessidade
de desenvolver ambientes de simulação robustos para uma segurança cibernética avançada
em sistemas críticos.
2.8
Metodologia proposta
Neste trabalho, buscou-se simular o mesmo processo industrial descrito por Alves, Rudie
e Pena [2], realizando a implementação das plantas e do controlador. Também foram
implementados cinco tipos de ataques, descritos no capítulo 3, controlados por um autômato que simula o comportamento do atacante. Além disso, também foi implementado
um IDS que tenta identificar a ocorrência de um ataque, além de tratar preditivamente
sua mitigação no sistema de modo que ele não ocorra.
14
CAPÍTULO 2. CONCEITOS PRELIMINARES
Capítulo 3
Descrição do Processo de Simualação
Neste capítulo, será apresentada uma visão detalhada da estrutura e funcionamento do
sistema simulado, destacando a configuração da Arquitetura de Rede Adotada e as soluções de conectividade integradas para suportar o tráfego de dados em tempo real. Em
seguida, na seção de "Entrega de Eventos", serão discutidos os métodos implementados
para garantir a comunicação precisa e rápida dos eventos entre os diferentes componentes
do sistema. A subseção "O Controlador"explorará o papel do controlador na execução
e automação das tarefas de controle, bem como sua interação com sensores e atuadores na simulação. Por fim, a seção Processamento de Ataques abordará as estratégias e
algoritmos aplicados para a implementação dos ataques no sistema.
3.1
Descrição do sistema
O sistema é implementado com base em uma arquitetura cliente-servidor, utilizando a
tecnologia OPC UA (Open Platform Communications - Unified Architecture), que é um
padrão de comunicação amplamente adotado em automação industrial para permitir a
troca de dados entre dispositivos, sistemas e softwares. A interface do sistema, mostrada
na Figura 3.1, representa o tanque que integra seis subsistemas distintos, os quais operam
conjuntamente no processo de produção de um produto.
Os subsistemas presentes na planta são:
• Válvula de entrada: Controla a abertura e o fechamento das válvulas responsáveis
pelo fluxo de três tipos de líquidos no sistema.
• Transmissor de nível: Monitora o nível do tanque.
• Dispositivo de Controle de Temperatura: Gerencia o aquecimento e o resfriamento do tanque.
• Mixer: Responsável por misturar os líquidos no tanque, assegurando uma homogenização durante o processo de aquecimento.
15
16
CAPÍTULO 3. DESCRIÇÃO DO PROCESSO DE SIMUALAÇÃO
• Bomba: Bombeia o líquido do tanque principal para um trocador de calor.
• Válvula de Saída: Controla a abertura e o fechamento da válvula responsável
pelo esvaziamento do tanque.
Figura 3.1: Interface gráfica do sistema
O processo de produção segue a sequência descrita a seguir: inicialmente, a válvula
de entrada é aberta, permitindo que os fluidos entrem no tanque. O sistema monitora o
nível de fluido, aguardando a ocorrência do evento de nível alto, que indica que o tanque
está cheio. Ao detectar o nível alto, a válvula de entrada é fechada, interrompendo o
fluxo de entrada.
Na etapa seguinte, o sistema de controle de temperatura é ativado para aquecer o fluido
no tanque. Ao mesmo tempo, o misturador é acionado para garantir que o aquecimento
ocorra de forma homogênea. O misturador permanece ativo até que o evento do tanque
aquecido seja disparado, indicando que a temperatura desejada foi atingida. Após o
aquecimento, o processo de resfriamento começa. A bomba é ativada para auxiliar na
redução da temperatura do fluido. O sistema continua o resfriamento até que o evento
do tanque resfriado tenha sido disparado, sinalizando que o fluido atingiu a temperatura
requerida. Por fim, a válvula de saída é aberta para liberar o produto do tanque. O
sistema aguarda o evento de nível baixo, que indica que o tanque foi esvaziado até o nível
desejado. Assim que o tanque é esvaziado, a válvula de saída é fechada, encerrando o
processo.
O objetivo desta simulação é representar um conjunto de ataques predefinidos na
planta, com o intuito de identificar vulnerabilidades no sistema. Utilizando técnicas de
controle supervisório, busca-se estruturar um sistema de detecção de invasões que possa
atuar de forma preditiva, antecipando e mitigando possíveis ataques, minimizando assim
os impactos dessas invasões na operação da planta.
3.2. ARQUITETURA DE REDE ADOTADA
3.2
17
Arquitetura de rede adotada
O sistema é implementado com base em uma arquitetura cliente-servidor, utilizando a
tecnologia OPC como representado na figura 3.2 abaixo:
Figura 3.2: Arquitetura da rede do sistema.
O controlador da planta é representado como um servidor e cada um dos seis subsistemas um cliente. Nessa implementação, cada subsistema (cliente) consegue receber alguma
informação do controlador (servidor) a respeito do disparo de algum evento controlável
do sistema, além de que cada subsistema também pode disparar algum evento não controlável do sistema dado o seu contexto. Com relação aos eventos que trafegam na rede,
eles foram estruturados como TAGs do servidor OPC e o disparo de cada evento resulta
em um comportamento no sistema. Ao todo são trinta e quatro TAGs implementadas no
sistema, como mostrado na tabela 3.1 abaixo:
TAG
Descrição de Funcionamento
Start_Process
Inicia o processo de produção.
Finish_Process
Finaliza o processo de produção.
Level_High
Indica que o nível do tanque atingiu o valor máximo.
Level_Low
Indica que o nível do tanque atingiu o valor mínimo.
Open_Input_Valve
Abre a válvula de entrada para permitir o fluxo de líquido no tanque.
Close_Input_Valve
Fecha a válvula de entrada para interromper o fluxo de
líquido no tanque.
Open_Output_Valve
Abre a válvula de saída para liberar o líquido do tanque.
Close_Output_Valve
Fecha a válvula de saída para interromper a liberação
do líquido do tanque.
Heated
Indica que o fluido no tanque atingiu a temperatura desejada de aquecimento.
18
CAPÍTULO 3. DESCRIÇÃO DO PROCESSO DE SIMUALAÇÃO
Cooled
Indica que o fluido no tanque atingiu a temperatura desejada de resfriamento.
Control_Temperature_On
Ativa o controle de temperatura para aquecer ou resfriar
o fluido.
Control_Temperature_Off
Desativa o controle de temperatura.
Mixer_On
Liga o misturador para homogeneizar o fluido no tanque.
Mixer_Off
Desliga o misturador.
Pump_On
Liga a bomba para acelerar o resfriamento do fluido no
tanque.
Pump_Off
Desliga a bomba.
Reset
Retorna para o estado inicial do autômato.
Level
Monitora o nível atual do fluido no tanque.
Temperature
Monitora a temperatura atual do fluido no tanque.
Volume
Monitora o volume de fluido no tanque.
Heating_Time
Tempo necessário para o aquecimento do fluido.
Cooling_Time
Tempo necessário para o resfriamento do fluido.
Initial_Temperature
Temperatura inicial do fluido no tanque.
Heating_Temperature
Temperatura alvo para o aquecimento do fluido.
Cooling_Temperature
Temperatura alvo para o resfriamento do fluido.
Attack_Type
Define o tipo de ataque simulado no sistema.
Attack_Event
Evento específico associado ao ataque simulado.
Processed_Events
Lista de eventos já processados pelo sistema.
Unprocessed_Events
Lista de eventos que ainda não foram processados.
Stop_Process
Interrompe o processo de produção, pausando temporariamente.
Reset_Process
Reseta o processo de produção para o estado inicial.
Under_Attack
Indica se o sistema está sob ataque.
Release_Attack
Finaliza o estado de ataque no sistema.
Operation_Mode
Define o modo de operação atual do sistema.
Tabela 3.1: Descrição das TAGs e seu funcionamento.
3.3
Entrega de eventos
Na teoria de controle supervisório, um evento é considerado uma transição discreta que
em alguns casos causa uma mudança de estado dentro de um sistema de eventos discretos
(DES - Discrete Event System). Esse sistema é estruturado para monitorar e gerenciar
3.3. ENTREGA DE EVENTOS
19
operações em tempo real, onde cada evento representa uma ação específica ou uma alteração em uma variável controlada pelo sistema. Os eventos são fundamentais para
capturar as dinâmicas do sistema e incluem ativações de sensores, mudanças de estado
em atuadores e comandos de controle.
Nessa implementação, contudo, a propagação de informações sobre a operação do
sistema é realizada através das TAGs alocadas no servidor. Nesse contexto, a definição
de um evento está ligada à transição do valor de uma TAG, passando de seu valor atual
para um valor específico no futuro, causada por alguma mudança na operação do sistema.
Assim, cada estado de um determinado autômato implementado no sistema corresponde
a um dos valores assumidos pela TAG em questão.
Considere como exemplo o autômato abaixo representado na figura 3.3 responsável
pela operação da válvula de entrada. O estado inicial (C) corresponde ao valor False
assumido pela TAG Open_Input_Valve já que a válvula encontra-se fechada, assim como
o estado final (O) corresponde ao valor True já que nessa momento a válvula encontra-se
aberta.
Figura 3.3: Autômato da válvula de entrada.
Os eventos no sistema são então representados por cada uma das transições de valor
sofrida pelas TAGs do servidor, que podem ser escritas tanto pelo servidor quanto pelos clientes que fazem parte da planta industrial simulada. Cada subsistema, operando
como um cliente OPC, e o controlador, que atua como servidor OPC, funcionam em threads independentes que operam em paralelo. Essas threads monitoram continuamente os
eventos disparados de acordo com o contexto e relação com os subsistemas, e, a partir do
momento em que um evento é recebido na rede, ele é também disparado nos autômatos
associados.
Por exemplo, a thread responsável pela válvula de entrada monitora continuamente a
TAG Open_Input_Valve no cliente OPC. Assim que essa TAG sofre uma alteração no
seu valor, indicando que a válvula de entrada deve ser aberta, o autômato associado à
válvula de entrada é acionado para disparar o evento correspondente. O mesmo ocorre
quando o evento de nível alto e o evento de fechamento da válvula são processados.
Esse comportamento genérico se aplica a todos os subsistemas, como a bomba, o
mixer e o controle de temperatura, com cada subsistema operando de forma semelhante:
20
CAPÍTULO 3. DESCRIÇÃO DO PROCESSO DE SIMUALAÇÃO
monitorando as TAGs OPC e disparando os eventos nos seus autômatos conforme o
estado do processo. Em alguns casos, o evento pode ser atuado em um subsistema, e
não no controlador, como ocorre na grande maioria dos eventos da rede. Esses casos se
referem aos eventos não controláveis do sistema, acionados pelos sensores da planta. São
eles:
• Level_High;
• Level_Low;
• Heated;
• Cooled.
Para a geração desses eventos, dado o contexto dos mesmos estarem diretamente
ligados a operação do tanque, foi desenvolvida uma classe com quatro threads que emulam
o comportamento desses processos, assim, além de gerarem esses eventos não controláveis,
também são atualizados os valores do nível e da temperatura do tanque, sendo o tanque
mais um subsistema acoplado na rede dedicado ao disparo dos eventos relacionados à
atuação dos sensores.
Dessa forma, a entrega e o tráfego das informações relacionadas às TAGs funcionam
como mostrado na tabela 3.2 abaixo, onde são listados os eventos que são enviados ou
recebidos pelo cliente e o servidor.
TAG
Cliente
Servidor
Start_Process
Recebido
Enviado
Finish_Process
Recebido
Enviado
Level_High
Enviado
Recebido
Level_Low
Enviado
Recebido
Open_Input_Valve
Recebido
Enviado
Close_Input_Valve
Recebido
Enviado
Open_Output_Valve
Recebido
Enviado
Close_Output_Valve
Recebido
Enviado
Heated
Enviado
Recebido
Cooled
Enviado
Recebido
Control_Temperature_On Recebido
Enviado
Control_Temperature_Off Recebido
Enviado
Mixer_On
Recebido
Enviado
Mixer_Off
Recebido
Enviado
Pump_On
Recebido
Enviado
21
3.4. O CONTROLADOR
TAG
Cliente
Servidor
Pump_Off
Recebido
Enviado
Tabela 3.2: Descrição dos eventos do sistema e interações
Cliente-Servidor
3.4
O controlador
O controlador é uma outra parte do sistema que opera em paralelo, sofrendo diretamente
com os efeitos dos ataques nos subsistemas, desempenhando um papel central no gerenciamento da operação como um todo. Ele atua em conjunto com supervisores e autômatos,
garantindo o controle adequado dos subsistemas para o seguimento correto do processo.
O controlador atua portanto como um componente central no sistema, orquestrando
as interações entre diferentes instâncias: servidor OPC, supervisores e autômatos. Essa
estrutura reflete os princípios da Programação Orientada a Objetos (POO), especialmente
os conceitos de encapsulamento e abstração. O Controlador encapsula a lógica de controle,
fornecendo uma interface para gerenciar a comunicação entre os supervisores e autômatos,
que representam as entidades responsáveis pela supervisão e execução das operações.
De uma forma abstrata, a implementação do controlador e sua relação com o servidor,
supervisores e autômatos pode ser vista na figura 3.4 abaixo:
Figura 3.4: Diagrama de classes representando os componentes e as dependências do
controlador.
O ciclo de operação do controlador começa, portanto, com a inicialização dos supervisores, responsáveis por monitorar e gerenciar o comportamento dos subsistemas. Esses
supervisores são integrados ao sistema de controle de eventos discretos (DES), o que
permite que eles se alinhem à lógica de operação do processo a medida que garantem o
processamento correto dos eventos de modo a obter um produto final seguindo todas as
especificações de qualidade necessárias.
22
CAPÍTULO 3. DESCRIÇÃO DO PROCESSO DE SIMUALAÇÃO
Em seguida, o controlador inicializa os autômatos de cada subsistema, onde cada
autômato define os estados e as transições possíveis para o subsistema correspondente,
assegurando que ele opere conforme as condições e regras estabelecidas. Esses autômatos
são fundamentais para a lógica de controle do sistema, pois representam o comportamento desejado e reagem aos eventos relevantes para cada subsistema. Cada autômato
possui uma instância duplicada: uma no servidor (controlador) e outra em cada cliente
(subsistema). Essa abordagem permite uma sincronização contínua entre o servidor e
os clientes, garantindo que todas as instâncias do autômato reflitam o estado atual de
operação.
No lado dos clientes (subsistemas), a atualização dos autômatos é feita de forma
periódica, no ritmo do tempo de execução de cada thread, assegurando que as mudanças
sejam aplicadas de maneira consistente e regular. Isso permite que os subsistemas reajam
de forma independente, mesmo quando não há novos eventos provenientes do controlador,
mantendo-os em conformidade com o último estado conhecido.
Por outro lado, no controlador, a atualização dos autômatos é disparada imediatamente quando um evento específico ocorre na rede. Sempre que um evento é detectado, o
controlador avalia e atualiza os estados dos autômatos e dos supervisores, propagando as
mudanças para os subsistemas conforme necessário. Essa atualização baseada em eventos
permite uma resposta ágil e sincronizada, especialmente para mudanças críticas de estado
que precisam ser refletidas de imediato em todo o sistema. Dessa forma, a coexistência
de instâncias dos autômatos no servidor e nos clientes, junto com a atualização periódica
nos subsistemas e a atualização por evento no controlador, assegura que todos os subsistemas permaneçam alinhados e prontos para reagir às novas condições, promovendo uma
operação coordenada e robusta.
Durante o processamento dos eventos, enquanto ainda existem eventos na fila de eventos não processados, o controlador verifica em um loop se um evento já foi processado.
Caso não tenha sido, ele identifica em um outro loop quais autômatos podem processá-lo,
analisando ainda se não existe nenhum supervisor que esteja desabilitando o evento naquele momento. Se o evento não puder ser executado por nenhum autômato, ou ele seja
disabilitado por algum supervisor, ele é adicionado à lista de eventos não processados garantindo prioridade na próxima execução do processamento de eventos frente aos demais.
Simultaneamente, o sistema monitora se há ataques em andamento e, caso detectados,
aciona o atacante, interferindo na sequência normal dos eventos processando o ataque.
De uma forma simplificada, o funcionamento do controlador pode ser entendido por meio
do diagrama de sequência mostrado na figura 3.5.
Com relação aos eventos não controláveis, eles são ativados posteriormente de uma
forma sequencial, sendo atualizados após o processamento dos eventos controláveis em
cada loop de interação. Esses eventos não são diretamente controlados pelo sistema prin-
3.4. O CONTROLADOR
23
Figura 3.5: Diagrama de sequência representando o processamento dos eventos pelo controlador.
cipal, mas são verificados periodicamente pelo controlador, que consulta o estado de cada
evento não controlável. Para avaliar a factibilidade dos eventos não controláveis, primeiramente verifica-se se esses eventos são viáveis nos supervisores (não desabilitados). Se
forem, eles também serão considerados viáveis nos autômatos das plantas, conforme estabelecido na construção do sistema. Assim, se o evento for viável, os autômatos associados
devem ser atualizados. Quando um evento não controlável está ativo, cada supervisor
analisa sua viabilidade no contexto atual. Caso seja considerado viável, o supervisor
correspondente aciona o evento, integrando-o ao funcionamento geral do sistema.
Esse processo permite que os eventos não controláveis sejam tratados em paralelo
com os eventos controláveis, garantindo uma gestão eficiente e contínua de ambos os
tipos de eventos. A integração desses eventos à operação do sistema é feita de maneira
fluida, permitindo que o sistema mantenha seu comportamento previsto mesmo diante
de condições inesperadas. Na Figura 3.6 o diagrama de sequência ilustra o fluxo de
processamento dos eventos não controláveis mais detalhadamente.
O controlador continua a monitorar e processar eventos enquanto o processo estiver
em execução, ele também gerencia interrupções no processo, assegurando uma retomada
adequada quando o sistema é reiniciado. Dependendo do modo de operação, seja manual
ou automático, o controlador ajusta o processamento de eventos conforme as interações
do operador ou a lógica automática. De forma geral, o controlador atua como o núcleo do
sistema. Ele monitora e aciona eventos, utilizando supervisores e autômatos para manter
o controle dos subsistemas e o fluxo correto das etapas de produção.
24
CAPÍTULO 3. DESCRIÇÃO DO PROCESSO DE SIMUALAÇÃO
Figura 3.6: Diagrama de sequência representando o processamento dos eventos não controláveis.
3.5
Processamento de ataques
O sistema implementa um mecanismo de ataque simulado, onde diferentes tipos de ataques são manipulados pela entidade atacante. Cada tipo de ataque, como negar eventos,
interceptar eventos ou inserir eventos furtivamente, é implementado como um método
específico que realiza as operações de manipulação dos eventos diretamente no servidor
OPC. Esses métodos são organizados em um conjunto de "handlers"de ataque, cada um
dedicado a um tipo particular de ataque, garantindo que as ações sejam direcionadas de
forma precisa.
O atacante age como um manipulador central (handler) e recebe o servidor OPC
como parâmetro em sua inicialização, permitindo-lhe acesso direto para manipular os
eventos e variáveis controladas. O processo começa quando o atacante consulta o tipo de
ataque configurado no servidor, acessando a variável Attack_Type. Esse tipo de ataque
é essencial para definir a ação que será realizada e permite que o sistema adapte-se
dinamicamente a diferentes estratégias de ataque.
Após obter o tipo de ataque, o atacante utiliza um mapeamento interno que associa
cada valor de tipo de ataque a uma função específica de manipulação. Esse mapeamento funciona como um tradutor, onde cada número de Attack_Type corresponde a
um método distinto de ataque:
• deny_event (0): Implementa um ataque que nega a ocorrência de um evento
específico, bloqueando seu processamento.
• host_and_watch (1): Implementa um ataque que apenas observa os eventos que
estão sendo disparados mas não interfere em nada de fato.
• insert_event (2): Insere um novo evento diretamente no sistema, permitindo que
o atacante interfira de forma ativa nos eventos processados.
3.5. PROCESSAMENTO DE ATAQUES
25
• intercept_event (3): Intercepta e modifica um evento antes de seu processamento, ou seja a adição desse evento na fila de eventos processados, fazendo com
que um evento não processado seja adicionado na lista de eventos processados.
• stealth_insert (4): Realiza uma inserção furtiva de um evento, de modo que
somente o controlador consiga vê-lo.
Caso o tipo de ataque configurado não corresponda a nenhum dos valores esperados,
uma exceção é levantada para alertar sobre um tipo de ataque inválido, assegurando a
integridade do processo. O diagrama na figura 3.7 ilustra detalhadamente esse processo,
mostrando como o atacante consulta o servidor OPC para determinar o tipo de ataque e,
em seguida, utiliza o handler adequado para executar o método correspondente ao ataque
selecionado. Esse mecanismo permite que o sistema realize ataques simulados em tempo
de execução, integrando-os ao fluxo geral de eventos e possibilitando testes robustos de
segurança.
Explicar o que é o handler!
Figura 3.7: Diagrama de sequência representando o processamento dos ataques pelo
atacante.
Durante o processamento dos eventos, os ataques podem ocorrer ao longo do tempo de
produção caso algum ataque tenha sido habilitado pelo operador. De um modo geral, os
ataques são processados na mesma região que os eventos são processados no controlador,
26
CAPÍTULO 3. DESCRIÇÃO DO PROCESSO DE SIMUALAÇÃO
como é possível ver no diagrama representado na figura 3.8, onde há uma representação mais abrangente e detalhada do processamento dos eventos no sistema, incluindo o
processamento dos ataques:
Figura 3.8: Diagrama de sequência representando o processamento dos ataques pelo
atacante.
Capítulo 4
Metodologia
Este capítulo deve descrever os métodos utilizados no projeto. As teorias e ferramentas
utilizadas, assim como as ações executadas, devem ser escritas de forma clara e precisa,
sem deixar espaço para ambiguidades. Tenha em mente que o objetivo aqui é dar
credibilidade ao seu trabalho e permitir que ele possa ser reproduzido por
quem tenha interesse (algumas vezes por você mesmo!).
É natural que este capítulo contenha uma revisão bibliográfica mais detalhada das
técnicas utilizadas. O ideal é que o capítulo seja auto-contido, de modo que o leitor não
necessite recorrer às referências para entender seu trabalho ou reproduzi-lo.
Ao apresentar os métodos, será importante justificar devidamente as opções tomadas
e discutir as alternativas disponíveis e os critérios que o levaram à escolha do método.
No restante do capítulo, apresentamos um pequeno manual de escrita técnica.
4.1
O atacante
4.1.1
Implementação
4.1.2
Fluxo dos ataques
4.2
O IDS
4.2.1
Implementação
4.2.2
Funcionamento e operação
27
28
CAPÍTULO 4. METODOLOGIA
Capítulo 5
Resultados
Para a execução do projeto, algumas etapas de desenvolvimento tiveram de ser seguidas:
familiarização com o sistema, estudo dos módulos envolvidos, leitura dos requisitos, elaboração de documento descrevendo todo o processo de implementação e relacionamento
com os diversos módulos, implementação e testes.
5.1
Atividades do Projeto
5.2
Requisitos do Sistema
5.3
Desenvolvimeto e Implementação
5.4
Testes
5.5
Análise dos Resultados
29
30
CAPÍTULO 5. RESULTADOS
Capítulo 6
Conclusões
Novamente, este será um dos trechos que o leitor experiente lerá antes de decidir se vale
a pena ler o texto integral. Seja convincente.
6.1
Considerações Finais
Reitere o que de mais importante foi feito, qual era o objetivo inicial e qual o resultado
obtido. Se houve requisitos ou especificações de projeto, discuta se foram atingidos. Se os
resultados não foram conclusivos ou contrariam o que se esperava, seja honesto e diga-o
explicitamente. Busque explicar os insucessos com argumentos sólidos e plausíveis.
6.2
Propostas de Continuidade
Se houve questões ainda não respondidas ou resultados insatisfatórios, aponte direções
de continuação.
31
32
CAPÍTULO 6. CONCLUSÕES
Referências Bibliográficas
[1] DRIAS, Z.; SERHROUCHNI, A.; VOGEL, O. Analysis of cyber security for industrial control systems. In: IEEE. 2015 international conference on cyber security of smart cities, industrial control system and communications (ssic). [S.l.], 2015. p. 1–8.
[2] ALVES, M. R.; RUDIE, K.; PENA, P. N. A security testbed for networked des control
systems. IFAC-PapersOnLine, Elsevier, v. 55, n. 28, p. 128–134, 2022.
[3] RASHIDINEJAD, A. et al. Supervisory control of discrete-event systems under attacks: An
overview and outlook. In: IEEE. 2019 18th European Control Conference (ECC). [S.l.], 2019.
p. 1732–1739.
[4] BHAMARE, D. et al. Cybersecurity for industrial control systems: A survey. computers &
security, Elsevier, v. 89, p. 101677, 2020.
[5] MACAULAY, T.; SINGER, B. L. Cybersecurity for industrial control systems: SCADA,
DCS, PLC, HMI, and SIS. [S.l.]: CRC Press, 2011.
[6] CASSANDRAS, C. G.; LAFORTUNE, S. Introduction to discrete event systems. [S.l.]: Springer, 2008.
[7] WONHAM, W. M.; CAI, K. et al. Supervisory control of discrete-event systems. [S.l.]: Springer, 2019.
33