grizzly/deneir
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

fix intro text

Browse source
This commit is contained in:
Arthur Grisel-Davy 2023-10-02 07:59:41 -04:00
parent e1e9b0183e
commit 1c46064a66
3 changed files with 45 additions and 37 deletions
Download patch file Download diff file Expand all files Collapse all files

50
PhD/research_proposal/introduction.tex
View file

@ -1,45 +1,53 @@
\chapter{Introduction to Physics-Based Security}
\section{Context}
\gls{scs} are those whose failure to perform their task could result in significant safety risks for humans or the environment.
These systems are present in many aspects of our daily life from transportation (ABS, airbags, traffic lights), or energy production (nuclear controle systems), to medicine (ventilation systems, radiation machines) and many others.
\gls{scs} are now more and more computer-based to enable features such as remote control or lower cost maintenance.
These systems are also increasingly connected to the internet to allow for offsite monitoring or data collection.
This digitalization of \gls{scs} also brings the undesirable aspects of connected computers.
The more connection and interraction types are available to a computer system, the greater is the risk of an attacker using one of these connection.
This sum of potential attack points, called attack surface, should typically be as small as possible, especially for \gls{scs} that require high reliability and availability.
Increasing the capabilities and connectivity of \gls{scs} enable large scale attacks that would be infeasible before.
For example, if all the water treatment plants in Canada are equipped with a data collection mechanisme exposed to the internet for centralized analysis, then an atacker could leverage this mechanism to take over all these system and put the whole country at risk.
A wide variety range of solutions are available to protect computer systems in general.
Among them, \gls{ids} aim at detecting security policies violations or suspicious activities from or among computers.
Collection and analysis of data related to the machines activity often enable the detection.
%\gls{scs} are those whose failure to perform their task could result in significant safety risks for humans or the environment.
%These systems are present in many aspects of our daily life from transportation (ABS, airbags, traffic lights), or energy production (nuclear controle systems), to medicine (ventilation systems, radiation machines) and many others.
%\gls{scs} are now more and more computer-based to enable features such as remote control or lower maintenance cost.
%These systems are also increasingly connected to the internet to allow for offsite monitoring or data collection.
%This digitalization of \gls{scs} also brings the undesirable aspects of connected computers.
%The more connection and interraction types are available to a computer system, the greater is the risk of an attacker using one of these connection.
%This sum of potential attack points, called attack surface, should typically be as small as possible, especially for \gls{scs} that require high reliability and availability.
%Increasing the capabilities and connectivity of \gls{scs} enable large scale attacks that would be infeasible before.
%For example, if all the water treatment plants in Canada are equipped with a data collection mechanisme exposed to the internet for centralized analysis, then an atacker could leverage this mechanism to take over all these system and put the whole country at risk.
A wide variety of solutions are available to protect embedded.
No solution can claim to protect against all possible attacks and multiple layers of prevention, detection, and mitigation mechanism are often require to protect a system as best as possible.
Each solution present different domains of application, requirements, and capabilities that are important to understand to reduce the attack surface.
Among all these solutions, \gls{ids} aim at detecting security policies violations or suspicious activities from or among computers.
The detection always starts with the collection and analysis of data related to the activity of the machine to protect --- also called the target.
If the \gls{ids} only consideres local ressources (e.g. CPU load, RAM data, disks read/write speed), then it is called \gls{hids}.
\gls{hids} have access to relevant local data but they require to install a software on the machine (either for collection only or for local analysis).
This represent a potential flaw for multiple reasons.
First, the host machine may not be trusted and can be compromised, allowing the attacker to deploy stealth attacks \cite{10.1145/586110.586145}.
Second, an \gls{hids} can lack the broader vision required to detect intrusions distributed over a network of machines.
Finally, the operation of the \gls{hids} may interfer with the critical operation of the system (for example if the \gls{hids} missbehave and block other operations).
For these reasons, \gls{hids} may be difficult to implement on a wide range of embedded systems.
This represent a potential flaw for two main reasons.
First, the host machine may not be trusted and can be compromised, allowing the attacker to deploy or bypass the detection by feeding forged data to the \gls{ids}, shutting it down, or forging the result of the detection.
Second, the operation of the \gls{hids} may interfer with the critical operation of the system (for example if the \gls{hids} missbehave and block other operations).
For these reasons, \gls{hids} may be difficult to implement on a wide range of embedded systems and lack the reliability of an external solution.
The other main class of \gls{ids} aims at solving these issues.
One other main class of \gls{ids} takes a different approach to solve some of these issues.
\gls{nids} \cite{vigna1999netstat, bivens2002network} consider the communication between machines in a network to detect intrusions.
This solution does not require installing individual software on each machines and can detect network-level intrusions.
However, \gls{nids} present their own concerns.
However, \gls{nids} present their own drawbacks.
First, machine-specific attacks can remain undetected as only network information are accessible.
Then, they require the installation of dedicated equipment to collect network traffic.
Finally, modern traffic encryption practices will limit the \gls{nids} to sender-receiver pattern analysis unless traffic flows unencrypted, which can raises privacy issues.
It appears that the current \gls{ids} scene present a tradeoff between granularity of detection and isolation from the protected machine.
What about the case of protecting a machine against a local intrusion without the possibility to install additional software?
This use case can seem niche but it represent a reality for many purpose-built embedded systems with minimal \gls{os}.
How can and \gls{ids} protect a machine again attackers bypassing the secure boot verification and booting a completely different \gls{os}?
If a vulnerability is discovered on a \gls{scs}, how can the detection mechanism evolve without requiring the re-certification of the whole system?
These use case can seem niche but it represent a reality for many purpose-built embedded systems with minimal \gls{os}.
Systems like network switchs, \gls{rtu}, \gls{wap} rarely allow the installation of any software and yet perform critical tasks.
In these cases, neither local ressources usage or network information can be leveraged for local attacks detection.
Moreover, any industry that rely on \gls{scs} have strict regulations (e.g. DO-178C for aerospace systems in Canada, ISO 26262 for automotive system, ISO 16142 for medical devices) that guarantee the safety of every equipment.
Modifying an existing system to add intrusion detection capabilities is expensive as it requires the re-validation of the whole system.
%An external solution relying on side-channel anaylysis is easier to get certified as it does not directly interact with the \gls{scs}
A third, under-exploited, source of information for embedded systems activity are the side-channels.
A third under-exploited source of information for embedded systems activity are the side-channels.
The side-channels are all the physical emissions that a machine involuntarely generates.
For example, the sound of a fan, the temperature of a CPU, or the power consumption of a \gls{psu} are common side-channels.