This commit is contained in:
Arthur Grisel-Davy 2023-07-14 14:49:32 -04:00
parent 5f2cb74c7b
commit 68f4aa4158

View file

@ -609,11 +609,14 @@ A power measurement device is placed in series with the main power cable of the
The measurement devices captures the power consumption at 10 kilo-sampls per seconds. The measurement devices captures the power consumption at 10 kilo-sampls per seconds.
The pre-processing step downsamples the trace to 20 samples per seconds using a median filter. The pre-processing step downsamples the trace to 20 samples per seconds using a median filter.
This step greatly reduces the measurement noise and the processing time, and increases the consistency of the results. This step greatly reduces the measurement noise and the processing time, and increases the consistency of the results.
The final sampling rate of 20 samples per seconds was selected empirically to be about one order of magnitude highter than the typical length of the patterns to detect (around 5 seconds). The final sampling rate of 20 samples per seconds was selected empirically to be around one order of magnitude highter than the typical length of the patterns to detect (around 5 seconds).
For each comrpessed day of experiment (4 hours segment, thereafter refered as days), the \gls{mad} performs state detection and returns a label vector. For each comrpessed day of experiment (4 hours segment, thereafter refered as days), the \gls{mad} performs state detection and returns a label vector.
This label vector associate a label to each sample of the power trace following the mapping: -1 is UNKNOWN, 0 is SLEEP, 1 is IDLE, 2 is HIGH and 3 is REBOOT. This label vector associate a label to each sample of the power trace following the mapping: -1 is UNKNOWN, 0 is SLEEP, 1 is IDLE, 2 is HIGH and 3 is REBOOT.
The training dataset comprise one sample per state, captured during a the run of a benchmark script that interatively place the machine in each states to detect.
\agd{make dataset available}
\subsection{Security Rules}
Many rules can be imagined to describe the expected and unwanted behavior of a machine. Many rules can be imagined to describe the expected and unwanted behavior of a machine.
System administrators can define highly specific rules to detect specific attacks or to match the typicall acticities of their infrastructure. System administrators can define highly specific rules to detect specific attacks or to match the typicall acticities of their infrastructure.
We selected 4 rules (see Table~\ref{tab:rules}) that are representative of common threats on companies or administrations's \gls{it} infrastructures. We selected 4 rules (see Table~\ref{tab:rules}) that are representative of common threats on companies or administrations's \gls{it} infrastructures.
@ -635,9 +638,12 @@ The rules are formaly defined using the \gls{stl} syntax which is bespoke for de
\label{tab:rules} \label{tab:rules}
\end{table*} \end{table*}
\subsection{Results} \subsection{Results}
The performance measure represent the ability of the whole pipeline (\gls{mad} and rule checking) to detect anomalous behavior.
The script on the machine generates logs that serves as ground truth to verify the results of rule checking.
The main metrics are the \agd{name of metric chosen} for each rule (micro-\agd{name}) and the global \agd{name} (macro-\agd{name}).
It is important to note that the attack frequency was intentionally increase compared to the expected attack frequency in the real world.
\section{Discussion}\label{sec:discussion} \section{Discussion}\label{sec:discussion}
In this section we highlight specific aspects of the proposed solution. In this section we highlight specific aspects of the proposed solution.