Vrizlynn L L Thing

Zheng-Leong Chua

Smartphone Volatile Memory Acquisition for Security Analysis and Forensics Investigation

Keywords: Forensics Investigation Symbian, mobile devices, smartphones, volatile memory data acquisition, malware security and forensics analysis

published or not. The documents may come

Introduction

Mobile phones are becoming increasingly prevalent and sophisticated. They are continuously evolving into "smarter" devices (i.e. smartphones with higher processing power and enhanced features) to cater to the needs of users to stay connected anytime, anywhere, with information readily available. Due to the connection and processing capability of smartphones, illegal access to a wealth of information (for example, contacts list, emails, messages, downloaded confidential documents from email attachments) belonging to the users can be acquired from their smartphones with the appropriate technologies (for example, information theft malwares [START_REF] Thing | Mobile phone anomalous behaviour detection for real-time information theft tracking[END_REF], or mobile forensics tools). Therefore, the capabilities to perform in-depth security analysis to prevent and detect attacks, and forensics investigation to acquire evidence from these devices are essential.

Current mobile phone forensics tools are restricted to the acquisition and analysis of active files and data (i.e. logical data acquisition) from the Subscriber Identity Module (SIM), memory cards and the internal flash memory [START_REF] Willassen | Forensics and the GSM mobile telephone system[END_REF][START_REF] Casadei | Forensics and SIM cards: an overview[END_REF][START_REF] Kim | Data acquisition from cell phone using logical approach[END_REF][START_REF] Mokhonoana | Acquisition of a Symbian smart phone's content with an on-phone forensic tool[END_REF][START_REF] Distefano | An overall assessment of mobile internal acquisition tool[END_REF][START_REF] Jansen | Overcoming impediments to cell phone forensics[END_REF][START_REF] Hoog | Android forensics[END_REF]. There exists research work focusing on the low-level physical accquisition of raw data from the mobile phones' non-volatile memories [START_REF] Willassen | Forensic analysis of mobile phone internal memory[END_REF][START_REF] Al-Zarouni | Introduction to mobile phone flasher devices and considerations for their use in mobile phone forensics[END_REF][START_REF] Thing | Symbian smartphone forensics and security: Recovery of privacy-protected deleted data[END_REF][START_REF] Thing | Symbian smartphone forensics: Linear bitwise data acquisition and fragmentation analysis[END_REF], to support indepth forensics investigations and evidence analysis, but did not take the volatile memories into consideration.

On the other hand, to support smartphones volatile application data acquisition, loaded malware driver detection, malware behaviour and analysis, it is necessary to have the capability to perform raw volatile memory data acquisition from mobile devices. The ability to acquire the raw volatile memory data from a live device provides security analysts and forensics investigators with a complete picture and insight of the operational states of the live device. However, current anti-virus and anti-malware tools [START_REF] Thing | Mobile phone anomalous behaviour detection for real-time information theft tracking[END_REF][START_REF] Avg | Mobilation[END_REF][START_REF] Robota | Anti-virus scanner for symbian mobile phones[END_REF][START_REF] Dr | Mobile security suite[END_REF][START_REF] Lookout | Mobile security[END_REF] for smartphones are limited to the scanning of programs and files in the non-volatile storage space to carry out signature based virus detection.

In this paper, we propose a method to acquire raw volatile memory data from live Symbian smartphones and the methodology to analyse the acquired data to facilitate security analysis and forensics investigations. We develop the tools to conduct the proof-of-concept experiments on commercial Symbian smartphones. There are two main reasons for the choice on the Symbian OS in this research:

1. Even as Android and iOS is rising fast to become the most popular mobile OSes, with Android holding a market share of 52.5%, according to a mobile OS market share survey by Gartner [START_REF] Gartner | Market Share: mobile communication devices by region and country, 3q11[END_REF]18], Symbian still holds 16.9% of the market share and is the second most widely used OS in mobile phones.

In addition, based on the statistics provided by StatCounter [START_REF] Statcounter | Top 8 mobile operating systems[END_REF], Symbian is observed to be the top smartphones used for the purpose of mobile web browsing. 2. Nonetheless, little has been done on the research of Symbian smartphones live memory security and forensics analysis yet. The reason is that most modern mobile OSes (including Symbian), like generic computer system OSes, use a layer of abstraction such as the virtual memory instead of operating directly on the physical memory. This abstraction layer provides the ability to sandbox each process into its own memory space for security protection. Therefore, with this memory protection in place, a raw volatile memory acquisition tool would have to reside in the kernel space to gain access to the entire memory space [START_REF] Sales | Symbian os internals: Real-time kernel programming[END_REF][START_REF] Vomel | A survey of main memory acquisition and analysis techniques for the windows operating system[END_REF]. However, in Android, a process memory is exposed to the user-side through the procfs filesystem and this mechanism can be utilized to achieve the live volatile memory acquisition from smartphones running Android OS [START_REF] Thing | Live memory forensics of mobile phones[END_REF]. On the other hand, Symbian OS does not provide any such mechanism to be leveraged on. As such, it is necessary to investigate and devise a method for conducting a live volatile memory data acquisition pertaining to Symbian smartphones.

The rest of the paper is organised as follow. In Section 2, we present an overview of the existing work on mobile phone forensics research. In Section 3, we present the historical account of mobile forensics research specific to the Symbian smartphones. In Section 4, we present our investigation on the potential approaches to achieve a raw volatile memory data acquisition from commercial Symbian smartphones. We describe the design and the implementation of our live Symbian volatile memory acquisition tool, the problems we encountered and the solutions we devised, in Section 5. The experiments are described in Section 6. We also proposed the analysis methodology in Section 6. Conclusions follow in Section 7.

Mobile Phone Forensics Research

In this section, we present an overview of the existing mobile forensics work in general.

In an early work in 2003, Willassen [START_REF] Willassen | Forensics and the GSM mobile telephone system[END_REF] researched on the forensic investigation of GSM phones. The author presented the types of data of forensic relevance, which can exist on the phones, the SIM and the core network, and emphasized the need for more sound mobile forensics procedures and tools.

In 2006, Willassen [START_REF] Willassen | Forensic analysis of mobile phone internal memory[END_REF] proposed extracting the physical image of the mobile phone's internal flash memory by desoldering the memory chip and reading it from a device programmer. However, this method is too invasive and brings with it a high risk of chip damage if the extraction is not performed with high precision and care. Another proposed method was to read the memory through the boundary-scan (JTAG) test pins. The extracted memory was examined to detect the presence of deleted file contents. However, the test pins are usually not prominently shown and labelled. In this case, attempting to identify them may be very challenging and time consuming. There is also the possibility that these pins on the commercial smartphones are not accessible to users.

In the same year (2006), Casadei et al. [START_REF] Casadei | Forensics and SIM cards: an overview[END_REF] presented their SIMbrush tool developed for both the Linux and Windows platforms. The tool relied on the PCSC library and supported the acquisition of the entire file system, including the non standard files, on the SIM. However, files with restricted read access conditions could not be extracted.

In 2007, Kim et al. [START_REF] Kim | Data acquisition from cell phone using logical approach[END_REF] presented a tool to acquire the data from a Korea CDMA mobile phone's internal flash memory. The tool communicated with the phone through the RS-232C serial interface and was able to acquire the existing files on the phone using the underlying Qualcomm Mobile Station Modem diagnostic mode protocol.

In the same year (2007), Al-Zarouni [START_REF] Al-Zarouni | Introduction to mobile phone flasher devices and considerations for their use in mobile phone forensics[END_REF] studied the mobile phone flasher devices and considered their applicability in mobile phone forensics. Flasher devices were originally used to perform SIM unlocking and firmware flashing. Therefore, they offered access to the phone's flash memory. As they did not need installation on the phone, they were deemed to be forensically sound. However, their operations were not well-documented and since they were designed to write to the memory, the effect of evidence altering while performing a read was also unknown. Their reading capability and memory access range also varied for phones of different brands and models.

In 2008, Jansen et al. [START_REF] Jansen | Overcoming impediments to cell phone forensics[END_REF] proposed a phone manager protocol filtering technique by intercepting the data between the phone and the phone manager. The objective was to address the latency in the coverage of newly available phone models by existing forensic tools. The authors also proposed an identity module programming technique, to populate the phone's SIM with reference test data, so as to provide a baseline for the validation of SIM forensic tools.

In 2008, Zdziarski [START_REF] Zdziarski | iPhone forensics[END_REF] published a book on iPhone forensics which contains information on how to conduct forensic analysis of iPhone, iPhone 3G, and iPod Touch. The book covers information on the type of data that can be stored on an iPhone, the procedure to build a custom recovery toolkit, the recovery of the raw user disk partition, and the application of data carving techniques to recover deleted voicemail, images, emails, etc. from the phone.

In 2009, Hoog [START_REF] Hoog | Android forensics[END_REF] presented the existing forensic evidence acquisition tools for Android phones. The Android Debug Bridge (ADB) enabled interaction with the phone over the USB connection. Therefore, active files on the phone can be retrieved through the "adb pull" command. Other tools such as the Nandroid backup and Paraben Device Seizure also supported the extraction of files residing on the phone.

In 2010, Thing et al. [START_REF] Thing | Live memory forensics of mobile phones[END_REF] proposed a method to acquire live volatile memory data from Android smartphones. In Android, the process memory is exposed to the user-side through the procfs filesystem. The authors proposed utilizing the process tracing (ptrace) system call to suspend the target process, acquire a snapshot of its memory, and then resume its execution. A study and analysis of the dynamic characteristics of volatile data in the process memory was then carried out.

