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

add L3 results

Browse source
This commit is contained in:
Arthur Grisel-Davy 2023-06-26 10:02:56 -04:00
parent 3fcea8ade0
commit fb23f011b1
1 changed files with 25 additions and 17 deletions
Download patch file Download diff file Expand all files Collapse all files

42
BPV/qrs/main.typ
View file

@ -270,10 +270,10 @@ Our approach is to develop one model per mode following the same procedure as fo
With multiple models available, the detection logic evolves to consider the new trace nominal if it matches any of the models.
If the new trace does not match any model, then it does not follow any of the nominal modes and is considered abnormal.
@fig-modes illustrate the trained @BPV models when two modes are present in the bootup sequence.
The top part of the figure represents the average power trace for each mode. The x axis is the time in milliseconds and the y axis is the amplitude in a unit proportional to the ampere (the absolute value of the consumption is uninportant for this study, only the global pattern matters).
The top part of the figure represents the average power trace for each mode. The x-axis is the time in milliseconds, and the y-axis is the amplitude in a unit proportional to the ampere (the absolute value of the consumption is unimportant for this study, only the global pattern matters).
The bottom part of the figure represents the distances and the threshold.
Each color represent one mode.
Each point represent the distance from one training sample to the average trace of its mode.
Each colour represents one mode.
Each point represents the distance from one training sample to the average trace of its mode.
The vertical dashed lines represent the distance threshold.
#figure(
@ -283,31 +283,30 @@ The vertical dashed lines represent the distance threshold.
= Test Case 0: General Purpose Computer
This test case illustrate the first application of the @BPV and follows a slightly different setup and assumptions.
This test case illustrates the first application of the @BPV and follows a slightly different setup and assumptions.
First, the power consumption measurement does not only contain the consumption of the machine to protect.
In some cases, capturing only the power consumption of the machine to protect is impossible.
For example, if the power connections follow proprietary designs, or if the machine to protect is innaccessible (for practical or security reasons).
For example, if the power connections follow proprietary designs or if the machine to protect is inaccessible (for practical or security reasons).
In this case, the data available is an aggregate of the machine to protect and a second machine.
The second machine does not perform any task and its contribution to the aggregated power consumption is constant.
The second machine does not perform any task, and its contribution to the aggregated power consumption is constant.
Second, anomalous examples of bootup sequences are available.
This test case was designed with an industry partner for the detection of two specific attack: bootup on an extrnal USB drive and access to the machine's @BIOS.
Because hte machine and the expected attacks are known in advance, it is possible to tailor the @BPV's parameters for maximizing the performances at detecting the attacks.
This test case was designed with an industry partner for the detection of two specific attacks: bootup on an external USB drive and access to the machine's @BIOS.
Because the machine and the expected attacks are known in advance, it is possible to tailor the @BPV's parameters for maximizing the performances at detecting the attacks.
Because of these two specificities, this test case should be regarded as a first iteration to demonstrate the potential of the @BPV in a more restrictive environment.
The following test cases in @exp-network and @exp-drone present other applications in more challenging environments.
== Experimental Setup
This test case was conducted on a micro-pc running Windows 10.
This test case was conducted on a micro PC running Windows 8.
The available power consumption was an aggregate of two micro-pc, one being the machine to protect.
The second machine remained idle for the duration of the experiment.
@l3-setup illustrate the setup for the data capture.
@l3-setup illustrates the setup for the data capture.
#figure(
image("images/l3-setup.svg", width:100%),
caption: [Overview of the setup for the test case.]
)<l3-setup>
#agd[find number of training samples] samples were collected for training the model.
From these samples representing nominal bootups, it appear that the machine presents multiple bootup modes.
From these samples representing nominal bootups, it appears that the machine presents multiple bootup modes.
Hence, the model is multi-modal with three modes.
See @multi-modal for more details about how multi-modal models are defined.
@l3-training illustrates the power traces associated with each mode as well as the distance distribution and the thresholds.
@ -317,15 +316,23 @@ See @multi-modal for more details about how multi-modal models are defined.
caption: [Multi-Modal BPV model after training.]
)<l3-training>
After collecting training traces, the distribution of samples in each model was $(0.31,0.06,0.62)$.
This distribution remains purely circumstantial from the point of view of the detector that considers the machine to protect as a black box.
The root causes for the appearance of one bootup mode, or another is outside the scope of this work.
The final training dataset comprises 93 training samples divided into three models following the above distribution.
Abnormal bootup traces are also collected.
The abnormal boot sequences are composed of sequences where an operator went into the @BIOS and then continued booting into the OS.
== Results
The models are manually tuned to obtain 100% accuracy in the classification of nominal and abnormal boot sequences.
Obtaining 100% accuracy illustrates that there is a clear separation between nominal and abnormal boot sequences for this type of attack.
#agd[could not redo the results as teh data for bios boot are missing]
#agd[results]
Althoug this test case represent an unrealistic situation (mainly because the anomalous samples are accessible), it is still a valuable first evaluation of the @BPV.
Although this test case represents an unrealistic situation (mainly because the anomalous samples are accessible), it is still a valuable first evaluation of the @BPV.
This test case serves as a proof-of-concept and indicates that there is a potential for the detection of firmware-level attacks with power consumption.
The method detected the pre-defined attack in complete independence from the machine and with a very-high success rate.
Having access to anomalous samples enabled to optimize the threshold placmeent to minimize false-positive (nominal bootups detected as anomalous) by relaxing the threshold value.
The method detected the pre-defined attack with complete independence from the machine and with a perfect success rate.
Having access to anomalous samples enabled us to optimize the threshold placement to minimize false-positive (nominal bootups detected as anomalous) by relaxing the threshold value.
= Test Case 1: Network Devices<exp-network>
@ -646,3 +653,4 @@ On a per-machine basis, anomaly generation can enhance the training set without
Finally, deploying this technology to production networking equipment requires minimal downtime and hardware intrusion, and it is applicable to clientless equipment.
This study illustrates the potential of independent, side-channel-based @IDS for the detection of low-level attacks that can compromise machines even before the operating system gets loaded.