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

add tablex and test case 0

Browse source
This commit is contained in:
Arthur Grisel-Davy 2023-06-25 14:34:10 -04:00
parent d9305f3a87
commit f12b3d6d76
1 changed files with 26 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

32
BPV/qrs/main.typ
View file

@ -257,22 +257,29 @@ The Euclidean distance is computed between each trace and the reference, and the
The distance threshold takes the value $1.5 * "IQR"$. For the detection, the distance of each new trace to the reference is computed and compared to the threshold. The distance threshold takes the value $1.5 * "IQR"$. For the detection, the distance of each new trace to the reference is computed and compared to the threshold.
If the distance is above the threshold, the new trace is considered anomalous. If the distance is above the threshold, the new trace is considered anomalous.
=== Support For Multi-modal Boot-up Sequences === Support For Multi-modal Bootup Sequences<multi-modal>
Some machines can boot following multiple different bootup sequences that are considered normal. Some machines can boot following multiple different bootup sequences that are considered normal.
There can exist various reasons for such behaviour. There can exist various reasons for such behaviour.
For example, a machine can perform recovery operations if the power is interrupted while the machine is off or perform health checks on components that may pass or fail and trigger deeper inspections procedure. For example, a machine can perform recovery operations if the power is interrupted while the machine is off or perform health checks on components that may pass or fail and trigger deeper inspections procedure.
Because the machines are treated as black boxes, it is important for the @BPV to deal with these multiple modes during training. Because the machines are treated as black boxes, it is important for the @BPV to deal with these multiple modes during training.
See @online for more details about how the online training procedure deals with multi-modal models.
Our approach is to develop one model per mode following the same procedure as for a single mode, presented in Section~@detector. Our approach is to develop one model per mode following the same procedure as for a single mode, presented in Section~@detector.
Then, the detection logic evolves to consider the new trace nominal if it matches any of the models. 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. 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. @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 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.
The vertical dashed lines represent the distance threshold.
#figure( #figure(
image("images/training.svg", width:100%), image("images/training.svg", width:100%),
caption: [BPV model trained with two modes.] caption: [BPV model trained with two modes.]
)<fig-modes> )<fig-modes>
= Test Case 0: Aggregated Power Measurements = 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 illustrate 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. 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. In some cases, capturing only the power consumption of the machine to protect is impossible.
@ -296,6 +303,12 @@ The second machine remained idle for the duration of the experiment.
caption: [Overview of the setup for the test case.] caption: [Overview of the setup for the test case.]
)<l3-setup> )<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.
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.
#figure( #figure(
image("images/l3-training.svg", width:100%), image("images/l3-training.svg", width:100%),
caption: [Multi-Modal BPV model after training.] caption: [Multi-Modal BPV model after training.]
@ -304,6 +317,13 @@ The second machine remained idle for the duration of the experiment.
== Results == Results
#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.
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.
= Test Case 1: Network Devices<exp-network> = Test Case 1: Network Devices<exp-network>
To verify the performance of the proposed detector, we design an experiment that aims at detecting firmware modifications on different devices. To verify the performance of the proposed detector, we design an experiment that aims at detecting firmware modifications on different devices.
@ -390,7 +410,7 @@ The results are presented in @tab-results.
)<tab-results> )<tab-results>
There are two hyper-parameters to tune to obtain the best performances. There are two hyper-parameters to tune to obtain the best performances.
First, the length of the trace considered is essential. First, the length of the trace considered is important.
The trace needs to cover the whole boot-up sequence to be sure to detect any possible change. The trace needs to cover the whole boot-up sequence to be sure to detect any possible change.
It is better to avoid extending the trace too much after the firmware sequence is done, as the typical operation of the machine can produce noisy power consumption that interferes with the optimal placement of the threshold. It is better to avoid extending the trace too much after the firmware sequence is done, as the typical operation of the machine can produce noisy power consumption that interferes with the optimal placement of the threshold.
Second, the number of training traces can be optimized. Second, the number of training traces can be optimized.
@ -417,7 +437,7 @@ The experimental setup for this case study is similar to the one presented in @e
The experiment focuses on the Spiri Mu drone #footnote[#link("https://spirirobotics.com/products/spiri-mu/")] flashed with the PX4 Drone Autopilot firmware #footnote[#link("https://px4.io/")]. The experiment focuses on the Spiri Mu drone #footnote[#link("https://spirirobotics.com/products/spiri-mu/")] flashed with the PX4 Drone Autopilot firmware #footnote[#link("https://px4.io/")].
The firmware for the flight controller consists of a microprocessor-specific bootloader, a second-stage bootloader common to all supported flight controllers. The firmware for the flight controller consists of a microprocessor-specific bootloader, a second-stage bootloader common to all supported flight controllers.
The battery of the drone is disconnected to ensure reproducible results and replaced with a laboratory power supply. The battery of the drone is replaced with a laboratory power supply to ensure reproducible results.
The power consumption measurement device (see @capture for more details) is attached in series with the main power cable that provides an 11V @DC current to the drone. The power consumption measurement device (see @capture for more details) is attached in series with the main power cable that provides an 11V @DC current to the drone.
A controllable relay is placed in series with the main cable to enable scripted bootup and shutdown scenarios. A controllable relay is placed in series with the main cable to enable scripted bootup and shutdown scenarios.
The experiment scenarios are: The experiment scenarios are:
@ -602,7 +622,7 @@ This pre-processing removes most of the impulse noise that could falsely trigger
The final step of the detection is to store all the boot sequences under the same label for evaluation. The final step of the detection is to store all the boot sequences under the same label for evaluation.
The complete dataset corresponding to this experiment is available online @dataset. The complete dataset corresponding to this experiment is available online @dataset.
== Support for Online Training == Support for Online Training<online>
In order for the @BPV to integrate in a realistic environment, the training procedure takes the rareness of the boot-up event into account. In order for the @BPV to integrate in a realistic environment, the training procedure takes the rareness of the boot-up event into account.
Once the measurement device is set up on the machine to protect, the streaming time series representing the power consumption serves as input for the bootup detection algorithm (see @sds). Once the measurement device is set up on the machine to protect, the streaming time series representing the power consumption serves as input for the bootup detection algorithm (see @sds).
Each bootup event is extracted and added to a dataset of bootup traces. Each bootup event is extracted and added to a dataset of bootup traces.