In 2011, Hoog and Strzempka [START_REF] Hoog | iPhone and iOS forensics[END_REF] published a book on iPhone and iOS forensics. The book covers information on the techniques to acquire evidentiary data from the iPhone, iPad and other iOS devices. It also provides practical advise on the securing of the devices, and the data and applications residing on them.

History of Symbian Smartphone Forensics

In 2007, Mokhonoana and Olivier [START_REF] Mokhonoana | Acquisition of a Symbian smart phone's content with an on-phone forensic tool[END_REF] proposed an on-phone forensic tool to acquire the active files from a Symbian OS version 7 phone and store it on the removable media. Instead of interfacing with the PC connectivity services, the tool interacts with the operating system to perform a logical copy of the files. Experiments were conducted on the Sony Ericcson P800 phone. The main limitation of the tool is that files in use could not be copied (e.g. call logs, contacts).

In 2008, Distefano et al. [START_REF] Distefano | An overall assessment of mobile internal acquisition tool[END_REF] proposed a mobile phone internal acquisition technique on the Symbian OS version 8 phones. The mobile phone data is acquired using a tool residing on the removable media, instead of the PC/mobile phone USB connection based approach. The tool utilizes the Symbian S60 File Server API in the read-only mode. The authors carried out experiments comparing the tool with Paraben Device Seizure (USB connection to phone) [START_REF] Paraben | Device seizure[END_REF] and P3nfs (Remote access through Bluetooth) [START_REF]P3nfs[END_REF]. The tool took a longer time to perform the acquisition but managed to acquire more data compared to the P3nfs. When compared with the Paraben Device Seizure, lesser data was ac-quired. However, the authors observed that the larger data size from Paraben was due to the additional information from its acquired data management.

In 2012, Thing and Tan [START_REF] Thing | Symbian smartphone forensics and security: Recovery of privacy-protected deleted data[END_REF] proposed a method to acquire privacy-protected data from Symbian OS version 9.3 and version 9.4 phones. The authors bypass the Symbian platform security (introduced from Symbian OS version 9.1) to obtain an unrestricted read access to the entire filesystem on the phone. Based on the obtained privilege, the authors retrieve the files relevant to SMS messages from the Nokia E72 and N97 phones (running Symbian OS version 9.3 and version 9.4, respectively). Reverse-engineering work is then carried out to derive the various SMS storage formats on the files and to recover both active and deleted SMSes previously stored on the phones' flash memory.

In the same year (2012), Thing and Chua [START_REF] Thing | Symbian smartphone forensics: Linear bitwise data acquisition and fragmentation analysis[END_REF] proposed a low-level linear bitwise data acquisition technique for the Symbian OS version 9.4 phones to support evidentiary file carving. A study and analysis of how files are stored and fragmented on the Symbian smartphone flash memory was also carried out.

However, there is no existing work on the live volatile memory data acquisition pertaining to Symbian smartphones. To the best of our knowledge, this is the first work that aims to investigate and devise a method for conducting a live volatile memory data acquisition from Symbian smartphones.

Investigation of Potential Live Symbian Volatile Memory Data Acquisition Approaches

In Symbian, debugging APIs are provided for its programmers. They are typically used during Symbian application development to debug and investigate program efficiency problems. We investigate the potential usefulness of these APIs in live raw volatile memory data acquisition from the commercial Symbian smartphones.

Run-mode Debugging

The run-mode debugging APIs are applicable in accessing the process memory of a running application. This type of debuggers is target-resident based and focus primarily in debugging applications and middleware. A process or thread identifier is required in order to access a relevant target specific memory region. However, they are restricted in capability and do not have a deep insight in the kernel-mode software and device drivers. For malwares and rootkits to obtain privileged functionalities, they must be able to execute in the supervisor mode and the way to achieve this is through the use of drivers or kernel modules. Therefore, the acquisition tool must be able to obtain a deep insight into the kernel space modules. In addition, memory not committed to any process at the acquisition point in time will not be accessible.

Stop-mode Debugging

The stop-mode debugging APIs are able to "freeze" the processes on the device and acquire a snapshot of its current memory state. However, they are required to be hardware-assisted by utilizing (or tapping onto) the JTAG boundaryscan test pins [START_REF] Willassen | Forensic analysis of mobile phone internal memory[END_REF][START_REF] Breeuwsma | Forensic imaging of embedded systems using jtag (boundaryscan)[END_REF][START_REF] Savoldi | Symbian forensics: An overview[END_REF] on the device. This hardware based approach works by accessing the debug ports used by the embedded device processors. JTAG is then switched between the extest or debug mode so as to produce an image dump of the memory. However, the test pins are usually not prominently shown and labelled. In this case, attempting to identify them is known to be very challenging and time consuming. On the commercial smartphones, these pins are commonly removed to prevent access by users.

Kernel Module

Instead of relying on the existing Symbian drivers or APIs, we can instead write our own kernel space driver for the purpose of memory acquisition. The driver can be a logical device driver that utilizes a logical channel to interact with the user-side application. The driver can then receive specific arguments such as the address of the memory to acquire, and send the acquired data to the user-side application to be stored on the non-volatile memory or to be transmitted out from the phone through a network connection such as 3G or Wifi. Upon receiving the memory address, we intend to perform direct de-referencing of the address to obtain the corresponding memory data and pass it back to the user-side calling application. The idea of the direct de-referencing of the address method is simple. It also provides a flexible way of accessing the memory on the device. Since it utilizes the basic de-reference operator, it should theoretically work across Symbian smartphones with different CPU architectures and/or memory models since the kernel shields us from the effect of these different implementations.

From the absence of relevant prior art, we observed that the live volatile memory data acquisition from Symbian smartphones remains a challenging task. However, we have identified a potential Symbian kernel space driver approach which could achieve a successful acquisition. In this paper, we propose a methodology and discuss the challenges we faced when devising the tool to perform the live volatile memory data acquisition. We also look into the security analysis and forensics investigation of Symbian smartphones based on the acquired data and discuss the observations we have made.

The Proposed Acquisition Approach

The live volatile memory data acquisition tool that we have designed, composes of two parts. It consists of a user-side component and a kernel-side component. The user-side component is responsible for loading the kernel-side component, initializing the client side of the logical channel (to support the subsequent communication with the kernel-side component during operation), passing in the addresses to be de-referenced and storing the returned data onto the non-volatile memory. The kernel-side component is a logical device driver which is responsible for setting up the logical channel with the user-side component to support communication during operation, and to return the acquired data from the dereferenced address (which is passed in by the user-side component). We named the kernel-side component the "Live Volatile Memory Data Acquisiton" driver or "Lamda", and referred to the user-side component as the "LamdaLoader". Within the multiple memory model there is an attempt to escape from the notion that all memory belongs to a chunk in the handling of program code that is loaded into memory.

However, because the moving memory model depends on the use of chunks to describe all of its memory, while Symbian OS supports ARMv5, chunks will continue to be the primary means of describing the memory that is mapped by a process, and as the abstract interface between generic kernel software and the memory model. Of course, even when no longer demanded by the underlying memory hardware, the chunk will always form part of the user-mode interface for memory management.

Algorithms

I will describe the same operations for the multiple memory model as I did for the moving model to illustrate the design.

Fig. 1: Symbian Multiple Model Memory Map

Figure 1 shows the Symbian multiple model memory map [START_REF] Sales | Symbian os internals: Real-time kernel programming[END_REF]. With the multiple memory model, Symbian has the concept of a local page directory and a global page directory. The memory region from 0x00000000 to 0x7FFFFFFF is translated via the local page directory while the memory region from 0x80000000 to 0xFFFFFFFF is translated via the global page directory. The global page directory memory regions is accessible by any process while the local page directory memory region is restricted to the current process.

The regions of memory that we are interested in is the global page directory region. Specifically, we are interested in the memory address region from 0xC9200000 to 0xFFEFFFFF (that is, the extra kernel mappings for the I/O and RAM loaded device drivers) and from 0xC8000000 to 0xC91FFFFF (that is, the kernel data, heap and stacks, which contain the kernel objects for the loaded drivers).

Even though we have identified the regions of the memory to perform acqui-sition, we tested our tool by trying to acquire the entire memory region, starting from the address 0x00000000, from a commercial Nokia N97 smartphone running Symbian OS version 9.4, S60 5th Edition. Upon execution, the smartphone returns a KERN-EXEC 3 panic result and causes it to reboot. Referring to the memory map, we noticed that the address that we sent in is in the region of unmapped NULL pointer traps. The KERN-EXEC 3 panic is caused by an untrapped page fault and since the offending process is a kernel thread, it causes the smartphone to reboot. The encountered page fault during this initial execution matches the documented behaviour that the kernel does not support on-demand paging [START_REF] Sales | Symbian os internals: Real-time kernel programming[END_REF]. However, upon investigation of the memory management unit (MMU) code in the Symbian product development kit, we realized that demand paging is actually implemented. This information leads us to believe that the KERN-EXEC 3 panic was not caused solely by a page fault but by other underlying mechanisms. We refer to the documentation provided by the product development kit which describes the impacts of demand page on kernel-side code. The document reveals that demand paging is not implemented for kernel code and data. Therefore, any page fault experienced in the kernel code and data will result in an unhandled fault. We decide to modify the tool to handle the page fault gracefully.

