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

28
PhD/research_proposal/frontpages.tex
View file

@ -34,7 +34,7 @@
thesis requirement for the degree of \\
Doctor of Philosophy \\
in \\
Philosophy of Electrical and Computer Engineering \\
Electrical and Computer Engineering \\
\vspace*{2.0cm}
@ -108,21 +108,21 @@ Supervisor: \> Sebastian Fischmeister \\
\addcontentsline{toc}{chapter}{Abstract}
\begin{center}\textbf{Abstract}\end{center}
Most current Intrusion Detection Systems (IDSs) share the flaw of requiring the cooperation of the system to protect.
Whether the IDS is a software or hardware component, they don't perform the detection independently and require the system to protect to execute or call them.
This is a critical flaw as it allows attackers to avoid detection by forging input data, forging detection results, or bypassing the IDS altogether.
This is particularly problematic for firmware-level attacks that enable control of the most critical components of the machine, making the attacks especially difficult to detect, mitigate, and remove.
Most current Intrusion Detection Systems (IDSs) share the flaw of requiring the cooperation of the system to protect --- the target.
Whether the IDS is a software or hardware component, they don't perform the detection independently and require the target to execute a programm, use a component, or transmit resuts.
In the case of a compromised target, this critical flaw allows attackers to avoid detection by forging input data, forging detection results, or bypassing the IDS altogether.
This design makes the result of the detection trustworthy only when the target is not compromised.
This observation leads to the conclusion that we cannot entrust machines to assess their integrity.
To remain trustworthy, the IDS must be independent of the machine to protect and require no cooperation to perform the detection.
The main challenge with such a system is getting access to relevant data.
Network-based IDS fit in this category and exhibit complete independence, but their input data --- network communication from the machine --- is only relevant for a small subset of attacks.
This observation leads to the conclusion that we cannot entrust machines to assess their own integrity.
To remain trustworthy, the IDS must be independent of the target and require no cooperation to perform the detection.
The main challenge with such a system is collecting relevant data.
The main example of such a system are Network-based IDS (NIDS).
NIDS exhibit complete independence, but their input data --- network communication from the machine --- is only relevant for a small subset of attacks.
This thesis proposes to explore another family of IDSs called physics-based IDS that leverages side-channel information.
Side-channel information is a perfect candidate for intrusion detection.
The generation of this information is, by definition, involuntary.
Hence, their measurement requires no communication with the machine to protect.
Moreover, if chosen carefully, side-channel information can provide insight into all activities performed by the machine.
This proposal describe another family of IDSs called physics-based IDS that leverages side-channel information.
Side-channel information is a perfect candidate for intrusion detection as it is, by definition, an involuntary emission from the target.
Collecting side-channel information requires no communication with the machine to protect.
Moreover, if chosen adequately, side-channel information can provide insight into all activities performed by the machine.
Finally, side-channel information remains practical to measure on virtually any embedded system, providing a solution that is not only theoretical but also applicable in the real world.
This proposal describes the exploratory work already achieved in the domain of physics-based IDS and outlines the main problems to study to evaluate the potential of this technology.

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.

4
PhD/research_proposal/proposal.tex
View file

@ -100,7 +100,7 @@
\newcommand{\mytitle}{Ph.D Research Proposal}
\newcommand{\myauthor}{Arthur Grisel-Davy}
\newcommand{\mytopic}{Physics-Based Cyber Security}
\newcommand{\mytopic}{Physics-Based Cybersecurity}
\newcommand{\myinstitution}{University of Waterloo}
\newtheorem{problem-statement}{Problem Statement}
@ -243,7 +243,7 @@
%\appendix
% Add an un-numbered title page before the appendices and a line in the Table of Contents
%\chapter*{APPENDICES}
\addcontentsline{toc}{chapter}{APPENDICES}
%\addcontentsline{toc}{chapter}{APPENDICES}
% Appendices are just more chapters, with different labeling (letters instead of numbers).
% GLOSSARIES (Lists of definitions, abbreviations, symbols, etc. provided by the glossaries-extra package)