backup before SnP
This commit is contained in:
parent
201c62b97d
commit
f5712a3a73
13 changed files with 7506 additions and 68 deletions
1484
pococha/images/figures.svg
Normal file
1484
pococha/images/figures.svg
Normal file
File diff suppressed because it is too large
Load diff
|
After Width: | Height: | Size: 103 KiB |
103
procver/SnP/acronyms.tex
Normal file
103
procver/SnP/acronyms.tex
Normal file
|
|
@ -0,0 +1,103 @@
|
|||
\DeclareAcronym{ids}{
|
||||
short={IDS},
|
||||
long={Intrusion Detection System}
|
||||
}
|
||||
\DeclareAcronym{hids}{
|
||||
short={HIDS},
|
||||
long={Host-Based Intrusion Detection System}
|
||||
}
|
||||
\DeclareAcronym{os}{
|
||||
short={OS},
|
||||
long={Operating System}
|
||||
}
|
||||
\DeclareAcronym{sci}{
|
||||
short={SCI},
|
||||
long={Side-Channel Information}
|
||||
}
|
||||
\DeclareAcronym{cpu}{
|
||||
short={CPU},
|
||||
long={Central Processing Unit}
|
||||
}
|
||||
\DeclareAcronym{ilp}{
|
||||
short={ILP},
|
||||
long={Instantaneous List of Processes}
|
||||
}
|
||||
|
||||
\DeclareAcronym{uefi}{
|
||||
short={UEFI},
|
||||
long={Unified Extensible Firmware Interface}
|
||||
}
|
||||
|
||||
\DeclareAcronym{vm}{
|
||||
short={VM},
|
||||
short-plural={s},
|
||||
long={Virtual Machine},
|
||||
long-plural={s}
|
||||
}
|
||||
|
||||
\DeclareAcronym{vmm}{
|
||||
short={VMM},
|
||||
short-plural={VMMs},
|
||||
long={Virtual Machine Monitor},
|
||||
long-plural={Virtual Machine Monitors}
|
||||
}
|
||||
|
||||
\DeclareAcronym{msrt}{
|
||||
short={MSRT},
|
||||
long={Malicious Software Removal Tool}
|
||||
}
|
||||
|
||||
\DeclareAcronym{cve}{
|
||||
short={CVE},
|
||||
long={Common Vulnerabilities and Exposures}
|
||||
}
|
||||
|
||||
\DeclareAcronym{ssl}{
|
||||
short={SSL},
|
||||
long={Secure Socket Layer}
|
||||
}
|
||||
|
||||
\DeclareAcronym{nilm}{
|
||||
short={NILM},
|
||||
long={Non-Intrusive Load Monitoring}
|
||||
}
|
||||
|
||||
\DeclareAcronym{bios}{
|
||||
short={BIOS},
|
||||
long={Basic Input/Output System}
|
||||
}
|
||||
|
||||
\DeclareAcronym{tsv}{
|
||||
short={TSV},
|
||||
long={Tab-Separated Values}
|
||||
}
|
||||
|
||||
\DeclareAcronym{pcb}{
|
||||
short={PCB},
|
||||
long={Printed Circuit Board}
|
||||
}
|
||||
|
||||
\DeclareAcronym{aws}{
|
||||
short={AWS},
|
||||
long={Amazon Web Services}
|
||||
}
|
||||
|
||||
\DeclareAcronym{dtw}{
|
||||
short={DTW},
|
||||
long={Dynamic Time Warping}
|
||||
}
|
||||
|
||||
\DeclareAcronym{mlp}{
|
||||
short={MLP},
|
||||
long={Multilayer Perceptron}
|
||||
}
|
||||
|
||||
\DeclareAcronym{mae}{
|
||||
short={MAE},
|
||||
long={Mean Absolute Error}
|
||||
}
|
||||
|
||||
\DeclareAcronym{mse}{
|
||||
short={MSE},
|
||||
long={Mean Squared Error}
|
||||
}
|
||||
286
procver/SnP/biblio.bib
Normal file
286
procver/SnP/biblio.bib
Normal file
|
|
@ -0,0 +1,286 @@
|
|||
@misc{win-msrt,
|
||||
author = {Microsoft},
|
||||
title = {Windows Malicious Software Removal Tool: Progress Made, Trends Observed},
|
||||
year = 2024,
|
||||
url = {https://www.microsoft.com/en-us/download/details.aspx?id=14591},
|
||||
urldate = {01-05-2025}
|
||||
}
|
||||
|
||||
@misc{cosmicstrand,
|
||||
author = {Kaspersky},
|
||||
title = {CosmicStrand: sophisticated firmware rootkit allows durable persistence},
|
||||
year = 2022,
|
||||
url = {https://www.kaspersky.com/about/press-releases/cosmicstrand-sophisticated-firmware-rootkit-allows-durable-persistence},
|
||||
urldate = {01-05-2025}
|
||||
}
|
||||
|
||||
@inproceedings{10.1145/1315245.1315262,
|
||||
author = {Jiang, Xuxian and Wang, Xinyuan and Xu, Dongyan},
|
||||
title = {Stealthy malware detection through vmm-based "out-of-the-box" semantic view reconstruction},
|
||||
year = {2007},
|
||||
isbn = {9781595937032},
|
||||
publisher = {Association for Computing Machinery},
|
||||
address = {New York, NY, USA},
|
||||
url = {https://doi.org/10.1145/1315245.1315262},
|
||||
doi = {10.1145/1315245.1315262},
|
||||
abstract = {An alarming trend in malware attacks is that they are armed with stealthy techniques to detect, evade, and subvert malware detection facilities of the victim. On the defensive side, a fundamental limitation of traditional host-based anti-malware systems is that they run inside the very hosts they are protecting ("in the box"), making them vulnerable to counter-detection and subversion by malware. To address this limitation, recent solutions based on virtual machine (VM) technologies advocate placing the malware detection facilities outside of the protected VM ("out of the box"). However, they gain tamper resistance at the cost of losing the native, semantic view of the host which is enjoyed by the "in the box" approach, thus leading to a technical challenge known as the semantic gap.In this paper, we present the design, implementation, and evaluation of VMwatcher - an "out-of-the-box" approach that overcomes the semantic gap challenge. A new technique called guest view casting is developed to systematically reconstruct internal semantic views (e.g., files, processes, and kernel modules) of a VM from the outside in a non-intrusive manner. Specifically, the new technique casts semantic definitions of guest OS data structures and functions on virtual machine monitor (VMM)-level VM states, so that the semantic view can be reconstructed. With the semantic gap bridged, we identify two unique malware detection capabilities: (1) view comparison-based malware detection and its demonstration in rootkit detection and (2) "out-of-the-box" deployment of host-based anti-malware software with improved detection accuracy and tamper-resistance. We have implemented a proof-of-concept prototype on both Linux and Windows platforms and our experimental results with real-world malware, including elusive kernel-level rootkits, demonstrate its practicality and effectiveness.},
|
||||
booktitle = {Proceedings of the 14th ACM Conference on Computer and Communications Security},
|
||||
pages = {128–138},
|
||||
numpages = {11},
|
||||
keywords = {virtual machines, rootkits, malware detection},
|
||||
location = {Alexandria, Virginia, USA},
|
||||
series = {CCS '07}
|
||||
}
|
||||
|
||||
@inproceedings{wen2008implicit,
|
||||
title={Implicit detection of hidden processes with a feather-weight hardware-assisted virtual machine monitor},
|
||||
author={Wen, Yan and Zhao, Jinjing and Wang, Huaimin and Cao, Jiannong},
|
||||
booktitle={Information Security and Privacy: 13th Australasian Conference, ACISP 2008, Wollongong, Australia, July 7-9, 2008. Proceedings 13},
|
||||
pages={361--375},
|
||||
year={2008},
|
||||
organization={Springer}
|
||||
}
|
||||
|
||||
@inproceedings{jones2008vmm,
|
||||
title={VMM-based hidden process detection and identification using Lycosid},
|
||||
author={Jones, Stephen T and Arpaci-Dusseau, Andrea C and Arpaci-Dusseau, Remzi H},
|
||||
booktitle={Proceedings of the fourth ACM SIGPLAN/SIGOPS international conference on Virtual execution environments},
|
||||
pages={91--100},
|
||||
year={2008}
|
||||
}
|
||||
|
||||
@inproceedings{wang2005detecting,
|
||||
title={Detecting stealth software with strider ghostbuster},
|
||||
author={Wang, Y-M and Beck, Doug and Vo, Binh and Roussev, Roussi and Verbowski, Chad},
|
||||
booktitle={2005 International Conference on Dependable Systems and Networks (DSN'05)},
|
||||
pages={368--377},
|
||||
year={2005},
|
||||
organization={IEEE}
|
||||
}
|
||||
|
||||
@article{cloudburst,
|
||||
title={Cloudburst},
|
||||
author={Kortchinsky, Kostya},
|
||||
journal={Black Hat USA.[http://www.blackhat.com/presentations/bh-usa-09/KORTCHINSKY/BHUSA09-Kortchinsky-Cloudburst-PAPER.pdf]},
|
||||
year={2009}
|
||||
}
|
||||
|
||||
@misc{cve-vmware-2017,
|
||||
title = {CVE-2017-4902},
|
||||
author = {VMware},
|
||||
howpublished = "Available from NIST NVD",
|
||||
year = {2017},
|
||||
url={https://nvd.nist.gov/vuln/detail/CVE-2017-4902},
|
||||
urldate={03 May 2025}
|
||||
}
|
||||
|
||||
@misc{cve-vbox-2021,
|
||||
title = {CVE-2021-2443},
|
||||
author = {VirtualBox},
|
||||
howpublished = "Available from NIST NVD",
|
||||
year = {2021},
|
||||
url={https://nvd.nist.gov/vuln/detail/CVE-2021-2443},
|
||||
urldate={03 May 2025}
|
||||
}
|
||||
|
||||
@misc{cve-qemu-2019,
|
||||
title = {CVE-2019-6778},
|
||||
author = {QEMU},
|
||||
howpublished = "Available from NIST NVD",
|
||||
year = {2019},
|
||||
url={https://nvd.nist.gov/vuln/detail/CVE-2019-6778},
|
||||
urldate={03 May 2025}
|
||||
}
|
||||
|
||||
@misc{cve-xen-2015,
|
||||
title = {CVE-2015-5154},
|
||||
author = {Xen},
|
||||
howpublished = "Available from NIST NVD",
|
||||
year = {2015},
|
||||
url={https://nvd.nist.gov/vuln/detail/CVE-2015-5154},
|
||||
urldate={03 May 2025}
|
||||
}
|
||||
|
||||
@misc{cve-hyperv-2021,
|
||||
title = {CVE-2021-28476},
|
||||
author = {Microsoft Hyper-V},
|
||||
howpublished = "Available from NIST NVD",
|
||||
year = {2021},
|
||||
url={https://nvd.nist.gov/vuln/detail/CVE-2021-28476},
|
||||
urldate={03 May 2025}
|
||||
}
|
||||
|
||||
@inproceedings{kocher1996timing,
|
||||
title={Timing attacks on implementations of Diffie-Hellman, RSA, DSS, and other systems},
|
||||
author={Kocher, Paul C},
|
||||
booktitle={Advances in Cryptology—CRYPTO’96: 16th Annual International Cryptology Conference Santa Barbara, California, USA August 18--22, 1996 Proceedings 16},
|
||||
pages={104--113},
|
||||
year={1996},
|
||||
organization={Springer}
|
||||
}
|
||||
|
||||
@article{van1985electromagnetic,
|
||||
title={Electromagnetic radiation from video display units: An eavesdropping risk?},
|
||||
author={Van Eck, Wim},
|
||||
journal={Computers \& Security},
|
||||
volume={4},
|
||||
number={4},
|
||||
pages={269--286},
|
||||
year={1985},
|
||||
publisher={Elsevier}
|
||||
}
|
||||
|
||||
@article{brumley2005remote,
|
||||
title={Remote timing attacks are practical},
|
||||
author={Brumley, David and Boneh, Dan},
|
||||
journal={Computer Networks},
|
||||
volume={48},
|
||||
number={5},
|
||||
pages={701--716},
|
||||
year={2005},
|
||||
publisher={Elsevier}
|
||||
}
|
||||
|
||||
@INPROCEEDINGS{1301311,
|
||||
author={Asonov, D. and Agrawal, R.},
|
||||
booktitle={IEEE Symposium on Security and Privacy, 2004. Proceedings. 2004},
|
||||
title={Keyboard acoustic emanations},
|
||||
year={2004},
|
||||
volume={},
|
||||
number={},
|
||||
pages={3-11},
|
||||
keywords={Keyboards;Neural networks;Microphones;Telephony;Acoustic devices;Immune system;Humans;Ear;Computer security;Information security},
|
||||
doi={10.1109/SECPRI.2004.1301311}
|
||||
}
|
||||
|
||||
@article{worden2007application,
|
||||
title={The application of machine learning to structural health monitoring},
|
||||
author={Worden, Keith and Manson, Graeme},
|
||||
journal={Philosophical Transactions of the Royal Society A: Mathematical, Physical and Engineering Sciences},
|
||||
volume={365},
|
||||
number={1851},
|
||||
pages={515--537},
|
||||
year={2007},
|
||||
publisher={The Royal Society London}
|
||||
}
|
||||
@inproceedings{shewale2019novel,
|
||||
title={Novel machine health monitoring system},
|
||||
author={Shewale, Mahesh S and Mulik, Sharad S and Deshmukh, Suhas P and Patange, Abhishek D and Zambare, Hrishikesh B and Sundare, Advait P},
|
||||
booktitle={Proceedings of the 2nd International Conference on Data Engineering and Communication Technology: ICDECT 2017},
|
||||
pages={461--468},
|
||||
year={2019},
|
||||
organization={Springer}
|
||||
}
|
||||
|
||||
@article{khan2019malware,
|
||||
title={Malware detection in embedded systems using neural network model for electromagnetic side-channel signals},
|
||||
author={Khan, Haider Adnan and Sehatbakhsh, Nader and Nguyen, Luong N and Prvulovic, Milos and Zaji{\'c}, Alenka},
|
||||
journal={Journal of Hardware and Systems Security},
|
||||
volume={3},
|
||||
pages={305--318},
|
||||
year={2019},
|
||||
publisher={Springer}
|
||||
}
|
||||
|
||||
@inproceedings{cathis2024sok,
|
||||
title={SoK Paper: Power Side-Channel Malware Detection},
|
||||
author={Cathis, Alexander and Li, Ge and Wei, Shijia and Orshansky, Michael and Tiwari, Mohit and Gerstlauer, Andreas},
|
||||
booktitle={Proceedings of the International Workshop on Hardware and Architectural Support for Security and Privacy 2024},
|
||||
pages={1--9},
|
||||
year={2024}
|
||||
}
|
||||
|
||||
@ARTICLE{7362010,
|
||||
author={Caviglione, Luca and Gaggero, Mauro and Lalande, Jean-François and Mazurczyk, Wojciech and Urbański, Marcin},
|
||||
journal={IEEE Transactions on Information Forensics and Security},
|
||||
title={Seeing the Unseen: Revealing Mobile Malware Hidden Communications via Energy Consumption and Artificial Intelligence},
|
||||
year={2016},
|
||||
volume={11},
|
||||
number={4},
|
||||
pages={799-810},
|
||||
keywords={Malware;Mobile handsets;Power demand;Energy measurement;Energy consumption;Performance evaluation;Neural networks;Energy-based malware detection;covert channels;colluding applications;neural networks;decision trees;Energy-based malware detection;covert channels;colluding applications;neural networks;decision trees},
|
||||
doi={10.1109/TIFS.2015.2510825}
|
||||
}
|
||||
|
||||
@article{chou2014real,
|
||||
title={Real-time detection of anomalous power consumption},
|
||||
author={Chou, Jui-Sheng and Telaga, Abdi Suryadinata},
|
||||
journal={Renewable and Sustainable Energy Reviews},
|
||||
volume={33},
|
||||
pages={400--411},
|
||||
year={2014},
|
||||
publisher={Elsevier}
|
||||
}
|
||||
|
||||
@inproceedings{cortez2017resource,
|
||||
title={Resource central: Understanding and predicting workloads for improved resource management in large cloud platforms},
|
||||
author={Cortez, Eli and Bonde, Anand and Muzio, Alexandre and Russinovich, Mark and Fontoura, Marcus and Bianchini, Ricardo},
|
||||
booktitle={Proceedings of the 26th Symposium on Operating Systems Principles},
|
||||
pages={153--167},
|
||||
year={2017}
|
||||
}
|
||||
|
||||
@misc{azure-dataset,
|
||||
author = {Azure},
|
||||
title = {Azure Public Dataset},
|
||||
year = {2019},
|
||||
publisher = {GitHub},
|
||||
journal = {GitHub repository},
|
||||
howpublished = {\url{https://https://github.com/Azure/AzurePublicDataset}},
|
||||
}
|
||||
|
||||
@misc{zenodo-dataset,
|
||||
author = {Anonymous},
|
||||
title = {Power Consumption and Process List from Replayed Azure VM Dataset},
|
||||
year = {2025},
|
||||
publisher = {Zenodo},
|
||||
howpublished = {\url{https://https://zenodo.org/records/14775781}},
|
||||
}
|
||||
|
||||
@inproceedings{tekiner2021sok,
|
||||
title={SoK: cryptojacking malware},
|
||||
author={Tekiner, Ege and Acar, Abbas and Uluagac, A Selcuk and Kirda, Engin and Selcuk, Ali Aydin},
|
||||
booktitle={2021 IEEE European Symposium on Security and Privacy (EuroS\&P)},
|
||||
pages={120--139},
|
||||
year={2021},
|
||||
organization={IEEE}
|
||||
}
|
||||
|
||||
@inproceedings{bridges2018towards,
|
||||
title={Towards malware detection via cpu power consumption: Data collection design and analytics},
|
||||
author={Bridges, Robert and Jim{\'e}nez, Jarilyn Hern{\'a}ndez and Nichols, Jeffrey and Goseva-Popstojanova, Katerina and Prowell, Stacy},
|
||||
booktitle={2018 17th IEEE International Conference On Trust, Security And Privacy In Computing And Communications/12th IEEE International Conference On Big Data Science And Engineering (TrustCom/BigDataSE)},
|
||||
pages={1680--1684},
|
||||
year={2018},
|
||||
organization={IEEE}
|
||||
}
|
||||
|
||||
@misc{chollet2015keras,
|
||||
title={Keras},
|
||||
author={Chollet, Fran\c{c}ois and others},
|
||||
year={2015},
|
||||
howpublished={\url{https://keras.io}},
|
||||
}
|
||||
|
||||
@article{eresheim2017evolution,
|
||||
title={The evolution of process hiding techniques in malware-current threats and possible countermeasures},
|
||||
author={Eresheim, Sebastian and Luh, Robert and Schrittwieser, Sebastian},
|
||||
journal={Journal of Information Processing},
|
||||
volume={25},
|
||||
pages={866--874},
|
||||
year={2017},
|
||||
publisher={Information Processing Society of Japan}
|
||||
}
|
||||
|
||||
@incollection{MCCUE20073,
|
||||
title = {1 - Basics},
|
||||
editor = {Colleen McCue},
|
||||
booktitle = {Data Mining and Predictive Analysis},
|
||||
publisher = {Butterworth-Heinemann},
|
||||
address = {Burlington},
|
||||
pages = {3-18},
|
||||
year = {2007},
|
||||
isbn = {978-0-7506-7796-7},
|
||||
doi = {https://doi.org/10.1016/B978-075067796-7/50023-4},
|
||||
url = {https://www.sciencedirect.com/science/article/pii/B9780750677967500234},
|
||||
author = {Colleen McCue}
|
||||
13
procver/SnP/checklist
Normal file
13
procver/SnP/checklist
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
All figures/tables/code are referenced in the text, all references have a capital letter, all have an unbreakable space between the name and the ref.
|
||||
|
||||
All citations are properly formated. No weird spacing, all titles with the same case.
|
||||
|
||||
All figures work in black and white.
|
||||
|
||||
All captions are self sufficient and follow the same format.
|
||||
|
||||
All acronyms uses and acronym manager package.
|
||||
|
||||
There is no two heading without text between them.
|
||||
|
||||
There is no more footnote review comments.
|
||||
531
procver/SnP/images/ael_illustration.svg
Normal file
531
procver/SnP/images/ael_illustration.svg
Normal file
|
|
@ -0,0 +1,531 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!-- Created with Inkscape (http://www.inkscape.org/) -->
|
||||
|
||||
<svg
|
||||
width="349.6778mm"
|
||||
height="101.18298mm"
|
||||
viewBox="0 0 349.6778 101.18298"
|
||||
version="1.1"
|
||||
id="svg1"
|
||||
inkscape:version="1.4.1 (93de688d07, 2025-03-30)"
|
||||
sodipodi:docname="ael_illustration.svg"
|
||||
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
|
||||
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
xmlns:svg="http://www.w3.org/2000/svg">
|
||||
<sodipodi:namedview
|
||||
id="namedview1"
|
||||
pagecolor="#ffffff"
|
||||
bordercolor="#eeeeee"
|
||||
borderopacity="1"
|
||||
inkscape:showpageshadow="0"
|
||||
inkscape:pageopacity="0"
|
||||
inkscape:pagecheckerboard="0"
|
||||
inkscape:deskcolor="#505050"
|
||||
inkscape:document-units="mm"
|
||||
inkscape:zoom="0.72426347"
|
||||
inkscape:cx="577.8284"
|
||||
inkscape:cy="399.71642"
|
||||
inkscape:window-width="1920"
|
||||
inkscape:window-height="1022"
|
||||
inkscape:window-x="0"
|
||||
inkscape:window-y="0"
|
||||
inkscape:window-maximized="1"
|
||||
inkscape:current-layer="layer1" />
|
||||
<defs
|
||||
id="defs1">
|
||||
<inkscape:path-effect
|
||||
effect="tiling"
|
||||
id="path-effect41"
|
||||
is_visible="true"
|
||||
lpeversion="1.3.1"
|
||||
unit="px"
|
||||
seed="1;1"
|
||||
lpesatellites=""
|
||||
num_rows="1"
|
||||
num_cols="26"
|
||||
gapx="15"
|
||||
gapy="0"
|
||||
offset="0"
|
||||
offset_type="false"
|
||||
scale="0"
|
||||
rotate="0"
|
||||
mirrorrowsx="false"
|
||||
mirrorrowsy="false"
|
||||
mirrorcolsx="false"
|
||||
mirrorcolsy="false"
|
||||
mirrortrans="false"
|
||||
shrink_interp="false"
|
||||
split_items="false"
|
||||
link_styles="false"
|
||||
interpolate_scalex="false"
|
||||
interpolate_scaley="true"
|
||||
interpolate_rotatex="false"
|
||||
interpolate_rotatey="true"
|
||||
random_scale="false"
|
||||
random_rotate="false"
|
||||
random_gap_y="false"
|
||||
random_gap_x="false"
|
||||
transformorigin="" />
|
||||
<marker
|
||||
style="overflow:visible"
|
||||
id="Triangle"
|
||||
refX="0"
|
||||
refY="0"
|
||||
orient="auto-start-reverse"
|
||||
inkscape:stockid="Triangle arrow"
|
||||
markerWidth="1.5"
|
||||
markerHeight="1.5"
|
||||
viewBox="0 0 1 1"
|
||||
inkscape:isstock="true"
|
||||
inkscape:collect="always"
|
||||
preserveAspectRatio="xMidYMid">
|
||||
<path
|
||||
transform="scale(0.5)"
|
||||
style="fill:context-stroke;fill-rule:evenodd;stroke:context-stroke;stroke-width:1pt"
|
||||
d="M 5.77,0 -2.88,5 V -5 Z"
|
||||
id="path135" />
|
||||
</marker>
|
||||
<marker
|
||||
style="overflow:visible"
|
||||
id="marker19"
|
||||
refX="0"
|
||||
refY="0"
|
||||
orient="auto-start-reverse"
|
||||
inkscape:stockid="Wide arrow"
|
||||
markerWidth="1"
|
||||
markerHeight="1"
|
||||
viewBox="0 0 1 1"
|
||||
inkscape:isstock="true"
|
||||
inkscape:collect="always"
|
||||
preserveAspectRatio="xMidYMid">
|
||||
<path
|
||||
style="fill:none;stroke:context-stroke;stroke-width:1;stroke-linecap:butt"
|
||||
d="M 3,-3 0,0 3,3"
|
||||
transform="rotate(180,0.125,0)"
|
||||
sodipodi:nodetypes="ccc"
|
||||
id="path19" />
|
||||
</marker>
|
||||
<marker
|
||||
style="overflow:visible"
|
||||
id="ArrowWide"
|
||||
refX="0"
|
||||
refY="0"
|
||||
orient="auto-start-reverse"
|
||||
inkscape:stockid="Wide arrow"
|
||||
markerWidth="1"
|
||||
markerHeight="1"
|
||||
viewBox="0 0 1 1"
|
||||
inkscape:isstock="true"
|
||||
inkscape:collect="always"
|
||||
preserveAspectRatio="xMidYMid">
|
||||
<path
|
||||
style="fill:none;stroke:context-stroke;stroke-width:1;stroke-linecap:butt"
|
||||
d="M 3,-3 0,0 3,3"
|
||||
transform="rotate(180,0.125,0)"
|
||||
sodipodi:nodetypes="ccc"
|
||||
id="path18" />
|
||||
</marker>
|
||||
<inkscape:path-effect
|
||||
effect="tiling"
|
||||
id="path-effect5"
|
||||
is_visible="true"
|
||||
lpeversion="1.3.1"
|
||||
unit="px"
|
||||
seed="1;1"
|
||||
lpesatellites=""
|
||||
num_rows="1"
|
||||
num_cols="56"
|
||||
gapx="7"
|
||||
gapy="0"
|
||||
offset="0"
|
||||
offset_type="false"
|
||||
scale="0"
|
||||
rotate="0"
|
||||
mirrorrowsx="false"
|
||||
mirrorrowsy="false"
|
||||
mirrorcolsx="false"
|
||||
mirrorcolsy="false"
|
||||
mirrortrans="false"
|
||||
shrink_interp="false"
|
||||
split_items="false"
|
||||
link_styles="false"
|
||||
interpolate_scalex="false"
|
||||
interpolate_scaley="true"
|
||||
interpolate_rotatex="false"
|
||||
interpolate_rotatey="true"
|
||||
random_scale="false"
|
||||
random_rotate="false"
|
||||
random_gap_y="false"
|
||||
random_gap_x="false"
|
||||
transformorigin="" />
|
||||
</defs>
|
||||
<g
|
||||
inkscape:label="Layer 1"
|
||||
inkscape:groupmode="layer"
|
||||
id="layer1"
|
||||
transform="translate(7.6715867,-14.612546)">
|
||||
<path
|
||||
style="fill:none;stroke:#999999;stroke-width:0.4;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:3.2, 0.4;stroke-dashoffset:0"
|
||||
d="M 7.068815,78.882337 H 166.8519"
|
||||
id="path7"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<path
|
||||
style="fill:none;stroke:#808080;stroke-width:0.746001;stroke-linecap:butt;stroke-linejoin:round"
|
||||
d="M 7.068815,101.29964 V 43.116742"
|
||||
id="path1"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<path
|
||||
style="fill:none;stroke:#808080;stroke-width:0.746001;stroke-linecap:butt;stroke-linejoin:round"
|
||||
d="M 4.471481,99.074395 H 142.27195"
|
||||
id="path2" />
|
||||
<path
|
||||
style="fill:none;stroke:#808080;stroke-width:0.746001;stroke-linecap:butt;stroke-linejoin:round"
|
||||
d="M 217.6747,99.838389 V 41.462177"
|
||||
id="path3"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<path
|
||||
style="fill:none;stroke:#808080;stroke-width:0.746001;stroke-linecap:butt;stroke-linejoin:round"
|
||||
d="M 215.63951,98.094758 H 323.6155"
|
||||
id="path4" />
|
||||
<path
|
||||
style="fill:none;stroke:#0000ff;stroke-width:0.4;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none"
|
||||
d="m 10.200644,96.02498 2.363655,-0.329666 2.363654,0.659335 2.363655,-0.989 2.363655,-20.933804 h 2.363655 l 2.363654,1.379641 2.363656,-2.972144 2.363655,1.592503 2.363654,21.834975 2.363654,-0.466218 2.363656,0.466218 2.363655,-2.680757 2.363654,-0.524495 2.363656,-2.389369 2.363654,2.156259 2.363655,-0.699329 2.363655,3.788028 2.363655,0.116557 2.363654,-0.932438 2.363656,-42.77554 2.363654,25.292349 2.363655,-17.483193 2.363655,1.748322 2.363655,0.116556 2.363654,2.214536 2.363655,31.236634 2.363656,-0.582773 2.363654,0.815883 2.363654,-1.165545 2.363656,0.699328 2.363655,-0.815884 2.363654,-19.9701 h 2.363656 l 2.363654,2.603464 2.363655,-2.603464 2.363655,-1.417669 2.363655,1.417669 2.363657,20.727707 2.36365,-0.291389 2.36366,0.466221 2.36365,0.116557 2.36366,-1.223823 2.36366,-19.795268 h 2.36365 l 2.36366,20.669429 2.36365,-2.797311 2.36365,-0.990712 2.36366,2.097982 2.36365,-2.039705 2.36366,1.223823 2.36366,3.554913 2.36365,-0.874158 2.36365,-0.349665 2.36366,-1.282101 2.36365,0.990716"
|
||||
id="path6" />
|
||||
<path
|
||||
style="opacity:0.202361;fill:none;stroke:#000000;stroke-width:0.3;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
d="M 19.266465,49.616466 V 78.627094"
|
||||
id="path8"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<path
|
||||
style="opacity:0.202361;fill:none;stroke:#000000;stroke-width:0.3;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
d="M 29.591652,49.616466 V 78.627094"
|
||||
id="path10"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<path
|
||||
style="opacity:0.202361;fill:none;stroke:#000000;stroke-width:0.3;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
d="M 56.006298,49.616466 V 78.627094"
|
||||
id="path11"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<path
|
||||
style="opacity:0.202361;fill:none;stroke:#000000;stroke-width:0.3;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
d="M 70.401934,49.616466 V 78.627094"
|
||||
id="path12"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<path
|
||||
style="opacity:0.202361;fill:none;stroke:#000000;stroke-width:0.3;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
d="M 85.310839,49.616466 V 78.627094"
|
||||
id="path13"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<path
|
||||
style="opacity:0.202361;fill:none;stroke:#000000;stroke-width:0.3;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
d="M 98.163377,49.616466 V 78.627094"
|
||||
id="path14"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<path
|
||||
style="opacity:0.202361;fill:none;stroke:#000000;stroke-width:0.3;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
d="M 111.3064,49.616466 V 78.627094"
|
||||
id="path15"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<path
|
||||
style="opacity:0.202361;fill:none;stroke:#000000;stroke-width:0.3;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
d="M 114.7104,49.616466 V 78.627094"
|
||||
id="path16"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-size:4.95243px;line-height:6.15903px;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Medium';text-align:start;letter-spacing:0px;writing-mode:lr-tb;direction:ltr;text-anchor:start;fill:#ff7f2a;fill-opacity:1;stroke:none;stroke-width:0.3;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
x="169.04597"
|
||||
y="80.558311"
|
||||
id="text16"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan16"
|
||||
style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-size:4.95243px;line-height:6.15903px;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Medium';fill:#ff7f2a;fill-opacity:1;stroke:none;stroke-width:0.3"
|
||||
x="169.04597"
|
||||
y="80.558311">Threshold</tspan></text>
|
||||
<path
|
||||
style="opacity:0.202361;fill:none;stroke:#000000;stroke-width:0.200001;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0;marker-start:url(#ArrowWide);marker-end:url(#marker19)"
|
||||
d="M 19.266465,47.020343 H 29.591652"
|
||||
id="path17" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-size:4.95243px;line-height:6.15905px;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Medium';text-align:start;letter-spacing:0px;writing-mode:lr-tb;direction:ltr;text-anchor:start;opacity:1;fill:#000000;stroke:none;stroke-width:0.200001;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
x="23.057627"
|
||||
y="44.432217"
|
||||
id="text19"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan19"
|
||||
style="fill:#000000;stroke:none;stroke-width:0.200001"
|
||||
x="23.057627"
|
||||
y="44.432217">2</tspan></text>
|
||||
<path
|
||||
style="opacity:0.202361;fill:none;stroke:#000000;stroke-width:0.200001;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0;marker-start:url(#ArrowWide);marker-end:url(#marker19)"
|
||||
d="M 56.189081,47.020343 H 70.140596"
|
||||
id="path20"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-size:4.95243px;line-height:6.15905px;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Medium';text-align:start;letter-spacing:0px;writing-mode:lr-tb;direction:ltr;text-anchor:start;opacity:1;fill:#000000;stroke:none;stroke-width:0.200001;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
x="61.92915"
|
||||
y="44.432217"
|
||||
id="text20"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan20"
|
||||
style="fill:#000000;stroke:none;stroke-width:0.200001"
|
||||
x="61.92915"
|
||||
y="44.432217">3</tspan></text>
|
||||
<path
|
||||
style="opacity:0.202361;fill:none;stroke:#000000;stroke-width:0.200001;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0;marker-start:url(#ArrowWide);marker-end:url(#marker19)"
|
||||
d="M 85.611791,47.020343 H 97.902403"
|
||||
id="path21"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-size:4.95243px;line-height:6.15905px;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Medium';text-align:start;letter-spacing:0px;writing-mode:lr-tb;direction:ltr;text-anchor:start;opacity:1;fill:#000000;stroke:none;stroke-width:0.200001;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
x="88.875069"
|
||||
y="44.432217"
|
||||
id="text21"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan21"
|
||||
style="fill:#000000;stroke:none;stroke-width:0.200001"
|
||||
x="88.875069"
|
||||
y="44.432217">2.5</tspan></text>
|
||||
<path
|
||||
style="opacity:0.202361;fill:none;stroke:#000000;stroke-width:0.200001;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0;marker-start:url(#ArrowWide);marker-end:url(#marker19)"
|
||||
d="m 111.31208,47.020343 h 3.2285"
|
||||
id="path22"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-size:4.95243px;line-height:6.15905px;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Medium';text-align:start;letter-spacing:0px;writing-mode:lr-tb;direction:ltr;text-anchor:start;opacity:1;fill:#000000;stroke:none;stroke-width:0.200001;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
x="111.77805"
|
||||
y="44.432217"
|
||||
id="text22"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan22"
|
||||
style="fill:#000000;stroke:none;stroke-width:0.200001"
|
||||
x="111.77805"
|
||||
y="44.432217">1</tspan></text>
|
||||
<circle
|
||||
style="opacity:1;fill:none;stroke:#000000;stroke-width:0.499999;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
id="path24"
|
||||
cx="245.11917"
|
||||
cy="58.49585"
|
||||
r="1.6895757" />
|
||||
<path
|
||||
style="opacity:1;fill:none;stroke:#ff7f2a;stroke-width:0.499999;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:1.5, 1.5;stroke-dashoffset:0"
|
||||
d="m 245.11918,61.735318 v 38.16765"
|
||||
id="path25"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<path
|
||||
style="opacity:1;fill:none;stroke:#cc00ff;stroke-width:0.499999;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:1.5, 1.5;stroke-dashoffset:0"
|
||||
d="M 241.75858,58.495849 H 215.80855"
|
||||
id="path26"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-size:3.60176px;line-height:4.47931px;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Medium';text-align:start;letter-spacing:0px;writing-mode:lr-tb;direction:ltr;text-anchor:start;opacity:1;fill:#000000;stroke:none;stroke-width:0.499999;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
x="167.82986"
|
||||
y="43.970543"
|
||||
id="text26"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan26"
|
||||
style="font-size:3.60176px;line-height:4.47931px;fill:#000000;stroke:none;stroke-width:0.5;stroke-dasharray:none"
|
||||
x="167.82986"
|
||||
y="43.970543" /><tspan
|
||||
sodipodi:role="line"
|
||||
style="font-size:3.60176px;line-height:4.47931px;fill:#000000;stroke:none;stroke-width:0.5;stroke-dasharray:none"
|
||||
x="167.82986"
|
||||
y="48.449852"
|
||||
id="tspan31">Avg</tspan><tspan
|
||||
sodipodi:role="line"
|
||||
style="font-size:3.60176px;line-height:4.47931px;fill:#000000;stroke:none;stroke-width:0.5;stroke-dasharray:none"
|
||||
x="167.82986"
|
||||
y="52.929165"
|
||||
id="tspan27">Med</tspan><tspan
|
||||
sodipodi:role="line"
|
||||
style="font-size:3.60176px;line-height:4.47931px;fill:#000000;stroke:none;stroke-width:0.5;stroke-dasharray:none"
|
||||
x="167.82986"
|
||||
y="57.408474"
|
||||
id="tspan28">Max</tspan><tspan
|
||||
sodipodi:role="line"
|
||||
style="font-size:3.60176px;line-height:4.47931px;fill:#000000;stroke:none;stroke-width:0.5;stroke-dasharray:none"
|
||||
x="167.82986"
|
||||
y="61.887783"
|
||||
id="tspan30">Min</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-size:4.95243px;line-height:6.15905px;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Medium';text-align:start;letter-spacing:0px;writing-mode:lr-tb;direction:ltr;text-anchor:start;opacity:1;fill:#cc00ff;fill-opacity:1;stroke:none;stroke-width:0.499999;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
x="161.71469"
|
||||
y="43.362156"
|
||||
id="text32"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan32"
|
||||
style="fill:#cc00ff;fill-opacity:1;stroke-width:0.5"
|
||||
x="161.71469"
|
||||
y="43.362156">Aggregation</tspan></text>
|
||||
<path
|
||||
style="opacity:1;fill:none;stroke:#000000;stroke-width:0.200001;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
d="M 166.80902,45.051558 V 62.812326"
|
||||
id="path32"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-size:5.85286px;line-height:7.27885px;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Medium';text-align:start;letter-spacing:0px;writing-mode:lr-tb;direction:ltr;text-anchor:start;opacity:1;fill:#000000;stroke:none;stroke-width:0.200001;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
x="14.980807"
|
||||
y="43.937721"
|
||||
id="text33"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan33"
|
||||
style="font-size:5.85286px;line-height:7.27885px;fill:#000000;stroke:none;stroke-width:0.200001"
|
||||
x="14.980807"
|
||||
y="43.937721">(</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-size:5.85286px;line-height:7.27885px;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Medium';text-align:start;letter-spacing:0px;writing-mode:lr-tb;direction:ltr;text-anchor:start;opacity:1;fill:#000000;stroke:none;stroke-width:0.200001;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
x="119.32017"
|
||||
y="43.937721"
|
||||
id="text34"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan34"
|
||||
style="font-size:5.85286px;line-height:7.27885px;fill:#000000;stroke:none;stroke-width:0.200001"
|
||||
x="119.32017"
|
||||
y="43.937721">)</tspan></text>
|
||||
<path
|
||||
style="opacity:1;fill:#000000;stroke:#000000;stroke-width:0.200001;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0;marker-end:url(#Triangle)"
|
||||
d="m 121.73002,42.360314 h 34.82826"
|
||||
id="path34"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<path
|
||||
style="opacity:1;fill:none;fill-opacity:1;stroke:#ff7f2a;stroke-width:0.2;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#Triangle)"
|
||||
d="m 181.8543,82.509725 c 2.51098,33.463385 54.00084,29.234555 60.57504,19.115365"
|
||||
id="path35"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<path
|
||||
style="opacity:1;fill:none;fill-opacity:1;stroke:#cc00ff;stroke-width:0.2;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#Triangle)"
|
||||
d="m 189.70854,42.548398 c 11.5525,0.03719 13.34672,12.091892 24.4063,15.412535"
|
||||
id="path36"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<rect
|
||||
style="opacity:1;fill:none;fill-opacity:1;stroke:#000000;stroke-width:0.2;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
|
||||
id="rect36"
|
||||
width="146.98166"
|
||||
height="75.686523"
|
||||
x="2.0665262"
|
||||
y="30.588257"
|
||||
ry="3.1483846" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-size:6.98191px;line-height:8.68299px;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Medium';text-align:start;letter-spacing:0px;writing-mode:lr-tb;direction:ltr;text-anchor:start;opacity:1;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.2;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
|
||||
x="6.6319842"
|
||||
y="28.727407"
|
||||
id="text36"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan36"
|
||||
style="fill:#000000;stroke:none;stroke-width:0.2"
|
||||
x="6.6319842"
|
||||
y="28.727407">Residuals</tspan></text>
|
||||
<rect
|
||||
style="opacity:1;fill:none;fill-opacity:1;stroke:#000000;stroke-width:0.2;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
|
||||
id="rect37"
|
||||
width="116.75873"
|
||||
height="75.686523"
|
||||
x="210.78566"
|
||||
y="30.588257"
|
||||
ry="3.1483846" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-size:6.98191px;line-height:8.68299px;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Medium';text-align:start;letter-spacing:0px;writing-mode:lr-tb;direction:ltr;text-anchor:start;opacity:1;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.2;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
|
||||
x="213.54291"
|
||||
y="28.727407"
|
||||
id="text37"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan37"
|
||||
style="fill:#000000;stroke:none;stroke-width:0.2"
|
||||
x="213.54291"
|
||||
y="28.727407">Aggregated Error Length (AEL)</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-size:4.95243px;line-height:6.15903px;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Medium';text-align:start;letter-spacing:0px;writing-mode:lr-tb;direction:ltr;text-anchor:start;fill:#ff7f2a;fill-opacity:1;stroke:none;stroke-width:0.3;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
x="302.56812"
|
||||
y="103.75573"
|
||||
id="text38"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan38"
|
||||
style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-size:4.95243px;line-height:6.15903px;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Medium';fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.3"
|
||||
x="302.56812"
|
||||
y="103.75573">Threshold</tspan></text>
|
||||
<circle
|
||||
style="opacity:1;fill:none;stroke:#b3b3b3;stroke-width:0.499999;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
id="circle42"
|
||||
cx="237.18169"
|
||||
cy="53.112087"
|
||||
r="1.6895757" />
|
||||
<circle
|
||||
style="opacity:1;fill:none;stroke:#b3b3b3;stroke-width:0.499999;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
id="circle43"
|
||||
cx="229.24419"
|
||||
cy="50.4179"
|
||||
r="1.6895757" />
|
||||
<circle
|
||||
style="opacity:1;fill:none;stroke:#b3b3b3;stroke-width:0.499999;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
id="circle44"
|
||||
cx="221.30669"
|
||||
cy="44.070576"
|
||||
r="1.6895757" />
|
||||
<circle
|
||||
style="opacity:1;fill:none;stroke:#b3b3b3;stroke-width:0.499999;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
id="circle45"
|
||||
cx="253.05669"
|
||||
cy="67.689087"
|
||||
r="1.6895757" />
|
||||
<circle
|
||||
style="opacity:1;fill:none;stroke:#b3b3b3;stroke-width:0.499999;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
id="circle46"
|
||||
cx="260.99417"
|
||||
cy="77.246773"
|
||||
r="1.6895757" />
|
||||
<circle
|
||||
style="opacity:1;fill:none;stroke:#b3b3b3;stroke-width:0.499999;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
id="circle47"
|
||||
cx="268.93167"
|
||||
cy="83.91375"
|
||||
r="1.6895757" />
|
||||
<circle
|
||||
style="opacity:1;fill:none;stroke:#b3b3b3;stroke-width:0.499999;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
id="circle48"
|
||||
cx="276.86917"
|
||||
cy="87.658218"
|
||||
r="1.6895757" />
|
||||
<circle
|
||||
style="opacity:1;fill:none;stroke:#b3b3b3;stroke-width:0.499999;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
id="circle49"
|
||||
cx="284.80667"
|
||||
cy="88.023529"
|
||||
r="1.6895757" />
|
||||
<circle
|
||||
style="opacity:1;fill:none;stroke:#b3b3b3;stroke-width:0.499999;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
id="circle50"
|
||||
cx="292.74417"
|
||||
cy="88.754158"
|
||||
r="1.6895757" />
|
||||
<circle
|
||||
style="opacity:1;fill:none;stroke:#b3b3b3;stroke-width:0.499999;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
id="circle51"
|
||||
cx="300.68167"
|
||||
cy="91.448349"
|
||||
r="1.6895757" />
|
||||
<circle
|
||||
style="opacity:1;fill:none;stroke:#b3b3b3;stroke-width:0.499999;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
id="circle52"
|
||||
cx="308.61917"
|
||||
cy="91.494011"
|
||||
r="1.6895757" />
|
||||
<circle
|
||||
style="opacity:1;fill:none;stroke:#b3b3b3;stroke-width:0.499999;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
id="circle53"
|
||||
cx="316.55667"
|
||||
cy="91.631004"
|
||||
r="1.6895757" />
|
||||
</g>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 26 KiB |
File diff suppressed because it is too large
Load diff
|
Before Width: | Height: | Size: 78 KiB After Width: | Height: | Size: 137 KiB |
BIN
procver/SnP/images/collection_pipeline_small.png
Normal file
BIN
procver/SnP/images/collection_pipeline_small.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 24 KiB |
1251
procver/SnP/images/model.svg
Normal file
1251
procver/SnP/images/model.svg
Normal file
File diff suppressed because it is too large
Load diff
|
After Width: | Height: | Size: 67 KiB |
1162
procver/SnP/images/proposed_approach_overview.svg
Normal file
1162
procver/SnP/images/proposed_approach_overview.svg
Normal file
File diff suppressed because it is too large
Load diff
|
After Width: | Height: | Size: 67 KiB |
592
procver/SnP/images/related_work.svg
Normal file
592
procver/SnP/images/related_work.svg
Normal file
|
|
@ -0,0 +1,592 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!-- Created with Inkscape (http://www.inkscape.org/) -->
|
||||
|
||||
<svg
|
||||
width="792.42957mm"
|
||||
height="259.8837mm"
|
||||
viewBox="0 0 792.42956 259.88371"
|
||||
version="1.1"
|
||||
id="svg5"
|
||||
inkscape:version="1.4.1 (93de688d07, 2025-03-30)"
|
||||
xml:space="preserve"
|
||||
sodipodi:docname="related_work.svg"
|
||||
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
|
||||
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
xmlns:svg="http://www.w3.org/2000/svg"><sodipodi:namedview
|
||||
id="namedview7"
|
||||
pagecolor="#ffffff"
|
||||
bordercolor="#000000"
|
||||
borderopacity="1"
|
||||
inkscape:showpageshadow="0"
|
||||
inkscape:pageopacity="0"
|
||||
inkscape:pagecheckerboard="0"
|
||||
inkscape:deskcolor="#b5b5b5"
|
||||
inkscape:document-units="mm"
|
||||
showgrid="false"
|
||||
inkscape:zoom="2.7891246"
|
||||
inkscape:cx="1683.6824"
|
||||
inkscape:cy="281.98812"
|
||||
inkscape:window-width="1920"
|
||||
inkscape:window-height="1022"
|
||||
inkscape:window-x="0"
|
||||
inkscape:window-y="0"
|
||||
inkscape:window-maximized="1"
|
||||
inkscape:current-layer="layer1"><inkscape:page
|
||||
x="0"
|
||||
y="0"
|
||||
width="792.42957"
|
||||
height="259.8837"
|
||||
id="page1"
|
||||
margin="0"
|
||||
bleed="0" /></sodipodi:namedview><defs
|
||||
id="defs2"><marker
|
||||
style="overflow:visible"
|
||||
id="Dot"
|
||||
refX="0"
|
||||
refY="0"
|
||||
orient="auto"
|
||||
inkscape:stockid="Dot"
|
||||
markerWidth="1"
|
||||
markerHeight="1"
|
||||
viewBox="0 0 1 1"
|
||||
inkscape:isstock="true"
|
||||
inkscape:collect="always"
|
||||
preserveAspectRatio="xMidYMid"><path
|
||||
transform="scale(0.5)"
|
||||
style="fill:context-stroke;fill-rule:evenodd;stroke:none"
|
||||
d="M 5,0 C 5,2.76 2.76,5 0,5 -2.76,5 -5,2.76 -5,0 c 0,-2.76 2.3,-5 5,-5 2.76,0 5,2.24 5,5 z"
|
||||
sodipodi:nodetypes="sssss"
|
||||
id="path17" /></marker><marker
|
||||
style="overflow:visible"
|
||||
id="Triangle"
|
||||
refX="0"
|
||||
refY="0"
|
||||
orient="auto-start-reverse"
|
||||
inkscape:stockid="Triangle arrow"
|
||||
markerWidth="1"
|
||||
markerHeight="1"
|
||||
viewBox="0 0 1 1"
|
||||
inkscape:isstock="true"
|
||||
inkscape:collect="always"
|
||||
preserveAspectRatio="xMidYMid"><path
|
||||
transform="scale(0.5)"
|
||||
style="fill:context-stroke;fill-rule:evenodd;stroke:context-stroke;stroke-width:1pt"
|
||||
d="M 5.77,0 -2.88,5 V -5 Z"
|
||||
id="path135" /></marker></defs><g
|
||||
inkscape:label="Layer 1"
|
||||
inkscape:groupmode="layer"
|
||||
id="layer1"
|
||||
transform="translate(224.10697,45.791336)"><circle
|
||||
style="fill:#e6e6e6;fill-opacity:1;stroke:#000000;stroke-width:1;stroke-linejoin:round;stroke-dasharray:none"
|
||||
id="path87"
|
||||
cx="-328.62012"
|
||||
cy="299.08551"
|
||||
r="59.431034"
|
||||
transform="rotate(-135)" /><circle
|
||||
style="fill:#999999;fill-opacity:1;stroke:#000000;stroke-width:1;stroke-linejoin:round;stroke-dasharray:none"
|
||||
id="path78"
|
||||
cx="-336.25137"
|
||||
cy="291.13647"
|
||||
r="42.21381"
|
||||
transform="rotate(-135)" /><path
|
||||
style="fill:none;stroke:#000000;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#Triangle)"
|
||||
d="M -215.89073,87.23208 H 286.59341"
|
||||
id="path1"
|
||||
sodipodi:nodetypes="cc" /><text
|
||||
xml:space="preserve"
|
||||
style="font-size:3.88056px;line-height:1.25;font-family:'Monaspace Neon Var';-inkscape-font-specification:'Monaspace Neon Var';letter-spacing:-0.291042px;word-spacing:0px;stroke-width:0.264583"
|
||||
x="327.862"
|
||||
y="71.679672"
|
||||
id="text36"><tspan
|
||||
sodipodi:role="line"
|
||||
style="stroke-width:0.264583"
|
||||
x="327.862"
|
||||
y="71.679672"
|
||||
id="tspan37" /></text><path
|
||||
id="path3"
|
||||
style="color:#000000;fill:#000000;-inkscape-stroke:none"
|
||||
d="m -147.72485,67.47964 v 15.777332 c -1.83131,0.128657 -3.28145,1.657668 -3.28145,3.521228 0,1.94765 1.5834,3.53157 3.53105,3.53157 1.94765,0 3.53156,-1.58392 3.53156,-3.53157 0,-1.86356 -1.45014,-3.392571 -3.28145,-3.521228 V 67.47964 Z m 0.2496,16.267224 c 1.67743,0 3.03134,1.353906 3.03134,3.031336 0,1.67743 -1.35391,3.03134 -3.03134,3.03134 -1.67743,0 -3.03082,-1.35391 -3.03082,-3.03134 0,-1.67743 1.35339,-3.031336 3.03082,-3.031336 z" /><text
|
||||
xml:space="preserve"
|
||||
style="font-size:3.88056px;line-height:1.25;font-family:'Monaspace Neon Var';-inkscape-font-specification:'Monaspace Neon Var';letter-spacing:-0.291042px;word-spacing:0px;stroke-width:0.264583"
|
||||
x="-151.82608"
|
||||
y="66.915802"
|
||||
id="text50"><tspan
|
||||
id="tspan50"
|
||||
style="stroke-width:0.264583"
|
||||
x="-151.82608"
|
||||
y="66.915802"
|
||||
sodipodi:role="line">1969</tspan></text><rect
|
||||
style="fill:#cccccc;fill-opacity:1;stroke:#1a1a1a;stroke-width:0.577775;stroke-dasharray:none;stroke-opacity:1"
|
||||
id="rect50"
|
||||
width="56.265244"
|
||||
height="25.585007"
|
||||
x="-173.95004"
|
||||
y="37.277485"
|
||||
ry="1.3401735" /><text
|
||||
xml:space="preserve"
|
||||
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:2.11667px;line-height:1.25;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono';letter-spacing:-0.291042px;word-spacing:0px;white-space:pre;inline-size:54.6704;display:inline;stroke-width:0.264583"
|
||||
x="190.02438"
|
||||
y="196.82707"
|
||||
id="text81"
|
||||
transform="translate(-362.699,-146.55585)"><tspan
|
||||
x="190.02438"
|
||||
y="196.82707"
|
||||
id="tspan44">Invented the term "Covert Channel".
|
||||
</tspan><tspan
|
||||
x="190.02438"
|
||||
y="199.47292"
|
||||
id="tspan45">This is though of in the case of programms </tspan><tspan
|
||||
x="190.02438"
|
||||
y="202.11876"
|
||||
id="tspan46">communicating on the same machine. It is the early days </tspan><tspan
|
||||
x="190.02438"
|
||||
y="204.7646"
|
||||
id="tspan47">of the idea of covert channels in computer science.</tspan></text><rect
|
||||
style="fill:#ffc6a0;fill-opacity:1;stroke:#ff6803;stroke-width:0.577775;stroke-dasharray:none;stroke-opacity:1"
|
||||
id="rect81"
|
||||
width="56.26524"
|
||||
height="10.447671"
|
||||
x="-173.95004"
|
||||
y="37.277485"
|
||||
ry="1.3401735" /><text
|
||||
xml:space="preserve"
|
||||
style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:3.88056px;line-height:1.25;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono Bold';letter-spacing:-0.291042px;word-spacing:0px;white-space:pre;inline-size:88.3485;display:inline;stroke-width:0.264583"
|
||||
x="320.76639"
|
||||
y="166.06209"
|
||||
id="text82"
|
||||
transform="matrix(0.72076737,0,0,0.72076737,-402.47872,-76.749177)"><tspan
|
||||
x="320.76639"
|
||||
y="166.06209"
|
||||
id="tspan48">A note on the confinement problem</tspan></text><text
|
||||
xml:space="preserve"
|
||||
style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:16.9333px;line-height:21.059px;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono Bold';text-align:center;letter-spacing:0px;writing-mode:lr-tb;direction:ltr;text-anchor:middle;fill:#000000;stroke:none;stroke-width:0.746001;stroke-linecap:round;stroke-linejoin:round"
|
||||
x="-184.64418"
|
||||
y="-28.716087"
|
||||
id="text83"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan83"
|
||||
style="stroke:none;stroke-width:0.746"
|
||||
x="-184.64418"
|
||||
y="-28.716087">General</tspan></text><text
|
||||
xml:space="preserve"
|
||||
style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:16.9333px;line-height:21.059px;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono Bold';text-align:start;letter-spacing:0px;writing-mode:lr-tb;direction:ltr;text-anchor:start;fill:#000000;stroke:none;stroke-width:0.746001;stroke-linecap:round;stroke-linejoin:round"
|
||||
x="-220.59908"
|
||||
y="210.33742"
|
||||
id="text84"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan84"
|
||||
style="text-align:start;text-anchor:start;stroke:none;stroke-width:0.746"
|
||||
x="-220.59908"
|
||||
y="210.33742">Specific</tspan></text><path
|
||||
id="path84"
|
||||
style="color:#000000;fill:#000000;-inkscape-stroke:none"
|
||||
d="M 202.50751,106.54263 V 90.76529 c -1.83131,-0.12865 -3.28145,-1.65766 -3.28145,-3.52122 0,-1.94765 1.5834,-3.531573 3.53105,-3.531573 1.94765,0 3.53156,1.583923 3.53156,3.531573 0,1.86356 -1.45014,3.39257 -3.28145,3.52122 v 15.77734 z m 0.2496,-16.26723 c 1.67743,0 3.03134,-1.3539 3.03134,-3.03133 0,-1.67743 -1.35391,-3.031343 -3.03134,-3.031343 -1.67743,0 -3.03082,1.353913 -3.03082,3.031343 0,1.67743 1.35339,3.03133 3.03082,3.03133 z" /><text
|
||||
xml:space="preserve"
|
||||
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:3.88056px;line-height:1.25;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono';letter-spacing:-0.291042px;word-spacing:0px;stroke-width:0.264583"
|
||||
x="198.40628"
|
||||
y="110.24815"
|
||||
id="text85"><tspan
|
||||
id="tspan85"
|
||||
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono';stroke-width:0.264583"
|
||||
x="198.40628"
|
||||
y="110.24815"
|
||||
sodipodi:role="line">2008</tspan></text><rect
|
||||
style="fill:#cccccc;fill-opacity:1;stroke:#1a1a1a;stroke-width:0.577775;stroke-dasharray:none;stroke-opacity:1"
|
||||
id="rect85"
|
||||
width="56.265244"
|
||||
height="90.850403"
|
||||
x="176.28232"
|
||||
y="111.3315"
|
||||
ry="1.3401735" /><rect
|
||||
style="fill:#ffc6a0;fill-opacity:1;stroke:#ff6803;stroke-width:0.577775;stroke-dasharray:none;stroke-opacity:1"
|
||||
id="rect90"
|
||||
width="59.49057"
|
||||
height="11.870605"
|
||||
x="174.66965"
|
||||
y="111.3315"
|
||||
ry="1.3401735" /><text
|
||||
xml:space="preserve"
|
||||
style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:3.88056px;line-height:1.25;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono Bold';letter-spacing:-0.291042px;word-spacing:0px;white-space:pre;inline-size:78.7407;display:inline;stroke-width:0.264583"
|
||||
x="320.76639"
|
||||
y="166.06209"
|
||||
id="text91"
|
||||
transform="matrix(0.72076737,0,0,0.72076737,-54.807652,-4.4026833)"><tspan
|
||||
x="320.76639"
|
||||
y="166.06209"
|
||||
id="tspan49">Implicit Detection of Hidden Processes </tspan><tspan
|
||||
x="320.76639"
|
||||
y="170.91278"
|
||||
id="tspan51">with aFeather-Weight Hardware-Assisted </tspan><tspan
|
||||
x="320.76639"
|
||||
y="175.76347"
|
||||
id="tspan52">Virtual Machine Monitor</tspan></text><path
|
||||
id="path93"
|
||||
style="color:#000000;fill:#000000;-inkscape-stroke:none"
|
||||
d="M -6.7755952,106.54263 V 90.76529 c -1.83131,-0.12865 -3.2814498,-1.65766 -3.2814498,-3.52122 0,-1.94765 1.5833998,-3.531573 3.5310498,-3.531573 1.94765,0 3.53156,1.583923 3.53156,3.531573 0,1.86356 -1.45014,3.39257 -3.28145,3.52122 v 15.77734 z m 0.2496,-16.26723 c 1.67743,0 3.03134,-1.3539 3.03134,-3.03133 0,-1.67743 -1.35391,-3.031343 -3.03134,-3.031343 -1.67743,0 -3.03082,1.353913 -3.03082,3.031343 0,1.67743 1.35339,3.03133 3.03082,3.03133 z" /><text
|
||||
xml:space="preserve"
|
||||
style="font-size:3.88056px;line-height:1.25;font-family:'Monaspace Neon Var';-inkscape-font-specification:'Monaspace Neon Var';letter-spacing:-0.291042px;word-spacing:0px;stroke-width:0.264583"
|
||||
x="-10.876826"
|
||||
y="110.24815"
|
||||
id="text94"><tspan
|
||||
id="tspan94"
|
||||
style="stroke-width:0.264583"
|
||||
x="-10.876826"
|
||||
y="110.24815"
|
||||
sodipodi:role="line">1969</tspan></text><rect
|
||||
style="fill:#cccccc;fill-opacity:1;stroke:#1a1a1a;stroke-width:0.577775;stroke-dasharray:none;stroke-opacity:1"
|
||||
id="rect94"
|
||||
width="56.265244"
|
||||
height="25.585007"
|
||||
x="-33.00079"
|
||||
y="111.3315"
|
||||
ry="1.3401735" /><rect
|
||||
style="fill:#ffc6a0;fill-opacity:1;stroke:#ff6803;stroke-width:0.577775;stroke-dasharray:none;stroke-opacity:1"
|
||||
id="rect95"
|
||||
width="56.265244"
|
||||
height="11.870608"
|
||||
x="-33.00079"
|
||||
y="111.3315"
|
||||
ry="1.3401735" /><text
|
||||
xml:space="preserve"
|
||||
style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:3.88056px;line-height:1.25;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono Bold';letter-spacing:-0.291042px;word-spacing:0px;white-space:pre;inline-size:78.7407;display:inline;stroke-width:0.264583"
|
||||
x="320.76639"
|
||||
y="166.06209"
|
||||
id="text97"
|
||||
transform="matrix(0.72076737,0,0,0.72076737,-262.9524,-4.4026833)"><tspan
|
||||
x="320.76639"
|
||||
y="166.06209"
|
||||
id="tspan53">Microsoft / Kaspersky Reports on </tspan><tspan
|
||||
x="320.76639"
|
||||
y="170.91278"
|
||||
id="tspan54">rootkits</tspan></text><text
|
||||
xml:space="preserve"
|
||||
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:2.11667px;line-height:1.25;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono';letter-spacing:-0.291042px;word-spacing:0px;white-space:pre;inline-size:54.6704;display:inline;stroke-width:0.264583"
|
||||
x="190.02438"
|
||||
y="196.82707"
|
||||
id="text101"
|
||||
transform="translate(-12.552264,-70.087023)"><tspan
|
||||
x="190.02438"
|
||||
y="196.82707"
|
||||
id="tspan55">- Their solution affect the performance. Yes it is only </tspan><tspan
|
||||
x="190.02438"
|
||||
y="199.47292"
|
||||
id="tspan56">~5% but it is still a performance loss. Our solution </tspan><tspan
|
||||
x="190.02438"
|
||||
y="202.11876"
|
||||
id="tspan57">cannot affect the performance because the data </tspan><tspan
|
||||
x="190.02438"
|
||||
y="204.7646"
|
||||
id="tspan58">collection and analysis is separated.
|
||||
</tspan><tspan
|
||||
x="190.02438"
|
||||
y="207.41045"
|
||||
id="tspan59">- They claim to support "Dynamic OS migration" which </tspan><tspan
|
||||
x="190.02438"
|
||||
y="210.05629"
|
||||
id="tspan60">means the solution can be applied to an existing </tspan><tspan
|
||||
x="190.02438"
|
||||
y="212.70213"
|
||||
id="tspan61">running VM without restarting/recreating it. We also </tspan><tspan
|
||||
x="190.02438"
|
||||
y="215.34798"
|
||||
id="tspan62">have that and it seems like a desirable property so </tspan><tspan
|
||||
x="190.02438"
|
||||
y="217.99382"
|
||||
id="tspan63">let's mention it.
|
||||
</tspan><tspan
|
||||
x="190.02438"
|
||||
y="220.63967"
|
||||
id="tspan64">- They provide "non-bypassable interfaces" as a way for </tspan><tspan
|
||||
x="190.02438"
|
||||
y="223.28551"
|
||||
id="tspan65">the OS to communicate with the monitoring system and </tspan><tspan
|
||||
x="190.02438"
|
||||
y="225.93135"
|
||||
id="tspan66">retrieve the True Process List. They apparently use </tspan><tspan
|
||||
x="190.02438"
|
||||
y="228.5772"
|
||||
id="tspan67">very low level mechanisms specific to Intel processor </tspan><tspan
|
||||
x="190.02438"
|
||||
y="231.22304"
|
||||
id="tspan68">to establish this communication but I am not sure what </tspan><tspan
|
||||
x="190.02438"
|
||||
y="233.86888"
|
||||
id="tspan69">makes them completely "non-bypassable".
|
||||
</tspan><tspan
|
||||
x="190.02438"
|
||||
y="236.51473"
|
||||
id="tspan70">- They have a more comprehensive evaluation of the </tspan><tspan
|
||||
x="190.02438"
|
||||
y="239.16057"
|
||||
id="tspan71">detection performances compared with other softwares. </tspan><tspan
|
||||
x="190.02438"
|
||||
y="241.80641"
|
||||
id="tspan73">However the same comparison would be unfaire to ProcVer </tspan><tspan
|
||||
x="190.02438"
|
||||
y="244.45226"
|
||||
id="tspan74">because its achievement lies in the fact that it is </tspan><tspan
|
||||
x="190.02438"
|
||||
y="247.0981"
|
||||
id="tspan75">completely remote from the OS and the fact that it </tspan><tspan
|
||||
x="190.02438"
|
||||
y="249.74394"
|
||||
id="tspan82">should work the same on known malwares and zero-days </tspan><tspan
|
||||
x="190.02438"
|
||||
y="252.38979"
|
||||
id="tspan86">attacks. Moreover, it is an additional layer of </tspan><tspan
|
||||
x="190.02438"
|
||||
y="255.03563"
|
||||
id="tspan87">defense, not a silver bullet.
|
||||
</tspan><tspan
|
||||
x="190.02438"
|
||||
y="257.68147"
|
||||
id="tspan88">- Their solution is very hardware specific in the sense </tspan><tspan
|
||||
x="190.02438"
|
||||
y="260.3273"
|
||||
id="tspan89">that it is designed for a processor model/family/</tspan><tspan
|
||||
x="190.02438"
|
||||
y="262.97315"
|
||||
id="tspan90">manufacturer and would require significant rework to be </tspan><tspan
|
||||
x="190.02438"
|
||||
y="265.61899"
|
||||
id="tspan91">ported to another hardware. Our solution is hardware </tspan><tspan
|
||||
x="190.02438"
|
||||
y="268.26483"
|
||||
id="tspan92">specific for training but hardware agnostic in its </tspan><tspan
|
||||
x="190.02438"
|
||||
y="270.91068"
|
||||
id="tspan93">design and capabilities.</tspan></text><path
|
||||
id="path101"
|
||||
style="color:#000000;fill:#000000;-inkscape-stroke:none"
|
||||
d="M 136.23453,106.54263 V 90.76529 c -1.83131,-0.12865 -3.28145,-1.65766 -3.28145,-3.52122 0,-1.94765 1.5834,-3.531573 3.53105,-3.531573 1.94765,0 3.53156,1.583923 3.53156,3.531573 0,1.86356 -1.45014,3.39257 -3.28145,3.52122 v 15.77734 z m 0.2496,-16.26723 c 1.67743,0 3.03134,-1.3539 3.03134,-3.03133 0,-1.67743 -1.35391,-3.031343 -3.03134,-3.031343 -1.67743,0 -3.03082,1.353913 -3.03082,3.031343 0,1.67743 1.35339,3.03133 3.03082,3.03133 z" /><text
|
||||
xml:space="preserve"
|
||||
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:3.88056px;line-height:1.25;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono';letter-spacing:-0.291042px;word-spacing:0px;stroke-width:0.264583"
|
||||
x="132.1333"
|
||||
y="110.24815"
|
||||
id="text102"><tspan
|
||||
id="tspan101"
|
||||
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono';stroke-width:0.264583"
|
||||
x="132.1333"
|
||||
y="110.24815"
|
||||
sodipodi:role="line">2005</tspan></text><rect
|
||||
style="fill:#cccccc;fill-opacity:1;stroke:#1a1a1a;stroke-width:0.577775;stroke-dasharray:none;stroke-opacity:1"
|
||||
id="rect102"
|
||||
width="56.667709"
|
||||
height="41.683708"
|
||||
x="110.00934"
|
||||
y="111.3315"
|
||||
ry="1.3401735" /><rect
|
||||
style="fill:#ffc6a0;fill-opacity:1;stroke:#ff6803;stroke-width:0.577775;stroke-dasharray:none;stroke-opacity:1"
|
||||
id="rect103"
|
||||
width="59.49057"
|
||||
height="11.870605"
|
||||
x="108.39667"
|
||||
y="111.3315"
|
||||
ry="1.3401735" /><text
|
||||
xml:space="preserve"
|
||||
style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:3.88056px;line-height:1.25;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono Bold';letter-spacing:-0.291042px;word-spacing:0px;white-space:pre;inline-size:78.7407;display:inline;stroke-width:0.264583"
|
||||
x="320.76639"
|
||||
y="166.06209"
|
||||
id="text105"
|
||||
transform="matrix(0.72076737,0,0,0.72076737,-121.08064,-4.4026833)"><tspan
|
||||
x="320.76639"
|
||||
y="166.06209"
|
||||
id="tspan95">Detecting Stealth Software with </tspan><tspan
|
||||
x="320.76639"
|
||||
y="170.91278"
|
||||
id="tspan96">Strider GhostBuster</tspan></text><text
|
||||
xml:space="preserve"
|
||||
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:2.11667px;line-height:1.25;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono';letter-spacing:-0.291042px;word-spacing:0px;white-space:pre;inline-size:54.6704;display:inline;stroke-width:0.264583"
|
||||
x="190.02438"
|
||||
y="196.82707"
|
||||
id="text106"
|
||||
transform="translate(-78.825247,-54.909023)" /><text
|
||||
xml:space="preserve"
|
||||
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:2.11667px;line-height:1.25;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono';letter-spacing:-0.291042px;word-spacing:0px;white-space:pre;inline-size:54.6704;display:inline;stroke-width:0.264583"
|
||||
x="190.02438"
|
||||
y="196.82707"
|
||||
id="text72"
|
||||
transform="translate(-79.14574,-70.087023)"><tspan
|
||||
x="190.02438"
|
||||
y="196.82707"
|
||||
id="tspan97">- Their solution relies on the comparison of two </tspan><tspan
|
||||
x="190.02438"
|
||||
y="199.47292"
|
||||
id="tspan98">snapshot made at the same time using two different </tspan><tspan
|
||||
x="190.02438"
|
||||
y="202.11876"
|
||||
id="tspan99">mechanism, assuming one goes through the hidden malware </tspan><tspan
|
||||
x="190.02438"
|
||||
y="204.7646"
|
||||
id="tspan100">and one does not. The method is called cross-view diff.
|
||||
</tspan><tspan
|
||||
x="190.02438"
|
||||
y="207.41045"
|
||||
id="tspan102">- In a sense, there is a parallel to be drawn between </tspan><tspan
|
||||
x="190.02438"
|
||||
y="210.05629"
|
||||
id="tspan103">their approach an mine. I also doo a cross-view diff of </tspan><tspan
|
||||
x="190.02438"
|
||||
y="212.70213"
|
||||
id="tspan104">the state ofthe machine but one of my view is the power </tspan><tspan
|
||||
x="190.02438"
|
||||
y="215.34798"
|
||||
id="tspan105">and the other one is the process list.
|
||||
</tspan><tspan
|
||||
x="190.02438"
|
||||
y="217.99382"
|
||||
id="tspan106">- Our method only exposes CPU-consuming malware. The </tspan><tspan
|
||||
x="190.02438"
|
||||
y="220.63967"
|
||||
id="tspan107">file-hiding malware are invisible to us.</tspan></text><path
|
||||
id="path72"
|
||||
style="color:#000000;fill:#000000;-inkscape-stroke:none"
|
||||
d="m 185.43665,67.933517 v 15.77734 c -1.83131,0.12865 -3.28145,1.657663 -3.28145,3.521223 0,1.94765 1.5834,3.53157 3.53105,3.53157 1.94765,0 3.53156,-1.58392 3.53156,-3.53157 0,-1.86356 -1.45014,-3.392573 -3.28145,-3.521223 v -15.77734 z m 0.2496,16.26723 c 1.67743,0 3.03134,1.353903 3.03134,3.031333 0,1.67743 -1.35391,3.03134 -3.03134,3.03134 -1.67743,0 -3.03082,-1.35391 -3.03082,-3.03134 0,-1.67743 1.35339,-3.031333 3.03082,-3.031333 z" /><text
|
||||
xml:space="preserve"
|
||||
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:3.88056px;line-height:1.25;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono';letter-spacing:-0.291042px;word-spacing:0px;stroke-width:0.264583"
|
||||
x="181.33542"
|
||||
y="67.18058"
|
||||
id="text73"><tspan
|
||||
id="tspan72"
|
||||
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono';stroke-width:0.264583"
|
||||
x="181.33542"
|
||||
y="67.18058"
|
||||
sodipodi:role="line">2005</tspan></text><rect
|
||||
style="fill:#cccccc;fill-opacity:1;stroke:#1a1a1a;stroke-width:0.577775;stroke-dasharray:none;stroke-opacity:1"
|
||||
id="rect73"
|
||||
width="56.667709"
|
||||
height="41.683708"
|
||||
x="159.21146"
|
||||
y="20.624043"
|
||||
ry="1.3401735" /><rect
|
||||
style="fill:#ffc6a0;fill-opacity:1;stroke:#ff6803;stroke-width:0.577775;stroke-dasharray:none;stroke-opacity:1"
|
||||
id="rect74"
|
||||
width="59.49057"
|
||||
height="15.626968"
|
||||
x="157.59879"
|
||||
y="16.86768"
|
||||
ry="1.3401735" /><text
|
||||
xml:space="preserve"
|
||||
style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:3.88056px;line-height:1.25;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono Bold';letter-spacing:-0.291042px;word-spacing:0px;white-space:pre;inline-size:78.7407;display:inline;stroke-width:0.264583"
|
||||
x="320.76639"
|
||||
y="166.06209"
|
||||
id="text75"
|
||||
transform="matrix(0.72076737,0,0,0.72076737,-71.878518,-99.356979)"><tspan
|
||||
x="320.76639"
|
||||
y="166.06209"
|
||||
id="tspan108">Stealthy Malware Detection Through </tspan><tspan
|
||||
x="320.76639"
|
||||
y="170.91278"
|
||||
id="tspan109">VMM-BasedS“Out-of-the-Box” Semantic </tspan><tspan
|
||||
x="320.76639"
|
||||
y="175.76347"
|
||||
id="tspan110">View Reconstructiontealthy Malware </tspan><tspan
|
||||
x="320.76639"
|
||||
y="180.61416"
|
||||
id="tspan111">Detection Through VMM-Based</tspan></text><text
|
||||
xml:space="preserve"
|
||||
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:2.11667px;line-height:1.25;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono';letter-spacing:-0.291042px;word-spacing:0px;white-space:pre;inline-size:54.6704;display:inline;stroke-width:0.264583"
|
||||
x="190.02438"
|
||||
y="196.82707"
|
||||
id="text76"
|
||||
transform="translate(-29.943618,-160.79447)"><tspan
|
||||
x="190.02438"
|
||||
y="196.82707"
|
||||
id="tspan112">Important paper in the field. Lots of citation.
|
||||
</tspan><tspan
|
||||
x="190.02438"
|
||||
y="199.47292"
|
||||
id="tspan113">
|
||||
</tspan><tspan
|
||||
x="190.02438"
|
||||
y="202.11876"
|
||||
id="tspan114">- They claim to have a method that is "Out-of-the-Box" </tspan><tspan
|
||||
x="190.02438"
|
||||
y="204.7646"
|
||||
id="tspan115">opposit to the host-based methods. This follows the </tspan><tspan
|
||||
x="190.02438"
|
||||
y="207.41045"
|
||||
id="tspan116">same idea that we have for independance but we take it </tspan><tspan
|
||||
x="190.02438"
|
||||
y="210.05629"
|
||||
id="tspan117">one step further, making it "out-of-the-case/rack" for </tspan><tspan
|
||||
x="190.02438"
|
||||
y="212.70213"
|
||||
id="tspan118">complete and undeniable independence. Their method only </tspan><tspan
|
||||
x="190.02438"
|
||||
y="215.34798"
|
||||
id="tspan119">work on VM because there is a place between the VM and </tspan><tspan
|
||||
x="190.02438"
|
||||
y="217.99382"
|
||||
id="tspan120">the hardware to install their detector. Our method is </tspan><tspan
|
||||
x="190.02438"
|
||||
y="220.63967"
|
||||
id="tspan121">applicable to any hardware.</tspan></text><circle
|
||||
style="fill:#cccccc;fill-opacity:1;stroke:#000000;stroke-width:1;stroke-linejoin:round;stroke-dasharray:none"
|
||||
id="path76"
|
||||
cx="-404.80991"
|
||||
cy="185.1604"
|
||||
r="22.767"
|
||||
transform="rotate(-150)" /><text
|
||||
xml:space="preserve"
|
||||
style="font-size:4.5861px;line-height:5.70346px;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono';text-align:start;letter-spacing:0px;writing-mode:lr-tb;direction:ltr;text-anchor:start;fill:#000000;stroke:none;stroke-width:2.1;stroke-linejoin:round"
|
||||
id="text77"
|
||||
transform="translate(-1.4757142,-1.8781817)"><textPath
|
||||
xlink:href="#path76"
|
||||
id="textPath86"><tspan
|
||||
id="tspan77"
|
||||
style="fill:#000000;stroke:none;stroke-width:2.1">Target OS</tspan></textPath></text><text
|
||||
xml:space="preserve"
|
||||
style="font-size:4.5861px;line-height:5.70346px;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono';text-align:start;letter-spacing:0px;writing-mode:lr-tb;direction:ltr;text-anchor:start;fill:#000000;stroke:none;stroke-width:2.1;stroke-linejoin:round"
|
||||
x="424.49768"
|
||||
y="43.393692"
|
||||
id="text78"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan78"
|
||||
style="fill:#000000;stroke:none;stroke-width:2.1"
|
||||
x="424.49768"
|
||||
y="43.393692">Host-Based IDS</tspan></text><text
|
||||
xml:space="preserve"
|
||||
style="font-size:4.5861px;line-height:5.70346px;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono';text-align:start;letter-spacing:0px;writing-mode:lr-tb;direction:ltr;text-anchor:start;fill:#000000;stroke:none;stroke-width:2.1;stroke-linejoin:round"
|
||||
id="text79"
|
||||
transform="translate(-2.0123375,-1.2074025)"><textPath
|
||||
xlink:href="#path78"
|
||||
id="textPath87"><tspan
|
||||
id="tspan79"
|
||||
style="fill:#000000;stroke:none;stroke-width:2.1">Hardware</tspan></textPath></text><text
|
||||
xml:space="preserve"
|
||||
style="font-size:4.5861px;line-height:5.70346px;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono';text-align:start;letter-spacing:0px;writing-mode:lr-tb;direction:ltr;text-anchor:start;fill:#000000;stroke:none;stroke-width:2.1;stroke-linejoin:round"
|
||||
x="430.40054"
|
||||
y="4.8795161"
|
||||
id="text80"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan80"
|
||||
style="fill:#000000;stroke:none;stroke-width:2.1"
|
||||
x="430.40054"
|
||||
y="4.8795161">VM Monitors</tspan></text><text
|
||||
xml:space="preserve"
|
||||
style="font-size:4.5861px;line-height:5.70346px;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono';text-align:start;letter-spacing:0px;writing-mode:lr-tb;direction:ltr;text-anchor:start;fill:#000000;stroke:none;stroke-width:2.1;stroke-linejoin:round"
|
||||
x="421.81458"
|
||||
y="-23.579235"
|
||||
id="text86"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan81"
|
||||
style="fill:#000000;stroke:none;stroke-width:2.1"
|
||||
x="421.81458"
|
||||
y="-23.579235">Physics-Based IDS</tspan></text><text
|
||||
xml:space="preserve"
|
||||
style="font-size:4.5861px;line-height:5.70346px;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono';text-align:start;letter-spacing:0px;writing-mode:lr-tb;direction:ltr;text-anchor:start;fill:#000000;stroke:none;stroke-width:2.1;stroke-linejoin:round"
|
||||
id="text88"
|
||||
transform="translate(-1.8877159,-1.615455)"><textPath
|
||||
xlink:href="#path87"
|
||||
id="textPath88">Server Room</textPath></text><path
|
||||
style="fill:none;fill-opacity:1;stroke:#ffb37e;stroke-width:1;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1;marker-start:url(#Dot)"
|
||||
d="M 427.02924,4.6755133 C 361.20707,11.587768 304.15054,22.636116 216.62419,24.122327"
|
||||
id="path88"
|
||||
sodipodi:nodetypes="cc" /><path
|
||||
style="fill:none;fill-opacity:1;stroke:#ffb37e;stroke-width:1;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1;marker-start:url(#Dot)"
|
||||
d="M 420.38886,13.497726 C 378.0926,35.018806 321.13093,116.07567 233.60458,117.56189"
|
||||
id="path89"
|
||||
sodipodi:nodetypes="cc" /></g></svg>
|
||||
|
After Width: | Height: | Size: 30 KiB |
851
procver/SnP/main.tex
Normal file
851
procver/SnP/main.tex
Normal file
|
|
@ -0,0 +1,851 @@
|
|||
%% bare_conf_compsoc.tex
|
||||
%% V1.4b
|
||||
%% 2015/08/26
|
||||
%% by Michael Shell
|
||||
%% See:
|
||||
%% http://www.michaelshell.org/
|
||||
%% for current contact information.
|
||||
%%
|
||||
%% This is a skeleton file demonstrating the use of IEEEtran.cls
|
||||
%% (requires IEEEtran.cls version 1.8b or later) with an IEEE Computer
|
||||
%% Society conference paper.
|
||||
%%
|
||||
%% Support sites:
|
||||
%% http://www.michaelshell.org/tex/ieeetran/
|
||||
%% http://www.ctan.org/pkg/ieeetran
|
||||
%% and
|
||||
%% http://www.ieee.org/
|
||||
|
||||
%%*************************************************************************
|
||||
%% Legal Notice:
|
||||
%% This code is offered as-is without any warranty either expressed or
|
||||
%% implied; without even the implied warranty of MERCHANTABILITY or
|
||||
%% FITNESS FOR A PARTICULAR PURPOSE!
|
||||
%% User assumes all risk.
|
||||
%% In no event shall the IEEE or any contributor to this code be liable for
|
||||
%% any damages or losses, including, but not limited to, incidental,
|
||||
%% consequential, or any other damages, resulting from the use or misuse
|
||||
%% of any information contained here.
|
||||
%%
|
||||
%% All comments are the opinions of their respective authors and are not
|
||||
%% necessarily endorsed by the IEEE.
|
||||
%%
|
||||
%% This work is distributed under the LaTeX Project Public License (LPPL)
|
||||
%% ( http://www.latex-project.org/ ) version 1.3, and may be freely used,
|
||||
%% distributed and modified. A copy of the LPPL, version 1.3, is included
|
||||
%% in the base LaTeX documentation of all distributions of LaTeX released
|
||||
%% 2003/12/01 or later.
|
||||
%% Retain all contribution notices and credits.
|
||||
%% ** Modified files should be clearly indicated as such, including **
|
||||
%% ** renaming them and changing author support contact information. **
|
||||
%%*************************************************************************
|
||||
|
||||
|
||||
% *** Authors should verify (and, if needed, correct) their LaTeX system ***
|
||||
% *** with the testflow diagnostic prior to trusting their LaTeX platform ***
|
||||
% *** with production work. The IEEE's font choices and paper sizes can ***
|
||||
% *** trigger bugs that do not appear when using other class files. *** ***
|
||||
% The testflow support page is at:
|
||||
% http://www.michaelshell.org/tex/testflow/
|
||||
|
||||
|
||||
|
||||
\documentclass[conference,compsoc]{IEEEtran}
|
||||
% Some/most Computer Society conferences require the compsoc mode option,
|
||||
% but others may want the standard conference format.
|
||||
%
|
||||
% If IEEEtran.cls has not been installed into the LaTeX system files,
|
||||
% manually specify the path to it like:
|
||||
% \documentclass[conference,compsoc]{../sty/IEEEtran}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
% Some very useful LaTeX packages include:
|
||||
% (uncomment the ones you want to load)
|
||||
|
||||
|
||||
% *** MISC UTILITY PACKAGES ***
|
||||
%
|
||||
%\usepackage{ifpdf}
|
||||
% Heiko Oberdiek's ifpdf.sty is very useful if you need conditional
|
||||
% compilation based on whether the output is pdf or dvi.
|
||||
% usage:
|
||||
% \ifpdf
|
||||
% % pdf code
|
||||
% \else
|
||||
% % dvi code
|
||||
% \fi
|
||||
% The latest version of ifpdf.sty can be obtained from:
|
||||
% http://www.ctan.org/pkg/ifpdf
|
||||
% Also, note that IEEEtran.cls V1.7 and later provides a builtin
|
||||
% \ifCLASSINFOpdf conditional that works the same way.
|
||||
% When switching from latex to pdflatex and vice-versa, the compiler may
|
||||
% have to be run twice to clear warning/error messages.
|
||||
|
||||
|
||||
\usepackage{graphicx}
|
||||
\usepackage{xcolor}
|
||||
\usepackage{amsfonts}
|
||||
\usepackage{amssymb}
|
||||
\usepackage{acro}
|
||||
\usepackage{booktabs}
|
||||
\usepackage{url}
|
||||
\usepackage{algorithm}
|
||||
\usepackage{algpseudocode}
|
||||
|
||||
|
||||
\input{acronyms}
|
||||
|
||||
|
||||
|
||||
% *** CITATION PACKAGES ***
|
||||
%
|
||||
\ifCLASSOPTIONcompsoc
|
||||
% IEEE Computer Society needs nocompress option
|
||||
% requires cite.sty v4.0 or later (November 2003)
|
||||
\usepackage[nocompress]{cite}
|
||||
\else
|
||||
% normal IEEE
|
||||
\usepackage{cite}
|
||||
\fi
|
||||
|
||||
|
||||
% correct bad hyphenation here
|
||||
\hyphenation{op-tical net-works semi-conduc-tor}
|
||||
|
||||
\input{utils}
|
||||
|
||||
|
||||
\begin{document}
|
||||
%
|
||||
% paper title
|
||||
% Titles are generally capitalized except for words such as a, an, and, as,
|
||||
% at, but, by, for, in, nor, of, on, or, the, to and up, which are usually
|
||||
% not capitalized unless they are the first or last word of the title.
|
||||
% Linebreaks \\ can be used within to get better formatting as desired.
|
||||
% Do not put math or special symbols in the title.
|
||||
\title{Electron Accounting: Hidden Process Detection through Power Consumption Prediction}
|
||||
|
||||
|
||||
% author names and affiliations
|
||||
% use a multiple column layout for up to three different
|
||||
% affiliations
|
||||
% \author{
|
||||
% \IEEEauthorblockN{Arthur Grisel-Davy}
|
||||
% \IEEEauthorblockA{Electrical and\\Computer Engineering\\
|
||||
% University of Waterloo\\
|
||||
% Ontario, CA\\
|
||||
% agriseld@uwaterlo.ca}
|
||||
% \and
|
||||
% \IEEEauthorblockN{Mahesh Tripunitara}
|
||||
% \IEEEauthorblockA{Electrical and\\Computer Engineering\\
|
||||
% University of Waterloo\\
|
||||
% Ontario, CA\\
|
||||
% tripunit@uwaterloo.ca}
|
||||
% \and
|
||||
% \IEEEauthorblockN{Sebastian Fischmeister}
|
||||
% \IEEEauthorblockA{Electrical and\\Computer Engineering\\
|
||||
% University of Waterloo\\
|
||||
% Ontario, CA\\
|
||||
% sfischme@uwaterloo.ca}
|
||||
% }
|
||||
|
||||
\author{
|
||||
\IEEEauthorblockN{Anonymous}
|
||||
\IEEEauthorblockA{None\\
|
||||
None\\
|
||||
None\\
|
||||
none@example.com}
|
||||
\and
|
||||
\IEEEauthorblockN{Anonymous}
|
||||
\IEEEauthorblockA{None\\
|
||||
None\\
|
||||
None\\
|
||||
none@example.com}
|
||||
\and
|
||||
\IEEEauthorblockN{Anonymous}
|
||||
\IEEEauthorblockA{None\\
|
||||
None\\
|
||||
None\\
|
||||
none@example.com}
|
||||
}
|
||||
|
||||
% conference papers do not typically use \thanks and this command
|
||||
% is locked out in conference mode. If really needed, such as for
|
||||
% the acknowledgment of grants, issue a \IEEEoverridecommandlockouts
|
||||
% after \documentclass
|
||||
|
||||
% for over three affiliations, or if they all won't fit within the width
|
||||
% of the page (and note that there is less available width in this regard for
|
||||
% compsoc conferences compared to traditional conferences), use this
|
||||
% alternative format:
|
||||
%
|
||||
%\author{\IEEEauthorblockN{Michael Shell\IEEEauthorrefmark{1},
|
||||
%Homer Simpson\IEEEauthorrefmark{2},
|
||||
%James Kirk\IEEEauthorrefmark{3},
|
||||
%Montgomery Scott\IEEEauthorrefmark{3} and
|
||||
%Eldon Tyrell\IEEEauthorrefmark{4}}
|
||||
%\IEEEauthorblockA{\IEEEauthorrefmark{1}School of Electrical and Computer Engineering\\
|
||||
%Georgia Institute of Technology,
|
||||
%Atlanta, Georgia 30332--0250\\ Email: see http://www.michaelshell.org/contact.html}
|
||||
%\IEEEauthorblockA{\IEEEauthorrefmark{2}Twentieth Century Fox, Springfield, USA\\
|
||||
%Email: homer@thesimpsons.com}
|
||||
%\IEEEauthorblockA{\IEEEauthorrefmark{3}Starfleet Academy, San Francisco, California 96678-2391\\
|
||||
%Telephone: (800) 555--1212, Fax: (888) 555--1212}
|
||||
%\IEEEauthorblockA{\IEEEauthorrefmark{4}Tyrell Inc., 123 Replicant Street, Los Angeles, California 90210--4321}}
|
||||
|
||||
|
||||
|
||||
|
||||
% use for special paper notices
|
||||
%\IEEEspecialpapernotice{(Invited Paper)}
|
||||
|
||||
|
||||
|
||||
|
||||
% make the title area
|
||||
\maketitle
|
||||
|
||||
% As a general rule, do not put math, special symbols or citations
|
||||
% in the abstract
|
||||
\begin{abstract}
|
||||
One important source of information for detecting malware on a machine is the list of processes.
|
||||
By analyzing this list, an Intrusion Detection System (IDS) can detect known malware, mine and verify security rules, or confirm the presence and activity of expected key processes.
|
||||
For this reason, tampering with the process list is a common evasion technique for malware that aims to remain hidden on the machine.
|
||||
The tampering can involve removing processes associated with malicious activities or injecting expected processes that have been stopped.
|
||||
|
||||
We propose a new approach to verify the integrity of the process list --- before its use by traditional IDS --- using \ac{sci}.
|
||||
The proposed approach uses the process list to predict the power consumption of the Central Processing Unit (CPU).
|
||||
If the prediction matches the ground truth consumption measured externally, then the process list is trusted.
|
||||
Otherwise, the discrepancy is evidence of modifications to the list.
|
||||
|
||||
We evaluate the potential of this approach on 388 CPU activity traces of real-world virtual machines gathered from a public dataset and replayed on local machines to collect the necessary information.
|
||||
We also evaluate the sensitivity of the approach in terms of the energy consumption of malware to determine the range of detection.
|
||||
The results validate the potential of the proposed approach as a complementary validation system for detecting process list tampering.
|
||||
|
||||
\end{abstract}
|
||||
|
||||
% no keywords
|
||||
|
||||
|
||||
|
||||
|
||||
% For peer review papers, you can put extra information on the cover
|
||||
% page as needed:
|
||||
% \ifCLASSOPTIONpeerreview
|
||||
% \begin{center} \bfseries EDICS Category: 3-BBND \end{center}
|
||||
% \fi
|
||||
%
|
||||
% For peerreview papers, this IEEEtran command inserts a page break and
|
||||
% creates the second title. It will be ignored for other modes.
|
||||
\IEEEpeerreviewmaketitle
|
||||
|
||||
|
||||
|
||||
\section{Introduction}
|
||||
% no \IEEEPARstart
|
||||
Malware development has always been a field of computer science that rivals in complexity with the most current academic research.
|
||||
To remain effective, malware must keep pace with, and even outpace, the most advanced detection and prevention mechanisms.
|
||||
This complexity has kept modern malware capable of infiltrate and disrupt systems while avoiding detection.
|
||||
|
||||
While stealth may not be the main focus of all malware --- some are designed for destructive power or speed of deployment and action ---, the ability to remain hidden on the infected system --- called evasion --- is a common feature of many modern malware.
|
||||
Because of the creativity of malware authors, many evasion techniques have been used over time.
|
||||
While most were discovered and documented, it is safe to assume that there are and will always be evasion techniques that are one step ahead and bypass the current detection methods.
|
||||
|
||||
\textit{Evasion techniques} is an umbrella term that covers multiple sub-categories, each for a different purpose.
|
||||
One aspect of evasion is the ability to conceal the malicious nature of the files that constitute the malware.
|
||||
For this purpose, malware may employ homomorphic or metamorphic methods to bypass signature matching or use a file-less design to avoid analysis altogether.
|
||||
Hiding artifacts is another capability that malware author employ to evade detection.
|
||||
By exploiting the \ac{os} mechanisms, malware can hide their executables, logs, or users.
|
||||
|
||||
This study focuses on another specific evasion domain: process hiding.
|
||||
The list of running processes is an obviously compelling resource to start detecting malware.
|
||||
To detect running malware, one could simply gather the list of all running software and search for known malware.
|
||||
With the list of processes frequently collected, an \ac{hids} can detect known malware, mine rules, define an activity profile, or detect anomalous situations.
|
||||
|
||||
\begin{figure}[t]
|
||||
\centering
|
||||
\includegraphics[width=1\linewidth]{images/contribution.pdf}
|
||||
\caption{Intrusion detection systems traditionally trust the list of processes to be complete and accurate. We propose an independent verification mechanism that uses the power consumption of the processor to identify tampering with the process list before its usage.}
|
||||
\label{fig:contribution}
|
||||
\end{figure}
|
||||
|
||||
Removing itself from the process list is a good first step for any malware aiming for stealth.
|
||||
We can categorize the techniques achieving this type of evasion between hiding and masquerading.
|
||||
For process hiding, the goal is to execute a program and leave no trace of it in the process list.
|
||||
For process masquerading, the aim is not as much to avoid the listing but to avoid the malware being listed with its real identity.
|
||||
A process masquerading as another will assume its process name and characteristics, with the goal of appearing legitimate on the machine.
|
||||
Process hiding and masquerading differ in their ultimate goal but leverage common techniques.
|
||||
The core idea of process list manipulation is tampering with the process listing mechanism provided by the \ac{os} to the monitoring software.
|
||||
Independently of the \ac{os}, attackers often rely on intercepting system calls to remove or replace information or directly manipulating kernel objects.
|
||||
For the purpose of this study, we do not differentiate between Unix-based \acp{os} and Windows systems, as process hiding is a common practice for malware in both environments.
|
||||
|
||||
|
||||
% there are detection methods but they are all host-based and doomed to be bypassed
|
||||
Of course, many methods have been proposed and implemented to detect or counter process list tampering (see Section~\ref{sec:related-work}).
|
||||
These methods --- although they leverage different mechanisms --- are all host-based.
|
||||
This creates a circular dependency where the \ac{ids} rely on the host system to provide the very information leveraged to assess its integrity.
|
||||
In this situation, an attacker that successfully compromises a machine can employ evasion techniques that manipulate the data used for detection.
|
||||
Some methods, targeting hypervisor systems specifically, run on the host instead of the \ac{vm}.
|
||||
This position adds distances between the \ac{ids} and the machine being monitored and provides additional security against bypasses.
|
||||
However, multiple \ac{vm} escape mechanisms have been documented over the years, affecting most virtualization software and reducing the virtual distance between the attacker and the detection system.
|
||||
As rootkits providing process hiding remained a threat since their introduction, it is safe to assume that current countermeasures --- and future ones based on similar techniques --- do not provide complete protection.
|
||||
|
||||
% is it a bird? is it a plane? No its the good old power consumption!
|
||||
One possible alternate method for detecting process list manipulation is using a secondary source of information to corroborate the process list (see Figure~\ref{fig:contribution}).
|
||||
To avoid bypass, the secondary source must be independent of the \ac{os} and not require its cooperation to enable protection.
|
||||
However, the source must also provide information correlated with process presence and activity on the machine.
|
||||
|
||||
|
||||
\ac{sci} is compelling as the secondary source.
|
||||
As involuntary emissions, they are naturally independent of the origin system.
|
||||
No communication is required with the system to access this information.
|
||||
As physical by-products of the computation, they are hard to forge or remove from the attacker's standpoint.
|
||||
A program can somewhat control its computation intensity, but it is difficult to precisely control the generated emissions and impossible to fully suppress them.
|
||||
If the attacker wants to perform any computation on the compromised machine, it will result in some form of physical emission.
|
||||
The most common \ac{sci} leveraged for attack or defense is energy consumption due to its ease of capture, high reliability, large range of applications, and good informative potential about the activity of the system.
|
||||
|
||||
However, there are drawbacks to using power consumption as a source of information.
|
||||
First, the raw power consumption of a machine is not an actionable piece of information.
|
||||
A step of information mining --- for example, pattern recognition, anomaly detection, or even the comparison to a threshold --- is always required to make a decision.
|
||||
Then, measuring true independent power consumption data requires additional hardware.
|
||||
Although software estimations of power consumption are available, they bear the same circular dependency issue as other host-based sources of information (see Section~\ref{sec:soft-power} for more details about software-based measurements).
|
||||
Finally, the power consumption of a machine only contains a small subset of all information related to process activity.
|
||||
A modern \ac{cpu} executes hundreds to thousands of millions of instructions per second.
|
||||
Each instruction triggers multiple consumption patterns across multiple components of the system.
|
||||
Although --- in theory --- the power consumption is a sum of all these sub-consumptions, the reality of measurement, in terms of resolution, accuracy, and sampling rate, makes single-instruction measurement unrealistic at a global scale of the \ac{cpu}.
|
||||
|
||||
Taking all these limitations into account, the power consumption of a machine --- and more specifically, the power consumption of its \ac{cpu} --- can be a valuable complementary source of information if properly exploited.
|
||||
The correlation between a list of processes and the power consumption can enable the detection of process list tampering and evidence of malware activity.
|
||||
|
||||
\section{Contribution}
|
||||
In this paper, we propose a novel hidden process detection approach that leverages the power consumption of the \ac{cpu} as ground truth information to verify the process list (see Figure~\ref{fig:contribution}).
|
||||
The list of processes serves as input to a machine-learning model that predicts the expected power consumption based on the instances of processes and their state.
|
||||
The comparison between this predicted power and the independently-measured reference enables the detection of \ac{cpu}-consuming malware.
|
||||
|
||||
|
||||
\section{Related Work}\label{sec:related-work}
|
||||
Hiding malicious activity to avoid detection is neither a new nor a diminishing issue.
|
||||
Rootkits are a well-established threat with a history spanning decades and modern examples still in use by malicious actors.
|
||||
In 2022, Kaspersky announced the detection of CosmicStrand, a \ac{uefi} firmware rootkit resistant to \ac{os} reinstallation \cite{cosmicstrand}.
|
||||
In 2024, the Windows \ac{msrt} reported that Rootkits represented 14\% of all detected malware \cite{win-msrt}.
|
||||
|
||||
As a response to this threat, the field of hidden malware detection has received frequent contributions over the last twenty years.
|
||||
With the emergence and popularization of virtualized environments for cloud computing over the same period, many proposed approaches leveraged the special position and visibility that a software running on the host machine has over the \acp{vm}.
|
||||
These \ac{vmm}-based methods can be considered \textit{out-of-the-box} as there is a logical isolation between the monitoring software and the monitored \ac{vm}.
|
||||
This isolation provides a compelling independence from the potentially compromised target, which improves robustness to bypasses by the malware.
|
||||
VMWatcher proposed by Jiang et al. in 2007 \cite{10.1145/1315245.1315262} is an important contribution to the field and an example of \ac{vmm}-based approaches.
|
||||
Their proposed approach reconstructs the monitored \ac{vm}'s objects at the host level to enable host-based anti-malware to run from the safety of the host while enjoying the same visibility as running in the \ac{vm}.
|
||||
This approach enables hidden-process detection to be more robust to bypass or counter-detection.
|
||||
Other proposed approaches \cite{wen2008implicit, jones2008vmm, wang2005detecting} leverage the special position of the host machine to perform rootkit detection.
|
||||
|
||||
However, all \ac{vmm}-based approaches make the hidden assumption that the host machine and the \ac{vm} can be considered isolated machines when it comes to malware, thus providing a secure environment for running protection software.
|
||||
While it is undeniable that virtualization provides, by design, a strong barrier between the host and the guest, it would be a mistake to consider it perfect.
|
||||
\ac{vm} escapes are usually made possible by the presence of vulnerabilities in the virtualization system, and \ac{cve} reports can be found for all major systems.
|
||||
In 2009, Kortchinsky presented Cloudburst, a \ac{vm} escape mechanism for the VMWare virtualization system based on the exploitation of vulnerabilities in the graphics stack.
|
||||
In 2017, a heap buffer overflow in SVGA \ac{vm} escape vulnerability for VMWare was exploited during the Pown2Own competition \cite{cve-vmware-2017}.
|
||||
In 2021, a vulnerability in Oracle VirtualBox allowed a highly privileged attacker to hang or crash the host system or update, insert or delete access to some of the host data \cite{cve-vbox-2021}.
|
||||
In 2019, a heap buffer overflow vulnerability was discovered in the QEMU virtualization system and could enable an attacker to execute arbitrary code with privileges of the QEMU process, potentially leading to \ac{vm} escape \cite{cve-qemu-2019}.
|
||||
Similar vulnerabilities exist for Xen Hypervisor (that uses QEMU for some tasks) \cite{cve-xen-2015} or Microsoft Hyper-V \cite{cve-hyperv-2021}.
|
||||
In light of all these vulnerabilities, it is valid to assume that, to a dedicated attacker, the host and the \ac{vm} guest are not isolated.
|
||||
Stemming from this assumption, \ac{vmm}-based hidden processes detection methods are as vulnerable to bypass or tampering as host-based approaches.
|
||||
However, the idea of an isolated source of information about the system's activity remains compelling for hidden process detection.
|
||||
|
||||
One solution to combine observability and independence is to study \ac{sci}.
|
||||
\ac{sci} is a by-product of a machine's normal operation.
|
||||
In the case of a computer, commonly studied side-channels are sound (fan, keyboard), electromagnetic emissions, timing, and power consumption.
|
||||
Historically, \ac{sci} have been leveraged for attacks.
|
||||
Since the seminal work of P. Kosher \cite{kocher1996timing} in 1996 on using timing information in the power consumption to extract cryptographic secrets, all side-channel emissions have been evaluated for extracting information about a system's activity or information.
|
||||
The sound of a person typing on a keyboard can be correlated to the typed text \cite{1301311}, the electromagnetic radiations from a display can reveal information about the displayed image \cite{van1985electromagnetic}, and \ac{ssl} connections are vulnerable to timing attacks even through multiple routers \cite{brumley2005remote}.
|
||||
|
||||
These works revealed the amount of information that leaks through involuntary emissions.
|
||||
Although side-channel was first studied as an attack vector, other researchers realized the potential of this source of information for defensive purposes.
|
||||
Akin to machine health monitoring \cite{worden2007application, shewale2019novel}, defensive side-channel analysis uses the \ac{sci} of a machine to non-intrusively infer and assess its state, activity, or performance.
|
||||
In the case of a computer, previous works evaluated the use of electromagnetic or power consumption emissions to detect malware \cite{khan2019malware, cathis2024sok}.
|
||||
In 2015, Caviglione et al. \cite{7362010} proposed to use the power consumption of a mobile device to identify evidence of hidden software communication.
|
||||
In 2018, Bridges et al.\cite{bridges2018towards} describe a power-based malware detection system for general purpose computers.
|
||||
Their method using only the power consumption as source of information, it relies on a labelled dataset to learn the power profiles associated with malware activity.
|
||||
These works illustrate the potential of power consumption as a proxy variable for the activity of hidden processes on a machine.
|
||||
|
||||
It is interesting to note that the problem of using the power consumption of a computing machine to identify hidden processes has a direct parallel in the domain of \ac{nilm} and smart buildings or cities.
|
||||
A study by Chou et al. \cite{chou2014real} proposes to apply machine-learning methods to process large datasets of building power consumption data for both consumption prediction and anomaly detection.
|
||||
It is easy to draw a conceptual parallel between a computer running multiple processes and a building containing multiple appliances.
|
||||
In both cases, the activity of each component is additive and contributes to global power consumption.
|
||||
However, it is important to keep in mind the differences between the two applications, such as the non-linearity and upper-bound of the accumulation of processes from the point of view of the \ac{cpu} consumption.
|
||||
|
||||
\section{Problem Statement}
|
||||
|
||||
The main problem that this study proposes to tackle can be described as follows:
|
||||
|
||||
\begin{center}
|
||||
Given the list of processes and their state and the power consumption of the \ac{cpu} over the same time period, identify any tampering with the process list.
|
||||
\end{center}
|
||||
|
||||
The list of processes over time $P = \{p_0,p_1\dots,p_{n-1}\}$ is a nested data object where each item $p_i$ contains all listed processes at timestamp $i$ named the \ac{ilp}.
|
||||
Each \ac{ilp} contains the name and state of each process present on the machine at a point in time.
|
||||
From capture to utilization in the prediction model, the process list $P$ undergoes a number of transformations to reorganize the information for learning.
|
||||
See Section~\ref{sec:feature-engineering} for technical details about the process list processing.
|
||||
The power consumption trace --- also named power trace --- is a univariate time series representing the measured power consumption of the \ac{cpu} over time.
|
||||
|
||||
\subsection{Attacker Model}
|
||||
The proposed approach makes several assumptions on the capabilities, goal, and knowledge of the attackers.
|
||||
Certain aspects of the detection framework --- for example, the strict independence requirement for the collection of the power trace --- are direct consequences of these assumptions.
|
||||
|
||||
\subsubsection{Capabilities}
|
||||
This study assumes a powerful attacker with complete remote access to the monitored machine.
|
||||
We suppose that the attacker previously established remote access and can use this access at will and without risking detection.
|
||||
For example, the attacker could have recovered legitimate credentials for a local account on the machine.
|
||||
Moreover, the attacker is assumed to enjoy unrestricted access to the machine with the highest privilege level.
|
||||
No operation on the machine is impossible for the attacker, including any firmware or \ac{bios} tampering.
|
||||
For example, it is expected that the attacker can attack storage devices and boot a different \ac{os} than expected.
|
||||
In the case of the virtualized environment, it is also assumed that the attacker can escape the initial infected \ac{vm} and infect the underlying host machine.
|
||||
|
||||
The only limitation of the attacker is the physical access to the power measurement system.
|
||||
This mechanism includes the hardware installed in a machine or built-in by the manufacturer, as well as the subsequent data processing pipeline.
|
||||
The attacker does not have access to the internal components responsible for measuring, processing, or verifying the power consumption.
|
||||
|
||||
\subsubsection{Goals}
|
||||
This study does not restrict the attacker to any specific intention beyond stealth.
|
||||
The attacker may want to secretly execute arbitrary code, exploit the machine's resources --- for example, cryptojacking malware\cite{tekiner2021sok} --- or prevent the execution of programs --- such as backup or updates.
|
||||
To achieve stealth, the attacker will employ evasion techniques \cite{eresheim2017evolution} to hide or masquerade its malicious processes.
|
||||
This study is not restricted to any specific evasion method.
|
||||
|
||||
|
||||
\subsubsection{Attacker's Knowledge}
|
||||
This study assumes that the attacker is aware that the proposed defense mechanism is deployed on the machine and understands all aspects of it.
|
||||
However, the attacker may ignore the implementation choices related to the proposed approach.
|
||||
For example, the attacker is aware that a power analysis method is active on the machine but may ignore the hyper-parameters of the model in use, the window of training data leveraged, or the sampling rate of the power capture system.
|
||||
See Section~\ref{sec:evasion} for a more detailed analysis of a possible partial evasion method depending on the attacker's knowledge.
|
||||
|
||||
\section{Proposed Approach}
|
||||
|
||||
To address the problem of hidden process detection, we use a method based on power prediction.
|
||||
Figure~\ref{fig:proposed_approach} presents an overview of the proposed approach.
|
||||
The intuition behind this approach is that the power consumption of a \ac{cpu} is an aggregate of the individual power consumption of the tasks it performs.
|
||||
Thus, given enough training samples involving different combinations of tasks and the associated power consumption, a machine-learning model should be able to infer the power consumption from the list of processes.
|
||||
After training and establishing the nominal accuracy of the prediction, the model starts inferring power traces associated with untrusted lists of processes.
|
||||
If the predicted power is different from the ground truth by a margin that exceeds the nominal error, then the list of processes might have been tampered with.
|
||||
The tampering could be subtractive --- an attacker ran a process but prevented it from appearing in the process list --- or additive --- a non-running process was artificially added to the process list --- resulting respectively in a negative or positive prediction error.
|
||||
|
||||
\begin{figure*}[t]
|
||||
\centering
|
||||
\includegraphics[width=1\linewidth]{images/proposed_approach_overview.pdf}
|
||||
\caption{Overview of the proposed approach. First, the regression model takes a list of process for a window of time and predicts the power consumption. Then, the comparison between the prediction and the actual consumption reveals any tampering of the process list.}
|
||||
\label{fig:proposed_approach}
|
||||
\end{figure*}
|
||||
|
||||
\subsection{Sources of Information}\label{sec:collection}
|
||||
|
||||
\begin{figure}[t]
|
||||
\centering
|
||||
\includegraphics[width=1\linewidth]{images/collection_pipeline_small.pdf}
|
||||
\caption{Data collection pipeline for process verification. The input data in the \ac{cpu} readings from the Azure dataset. The replay script stresses the local machine to replicate the activity on the \ac{vm}. The captured power consumption and processes list are preprocessed into usable training data for the prediction model.}
|
||||
\label{fig:pipeline}
|
||||
\end{figure}
|
||||
|
||||
This approach leverages two distinct sources of information.
|
||||
Figure~\ref{fig:pipeline} illustrates the data collection pipeline for each source of information.
|
||||
The first source is the list of processes.
|
||||
This list is accessible by any privileged users through \ac{os} utilities on every common \acp{os}.
|
||||
All implementations in this study use the \texttt{ps} command on the Debian 12 distribution.
|
||||
This command lists a lot of information from the processes that are retrieved from the \texttt{/proc} virtual file system.
|
||||
Out of all the available information, only the command and the state of the process are collected and used for training the model.
|
||||
The choice of collecting the complete command associated with each process stems from the necessity of differentiating instances of the same program working in different modes.
|
||||
From a power consumption point of view, programs performing different tasks should be considered independent to enable the prediction model to learn their power profile independently of the program name.
|
||||
The collection of the process list uses a \texttt{bash} script whose main loops consist of listing the processes and storing the information in a \ac{tsv} file.
|
||||
The target sampling rate was set to 10Hz, with actual sampling rates ranging from 8Hz to 10Hz depending on the hardware capabilities.
|
||||
|
||||
The second source of information is the power consumption of the \ac{cpu}.
|
||||
There are two main approaches for measuring the power: (1) placing a current sensing device in series with the power cable and (2) attaching a wireless current clamp around the power cable.
|
||||
While the second method is less intrusive, early exploratory work revealed that the measured values carried more noise, and that could affect the performance of the method.
|
||||
Thus, we chose to place the current sensing device in series with the power cable to access the best raw data possible.
|
||||
The current sensor consists of a \ac{pcb} that the current traverses.
|
||||
A Hall effect sensor produces a voltage proportional to the current, and this voltage is amplified and digitized before being sent to a storage server.
|
||||
The sensor samples the current at 10kHz.
|
||||
This high sampling rate is much higher than the sampling rate of the process list (to which the power trace must be reduced), but the extra information is useful for reducing the noise while down-sampling.
|
||||
|
||||
\subsection{Feature Engineering}\label{sec:feature-engineering}
|
||||
|
||||
Each source of information undergoes a pre-processing phase to form the training and testing dataset necessary for this evaluation.
|
||||
|
||||
\subsubsection{Process List}
|
||||
For the processes, the main task is the encoding of the occurrences in a format suitable for a machine-learning model.
|
||||
The collection file contains, for each timestamp, the command and state of all processes.
|
||||
A natural encoding is multi-hot, where each unique command --- across the whole collection file --- is associated with a position in an array.
|
||||
Each cell of the encoded array is populated with the number of occurrences of the associated command.
|
||||
However, this method encodes the occurrence of a process but not its state.
|
||||
To encode the state, we first separate all possible states as either consuming power or not consuming power.
|
||||
As an example, all processes with the \textit{running} state are actively running on the machine and thus using the \ac{cpu} and consuming power.
|
||||
On the other hand, all processes with the \textit{sleeping} state are idle and do not affect the power consumption.
|
||||
Using this binary partition of all states, two encoding arrays are created.
|
||||
The first array encodes the occurrences of the consuming processes, and the second encodes the occurrences of the non-consuming processes.
|
||||
These two arrays can be concatenated along either axis depending on the input shape of the machine learning model used.
|
||||
|
||||
\subsubsection{Power Trace}
|
||||
For the power trace, the pre-processing steps involve filtering and downsampling.
|
||||
The capture system produces raw power traces sampled at 10kHz.
|
||||
However, these traces must contain a single sample for each process list retrieved from the machine.
|
||||
Instead of sub-sampling the power trace to match the timestamps of the process list dataset (and loosing all extra information), some noise filtering takes place before the resampling of the trace.
|
||||
The filter is a rolling median function with a time window of one second and centred around the middle sample.
|
||||
Then the trace is down-sampled using the nearest power value for each process list timestamp.
|
||||
When loading the trace for analysis, a second median filter with a time window of 10 seconds helps remove more of the noise that affect the trace.
|
||||
|
||||
The final pre-processed data is two arrays.
|
||||
The first is a one-dimensional array of the power consumption of the \ac{cpu} at each timestamp.
|
||||
The second is a two-dimensional array where each row contains the multi-hot encoded information of all listed processes and their state at each timestamp.
|
||||
All data for the two case studies presented in this paper are freely available online \cite{zenodo-dataset}.
|
||||
|
||||
\subsubsection{Model}
|
||||
The task of predicting the power using a list of processes is a typical regression task.
|
||||
Each process has a power consumption value, and all consumptions add up to form the global power consumption of the \ac{cpu}.
|
||||
For processes always present in the list (for example, the init process), the model might not be able to learn its specific power consumption as it cannot be isolated from other constant or mandatory processes.
|
||||
Additionally, some process's consumption might be dependent on the presence of other processes.
|
||||
These potential dependencies motivate the selection of a neural network model over a simpler linear regression approach.
|
||||
Although no claim is made that the selected model is optimal for the task, we found from empirical evaluations that satisfactory results were achievable with an \ac{mlp} network composed of a few inner layers.
|
||||
|
||||
The selected network is a densely connected \ac{mlp} network with five inner layers of size $128,128,128,100,10$ and a single output layer value (see Figure~\ref{fig:model}), created using the Keras Python library \cite{chollet2015keras}.
|
||||
The training uses the Adam optimizer with an \ac{mae} loss, a batch size of 1024 and 100 epochs without an early stopping strategy.
|
||||
Additionally, dropouts with rates $0.3,0.3,0.3,0.1$ were added to the first four inner layers.
|
||||
|
||||
|
||||
\begin{figure}[t]
|
||||
\centering
|
||||
\includegraphics[width=1\linewidth]{images/model.pdf}
|
||||
\caption{The chosen model for this study is an \ac{mlp} with five densely connected hidden layers. The input is a 2D array populated with the number of occurrences of each process at a point in time. The first dimension contains the running processes, and the second is the sleeping processes. The output is a single number corresponding to the predicted power consumption at this instant. The model predicts the power at each instant independently from the previous or future observation.}
|
||||
\label{fig:model}
|
||||
\end{figure}
|
||||
|
||||
|
||||
\section{Case Study 1}
|
||||
|
||||
%To demonstrate the capabilities of the proposed approach, this paper presents two case study\agd{update if needed} that replicates real machine tasks.
|
||||
This first case study aims at evaluating the ability of a machine-learning model to infer the power consumption of the \ac{cpu} from the list of processes.
|
||||
To this purpose, we must acquire ground truth power consumption and process information during machine activity for training and validation.
|
||||
To the best of our knowledge, no dataset containing these information is publicly available.
|
||||
To provide a realistic evaluation, the captured data is based on a publicly available dataset of real production \ac{vm} deployed on the Azure cloud service \cite{cortez2017resource,azure-dataset}.
|
||||
However, this dataset only provides \ac{cpu} activity readings.
|
||||
To build the training dataset required for this experiment (process list and power consumption), we replicated the activity provided by the Azure dataset on multiple machines instrumented for collecting all required data (see Section~\ref{sec:collection}).
|
||||
|
||||
\subsection{Data Preparation}
|
||||
The core principle for replaying the dataset is to run a task on the machine with a target \ac{cpu} usage matching the value in the Azure dataset.
|
||||
The raw \ac{cpu} readings are values between 0\% and 100\% that are captured per \ac{vm}.
|
||||
|
||||
The initial idea would be to consider each sample iteratively and use the raw readings as the target usage.
|
||||
However, this approach would require running processes with different target usage (considered different processes) for consecutive values slightly varying around the same average.
|
||||
This approach would be an unfair replay that produces a large number of unique processes registered in the process list even when only a few processes are running on the source \ac{vm}.
|
||||
This artificial variety would make it harder for a model to learn the consumption associated with each process and would not correctly represent the activity on the production machine.
|
||||
To alleviate this issue, we first bin the \ac{cpu} readings in ten equal sections of ten percent usage each.
|
||||
Thus, all readings gravitating around a unique value are represented by the same process.
|
||||
|
||||
After binning the \ac{cpu} readings, we group the \ac{vm} in consolidated groups averaging 80\% \ac{cpu} usage.
|
||||
\ac{vm} consolidation --- also called \ac{vm} packing --- is the practice of grouping compatible virtual instances on the same hardware to optimize resource usage.
|
||||
The target of 80\% usage is the recommended average from \ac{aws}.
|
||||
Optimizing the \ac{vm} packing is a field of research in itself \cite{cortez2017resource} and is outside the scope of this study.
|
||||
We used a simple algorithm to pack \acp{vm} into consolidated groups by adding randomly selected \ac{vm} until the average activity is reached or exceeded.
|
||||
|
||||
The Azure dataset contains 2.6 million traces of individual \ac{vm}.
|
||||
To get a representative sample of all traces, we randomly selected 388 \ac{vm} traces to place in 71 consolidated replay groups.
|
||||
These groups were replayed on four different machines (see Table~\ref{tab:machines}).
|
||||
Multiple machines enable replaying more traces --- achieving a more accurate representation of the dataset --- and including some hardware diversity to help identify if some hardware is more suitable for this approach.
|
||||
|
||||
|
||||
|
||||
\begin{table}
|
||||
\centering
|
||||
\begin{tabular}{llll}
|
||||
\toprule
|
||||
Machine & CPU & Clock & RAM\\
|
||||
\midrule
|
||||
1 & i7-6700 (8) & 4.00 GHz & 16 GiB \\
|
||||
2 & E5-2620 v3 (12) & 3.20 GHz & 32 GiB \\
|
||||
3 & i7-2600 (8) & 3.80 GHz & 8 GiB \\
|
||||
4 & i7-3770 (8) & 3.90 GHz & 16 GiB \\
|
||||
\bottomrule\\
|
||||
\end{tabular}
|
||||
\caption{Specifications of the machines used for replaying the CPU activity from the Azure dataset.}
|
||||
\label{tab:machines}
|
||||
\end{table}
|
||||
|
||||
|
||||
\subsection{Results}
|
||||
Figure~\ref{fig:prediction} presents an example of the ground truth power consumption and the prediction.
|
||||
There are two elements that are interesting to notice in the figure.
|
||||
First, the power spikes associated with the processes are correctly predicted by the model.
|
||||
It is clear that, given the training data, the model can learn the power consumption associated with each process and sum them to reach a prediction consistent with the ground truth at a macro scale.
|
||||
On a per-sample scale, the ground truth contains noise that is impossible for the model to predict, given the input data.
|
||||
In a computer, sources of noise to the power consumption are myriad, and thus, it is expected that the prediction only outputs an average power level.
|
||||
|
||||
To compare the prediction of the model with the ground truth quantitatively, one common metric in machine learning is the \ac{mse}.
|
||||
The \ac{mse} computes the average of the point-wise square of the error.
|
||||
Table~\ref{tab:mse} presents the \ac{mse} values for both the normal and simulated attack version of each consolidated \ac{vm}.
|
||||
From these values, we can infer two important elements.
|
||||
First, the attack \ac{mse} is higher in 89\% of the traces.
|
||||
These results (similar to an ablation study) indicate that the model does extract valuable information from the input process list, as the prediction becomes worse when these are removed.
|
||||
The second important point comes from the relatively high number of runs where the \ac{mse} does not degrade when the process list is modified.
|
||||
This second element indicates that the \ac{mse} cannot be the determining value for detecting an attack as it does not robustly capture the presence of an attack.
|
||||
|
||||
To address the second point, we propose to use a different value to evaluate the performance of the prediction.
|
||||
When studying the prediction more closely, it becomes apparent that the prediction suffers from a misalignment with respect to the ground truth.
|
||||
Although the patterns are correct, the difference in timing introduces large errors around the transitions that greatly influence the \ac{mse} score.
|
||||
The objective is to choose a distance metric robust to static or dynamic misalignment between the two source signals.
|
||||
The \ac{dtw} distance was proposed for solving exactly this issue.
|
||||
When applied to two signals, \ac{dtw} computes an optimal match distance that is tolerant to static and dynamic shifts.
|
||||
Because the attacks mostly affect the amplitude and not the timing of the power consumption patterns, the \ac{dtw} distance should increase when an attack is present and the prediction worsens.
|
||||
Table~\ref{tab:cs1} presents the results for the \ac{dtw} distance for each run of a consolidated \ac{vm} for both the normal and the attack versions of the input process list.
|
||||
We can confirm from these values that the \ac{dtw} distance is a more robust metric for evaluating the performance of the model in predicting the power consumption.
|
||||
In 94\% of the runs, the value increases for the attack version compared with the normal version.
|
||||
|
||||
\begin{figure}[t]
|
||||
\centering
|
||||
\includegraphics[width=1\linewidth]{images/prediction.pdf}
|
||||
\caption{Example of ground truth power consumption and prediction from the model. The regular spikes in the prediction corresponds to state transition in the replay scripts that generate wide changes in the process list. The power levels generated by the stress program are correctly learned and predicted by the model, although miss-alignments are visible between the ground truth and the prediction.}
|
||||
\label{fig:prediction}
|
||||
\end{figure}
|
||||
|
||||
\begin{table*}
|
||||
\centering
|
||||
\begin{tabular}{cc|cc|cc|cc}\toprule
|
||||
\multicolumn{2}{c}{\textbf{Machine 1}} & \multicolumn{2}{c}{\textbf{Machine 2}} & \multicolumn{2}{c}{\textbf{Machine 3}} & \multicolumn{2}{c}{\textbf{Machine 4}}\\
|
||||
|
||||
\textbf{MSE} & \textbf{Attack MSE} & \textbf{MSE} & \textbf{Attack MSE} & \textbf{MSE} & \textbf{Attack MSE} & \textbf{MSE} & \textbf{Attack MSE}\\
|
||||
\midrule
|
||||
|
||||
0.016&\textbf{0.024}&0.104&\textbf{0.163}&0.045&\textbf{0.051}&0.02&\textbf{0.142}\\
|
||||
0.021&\textbf{0.027}&0.085&\textbf{0.088}&0.053&\textbf{0.055}&0.162&\textbf{0.21}\\
|
||||
0.012&\textbf{0.013}&0.023&\textbf{0.636}&0.07&\textbf{0.083}&0.07&\textbf{0.096}\\
|
||||
0.069&\textbf{0.13}&0.071&\textbf{0.107}&0.001&\textbf{0.001}&0.063&\textbf{0.08}\\
|
||||
0.02&\textbf{0.031}&0.062&\textbf{0.235}&0.051&\textbf{0.078}&0.134&\textbf{0.537}\\
|
||||
\textbf{0.068}&0.063&0.06&\textbf{0.089}&0.026&\textbf{0.03}&0.167&\textbf{0.306}\\
|
||||
\textbf{0.029}&0.028&0.009&\textbf{0.011}&0.014&\textbf{0.026}&0.057&\textbf{0.243}\\
|
||||
0.022&\textbf{0.034}&0.013&\textbf{0.024}&0.001&\textbf{0.001}&0.129&\textbf{0.238}\\
|
||||
0.002&\textbf{0.079}&\textbf{0.042}&0.041&\textbf{0.084}&0.067&0.099&\textbf{0.138}\\
|
||||
0.028&\textbf{0.044}&0.095&\textbf{0.099}&0.061&\textbf{0.075}&0.004&\textbf{0.005}\\
|
||||
0.007&\textbf{0.008}&0.015&\textbf{0.017}&\textbf{0.044}&0.033&0.015&\textbf{0.02}\\
|
||||
\textbf{0.035}&0.032&0.027&\textbf{0.048}&0.096&\textbf{0.11}&0.01&\textbf{0.011}\\
|
||||
0.085&\textbf{0.099}&0.028&\textbf{0.05}&\textbf{0.044}&0.039&0.041&\textbf{0.046}\\
|
||||
0.067&\textbf{0.097}&0.028&\textbf{0.044}&0.075&\textbf{0.107}&0.046&\textbf{0.05}\\
|
||||
0.006&\textbf{0.015}&0.011&\textbf{0.012}&0.081&\textbf{0.082}&0.102&\textbf{0.166}\\
|
||||
\textbf{0.059}&0.035&0.113&\textbf{0.128}&0.054&\textbf{0.151}&0.038&\textbf{0.068}\\
|
||||
0.015&\textbf{0.026}&0.004&\textbf{0.004}&0.02&\textbf{0.023}&0.068&\textbf{0.134}\\
|
||||
0.033&\textbf{0.04}&0.087&\textbf{0.146}&0.02&\textbf{0.027}&0.044&\textbf{0.045}\\
|
||||
\bottomrule\\
|
||||
\end{tabular}
|
||||
\caption{\ac{mse} of the \ac{cpu} power consumption prediction for each machine for both the correct process list and the modified process list. The prediction \ac{mse} increases in 64 runs and decreases in 8 runs out of the total 72 runs. These results illustrate the capability of the model to learn power consumption levels associated with processes and the effect of erroneous entries in the process list.}
|
||||
\label{tab:mse}
|
||||
\end{table*}
|
||||
|
||||
\begin{table*}
|
||||
\centering
|
||||
\begin{tabular}{cc|cc|cc|cc}\toprule
|
||||
\multicolumn{2}{c}{\textbf{Machine 1}} & \multicolumn{2}{c}{\textbf{Machine 2}} & \multicolumn{2}{c}{\textbf{Machine 3}} & \multicolumn{2}{c}{\textbf{Machine 4}}\\
|
||||
|
||||
\textbf{DTW} & \textbf{Attack DTW} & \textbf{DTW} & \textbf{Attack DTW} & \textbf{DTW} & \textbf{Attack DTW} & \textbf{DTW} & \textbf{Attack DTW}\\
|
||||
\midrule
|
||||
1040.0&\textbf{1400.0}&2200.0&\textbf{8540.0}&860.0&\textbf{1860.0}&\textbf{3770.0}&1810.0\\
|
||||
1350.0&\textbf{1710.0}&1190.0&\textbf{6560.0}&2360.0&\textbf{2970.0}&4110.0&\textbf{7450.0}\\
|
||||
850.0&\textbf{1690.0}&1140.0&\textbf{12000.0}&2710.0&\textbf{5320.0}&3010.0&\textbf{3730.0}\\
|
||||
3570.0&\textbf{9910.0}&2120.0&\textbf{5210.0}&804.0&\textbf{2900.0}&2610.0&\textbf{3450.0}\\
|
||||
1020.0&\textbf{1460.0}&2440.0&\textbf{7670.0}&2080.0&\textbf{2870.0}&3590.0&\textbf{20000.0}\\
|
||||
2340.0&\textbf{2870.0}&2220.0&\textbf{4020.0}&1320.0&\textbf{2280.0}&2720.0&\textbf{9070.0}\\
|
||||
1380.0&\textbf{2010.0}&765.0&\textbf{1660.0}&1670.0&\textbf{1810.0}&3590.0&\textbf{5370.0}\\
|
||||
874.0&\textbf{2290.0}&1020.0&\textbf{2800.0}&\textbf{76.0}&75.7&4180.0&\textbf{8180.0}\\
|
||||
997.0&\textbf{1540.0}&1650.0&\textbf{3330.0}&\textbf{3580.0}&2070.0&3520.0&\textbf{6710.0}\\
|
||||
1900.0&\textbf{2780.0}&2460.0&\textbf{5540.0}&2210.0&\textbf{3310.0}&388.0&\textbf{851.0}\\
|
||||
421.0&\textbf{447.0}&1000.0&\textbf{1670.0}&1900.0&\textbf{3090.0}&1140.0&\textbf{1570.0}\\
|
||||
2230.0&\textbf{2400.0}&1020.0&\textbf{2930.0}&3020.0&\textbf{3140.0}&944.0&\textbf{1890.0}\\
|
||||
3380.0&\textbf{3710.0}&1220.0&\textbf{3150.0}&2610.0&\textbf{2610.0}&1680.0&\textbf{2820.0}\\
|
||||
1120.0&\textbf{5260.0}&1840.0&\textbf{2860.0}&2520.0&\textbf{4960.0}&2000.0&\textbf{2460.0}\\
|
||||
589.0&\textbf{1050.0}&764.0&\textbf{1730.0}&4320.0&\textbf{5920.0}&3800.0&\textbf{4620.0}\\
|
||||
1410.0&\textbf{2410.0}&3160.0&\textbf{5930.0}&3040.0&\textbf{6880.0}&2160.0&\textbf{3650.0}\\
|
||||
599.0&\textbf{9910.0}&321.0&\textbf{670.0}&1130.0&\textbf{3710.0}&2600.0&\textbf{4740.0}\\
|
||||
X&X&3850.0&\textbf{7480.0}&\textbf{1710.0}&1540.0&1670.0&\textbf{3870.0}\\
|
||||
\bottomrule\\
|
||||
\end{tabular}
|
||||
\caption{\ac{dtw} distance between the predicted power and the ground truth during normal operation and simulated attack. The expected behaviour is an increase in the distance during the attack, representing the difficulty of the model to predict the correct pattern when the process information is wrong. The data confirm the expected behaviour in 94\% of the replayed consolidated \ac{vm}, confirming the soundness of the approach.}
|
||||
\label{tab:cs1}
|
||||
\end{table*}
|
||||
|
||||
\section{Case Study 2}
|
||||
The first case study provided evidence supporting the two statements: (1) \textit{A model can learn to predict the power consumption of the \ac{cpu} using the instantaneous process list with satisfactory accuracy.}, and (2) \textit{When the process list is modified to hide processes with significant \ac{cpu} usage, the accuracy of the prediction degrades.}
|
||||
Establishing these statements is an important step on the way to establishing if this method is suitable for detecting process list tampering and hidden malware.
|
||||
However, the experiment conducted in the first case study does not characterize the type of malware that can be detected.
|
||||
|
||||
By the very nature of the proposed approach, we already know that malware inducing marginal amounts of \ac{cpu} usage can likely evade detection.
|
||||
Indeed, if the inaccuracy added by the missing process information falls within the nominal inaccuracy of the model, then there is no basis for establishing that the process list is wrong.
|
||||
Similarly, malware requiring a high \ac{cpu} usage for a very short time would cause a thin spike in the power data that could get removed due to the reprocessing of the power trace.
|
||||
|
||||
From these observations, it appears that the important metric for establishing if a process can be detected in the power consumption is the total energy that it requires to perform its operation.
|
||||
The malware authors have some control over the power profile of the program --- for example, selecting a fast approach that maximizes \ac{cpu} usage over a short time of a discrete approach that performs little operations over a longer time ---, but they can never reduce their energy usage to zero.
|
||||
|
||||
In this case study, we want to illustrate the capabilities of the proposed approach for detecting hidden processes using different power profiles.
|
||||
We start by establishing a measure of the power consumption of a process in terms of time and \ac{cpu} usage.
|
||||
Let us consider a program $A$ using 50\% of the \ac{cpu} for 10 seconds.
|
||||
We measure its energy requirement as $E_A = 50 \textrm{CPU} \times 10s = 500 CPU.s$.
|
||||
Let us also suppose that the task of the program can be parallelized to take advantage of the multiple cores or modern \acp{cpu}.
|
||||
In this case, the program author has a range of activity profiles available.
|
||||
On one end, the program can use 100\% of the processor to minimize time.
|
||||
On the other, the program can spread the \ac{cpu} usage over a very large amount of time.
|
||||
Between these two extremes, all combinations of activity and duration that respect the total activity profile are possible.
|
||||
Figure~\ref{fig:malware_area} illustrates the different activity profiles that a hypothetical malware can take.
|
||||
|
||||
\begin{figure}[t]
|
||||
\centering
|
||||
\includegraphics[width=1\linewidth]{images/profiles.pdf}
|
||||
\caption{A program can spread its activity from a minimum duration --- when using all available \ac{cpu} resources --- to an arbitrarily long duration. Regardless of the pattern, the total activity remains the same. The second case study establishes which activity profiles are detectable by the proposed approach.}
|
||||
\label{fig:malware_area}
|
||||
\end{figure}
|
||||
|
||||
The point of the second case study is to establish the performance of the proposed method at detecting malware with different activity profiles.
|
||||
|
||||
\subsection{Data Collection and Detection Method}
|
||||
For this case study, we replayed and collected the same \ac{vm} as for the first case study.
|
||||
During the last 20\% of the trace --- that are excluded from training ---, a pre-defined malware script executed three instances of fake malware following three different activity profiles.
|
||||
The three instances of the malware are: (1) 100\% \ac{cpu} usage for two minutes, (2) 80\% \ac{cpu} usage for two minutes and 30 seconds, and (3) 60\% for three minutes and 20 seconds, following a constant total \ac{cpu} usage of $2000 CPU.s$.
|
||||
|
||||
After the data is collected, we split each trace --- following the same method as for the first case study --- and train a new model for each of them.
|
||||
The model predicts the remaining 20\% of the trace using the list of processes.
|
||||
Although the malware process occurrences are only present in the test part of the dataset --- and thus the model should not be able to predict their associated power ---, we still remove the occurrence from the test part to ensure that the input data resemble real data as closely as possible.
|
||||
|
||||
The detection relies on the comparison between the predicted power trace and the real power trace.
|
||||
One intuitive approach would be to compute the absolute difference between the two traces and set a threshold above which an attack is detected.
|
||||
While this approach does detect attacks in the correct periods corresponding to real attacks, early evaluations revealed that too many other parts of the trace were also detected as attacks.
|
||||
This was due to large error spikes due to timing inconsistencies between the process list information and the power consumption trace.
|
||||
The top graph of Figure~\ref{fig:cs2} illustrates this timing shift.
|
||||
We can see in this graph that the predicted power follows the same pattern as the ground truth trace, but their transitions are not perfectly aligned.
|
||||
This synchronization issue prompted the development of a more robust detection method that is more tolerant of timing inconsistencies and focuses more on pattern predictions.
|
||||
|
||||
The chosen solution is a combination of a sliding window and the \ac{dtw} distance.
|
||||
The \ac{dtw} distance is adequate for computing a similarity score between time series with different time references --- either offset or dilation/compression.
|
||||
To apply \ac{dtw}, we apply a sliding window of width 1000 samples --- approximately 10 seconds --- with a stride of one sample.
|
||||
For each window, the \ac{dtw} distance between the prediction and the ground truth is computed.
|
||||
The bottom graph of Figure~\ref{fig:cs2} shows the windowed \ac{dtw} distance corresponding to the traces in the top graph.
|
||||
Now that a more robust distance metric is available, a threshold calculated as $1.1\times max(D_{[0,4000]})$ --- $D$ the windowed \ac{dtw} distance --- is applied to determine which periods contain attacks.
|
||||
|
||||
\begin{figure*}[t]
|
||||
\centering
|
||||
\includegraphics[width=1\linewidth]{images/attack_detection.pdf}
|
||||
\caption{Visualization of the detection of hidden processes using the predicted power consumption. The top graph presents the real power consumption of the machine (Ground Truth), the prediction of the model over the same period, and the periods when the malware is running. The bottom graph presents the sliding DTW distance and the detected attack periods. An attack is detected when the DTW distance between the prediction and the ground truth exceeds the threshold. The highlighted periods show that, for this example, at least one detection is made for each real attack.}
|
||||
\label{fig:cs2}
|
||||
\end{figure*}
|
||||
|
||||
\subsection{Results}
|
||||
|
||||
For each run, we compute the accuracy, recall, and $F-1$ score of the attack prediction.
|
||||
Table~\ref{tab:cs2_results} presents the performance of the detection for each replayed \ac{vm}.
|
||||
It is important to notice that each \ac{vm} was replayed on a single machine, thus the results are not to be compared linewise.
|
||||
The bottom line presents the results of each metric averaged across all \ac{vm} of the machines.
|
||||
|
||||
To interpret the results, it is important to understand the type of problem studied.
|
||||
The detection of attacks in a time series is an infrequent event detection problem where most of the labels to predict are "no attack".
|
||||
As it is explained by McCue \cite{MCCUE20073}, this type of problem cannot use the same classical baseline as other machine learning problems because naive solution can yield seemingly excellent results.
|
||||
For example, in the case of this study, a naive model that always predict "no attack" achieves remarkable results with 97\% precision, 100\% recall and 98\% $F_1$.
|
||||
It is obvious that never predicting an attack should not be a high-achieving solution to this problem, and there lie the difficulty of interpreting the results.
|
||||
Instead of using the baseline results of naive or random methods, the performance metrics should aim for reaching their best possible value (100\% for the all three considered metrics).
|
||||
|
||||
The first important information from the results is that the average metrics achieve a score of at least 0.75.
|
||||
This result is promising as it indicates that the detection method does detect some attacks.
|
||||
However, the individual results are also interesting.
|
||||
For some traces, the performance can vary widely from a near-perfect detection to a hardly adequate one.
|
||||
This variety indicates that the type of hardware and the activity of the \ac{vm} have an influence on the detection performance.
|
||||
The root cause and precise nature of this influence is hard to determine with certitude and opens the way for future works dedicated to identifying more accurately the best environment for this approach.
|
||||
|
||||
|
||||
\begin{table*}
|
||||
\centering
|
||||
\begin{tabular}{ccc|ccc|ccc|ccc}\toprule
|
||||
\multicolumn{3}{c}{\textbf{Machine 1}} & \multicolumn{3}{c}{\textbf{Machine 2}} & \multicolumn{3}{c}{\textbf{Machine 3}} & \multicolumn{3}{c}{\textbf{Machine 4}}\\
|
||||
P & R & $F_1$ & P & R & $F_1$ & P & R & $F_1$ & P & R & $F_1$\\
|
||||
\midrule
|
||||
0.874&0.951&0.845&0.895&0.874&0.93&0.568&0.675&0.842&0.935&0.632&0.72\\
|
||||
0.828&0.93&0.801&0.928&0.91&0.882&0.746&0.874&0.867&0.894&0.768&0.887\\
|
||||
0.707&0.939&0.838&0.874&0.841&0.788&0.468&0.798&0.768&0.833&0.574&0.819\\
|
||||
0.698&0.933&0.946&0.916&0.83&0.924&0.868&0.92&0.758&0.927&0.89&0.914\\
|
||||
0.836&0.924&0.763&0.949&0.877&0.905&0.74&0.94&0.856&0.911&0.751&0.942\\
|
||||
0.885&0.891&0.758&0.788&0.581&0.889&0.762&0.794&0.631&0.89&0.76&0.791\\
|
||||
0.852&0.908&0.718&0.701&0.869&0.883&0.847&0.654&0.836&0.891&0.777&0.676\\
|
||||
0.839&0.911&0.848&0.916&0.916&0.914&0.867&0.835&0.876&0.879&0.831&0.853\\
|
||||
0.906&0.75&0.716&0.728&0.885&0.866&0.816&0.46&0.892&0.803&0.763&0.527\\
|
||||
0.703&0.939&0.762&0.956&0.839&0.927&0.76&0.955&0.765&0.93&0.761&0.953\\
|
||||
0.719&0.89&0.739&0.933&0.848&0.81&0.828&0.891&0.778&0.831&0.78&0.901\\
|
||||
1.0&0.752&0.803&0.831&1.0&0.824&0.744&0.666&1.0&0.778&0.767&0.711\\
|
||||
0.718&0.902&0.73&0.873&0.847&0.91&0.854&0.85&0.777&0.905&0.787&0.796\\
|
||||
0.785&0.896&0.838&0.723&0.826&0.885&0.828&0.85&0.796&0.89&0.833&0.782\\
|
||||
0.784&0.944&0.701&0.858&0.833&0.849&0.837&0.866&0.783&0.877&0.763&0.837\\
|
||||
0.694&0.919&0.921&0.908&0.833&0.908&0.913&0.776&0.757&0.912&0.872&0.806\\
|
||||
0.71&0.889&0.713&0.929&0.842&0.877&0.843&0.881&0.77&0.882&0.772&0.892\\
|
||||
0.708&0.943&0.685&0.827&0.841&0.844&0.828&0.849&0.769&0.873&0.75&0.796\\
|
||||
\midrule
|
||||
\multicolumn{12}{c}{\textbf{Average}}\\
|
||||
\midrule
|
||||
0.791&0.85&0.807&0.901&0.879&0.88&0.785&0.784&0.768&0.863&0.807&0.811\\
|
||||
\bottomrule\\
|
||||
\end{tabular}
|
||||
\caption{Results of the detection of hidden malware activity in the replayed \ac{vm}. Each machine replayed 18 different \ac{vm}. The results are not to be compared linewise across machines. The performance metrics are precision (P), recall (R) and the $F_1$ score of the attack vector. The average results per machine are consistently above 0.75 $F_1$ score. These results illustrate the promising results of the approach but also indicate that the type of machine and activity have an influence on the performance and should be taken into account.}
|
||||
\label{tab:cs2_results}
|
||||
\end{table*}
|
||||
|
||||
\section{Discussion}
|
||||
|
||||
In this section, we elaborate on aspects of the study that we think are important to further explain.
|
||||
|
||||
\subsection{Software Power Measurement}\label{sec:soft-power}
|
||||
The implementation of the approach proposed in this study can seem prohibitively complex due to the use of hardware components added to the machine to protect.
|
||||
After all, software solutions exist to measure or estimate the power consumption of a \ac{cpu} package. Removing the hardware components would enable mass deployment of this method to large fleets of machines at a fraction of the cost.
|
||||
|
||||
However, the hardware measurement of the power consumption is the guarantee of an independent and trustworthy source of information.
|
||||
As soon as the power measurement mechanism relies on the collaboration of the protected machine, it is considered tainted and thus cannot be used for verifying the integrity of the list of processes.
|
||||
For this reason, the implementation of this method requires the use of an independent measurement of the power.
|
||||
|
||||
|
||||
\subsection{Evasion Techniques}\label{sec:evasion}
|
||||
As mentioned in the attacker model section, one of the goals is to provide a method for detecting process list tampering that does not rely on security-by-obscurity.
|
||||
This results in complete transparency from the defender about what method is used.
|
||||
We thus assume that the attacker knows that the power consumption of the machine is being correlated with the process list to detect tampering --- although the implementation details, such as the model architecture, temporal resolution, or training data, might be unknown.
|
||||
It is important to notice that this knowledge offers some evasion possibilities for the attacker.
|
||||
|
||||
Let us suppose that an attacker can infect a machine and gain visibility on the running processes at all times.
|
||||
Let us also suppose that the attacker knows exactly the \ac{cpu} activity profile of their malware.
|
||||
In this situation, the attacker could select an ensemble of legitimate processes that, together, match the activity profile of their malware.
|
||||
Then, when it is time to run the malware, the attacker would delete it from the process list but inject in its place the group of legitimate processes to explain the increase of \ac{cpu} activity.
|
||||
|
||||
From the point of view of the proposed approach, this modification would be invisible.
|
||||
However, that does not automatically imply that the attack would remain undetected.
|
||||
The proposed method is not meant to be placed at the end of the cyber-security pipeline.
|
||||
It is actually the opposite, as this verification step should be performed in the early stages of the data gathering.
|
||||
The point is to provide assurance that the list of processes is complete so that other tools can use it for detecting malware or applying security rules.
|
||||
In the case of this evasion, the proposed method fails to recognize a tampered list but forces the attacker to modify it in a way that should trigger other methods down the line.
|
||||
|
||||
This theoretic evasion illustrates the necessity to implement the proposed approach as an additional layer and not a solution in itself.
|
||||
Verifying the integrity of the process list is not a replacement for analyzing it.
|
||||
|
||||
\section{Future Work}
|
||||
This work constitutes --- to the best of our knowledge --- the first exploration in using \ac{sci} to validate the collected information from a potentially infected machine.
|
||||
Being at the interface of cyber-security and machine learning, there are many aspects of this work that deserve a dedicated and meticulous study to reach optimal performance.
|
||||
The input data collected from the machine for this study is limited to the list of processes and their state reduced to a binary choice.
|
||||
These represent only a very small part of all information that could be collected and verified using the proposed approach.
|
||||
The reported resource usage (CPU, RAM, Disk I/O, Network, etc.), as well as more detailed information like the full process state range, would be interesting to validate and could enable the detection of other types of malware.
|
||||
On the side-channel side, power consumption is an obvious first choice as it is easy to measure and fairly informative, but other channels could provide useful complementary information.
|
||||
Finally, the machine learning model used in this study is only one example of an architecture that performs well for this task.
|
||||
|
||||
Our aim for the continuation of this work is to provide a more general framework of models capable of using multi-model input and predicting multiple side-channel activity profiles, providing a more complete view of the machine's activity and reducing the hiding places of the malware.
|
||||
|
||||
\section{Conclusion}
|
||||
This study provides an evaluation of using the power consumption of a machine to correlate and validate the list of processes before its use by an \ac{ids}.
|
||||
The independence of measurement provided by the \ac{sci} provides a ground truth against which the power predicted using the list of processes is compared.
|
||||
We illustrate the baseline performance of the prediction and, more importantly, the deviation that occurs when the list of processes is tampered with.
|
||||
This deviation enables the detection of hidden malware consuming \ac{cpu} resources while attempting to evade detection.
|
||||
The case studies illustrate the capability of the proposed approach in a consolidated \ac{vm} environment.
|
||||
To provide realistic evaluations, we replay public \ac{vm} activity traces from real instances.
|
||||
The proposed approach shows promising results for the \ac{sci} to be used as an additional complementary layer of protection against hidden malware.\\
|
||||
\newpage
|
||||
\clearpage
|
||||
\bibliographystyle{plain} % We choose the "plain" reference style
|
||||
\bibliography{biblio} % Entries are in the refs.bib file
|
||||
|
||||
|
||||
% that's all folks
|
||||
\end{document}
|
||||
|
||||
|
||||
5
procver/SnP/questions.tex
Normal file
5
procver/SnP/questions.tex
Normal file
|
|
@ -0,0 +1,5 @@
|
|||
Q: For Case Study 1, should I present both results or just one table?
|
||||
|
||||
Q: Should I insist on the fact that the dataset is public?
|
||||
|
||||
Q: Should I find a citation for the DTW distance metric?
|
||||
4
procver/SnP/utils.tex
Normal file
4
procver/SnP/utils.tex
Normal file
|
|
@ -0,0 +1,4 @@
|
|||
|
||||
% Comments commands
|
||||
\newcommand\agd[1]{{\color{red}$\bigstar$}\footnote{agd: #1}}
|
||||
\newcommand\cn{{\color{purple}\textsuperscript{[citation needed]}}}
|
||||
Loading…
Add table
Add a link
Reference in a new issue