In Symbian, the exception handling and trapping mechanism is provided in the form of the XTRAP/XTRAPD macros (to enable the exception trapping). The difference between the two macros is that the XTRAPD macro declares the result variable whereas the XTRAP macro uses a pre-existing variable. They behave in a similar way as the user-side TRAP/leave(), but instead, they can catch hardware exceptions such as those generated by a faulty memory access. In addition, we utilize the TPhysAddr Epoc::LinearToPhysical(TLinAddr aLinAddr) function in Lamda to return the physical address corresponding to the virtual address passed in by the LamdaLoader. We then check the returned value before de-referencing the virtual address as an additional safety net. If KPhysAddrInvalid (defined in kernel/kern priv.h) is returned, it indicates that the specific virtual address is unmapped. If the returned value is not KPhysAddrInvalid, we proceed to carry out address de-referencing. It is also important to note that even when a virtual address is mapped to a valid physical address, there are instances when the CPU is not permitted to access a page as it does not satisfy the access policy for the page currently. This could also result in a fault. Hence, the exception trapping is useful in this scenario even with the valid mapping check function in place.

Experiments and Analysis

In this section, we use our tool to perform the acquisition of the ROM shadow region (0x80000000 to 0x8FFFFFFF) for verification purpose, and the extra kernel mapping (I/O, RAM loaded device drivers) region (0xC9200000 to 0xFF-EFFFFF) and the kernel data, heap and stacks region (0xC8000000 to 0xC91FF-FFF) of the N97 smartphone's volatile memory for further analysis.

ROM Shadow Image

We acquired the ROM shadow images from three different experiments; one from a N97 smartphone, another from the same smartphone after a hard-reset was performed, and the third from another N97 smartphone with the same version of the ROM flash image. We performed a bitwise comparison and verified that the acquired memory images are identical and therefore, proved that they indeed contain the same version of the ROM image. Next, we analyse the image to identify an approach to facilitate integrity checks of the drivers provided in the ROM flash image on the smartphones originating from the manufactors.

Symbian drivers are binary files and should contain certain specific header information. In Symbian, its E32Image files contain a 12-byte UID (unique identifier and composes of a set of UID1, UID2 and UID3) data that indicate the file type and identify the particular file object. A 4-byte UID1 value of 0x1000007A indicates that the file is of an executable type. Therefore, a logical driver has a UID1 value of 0x1000007A as it is a DLL executable file. In addition, it has a 4-byte UID2 value of 0x100000AF to indicate that it is a logical device driver (LDD). The 4-byte UID3 value is used to identify a particular object (for example, a particular executable file). As the data is stored in little-endian format, the data pattern for searching and extracting the device driver binaries from the ROM memory image is (79 00 00 10 AF 00 00 10). On further analysis, we also discovered that the binary header structure of the detected driver within this memory image is that of the TRomImageHeader structure, as shown in Fig. 2. In this region of the memory, we are able to detect the presence of the loaded executables and libraries as their paths are clearly shown in this memory region. Therefore, known malware executables, loaded dynamic libraries and driver names can be easily detected by performing a simple search. As shown in Fig. 3, we observed that the path for the loaded sisadriver is at offset 0x855890. We also found the path of the LamdaLoader at offset 0x1903456, the path to AknI-conSrv (which is a system application loaded from the ROM) at 0x1920464 and the path of the nokiaiscdriver at 0x856592.

Extra Kernel Mappings

The extra kernel mappings region is the memory region where the RAM loaded drivers are residing in. Therefore, it would be a very important region of interest for conducting malware security analysis and forensics investigations. We designed an experiment to ensure that no other RAM loaded driver is present. After which, we load an additional driver other than Lamda and acquire this memory region. Therefore, we expect that the resultant memory image would contain these two drivers only. We use the similar technique in the ROM memory image analysis to search for presence of loaded drivers based on the UID string pattern (79 00 00 10 AF 00 00 10). Consistent with our expectation, only the two drivers were detected to be present.

We observed that the RAM loaded drivers have the E32ImageHeader (Fig. 4) rather than the TRomImageHeader header structure found in the ROM drivers.

The difference is due to the way these two types of drivers were compiled differently in Symbian. Unlike the previous case of ROM drivers integrity check, where simple matching can be performed, the actual extraction of the RAM drivers has to be conducted to facilitate further security and forensics analysis. Therefore, to do so, we have to first determine the size of the driver. Our first attempt is to use the TUint32 iUncompressedSize field in the E32ImageHeaderComp. However, this field could not be utilized as the loaded driver found in the RAM is in a compressed form and the size is (expectedly) different from its provided uncompressed driver size. We attempted to calculate the size by utilizing the fields such as the iCodeSize and iTextSize, but as expected, these attempts proved futile as these offsets are based on the uncompressed code.

We hypothesize that the compressed driver size information must exist within the header or within range of the located driver as the Loader Server has to be able to determine the size of the driver in order to decompress or load it. Through further analysis on a few examples of RAM loaded drivers in the memory image, we observe that the 4 bytes preceding the UID value hold the actual file size of the driver. With that information, we are able to extract the exact RAM loaded drivers from the memory image programmatically. The extracted compressed drivers can then be uncompressed and analysed offline.

As mentioned, the extra kernel mappings not only hold the RAM loaded device drivers but also the I/O information. While searching for the RAM loaded binary drivers, we came across an entire region of memory which corresponds to the content of the address map at offset 0x34525696. Offset 0x34525696 points to the user local data region in the local page directory. Therefore, our initial hypothesis is that this is the region which the kernel mapped for use as the I/O buffer. Since most I/O operations are buffered for performance benefits, this would imply that when an application requests for an input from the user (for example, a password), the input will first be buffered before being read by the application. The reverse is also true such as when an application needs to write data to a file. Therefore, further work can be done to research on the feasibility of monitoring the I/O buffer in order to intercept the information.

As such, since the framebuffer might be on the RAM, there is also a possibility that the current active screen of the device can be found in the image. Furthermore, for processes that have ended, traces of them may still be residing in the RAM since a deallocation of the memory does not result in the RAM being cleared. The reverse may also be true. However, for Symbian, when an unit of memory is allocated, it is initialized to zero.

Considering these characteristics of memory allocations and deallocations, we may be able to extract information such as the phone numbers, call logs, SMSes, recently opened files and even the plaintext version of the encrypted files; since in order to process an encrypted file, it must first be decrypted into the RAM.

Further Experiment: Page Tables Error

We have attempted to acquired the entire memory space from 0x00000000 to 0xFFFFFFFF without any unexpected error except during the acquisition of the page tables region from 0xC4000000 to 0xC8000000. A smooth process of nondisrupted successful acquisition of the page tables memory region is only possible from 0xC4000000 to 0xC6024599. When the tool tries to resolve the address at 0xC6024600, the smartphone was rebooted. We attempted the experiment a few times and the faulting point is consistent. This is an anomoly as we know that we already have the exception handling mechanism in place and this reboot must be caused by something else.

Unfortunately, we are unable to trace the system as tracing is disabled on commercial phones. Therefore, we are unable to identify the exact cause of this error. Our implemented solution is to skip this unaccessible memory and go to the next address. We then observed that after this faulting address at 0xC6024600, there are several interleaved regions of unaccessible memory.

A hypothesis that requires further investigation to verify in our future work is that this error could be caused by implementation differences on commercial phones. For example, Nokia, which is the manufacturer of N97, could have chosen to map a smaller memory range instead of that indicated by Symbian. It is therefore necessary to investigate where the manufacturer actually output the debug trace to. Possible investigative approaches could target the JTAG, Serial, or other ports on the phone.

With the prevalence of smartphones and the increasing amount of important information they are holding and storing, it is necessary to be equipped with the capability to conduct an in-depth security analysis and forensics investigations of smartphone information theft malwares. Therefore, in this paper, we identified the need for a memory acquisition technology or tool to conduct raw volatile memory acquisition from live Symbian smartphones. We investigated the different potential approaches to achieve this task and concluded that the kernel space driver approach to perform address de-referencing is the simplest, and most flexible and portable way to achieve the acquisition of raw volatile memory data from the live Symbian smartphones. This approach is also able to obtain a full-coverage view of the entire memory space. We designed and developed the tool for the purpose of performing the acquisition. Along the way, we also solved the problems relating to exception handling and detection of unmapped addresses by enhancing the tool.

In addition, we identified the relevant memory regions of interest to facilitate further in-depth security analysis and forensics investigations of malwares. Subsequently, we analysed the ROM memory image, the kernel data, heap and stacks memory image, and the extra kernel mappings (I/O, RAM loaded device drivers) to identify ways and devise methods to detect and extract useful information (for examples, the identification and matching of the ROM drivers, the identification and extraction of the RAM loaded device drivers, and the identification of the pathnames of the loaded executables) to support further analysis. Some interesting observations with regard to the I/O buffer region and corresponding information in the user local data memory region in the local page directory, were made.

With this research work, we hope that it provides more insights into the Symbian operational environment and an understanding of how more in-depth anti-malware tools and forensics acquisition and analysis tools can be designed and developed.

Figure 7 . 17

 717 Figure 7.17 Full memory map for the multiple memory model

Fig. 2 :

 2 Fig. 2: TRomImageHeader

Fig. 3 :

 3 Fig. 3: LDD Path in Kernel Data

Fig. 4 :

 4 Fig. 4: UID String with E32ImageHeader Signature 'EPOC'


Rafiqul Islam
email: mislam@csu.edu.au

Irfan Altas
email: ialtas@csu.edu.au

Md Saiful Islam

Exploring Timeline-Based Malware Classification

Keywords: Timeline, Malware Detection, Static and Dynamic Features

Over the decades or so, Anti-Malware (AM) communities have been faced with a substantial increase in malware activity, including the development of ever-more-sophisticated methods of evading detection. Researchers have argued that an AM strategy which is successful in a given time period cannot work at a much later date due to the changes in malware design. Despite this argument, in this paper, we convincingly demonstrate a malware detection approach, which retains high accuracy over an extended time period. To the best of our knowledge, this work is the first to examine malware executables collected over a span of 10 years. By combining both static and dynamic features of malware and cleanware, and accumulating these features over intervals in the 10-year period in our test, we construct a high accuracy malware detection method which retains almost steady accuracy over the period. While the trend is a slight down, our results strongly support the hypothesis that perhaps it is possible to develop a malware detection strategy that can work well enough into the future.

Introduction

Malware is one of the biggest challenges all over the world nowadays among the Internet users. Malware writers use various obfuscation techniques to transform a malicious program into undetectable variants with the same core functionalities of the parent malware program [START_REF] Bailey | Automated classification and analysis of internet malware[END_REF], [START_REF] Fossi | Samnani: Symantec global internet security threat report trends for[END_REF], [START_REF] Marcus | Mcafee threats report: Third quarter 2009[END_REF], [START_REF] Soltani | Detecting malware outbreaks using a statistical model of blackhole traffic[END_REF], [START_REF] Sukwong | Commercial antivirus software effectiveness: An empirical study[END_REF], [START_REF] You | Malware obfuscation techniques: A brief survey[END_REF]. Anti-Malware (AM) communities are trying hard to combat malware obfuscation techniques adopted by the malware writers by discovering the behavioral patterns of their parent malwares. However, one of the biggest challenges is that an AM strategy that has been found to be successful in a given time period cannot work at a much later time. This philosophy is supported by the works found in [START_REF] Bailey | Automated classification and analysis of internet malware[END_REF], [START_REF] Barford | An inside look at botnets[END_REF], [START_REF] Nair | Medusa: Metamorphic malware dynamic analysis using signature from API[END_REF], [START_REF] Sukwong | Commercial antivirus software effectiveness: An empirical study[END_REF], [START_REF] Tang | A new approach to malware detection[END_REF], [START_REF] Yagi | Investigation and analysis of malware on websites[END_REF] and [START_REF] You | Malware obfuscation techniques: A brief survey[END_REF], which indicates that current techniques fail to find the distinctive patterns of malicious software which can be used to identify future malwares. The argument is that malware evolves with time and eventually becomes unrecognizable from the original form; in addition com-pletely new malware is designed which is unlike any known malware and so would not be detected by anti-virus software constructed to detect known types of malware. In fact, the assumption that malwares which are completely unlike earlier malwares designed on a major scale is known to be false as indicated by the statistics in [START_REF] Braverman | Microsoft security intelligence report January[END_REF] showing that barely 25% of malwares found in 2006 are not variants of known malwares.

Despite the strong support in the literature of the assumption that malware detection methods cannot easily detect future malware, in this paper, we convincingly demonstrate that perhaps, it is possible to develop a malware detection strategy which can retain high accuracy over an extended time period. To the best of our knowledge, this paper is the first to examine malware executables collected over a span of 10 years. The key contributions of this paper are two-folds:

(a) A novel approach to feature collection by accumulating malware features over time segments of the 10 years span. (b) A novel malware detection method retaining steady accuracy over an extended period of time. The rest of the paper is organized as follows: Section 2 provides a review of the literature and Section 3 describes the set-up for the testing. In Section 4, we provide a detailed discussion of the experiment and present the results and in Section 5, we discuss the analysis and its implications for future work.

Related Work

A substantial research has been done on malware classification and detection. In this section, we present only a few of the existing works that are either closely related to or motivate us to conduct our research in this paper. The study in [START_REF] Yagi | Investigation and analysis of malware on websites[END_REF] investigates malicious attacks on several websites by creating web honey pots and collecting website-based malware executables over a period of five months. In their study, they collect and analyze malware samples using 6 different antivirus programs, and conduct the same experiment four months later using the updated versions of the 6 programs to determine their efficacy. Additionally, the work of Rajab et al. [START_REF] Rajab | Trends in circumventing web-malware detection[END_REF] also focuses on mitigating web-based malware. They study a dataset collected over a period of four years and demonstrate that existing malware characteristic can aid in detecting future malware. Both aforementioned works demonstrate that, some anti-virus software can significantly improve detection rates with training on older malware.

The research conducted by Rosyid et al. [START_REF] Rosyid | A discovery of sequential attack patterns of malware in botnets[END_REF] is focused on detecting malicious attack patterns in botnets attacking a honeypot during the year 2009. After extracting the log files of malware sequences, they then apply the PrefixSpan algorithm to discover subsequence patterns. The authors extend their work by identifying attack patterns based on IP address and timestamp. The authors argue that the signature of a single malware file is not enough to detect the complex variants of the attacks by botnets. In [START_REF] Bailey | Automated classification and analysis of internet malware[END_REF], the authors apply a dynamic method for classifying malware, considering the interactions between the operating system and malicious programs as behavioral features. In their study they use three different evaluation techniques: completeness, conciseness, and consistency. The authors mention that one limitation of their methodology is the failure to "detect fine-grained characteristics of the observed behaviors".

Another group of researchers, [START_REF] Lee | A study of malware detection and classification by comparing extracted strings[END_REF], build their malware detection and classification framework based on comparisons of extracted strings using static analysis. They claim that the similarity between two files can be determined by comparing the character strings, which in turn is used to identify and determine whether the two instances are variants. The authors present a three-step methodology of extraction, refinement and comparison. The authors show that if a mutated instance of malware is detected, it is reflected as a huge peak under the respective malware family.

In [START_REF] Islam | Classification of malware based on integrated static and dynamic features[END_REF], the authors use a combination of static and dynamic analysis to achieve a high level of accuracy over an 8 year time period. We are not the first to integrate dynamic with static features however (see for example [START_REF] Roundy | Hybrid analysis and control of malware[END_REF]), though we are the first to use this method applied over a long time period. In order to understand the evolution of malware over a long period of time and its effects on future malware, in this paper, we consider two types of analysis: static and dynamic, as these features are predominant for malware analysis in the literature.

3

Experimental Setup

The methodology

Static and dynamic analyses are two of the most popular forms of malware analysis techniques predominant in the literature [START_REF] Bailey | Automated classification and analysis of internet malware[END_REF], [START_REF] Islam | Classification of malware based on integrated static and dynamic features[END_REF], [START_REF] Lee | A study of malware detection and classification by comparing extracted strings[END_REF], [START_REF] Nair | Medusa: Metamorphic malware dynamic analysis using signature from API[END_REF], [START_REF] Roundy | Hybrid analysis and control of malware[END_REF], [START_REF] Tian | Function length as a tool for malware classification[END_REF], [START_REF] Tian | An automated classification system based on the strings of Trojan and virus families[END_REF], [START_REF] Tian | Differentiating malware from cleanware using behavioural analysis[END_REF], [START_REF] Yagi | Investigation and analysis of malware on websites[END_REF]. However, each of these analysis techniques comes with its own merits and demerits. Static analysis can analyze a wide spectrum of possible execution paths of an executable, thus providing a good global view of the whole executable and of the entire program logic without running it. But, static analysis is susceptible to inaccuracies due to obfuscation and polymorphic techniques.

On the otherhand, dynamic analysis monitors the behavior of the binary executable file during its execution, which enables it to collect a profile of the operations performed by the binary thus offering potentially greater insight into the code itself. The main limitation of dynamic analysis is that analysis results are only based on malware behavior during a specific execution run. Since some of the malware's behaviour may be triggered only under specific conditions, such behaviour would be easy to miss with only a single execution.

In our experiments, we extract both static and dynamic features from the malware and cleanware files collected over the 10 years period and learn our classifier to detect future malwares. More specifically, we extract from each executable (a) static features: printable string information (PSI) and function length frequency (FLF), (b) dynamic features: API calls including their parameters and (c) integrated features: a combination of the two static and the dynamic features. The WEKA library of data mining algorithms [START_REF] Mark | The WEKA Data Mining Software: An Update[END_REF] is used to learn the classifiers and derive the detection results based on the extracted feature vectors as input.

Data (malware and cleanware) collection

The malware executables used in the experiment were collected from CA's VET Zoo 1 over a span of 8 years (2002-2010) and we collect (2011-2012) manually from open sources (www.offensivecomputing.net, http://www.virussign.com); the cleanware executables were collected manually from various versions of Win32 based systems. Fig. 1 indicates the dates at which malware files were collected. The total numbers of malware and cleanware executables, used in our experiments, are 2617 and 541 respectively. Table 1 shows the executables family by family.

Timeline data preparation

The date of a malware file was associated with the file when the file was collected. We exported all files, along with their dates, into our Ida2DBMS schema [START_REF] Tian | An automated classification system based on the strings of Trojan and virus families[END_REF] and based on the dates broke the data into groups as described in Fig. 2.

To generate groups of malware for use in the testing, we begin with the earliest malware and add month by month across the timeline until all data are grouped. As the first data group, MG 1 , we take the earliest-dated 10% of the files. There are 262 executables in this group which covers the period from October 2002 to December 2004. The second data group, MG 2 , comprises the data collected during the period October 2002 to January 2005, and so on. When too few files appear in a subsequent month to justify including that month as a group, we jump to the following month. In all, this results in 65 malware data groups which are labeled as MG 1 , MG 2 ,…,MG 65 . Fig. 2 indicates the spread of malware across the sixty five groups with each bar corresponding to a group.

Throughout the test, the set of 541 WIN32 cleanware files is treated as a single group, cleanware group (CG). However, when it is tested against a particular malware group, depending on the comparative size of the two groups, the cleanware group may be divided into subgroups. We then divide CG into k disjoint groups of equal size. If R > 0, then the remaining elements must be padded out to a (k+1)'st group CG k+1 . However, if R = 0, this set is empty and is not used.

If |MG i | is bigger than |CG| then we compute the integer part of |MG i |/|CG| and proceed in the same way. This procedure is repeated for every malware group. The pseudocode of our proposed cumulative feature vector (CFV) generation and testing algorithm is given below:

Step 1: First we import the data from our database and group it according to system date. In our first data-group we called "MG 1 ", which is 10% of total malware from early malware executables. Then, we do remaining groups as month by month.

Step 2: We add the data in increasing order as mentioned earlier, so that each data-group MG i is the

MG i = MG i + MG i -1 .
Step 3: Since our test is based on malware versus cleanware test, we again divide each data-group MGi into subgroups, same size of cleanware, if the malware size is bigger; and vice versa for cleanware, if the cleanware size is bigger.

Step 4: Select a data-group (both from malware and cleanware) and extract the feature information (explained in the following section).

Step 5: Create CFV and construct the .arff file (WEKA) format.

Step 6: Select the data group and split it into n (n = 10) folds.

Step 7: Build training data using n-1 folds (90% of the total data) and the remaining fold as test data (10% of the total data). The detail can be found in Section 3.6.

Step 8: Call WEKA libraries to train the classifier using training data.

Step 9: Evaluate the test data set.

Step 10: Repeat until finish for all n folds (each fold should be used as test data and the remaining folds as training data).

Step 11: Repeat for other classifiers.

Step 12: Repeat until finish all data groups.

Feature Vector generation

In our experiment, we use both static and dynamic features as explained before. We also use a combined version of these two features for the purpose of detecting future malwares.

Static features.

From each of the executables, we extract two static features, function length frequency (FLF) and printable string information (PSI). These features are extracted from unpacked malware executables by means of a command line AV engine. The AV engine identifies and unpacks the packed executables in batch mode and identifies functions and printable strings.

To extract FLF features, we follow the methodology described in [START_REF] Tian | Function length as a tool for malware classification[END_REF]. However, in order to determine an appropriate number of intervals, we follow Sturges' wellestablished statistical formula [START_REF] Sturges | The choice of a class interval[END_REF], which recommends the use of approximately 1+log 2 (n) bins, where n represents the number of instances in the experiment. Based on our value of n = 771458 we use 20 bins.

As an example, consider an executable file with 22 functions which have the following lengths in bytes, presented in increasing order of size : 5, 6, 12, 12, 15, 18, 18, 50, 50, 130, 210, 360, 410, 448, 546, 544, 728, 848, 1344, 1538, 3138, 4632. For the purposes of illustration, we create 10 bins of function length ranges. The distribution of lengths across the bins is as shown in Table 2.

This produces a vector of length 10 using the entries in the second column of Table 2: (0.0, 2.0, 5.0, 2.0, 1.0, 4.0, 4.0, 3.0, 1.0, 0.0) which corresponds to the function length frequency for the file chosen.

In extracting PSI features, we use the methodology of [START_REF] Tian | An automated classification system based on the strings of Trojan and virus families[END_REF] for generating vectors to use in the classification process. We illustrate this with an example. Consider a global ordered string list containing 10 distinct strings: {"LoadMemory","GetNextFileA", "FindLastFileA" "GetProcAddress", "RegQueryValueExW", "CreateFileW", "OpenFile", "FindFirstFileA", "FindNextFileA", "CopyMemory"} Suppose that a particular executable has the following set of printable strings: {"GetProcAddress", "RegQueryValueExW","CreateFileW","GetProcAddress"}

The PSI vector for this executable file records, first of all, the total number of distinct strings in the file followed by a binary report on the presence of each string in the global list, where a 'true' represents the fact that the string is present and a 'false' that it is not. Table 3 presents the corresponding data for this executable file. The vector for this example becomes (4, false, false, false, true, true, true, false, false, false, false). Dynamic Features. To extract this feature, we follow the methodology to generate dynamic logs, described in [START_REF] Tian | Differentiating malware from cleanware using behavioural analysis[END_REF]. For generating a normalized feature vector from dynamic log files we construct a global feature list from all extracted API calls and API parameters. We treat the functions and parameters as separate entities as they may separately affect the ability to detect and identify the executable. For illustration, consider the following global API feature list: {"RegOpenKeyEx","RegQueryValueExW","Compositing","RegOpenKeyExW","0x54", "ControlPanel\Desktop","LameButtonText","LoadLibraryW",".\UxTheme.dll","LoadLibrary ExW", "MessageBoxW"}.

We now list the distinct features in the global list and generate a vector for the executable based on the frequency of these features. Table 4 shows the distinct global feature list with corresponding frequencies for this particular example and the corresponding feature vector is (0, 2, 1, 1, 1, 1, 1, 1, 2, 1, 0).

Detection Method

In our classification process, we input the generated feature vectors into the WEKA classification system [START_REF] Mark | The WEKA Data Mining Software: An Update[END_REF] for which we have developed an interface. In all of our experiments, 10-fold cross validation is applied to ensure a thorough mixing of the sample data and thereby, reducing the biasness as much as possible. In this procedure, we first select one group of malware data from a particular data set and divide it into ten portions of equal size. Then we select cleanware data of the same size as the group of malware data and also divide it into ten portions. The portions are, then, tested against each other. The whole process is repeated for each group and we then calculate average classification results. In our test, we have multiple tests within each group. The following Fig. 4 shows the number of tests within a period range.

To establish the training set, our detection engine takes nine portions from each of the malware and cleanware. The remaining portions from both malware and cleanware are used for the testing set. As is customary, the training set is used to establish the model and the testing set is used to validate it. The whole process is repeated so that every portion of both malware and cleanware is chosen as testing data. The results are then averaged. In order to ensure that the input vectors are trained and tested over a broad spectrum of classifiers, we chose the following four classifiers from WEKA [START_REF] Mark | The WEKA Data Mining Software: An Update[END_REF] as they represent differing approaches to statistical analysis of data: Support Vector Machines (SVM), Random Forest (RF), Decision Table (DT) and IB1. We have run the entire experiment using each of the four base classifiers SVM, IB1, DT and RF mentioned in Section 3.6. In addition, each test was run five times and the results averaged in order to ensure that any anomalies in the experimental setup were discounted. The following sections present our empirical results.

Timeline classification results using FLF features

As mentioned in Section 3.5, the total number of FLF features used is fixed at 20 (bins) throughout the tests. Fig. 5 shows the result over the 10 year timeline. The xaxis shows the timeline data group and the y-axis shows the detection ratio of malware. It is clear that we achieve better detection accuracy for early malware compared to that for later malware. IB1 and RF give consistently better results across the timeline. SVM gives the worst performance, likely due to the very small feature set used in the experiment given that it is designed to handle large feature spaces. All classifi- ers except SVM maintain their accuracies above 80% throughout the timeline. Specifically, RF maintains better accuracy throughout the timeline compared to other classifiers.

Timeline classification results using PSI features

The number of PSI features used for each data group grows across the timeline, varying from approximately 800 to 2085. Fig. 6 shows the detection results using the PSI feature set. All classifiers except DT maintains their accuracies above 80% using PSI features. However, once again RF maintains better accuracy compared to the other classifiers throughout the timeline.

Timeline classification results using dynamic features

The number of features used in this test increases from approximately 2600 to 8800 over the timeline. Fig. 7 shows the detection accuracy of the dynamic feature set which is based on API calls and API parameters. For all but the IB1 classifier, the dynamic feature results give almost consistent and better performance compared to either of the static features (i.e., FLF and PSI). With a large feature set, IB1 is inclined to make errors when building the training sets, which is likely to account for the poor performance here.

In Table 5, we have summarized the detection results for the last group, the 65 th group of our data set, which includes all of the executables, showing the false positive (FP) and false negative (FN) rates and also the accuracies. Note the very poor accuracy of SVM with PSI while, with IB1, FLF has slightly better accuracy than the dynamic and PSI test, and with DT and RF, the results for dynamics features are better. It is thus difficult to argue that FLF should be deleted from the test altogether. Additionally, the false negatives and false positives of all tests in the case of IB1and DT are much higher than other two classifiers. However, the dynamic features give better performances comparing all parameters.

Conclusion and Future Work

In this paper, we have presented a cumulative timeline approach for identifying malware from cleanware and demonstrated that perhaps it is possible to develop a malware detection strategy that can retains high accuracy over the long time period. The results presented in Section 4 indicate that our method retains fairly consistent accuracy over the 10 year period.

Our approach to feature collection is novel in that we accumulate the features over time segments of the 10 year span. In progressively adding malware over the time period, we thereby strengthen the accuracy of the test. The implication for anti-virus engines is that they are then able to use previously detected malware to provide features based on which to test new executables.

The results presented in section 4 indicate that no one feature type is the most significant for the specific classifier over the 10 year span. In our experiment, the static (FLF and PSI) and dynamic features act independently. Therefore, it is expected that combining static and dynamic features in an integrated manner could give a better detection rate. We would like to explore in our future work.

Features

Fig. 1 .

 1 Fig. 1. Collection of malware executables from 2002 to 2012

Fig. 2 .

 2 Fig. 2. Number of malware executables accumulated by date

Fig. 3 .

 3 Fig. 3. Cumulative Feature Vector (CFV) generation

Fig. 4 .

 4 Fig. 4. Number of test within the group of data set

Fig. 5 .

 5 Fig. 5. Timeline results based on FLF features

Fig. 6 .

 6 Fig. 6. Timeline results based on PSI features

Fig. 7 .

 7 Fig. 7. Timeline results based on dynamic test

Table 1 .

 1 Experimental set of 3158 files

	1 www.ca.com.au

Table 2 .

 2 FLF bin distribution example

	FLF Bin distribution
	Length of functions FLF Vectors
	1-2	0.0
	3-8	2.0
	9-21	5.0
	22-59	2.0
	60-166	1.0
	167-464	4.0
	465-1291	4.0
	1292-3593	3.0
	3594-9999	1.0
	>=10000	0.0

Table 3 .

 3 Example of PSI vector generation

	PSI Vector generation
	Printable string	PSI Vector
	String number	4
	LoadMemory	false
	GetNextFileA	false
	FindLastFileA	false
	GetProcAddress	true
	RegQueryValueExW	true
	CreateFileW	true
	OpenFile	false
	FindFirstFileA	false
	FindNextFielA	false
	CopyMemory	false

Table 4 .

 4 Example of dynamic feature vector generation

	Dynamic feature vector generation
	Global feature	Frequency
	RegOpenKeyEx	0
	RegQueryValueExW	2
	Compositing	1
	RegOpenKeyExW	1
	0x54	1
	ControlPanel\Desktop	1
	LameButtonText	1
	LoadLibraryW	1
	.\UxTheme.dll	2
	LoadLibraryExW	2
	MessageBoxW	0

Table 5 .

 5 Comparison of the performances of the tested classifiers for the 65 th group


Jin B Hong

Dong Seong Kim

Performance Analysis of Scalable Attack Representation Models

Keywords: Attack Graph, Attack Tree, Complexity Analysis, Security Model, Scalability

Attack graphs (AGs) have been widely used for security analysis. The construction of the graph-based attack models including the AG have been studied, but the security evaluation considering the full attack paths cannot be computed using existing attack models due to the scalability problem. To solve this, we propose to use hierarchical attack representation models (HARMs). First, we formulate key questions that need to be answered to compare the scalability of existing attack models. We show the scalability of the HARMs via simulations, by taking into account practical attack scenario based on various network topologies.

Introduction

Attack models are used to evaluate the security of networked systems and to provide countermeasures to enhance the security [START_REF] Ammann | Scalable, graph-based network vulnerability analysis[END_REF][START_REF] Dewri | Optimal security hardening using multiobjective optimization on attack tree models of networks[END_REF][START_REF] Gupta | Using Attack Graphs to Design Systems[END_REF][START_REF] Xie | Evaluating network security with two-layer attack graphs[END_REF][START_REF] Ou | A scalable approach to attack graph generation[END_REF][START_REF] Ingols | Modeling modern network attacks and countermeasures using attack graphs[END_REF][START_REF] Saini | Threat modeling using attack trees[END_REF][START_REF] Dawkins | A systematic approach to multi-stage network attack analysis[END_REF][START_REF] Edge | A Framework for Analyzing and Mitigating the Vulnerabilities of Complex Systems via Attack and Protection Trees[END_REF]. Previous studies showed that the graphbased attack models (e.g., attack graph (AG) [START_REF] Sheyner | Automated generation and analysis of attack graphs[END_REF], multiple prerequisite graph (MPG) [START_REF] Ingols | Practical attack graph generation for network defense[END_REF], two-layered attack graph (TLAG) [START_REF] Xie | Evaluating network security with two-layer attack graphs[END_REF]) have a scalability problem if full attack paths are considered [START_REF] Sheyner | Automated generation and analysis of attack graphs[END_REF][START_REF] Ingols | Practical attack graph generation for network defense[END_REF][START_REF] Lippmann | An Annotated Review of Past Papers on Attack Graphs[END_REF][START_REF] Noel | Managing attack graph complexity through visual hierarchical aggregation[END_REF][START_REF] Chen | A scalable approach to analyzing network security using compact attack graphs[END_REF]. The tree-based attack models (e.g., attack tree (AT) [START_REF] Schneier | Secrets and Lies: Digital Security in a Networked World[END_REF], attack countermeasure tree (ACT) [START_REF] Roy | Attack Countermeasure Trees (ACT): towards unifying the constructs of attack and defense trees[END_REF]) can be constructed and evaluated in a scalable manner depending on their structures. Methods to construct tree-based attack models are described as either decomposition of the attack goal [START_REF] Saini | Threat modeling using attack trees[END_REF], computing min-cuts from the networked system with an assumed attacker and the target [START_REF] Dawkins | A systematic approach to multi-stage network attack analysis[END_REF], or drawn by security experts manually. As far as we know, there is no automated generation method that captures all possible attack paths in tree-based attack models.

There are phases in the lifecycle of the attack models [START_REF] Hong | HARMs: Hierarchical Attack Representation Models for Network Security Analysis[END_REF]. The pre-processing phase gathers the network and security information, the construction phase generates the attack model, the evaluation phase processes the security analysis using security metrics, and the modification phase captures any updated events in the networked system and modifies the attack model accordingly.

Previous researchers proposed various attack model structures that improved the scalability in the construction phase, and heuristic methods, such as graph simplifications, are used to avoid the scalability problem in the evaluation phase [START_REF] Xie | Evaluating network security with two-layer attack graphs[END_REF][START_REF] Ou | A scalable approach to attack graph generation[END_REF][START_REF] Ingols | Practical attack graph generation for network defense[END_REF]. Full attack paths contain all possible attack scenarios, and analysing full attack paths can drive one to find out the optimal security solution. But as far as we know, computing full attack paths to evaluate the security of networked systems is scoped to small networks only, because of the scalability problem. Existing attack models are not scalable to compute the full attack paths in the networked system, because there are many attack paths in a general networked system (e.g., a networked system with fully connected components). Therefore, we require a general solution to the scalability problem for the attack models.

We proposed hierarchical attack representation models (HARMs) to improve the scalability problem [START_REF] Hong | HARMs: Hierarchical Attack Representation Models for Network Security Analysis[END_REF]. Our previous study shows that the HARMs have better or equal complexities in three phases of the attack models, such as construction, evaluation and modification, compared with an AG and an AT. It is important that the attack models are scalable for all network topologies (e.g., mesh, star, complete), so that all types of the networked systems can be modelled, analysed and secured (e.g., smart grids, sensor networks, ad hoc networks). However, our previous study only considered the worst case analysis using the system where nodes are fully connected.

We denote an AG that only represents the network structure (i.e., the full attack paths information is not expressed) as a simplified AG. The simplified AG representation is used in the layers of the HARMs, compared with the simplified AG in the phases of construction and evaluation. The simulation considered different network topologies and variable number of vulnerabilities to improve the limitations of simulations observed in previous works. We consider the evaluation phase to compute the full attack paths. The contributions of this paper are:

-To list key questions to compute the scalability, and identify unanswered questions for existing attack models; -To simulate the attack model's construction and evaluation phases, and compare the scalability considering multiple vulnerabilities and various network topologies using a practical network system

The rest of the paper is as organised as follows. In Section 2, related work is introduced. In Section 3, the HARMs and existing attack models are compared using five key questions. Section 4 represents the simulation result, and discussion is given in Section 5. Finally, section 6 concludes this paper.

Related Work

Over the last decade, many attack models have been proposed. There are no general tree-based attack model construction methods that avoid the scalability problem. Hence, we will consider graph-based attack models to compare the performance in the phases of attack models. Sheyner [START_REF] Sheyner | Automated generation and analysis of attack graphs[END_REF] used a full attack graph, but it had a scalability problem. Many researchers presented efficient methods of the AG construction and evaluation. To improve the efficiency of the attack models, researchers considered improvements on the full AG [START_REF] Sawilla | Identifying critical attack assets in dependency attack graphs[END_REF][START_REF] Noel | Understanding complex network attack graphs through clustered adjacency matrices[END_REF][START_REF] Hewett | Host-centric model checking for network vulnerability analysis[END_REF], or proposed new graph-based attack model structures [START_REF] Xie | Evaluating network security with two-layer attack graphs[END_REF][START_REF] Ou | A scalable approach to attack graph generation[END_REF][START_REF] Ingols | Practical attack graph generation for network defense[END_REF].

Ou et al. [START_REF] Ou | A scalable approach to attack graph generation[END_REF] used a logical attack graph (LAG), and the construction of the LAG can be done in a time of polynomial complexity. However, evaluation method and its complexity analysis are not mentioned. The simulation for the construction phase assumed that each host has same vulnerabilities, but in real systems we can expect various number of vulnerabilities for different hosts with different services and applications. Moreover, exploiting vulnerability does not necessarily give the root privilege, as assumed in their work. Ingols et al. [START_REF] Ingols | Practical attack graph generation for network defense[END_REF] used a predictive graph to avoid the scalability problem of the AG. Later, they proposed a multiple prerequisite graph (MPG), more scalable than the predictive graph. They reported the scalability of the MPG has the size complexity of O(nlogn), where n is the number of hosts in the networked system. They used heuristic methods to simply the MPG to evaluate the network security. A direct attack was used for the attack scenario in the simulation. Although they used more than one type of vulnerabilities, the number of vulnerabilities was fixed. Xie et al. [START_REF] Xie | Evaluating network security with two-layer attack graphs[END_REF] used a two-layer attack graph (TLAG), where the upper layer captured the host reachability, and the lower layer captured the vulnerability information. There are similarities between the HARMs and the TLAG, but the TLAG stores the lower level information in each edge (i.e., construct the vulnerability attack graph between host pairs), but the HARMs store the lower level information in each host. As a result, less memory space is required for the HARMs than the TLAG, as well as construction and evaluation times in general. The network structure was described, but the simulation did not perform the scalability test, and the vulnerability information was not given.

We compare the structure of the HARMs, which are designed to use any attack models in their layers, with simplified AG, LAG, MPG, and TLAG in terms of scalability by taking into account the worst case performance.

Model Comparisons

Existing attack models and their studies lack in comparative studies to show how well their models scale in various environments and attack scenarios. We listed five key questions to compare the scalability of attack models: Q1 Was the computational complexity analysis performed? Q2 Compared against other attack models? Q3 Different network topologies have been considered? Q4 The Effect of variable number of vulnerabilities for hosts is considered? Q5 Different types of vulnerabilities (user/root) are considered?

To compare the scalability of the HARMs, we will consider different graph-based attack models (simplified AG, LAG, MPG, and TLAG) and compare their scalability in the construction and the evaluation phase by inspecting their model structures and features. We assume the reachability information is given as in [START_REF] Ingols | Practical attack graph generation for network defense[END_REF]. Also, we assume that other information (e.g., credentials, interfaces, ports) is abstracted in the attack model, as they are linearly proportional to the number of hosts and vulnerabilities. The HARMs will consider the simplified AG model in both the upper and the lower layer. In the evaluation phase, we will consider the calculation of the full attack paths. We will only consider the number of hosts and vulnerabilities of each attack model to compare the scalability, because they are the major variable factors for the scalability among many others.

The Construction Phase

Studies on existing attack models have failed to answer some of the key questions when analysing the scalability of attack models. The answers for the key questions considering the construction phase are given in Table 1. Moreover, the corresponding attack model is required to be modified if there is a change in a networked system. The existing attack models that are not in a hierarchical representation require inspecting all attack model components to make modifications accordingly. However, attack models using the hierarchical representation (e.g., the HARMs and the TLAG) may apply modifications in the required layer only. The construction phase of the attack model is required to retrieve the network information and connecting the network components specific to the attack model requirements (e.g., connecting a vulnerability node to its subsequent vulnerabilities or hosts based on the reachability, application and port information). We assume that the vulnerabilities of each host can be exploited based on the reachability information only. The analysis is focused on answering the key questions, and identifying key features of each attack model.

The construction of the full AG requires the calculation of full attack paths in the construction phase, which has a scalability problem that is impractical for a large (sized) networked system [START_REF] Lippmann | An Annotated Review of Past Papers on Attack Graphs[END_REF]. Instead, a simplified AG can be constructed, which is a simplified version of the full AG that only captures the network properties. There are other simplified versions of the full AG, which are modified to fit their usage [START_REF] Albanese | Time-efficient and cost-effective network hardening using attack graphs[END_REF]. The connections between vulnerabilities and hosts are independent in the simplified AG, so there are more edges in the simplified AG than the HARMs. However, the computational complexity of the construction phase of simplified AG and the HARMs is equivalent [START_REF] Hong | HARMs: Hierarchical Attack Representation Models for Network Security Analysis[END_REF].

The LAG has a construction complexity of O(δ N), where N is the number of hosts in the networked system and δ is the time to find the host in the lookup table [START_REF] Ou | A scalable approach to attack graph generation[END_REF]. However, they assumed all vulnerabilities are the same (remote to exploits). Since each derivation node is an AND node, repeated nodes are required for each exploit if there are multiple sources it could be exploited from. If we allow the derivation nodes to be OR nodes, the number of repeated nodes will be reduced.

The MPG graph has the number of components linearly proportional to the number of hosts and vulnerabilities in the networked system [START_REF] Ingols | Practical attack graph generation for network defense[END_REF]. Their performance in the simulation showed almost linear relationship between the computational time and the number of hosts. Also, they use prerequisite nodes in the model. This reduces the number of independent connections between hosts and vulnerabilities. But in the worst case, there will only be a single reachability group without the number of edges reduced. Moreover, they reported that even after 99% reduction in the graph size, they still had a problem representing the MPG because of complex relationship between hosts and vulnerabilities. In work [START_REF] Ingols | Modeling modern network attacks and countermeasures using attack graphs[END_REF], they described the client-side attacks using the reverse reachability calculations as an additional function.

The TLAG divides the network into two layers, where the upper layer captured the host reachability and the lower layer captured the vulnerability information between each host pair [START_REF] Xie | Evaluating network security with two-layer attack graphs[END_REF]. The main representation is simplified AG for both the upper and the lower layer. The analysis on the computational cost was given as O(n 2 ), where n is the number of hosts in the network. The number of vulnerabilities is not assessed in the complexity analysis. They assumed that only the user level access is enough to compromise the host, and they did not take into account super-user (i.e., the root privilege). The lower level construction is based on host pairs. If the network consists of many edges between hosts, then the number of lower layer models increases proportional to the number of edges, which can be up to O(n 2 ) number of edges. However, if the lower layer models in the TLAG are identical between different host pairs, they can share the same lower layer model. In the optimal case, where a host will have the same exploit sequence from any source, the number of lower layer models is linearly proportional to the number of hosts in the TLAG. Only the optimal case will show the same number of lower layer models with the HARMs. However, the TLAG requires that every edge has a reference to its lower layer information, whereas the HARMs only require the reachability information.

The Evaluation Phase

The evaluation process is a critical part in the security analysis, but due to the structural design, some attack models lack in efficient security analysis (e.g., scalability problem). Studies on existing attack models only answered a few of key questions listed. This is shown in Table 2.

Table 2. Studies covered for the evaluation phase Attack models TLAG [START_REF] Xie | Evaluating network security with two-layer attack graphs[END_REF] LAG [START_REF] Ou | A scalable approach to attack graph generation[END_REF] MPG [START_REF] Ingols | Practical attack graph generation for network defense[END_REF] HARMs [START_REF] Hong | HARMs: Hierarchical Attack Representation Models for Network Security Analysis[END_REF]

Q1

Yes Yes Q5

No No Yes Yes

We consider the evaluation phase to compute the full attack paths (i.e., all possible attack sequences). Existing attack models use simplifications and heuristic methods (e.g., graph simplification [START_REF] Ingols | Practical attack graph generation for network defense[END_REF]) to evaluate the network security, but they only consider specific attack scenarios and subset of all possible attacks. Matrix evaluation can be used to compute the overall security of the networked system, but it lacks in detailed analysis of the individual attack path. To improve these limitations, we compute the full attack paths.

Security analysis using the LAG is not available [START_REF] Ou | A scalable approach to attack graph generation[END_REF]. We estimate the evaluation complexity for the LAG is equivalent to the simplified AG, because each fact node (or also known as a host node with a given privilege) makes an independent connection to derivation nodes (or also known as vulnerability nodes). The number of paths from each fact node increases exponentially as the number of choices increases in the attack path, which are the same characteristics found in the simplified AG.

The evaluation of the MPG is to simplify the graph, then analyse the security. The evaluation complexity is estimated from the trend observed in their simulation. However, we will consider computing the full attack paths. The number of edges in the MPG depends on the number of reachability groups. If we consider the worst case (i.e., a complete graph), the performance of the MPG is equivalent to the simplified AG with a single prerequisite node (i.e., a single reachability group). If there are multiple prerequisite nodes, then connections between hosts and vulnerabilities are grouped by the prerequisite nodes, and it reduces the complexity in the evaluation. The optimal number of reachability groups is not analysed. Their analysis or simulation did not consider different network topologies or variable number of vulnerabilities.

The evaluation of the TLAG considered the overall security using the probability of an attack. But this evaluation method lacks in assessing different attack paths and their effects. The number of host-pair attack graphs (i.e., lower layer information) was not linearly proportional to the number of hosts. The analysis did not consider different network topologies, variable number of vulnerabilities in their analyses and simulations, and vulnerabilities giving different privileges when exploited.

The evaluation of the HARMs was obtained using the simplified AG in both the upper and the lower layer, but we observe that the computational complexity in both construction and evaluation phase have improved in comparison to the simplified AG. The improvements achieved using the HARMs compared with the simplified AG will be shown in the next section.

Simulation Result

The HARMs improve the efficiency of the attack model by reducing the number of independent connections between hosts and vulnerabilities. We investigate the improvements achieved using the HARMs through simulations. Our simulation setup used identical hosts, so that the scalability of the HARMs and the TLAG will be identical. We will consider a network with heterogeneous nodes in our future work to compare the scalability of the HARMs and TLAG.

The result of the simulation must be credible using appropriate quantification methods. For our simulations, we used an automated network simulation tool named Akaroa2, which produces credible stochastic simulation results with statistical analysis [START_REF] Pawlikowski | On credibility of simulation studies of telecommunication networks[END_REF][START_REF] Ewing | Akaroa-2: Exploiting network computing by distributing stochastic simulation[END_REF]. All simulation results were obtained with the confidence level of 0.95, and the relative error of 0.05. The simulation program was coded using Python, and it was conducted in a Linux environment with Intel(R) Core2 Quad CPU 2.66GHz with 3.24GB of RAM.

A Practical Network Structure

In our previous study [START_REF] Hong | HARMs: Hierarchical Attack Representation Models for Network Security Analysis[END_REF], we considered a fully connected system for the complexity analysis. The attack scenario used in the simulation is similar to that in the experiment conducted by Ingols et al. [START_REF] Ingols | Practical attack graph generation for network defense[END_REF]. The networked system used in the simulation is shown in Figure 1. A network in our simulation setup used four sites, with each site consisting of five DMZ hosts, five administrative LAN hosts, and ten internal subnets. Each subnet has a bus topology to connect all hosts. The port information and the firewall rules are abstracted. We assigned ten remote-to-other vulnerabilities to half of hosts in each subnet, and the other half with one remote-to-root and nine remoteto-other vulnerabilities. The attack scenario was to compromise a host in the DMZ, an administrative LAN host, and all hosts in the network that has a remote-to-root vulnerability. Hosts that were not directly reachable from the attacker were compromised using other hosts as a stepping stones. The number of hosts in each subnet was increased to compare the scalability between the simplified AG and the HARMs. The scalability comparison is shown in Figure 2 for construction, and 3 for evaluation. Figure 2 shows the performances of the simplified AG and the HARMs in the construction phase. Only Ingols et al. [START_REF] Ingols | Practical attack graph generation for network defense[END_REF] and our work considered different types of vulnerabilities in the simulation. The simulation result shows that the number of edges in the simplified AG increases more rapidly than the HARMs. However, construction times for the simplified AG and the HARMs do not have a significant difference. This indicates that the number of edges has a little influence on the construction time. Both In contrast, the number of nodes computed in the HARMs is much greater than that of the simplified AG. The simplified AG constructs the attack paths using vulnerability sequences only, but the HARMs also analyse the sequence of hosts. Therefore, we require extra space of memory to store the information.

Network Topologies and Vulnerabilities

We use various network topologies and variable number of vulnerabilities in our second simulation and compare it with the performance of the simplified AG. We incorporate bus, ring, and star topologies to connect hosts in each internal network, and the number of vulnerabilities for each host is varied from 10 to 150. The number of hosts is fixed at 1200 when simulating the variable number of vulnerabilities. The same network structure was used, but the goal of the attack is to compromise a single host selected in the last subnet in the internal network (e.g., a host in the 10th subnet in each internal networks). The bridging hosts (i.e., head hosts that connect to other subnets) are not selected as the target host. In order to simulate different topologies, we assigned a single vulnerability to each host that is enough to gain the root access. The simulation of different topologies is shown in Figure 4. Since the construction of the HARMs and the simplified AG is similar, we compare the different performance observed in the evaluation phase. The construction of the full path topology was computable, but the evaluation of the full path topology suffered from the scalability problem in the evaluation phase, where the evaluation of 400 hosts reached to the time out (i.e., it took longer than three hours). However, we observe that the simplified AG is slower than the HARMs when all topologies are taken into account significantly.

The simulation of varying the number of vulnerabilities is shown in Figure 5. The number of hosts was fixed at 1200. The fully connected topology for both attack models could not be evaluated for 1200 hosts. In addition, the ring topology for the simplified AG reached to the time out during the simulation (i.e., it took longer than three hours to evaluate). The comparison in the evaluation phase shows that as the number of vulnerabilities increase, the growth rate of the simplified AG is much greater than the HARMs for all network topologies. The trend for the simplified AG showed a quadratic increase, whereas the trend for the HARMs showed a linear increase in time. The slopes are almost linear for all topologies of HARMs, indicating the number of vulnerabilities is also a constant factor in the evaluation phase.

We simulated the performance of the simplified AG and the HARMs considering practical attack scenarios, various network topologies and variable number of vulnerabilities. Both attack models were built and analysed using the same networked system in the simulation. The same method to construct the attack model was applied to both the simplified AG and the HARMs, and the result shows that the time measurement for the construction phase is similar. The same algorithm was used to compute the full attack paths, but we observe that the HARMs improved the performance in the evaluation phase dramatically.

Discussion

The efficiency of the HARMs is shown through comparisons with existing attack models and simulations. We listed some key questions to compare the scalability of attack models. The simulation shows that the scalability of the HARMs, and was compared with the simplified AG to show the efficiency of the HARMs in the construction and the evaluation phases. However, to improve the usability of the HARMs, we must consider the modification phase in case of update events in the networked system.

Scalability of attack model phases

The simplified AG suffered the scalability problem due to independent connections between the model components. The representation of the simplified AG had more edges compared with the HARMs. The number of nodes was the same, but the number of edges was greater in the simplified AG. However, the construction time shows that there is only a little difference between the HARMs and the simplified AG.

A few existing attack models compared the performance against the simplified AG in the construction and the evaluation phases. None of the attack models considered an update event in the networked system, and how their models are updated. The similarity between the simplified AG, LAG, and the MPG is that they are represented as a single layer in an attack model. Those attack models suffer from a scalability problem in the representation, and also the modification may affect all nodes in the attack model in the worst case. However, hierarchical models, such as the HARMs and the TLAG, have less structural changes as they have less relationship between nodes than attack models that are represented in a single layer. In addition, the HARMs have fewer components to update, because the TLAG has higher number of lower layer models.

Network Structure and Attack Scenarios

There are many different network structures and types threatened by cyber attacks. The worst case complexity defines the upper bound performance for the HARMs. We have built two different attack scenarios to compare the scalability of the HARMs and the simplified AG through simulations. The first attack scenario covered a practical network structure. The attack scenario was simulated, and the result shows that the performances of both the HARMs and the simplified AG are much better than the defined complexities. However, the improvements observed are proportional to their theoretical complexities. Thus, the complexity measurements are good indicators to estimate the performance of the HARMs. The efficiency of the HARMs is shown in the evaluation phase, where the HARMs outperform the simplified AG. The simulation study showed a clear benefit of using the HARMs.

The second simulation compares the scalability of different network topologies, and how much the scalability is affected when the number of vulnerabilities increased. The results were comparable with some of the existing attack models and their analyses [START_REF] Ou | A scalable approach to attack graph generation[END_REF][START_REF] Ingols | Practical attack graph generation for network defense[END_REF]. The comparison between the HARMs and the simplified AG shows the performance of the HARMs was always better than the simplified AG. The quadratic growth trend of the simplified AG in the evaluation phase was comparable against the HARMs, where the growth trend was almost linear. However, we only considered a single network topology for each simulation. The networked system consists of different network topologies, but this is not modelled in our study. To accurately measure the expected performance of the networked system and its attack models, combinations of network topologies need to be modelled and simulated.

The variation of vulnerabilities affected the simplified AG significantly, showing an almost exponential growth in the evaluation phase. However, the HARMs showed a linear growth of the evaluation time, which is practically computable for a large number of vulnerabilities. Because the underlying algorithms are the same (e.g., construction algorithm, full path search algorithm), the improvement of scalability comes from the structural advantages of the HARMs.

The performance between the HARMs and the TLAG is not compared in the simulation because identical hosts were used. A network with homogeneous hosts will result in HARMs and TLAG having the same number of upper and the lower layer components. A further comparison is required using a network with heterogeneous hosts to distinguish the HARMs and the TLAG performances.

Since our focus was on comparing the scalability of current attack representation models, we have not considered a real system because we have assumed that the complexity in each host is linearly proportional to the number of hosts (i.e., a constant factor). However, the complexities in real systems are difficult to represent in a simulation, and various network protocols and services may affect how the network traffic flows, such that considering the time in the security analysis may vary the result. We will consider a real system in our future works.

The Simplified AG and the HARMs

The simulation demonstrated the improvements of existing attack models using the same underlying attack model and algorithms. The time measurement for the construction phase was similar, but the simplified AG showed that it created more edges than the HARMs. Consequently, the performance of the evaluation phase shows that the evaluation time for the simplified AG has increased more rapidly compared with the HARMs, where the growth of the HARMs evaluation time was almost linear. The underlying algorithm to compute the attack paths was the same, but we observe that the performance of the HARMs is more efficient than the simplified AG. The structure of the HARMs reduces the total number of edges in the attack model, so we require fewer computations during the evaluation phase.

In the evaluation process, the number of nodes used in the computations was captured in the simulation. The simulation showed that the number of nodes in the HARMs is greater than the simplified AG, because the upper layer components of the HARMs are also evaluated. As a result, more memory space is required for the HARMs. However, if we allocate the memory space efficiently (e.g., by freeing spaces used by the lower layer calculations when finished), we can reduce the extra memory required by the HARMs. Also, if the lower layer information has been changed, only the lower layer calculations are affected. As a result, the complexity of the HARMs is not largely affected. In contrast, the evaluation time for the simplified AG may fluctuate depending on the changes in the lower layer. In addition, we observed that the number of nodes is only one of the factors that affect the time complexity in the evaluation phase. The clustering of nodes can reduce the time complexity dramatically, as shown in the simulation.

Conclusion

Attack models have evolved over the last decade to evaluate the network security. They can also provide countermeasures to enhance the security. The major hurdle of evaluating the network security considering the full attack paths is the scalability problem, where the number of possible attack scenarios grows exponentially as the number of hosts and vulnerabilities increase. Improvements to the full AG have been developed, and new types of attack models (e.g., LAG, MPG and TLAG) have been proposed to address the scalability problem. The HARMs are described and compared with some of the existing attack models to show the scalability improvements.

The efficiency of the HARMs is demonstrated through the simulation, where the underlying algorithms and models were the same to evaluate the full attack paths, but we observe that the performance of the HARMs was better than the simplified AG in the simulation. Moreover, the HARMs have better performance than computational complexities when a practical network scenario is considered.

Fig. 1 .

 1 Fig. 1. A Networked System Configuration for Simulation

Fig. 2 .

 2 Fig. 2. A Comparison between AG and HARMs in the Construction Phase

Fig. 3 .

 3 Fig. 3. A Comparison between AG and HARMs in the Evaluation Phase

Fig. 4 .

 4 Fig. 4. Scalability Difference of Network Topologies in the Evaluation Phase

  Fig. 5. Scalability Difference with Varying Number of Vulnerabilities

Table 1 .

 1 Studies covered for the construction phase

	Attack models TLAG [4] LAG [5] MPG [11] HARMs [17]
	Q1	Yes	Yes	Yes	Yes
	Q2	No	Yes	Yes	Yes
	Q3	No	Yes	No	Yes
	Q4	No	Yes	No	Yes
	Q5	No	No	Yes	Yes