Threat Analysis for Hardware and Software
Products using HazOp
Burzin Daruwala, Salvador Mandujano, Narasimha Kumar Mangipudi, Hao-chi Wong
Security Center of Excellence
Intel Corporation
2111 NE 25
thSt, Hillsboro, OR 97124
USA
{burzin.daruwala, salvador.mandujano, narasimha.kumar.v.mangipudi, hao-chi.wong}@intel.com
Abstract: - These days, hardware and software products must be designed with security in mind and threat modeling is a fundamental step towards properly securing sensitive areas on the system. The task of identifying all relevant threats, however, is not an easy challenge. Even though use cases may be properly documented and routinely used during the development cycle for elicitation of functional requirements, non-functional requirements, such as security, are often neglected due to the priority new non-functionality receives over other aspects of the product, as well as the complexity of analyzing and planning for the unexpected. Better methods are necessary to protect computing technologies whose complexity and attack surface keeps expanding with more and more features. In the field of process safety, a variety of techniques have emerged to assess and mitigate risk. Since the domains of safety and security share multiple similarities, various authors have suggested that safety techniques might find application in computer security. Actual applicability of these techniques to existing technologies, however, was yet to be demonstrated. This paper takes one such technique, HazOp, and applies it to Intel hardware and software shedding some light on the mechanization of use-case-based threat analysis. It shows how HazOp can be employed on a diverse range of technologies to correctly identify deviations from use cases that may represent a violation to the security objectives of the product. We document the advantages of this method over more traditional ones with regard to efficiency, extensibility and efficacy. The reader will also learn how to apply and, potentially, adapt HazOp to accelerate the discovery of system threats as well as the derivation of test scenarios for purposes of security evaluation. Key-Words: - HazOp, software security, hardware security, threat modeling
1 Introduction
Product teams at Intel use a Security Development Lifecycle (SDL) [1] to drive the creation of more secure products. A fundamental component of the SDL framework is threat identification, which can be divided into two parts: first, given a technology, determine what areas need protection; and, second, once the system has been implemented, assess the strength of the protections and identify any security holes that need to be closed. Both require an analysis of the different means an attacker could use to compromise the system. Having a methodology that provides consistency and repeatability to this analysis is key to the success of any threat modeling effort. A number of techniques exist that help identify and address security risks. One of them is the Hazards and Operability analysis approach, also known as HazOp [2, 3]. Unlike software-centric approaches, HazOp was originally created in the process industry, but has been applied to computer systems as well. We have obtained outstanding results applying HazOp to Intel software and hardware technologies. This paper documents our experiences with HazOp, describes lessons learned
and details examples of how to use this method to perform threat modeling.
1.2 Motivation & Importance
Security is an increasingly severe problem in all sorts of computing platforms. As we carry out more and more of our regular activities online, significant gains, ultimately financial, can be obtained by hackers from attacking these computer systems. With electronic systems and information services becoming more ubiquitous every day, and with the volumes of sensitive information available online, malicious parties are even more motivated to find vulnerabilities and exploit them. To retain customer loyalty and competitive advantage in the marketplace, it is essential that the makers of computer hardware and software ensure that their products are as secure as possible. Aware of this business requirement, Intel has been making security a top priority and an important design vector. Many product teams are creating secure-by-design products using the SDL framework, which adds a number of checkpoints along the Product Lifecycle (PLC) [4] to evaluate the security of the product at
each phase of its development – e.g., architecture, design, and implementation – and to identify design weaknesses and other vulnerabilities that need to be corrected along the way.
One of the phases of SDL is security testing, which means carrying out attacks that can be launched to compromise the target platform and its functionality. By thinking like an attacker, we try to discover vulnerabilities that need to be mitigated prior to release. Unlike functional validation, which verifies the operational soundness of a technology based on requirements and specifications, security testing is more concerned about deviations from expected behavior. For instance, if a use case indicates that the system should behave in a particular way under certain conditions, but it actually does something different than expected, there may be a security violation that may require further review (e.g., if a read-only component is enabled as read-write, data that should otherwise be protected may be exposed to unauthorized modification).
Traditionally, the above analysis has been performed in an ad-hoc fashion, relying on the evaluator's previous experience and intuition. This approach has a significant limitation: intuition usually leads the evaluator from one problem area to another, often not systematically. The analysis, therefore, may lack in structure and organized coverage, and this is where HazOp helps.
HazOp was originally used in the field of physical and procedural safety to enumerate all possible misbehaviors of a system and to identify hazards arising from deviations from intended behaviors. A variant of HazOp has been successfully used by product teams at Intel. The evaluation targets have included software, firmware, as well as hardware, and the method has been applied at different stages of the PLC, from analysis of data flows in architecture and design, to identification of test cases that validate a secure implementation., In one case, we also adapted HazOp to handle special requirements of the system in order to successfully identify key threats.
Our goal with this paper is to share our experiences in using HazOp for security analysis and show actual applicability of the method to hardware and software technologies. After reviewing this paper, the reader should be able to employ HazOp analysis on a chosen product by following some of the examples. Additionally, the reader will also be able to understand how HazOp analysis can be adapted and tuned to fit their specific needs in order to discover threats that would otherwise be invisible to the standard HazOp method (i.e., its guidewords),
important guide for accelerating the discovery of vulnerabilities.
1.3 Background Work
Different techniques exist in the literature to identify system threats. STRIDE [5], for instance, is a security analysis method based on decomposing the system and iteratively analyzing its parts. Once the different subsystems have been delimited and their interactions identified, they are matched against the six STRIDE vectors: spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. Each subsystem is then studied to find out whether each STRIDE vector is applicable or not (for instance, whether a potential spoofing problem needs to be analyzed for that specific subsystem). If a STRIDE vector is found to be relevant, the analyst then tries to learn how the system is protected from that threat and what attacks may be possible. Connections between modules can also be analyzed with STRIDE, as well as data flows and user interactions. However, the method relies on the proper segmentation of the system until small enough pieces suitable for analysis are found, and it does not help derive test scenarios directly, but enables rapid identification of risks.
Attack trees [6] are another method that has been widely used in software. The method uses diagrams to link conditions to attacks. Root nodes in the tree represent attacks for which a number of conditions (i.e., children nodes) must be satisfied. Logic operators like AND and OR can be used to link these conditions together and help understand the feasibility of an attack. Attacks at the root are directly related to a primary threat and can have a larger number of conditions. A path on the tree links together conditions that would make the attack possible, and, depending on system size, these could be counted in the hundreds. Once the attack tree is completed, protections are designed to address the threats that are closest to the root, hereby maximizing protection coverage. The complexity of creating an attack tree using use cases as input is a daring task, as, first of all, a list of potential attacks needs to be created. Once built, an attack tree may also become too complex to support proper identification of threats and test cases given the number of nodes and edges to analyze.
A software-centric tool by Microsoft called Security Development Lifecycle Threat Modeling Tool [7] allows system architects and analysts to identify protection issues and communicate their risk and potential mitigation. The tool incorporates STRIDE and concentrates on the study of software
allows for the construction of multi-level data flow diagrams, it relies on the proper decomposition of the system.
The tools listed above do not help with the derivation of test scenarios and, to the best of our knowledge, none of these have been applied to hardware. Part of the motivation behind our project was to investigate threat modeling methods that can be employed to analyze hardware, firmware, and software technologies in an attempt to develop a best-known-method in the area of systematic security modeling.
The methodology we chose is different from the above tools in that it is based on the creation of sentences produced from use cases and guidewords. We provide more details on HazOp in the next section.
2 HazOp Analysis
HazOp analysis [2] uses two main ingredients: use cases and guidewords. Use cases (UCs) describe the interactions (verbs) between an actor (subjects) and a system (objects) with a set of conditions (clauses, intentions). These can be obtained from the product use case documents, architecture and design specifications, or by gathering information from designers, marketers and users about the actual flow of events for using the product. Guidewords (Table 1) are used to specify deviations for each of the elements of the UC: actor, action, object, and condition.
When performing HazOp analysis, one needs to: 1) Define the system’s Use Cases (UCs) 2) Record the Intentions for each step in the UC 3) Apply HazOp guidewords to determine
Table 1: List of HazOp guidewords
Element Guide Word Meaning
NO Actor is not in the correct role
AS WELL AS Actor is in the correct role, but is also in another (typically more privileged)
role Actor
OTHER THAN Actor in a different, incorrect role (typically a legitimate role with different
goals than this role) takes the action
NO No action takes place
MORE The action takes place for a longer time than required
The action is incomplete LESS
The action takes place for a shorter time than required Action
OTHER THAN An incorrect action takes place instead of the correct one
NO The action occurs, but no object is provided
The action occurs on an empty object LESS
The action occurs on an object that is too small
MORE The action occurs on an object that is too big
AS WELL AS Additional objects are acted on
PART OF The action occurs on part of an object
Object
OTHER THAN An incorrect object is used (e.g. wrong data, wrong details, wrong format,
wrong button)
The condition is not met NO
The condition is not detected
MORE A quantitative condition is exceeded
AS WELL AS Additional conditions apply
Only some of the required conditions are met PART OF
Only some of the required conditions are detected Condition
possible deviations from each intention, feasible causes and likely consequences
4) Repeat the above process to completely eliminate or reduce the risk of deviation and/or reduce the severity of the consequences
Note that for any particular UC or a step within the UC, one may not be able to apply all the guidewords. The goal of HazOp is to lead the person doing the analysis into considering all feasible deviations and determine appropriate mitigations. The key to effective use of HazOp is to facilitate thinking about deviations. Coverage completeness comes from the proper analysis of all documented UCs, as well as the security objectives that have been established for the product.
The technique relies on the availability of documented UCs and is, therefore, applicable to all sorts of technology. At Intel, UCs are defined for pretty much all products (notice that UCs for certain technologies may involve internal interactions, as well as subjects and objects that represent system internals; this is no limitation to HazOp). The availability of UCs for a given technology makes HazOp an attractive method to use at Intel. In the following sections we will describe how threats and test cases were derived using this methodology.
3 Applying HazOp
HazOp can be used not only as a tool to create a threat model, but also to understand the general security needs of a product. We will now show how to proceed with the application of the methodology to different product features. For readability, this section has been divided into two parts: application to software/firmware, and application to hardware.
3.1. Software and Firmware Example -
Intel® Remote PC Assist Technology (Intel® RPAT)The following is an example of how to apply HazOp to software/firmware products.
HazOp analysis was used to identify threats to the architecture, design, implementation and validation of Intel® RPAT 2008 and 2009 [9]. Intel® RPAT enables you to make a fast call for help and request remote technical assistance from a service provider if you encounter a problem with your PC, even when the OS, network software, or applications are not functioning. While the entire Intel® RPAT model is comprised of more than a dozen UCs, we will illustrate HazOp with one of them, namely, the User Enrollment scenario. User enrollment is supported by flows involving interactions between software and firmware, for instance, between the RPATUI (Intel® RPAT User Interface) and the Manageability Engine (ME) embedded processor [10]. As the name implies, the RPATUI allows a user to enroll and un-enroll for Intel® RPAT services. This enrollment is registered with a Service Provider (SP) who offers on call, real-time diagnosis, solutions and technical assistance. Once the user is enrolled with an SP, a teardown connection from the end-user’s PC to a service technician’s console can be established at the wish of the end-user so that the PC can be accessed for repair. Table 2 is self-explanatory and shows parts of the HazOp analysis of the enrollment scenario. The use of HazOp guidewords helps us identify possible deviations from the UC and serves as an input for threat analysis (Table 2). For instance, an attacker may try to identify a backdoor into the system, and supply more characters than expected in the enrollment process (row 3). Additional input characters can lead to code injection exploits, privilege escalation or denial of service issues, all of which constitute threats that Intel® RPAT designers have to address.
Table 2: Applying HazOp to Intel® RPAT User Enrollment
Actor Action Object Condition Guideword Interpretation
1 User Enters Account ID,
Password
Not enrolled
NO Does not enter any credentials during
enrollment
2 LESS/PART OF
Enters only Account ID or Password;
enters only a few characters of
Account ID or Password
3 MORE Enters more characters than those
required in either or both Account ID and/or Password
4 OTHER
THAN
Enters invalid characters or encoded characters; enters an unregistered Account ID; enters a script instead of Account ID or Password
10 RPATUI Sends Account ID, Password
to ME NO Account ID and Password were not
received by ME
11 MORE Account ID and Password credentials
are received by ME as well as somewhere else
12 ME Stores Account ID,
Password
On flash NO Account ID and Password not stored
by ME on flash
13 LESS / PART
OF
Only Account ID or Password, or a part of them is stored on flash
14 MORE Account ID and Password are stored
on flash and somewhere else
15 AS WELL AS ME stores Account ID and Password
and reports insufficient flash space
The analysis further requires the processing of these deviations and translating them into a list of threats, mapping the threats to the product security objectives (if available) and providing solutions to thwart the attacks. In the above case, stronger input validation could be built into the software in order to deter this type of attacks in the User Enrollment case. HazOp also helps define test cases. In the case of the above UC, the security evaluation team could consider tests derived from rows 1, 2 and 3 above. That is, HazOp tells us that it may be worth testing the system with null input, or input larger than the expected size, or partial input. By implementing these tests, we will be able to validate the soundness of the input validation logic that was incorporated, and we will verify absence of vulnerability to the code injection and privilege escalation threats found with the application of the guidewords.
3.2 Hardware Example – Intel® VT-d
To the best of our knowledge, there are no reports of applications of threat modeling techniques to hardware in the literature. Given the internal interactions that need to be analyzed in a hardware system, it is counterintuitive to think that threat modeling techniques that have worked for software and firmware would work equally well for hardware. We decided to pilot the use of HazOp for a hardware product and selected Intel® VT-d [11], a technology in CPU.Virtualization technologies have received significant attention from the security community. We decided to use HazOp to identify threats to our Intel® VT-d hardware in CPU in order to make sure all relevant attack vectors were been addressed at the design and implementation levels.
Intel® Virtualization Technology for Directed I/O (Intel® VT-d) [11] incorporates hardware support to
isolate domains in a virtualized environment. In a platform with multiple virtual machines (VMs), a device must be assigned to a particular domain in order for a VM to have access to it (Figure 1). Intel® VT-d accelerates this mapping by providing transaction remapping capabilities and hardware encapsulation of the domains. Hypervisor writers (the layer between the guest OSs and the hardware) use Intel® VT-d to more effectively implement resource utilization on the platform by the VMs.
Figure 1: A virtualized environment
VM1 VM2
A domain is a set of physical memory resources that are assigned to a VM. A fundamental property of Intel® VT-d that must be preserved is that of domain isolation: Domains should not be able to access other domains or the resources assigned to them; similarly, a device should not be able to access other devices or domains beyond the ones granted by their existing privileges, unless the hypervisor configures Intel® VT-d remapping hardware to allow this operation.
A number of VM-escape attacks have been identified in the past [12]. These attacks allow guest operating systems (OSs) to alter the execution of the platform’s hypervisor responsible for orchestrating the concurrent execution of VMs, and in the case of
Hypervisor
Guest OS1 Guest OS2
Physical Host Hardware
Intel® VT-d, arbitrating access to the hardware. A vulnerability in this area could allow a guest OS, for example, to interact with Intel® VT-d hardware directly, and could allow malicious code to persist through system reboot. This would have obvious negative effects on the security of Intel® VT-d. An important UC in Intel® VT-d is the assignment of
devices to domains. Once a domain is created, the Intel® VT-d Remapping Engine will update its tables to capture what resources are assigned to what domain. For instance, a network card may be visible to only one of the VMs on the system and Intel® VT-d will be responsible for blocking unauthorized transactions from reaching the card. Table 3 shows the application of HazOp to this UC.
With the use of HazOp we were able to identify various threats to Intel® VT-d. For instance, row 3 identifies the threat of a device being assigned to more than one domain at the same time. A test for this scenario, for instance, could try to do device assignments on the fly in order to see how Intel® VT-d handles this condition and how an error is reported or not. In the case of access authorization, row 11 above identifies the possibility of a domain being able to access devices beyond its privilege. Validation plans may already include tests that guarantee a device that has been assigned to a domain is, in fact, visible to that domain as expected. From the attacker’s perspective, it is now necessary to guarantee that it is not possible for a malicious VM to eliminate this binding, or for a VM to reach beyond its limits and access devices assigned to other domains. By applying the AS
row 12 a potential consequence of a device being inaccessible to its legitimate domain, which might constitute a denial-of-service threat that needs to be considered and, potentially, mitigated.
By taking all UCs and iteratively applying the guidewords to them, security evaluators were able to detect sensitive conditions that had to be validated in
the lab. In this case, in which a hardware-based feature was analyzed, new security objectives for the analysis were also derived. Even when the method was not created to define such security objectives, our HazOp-aided analysis also served the purpose of determining what components needed protection and what the scope of those protections had to be.
4 Results and Lessons Learned
4.1 Applicability
The application of HazOp is not limited to a particular product (hardware or software) or a particular phase of the SDL. HazOp can be equally applied to the evaluation of very diverse architectures, designs and implementations, and assists in the validation of a product that needs to be scrutinized in order to identify its main threats and vulnerabilities. In general, our experience shows that HazOp helps to:
1. Identify threats that need to be mitigated 2. Derive abuse test cases for penetration testing 3. Define and/or validate security objectives
4.2 Data collection
One of our key learning points from applying HazOp was that, while HazOp analysis works well
Actor Action Object Condition Guideword Interpretation
1 NO Device does not get assigned to domain
3 MORE Device is assigned to more than one
domain 4
Hypervisor Assigns Device to Existing
Domain
OTHER THAN
Device is assigned to a domain other than the intended one
9 NO Intel® VT-d does not report
success/failure 10 Intel®
VT-d Reports Success/ Failure OTHER THAN
Intel® VT-d reports success instead of failure, or failure instead of success
11 MORE Domain is able to access more devices
than expected
12 AS WELL
AS
Domain is able to access Device and is able to remove it from the domain as well
14 NO Domain is not able to access the device
15
Domain Accesses Device Device
assigned to Domain
PART OF Domain is able to access the device only
sometimes (at boot only, upon assignment only)
application of the guidewords with all the permutations and combinations of actors, interactions, objects and conditions may result in large amounts of data. Having so much data may complicate the comprehension of the security properties of the system that are relevant to each UC and may slow down the creation of test cases if individuals other than those who actually performed the analysis are responsible for the testing. To address this problem, we recommend a method for consolidating data generation. The method can be summarized by the acronym DAT:
1. Decompose. Decompose the analysis into smaller steps (not necessarily with all the permutations and combinations of actors, interactions, objects and conditions, but at a level that makes sense)
2. Apply. Apply the HazOp guidewords to each step where it makes sense (comprehensible level)
3. Think. Think through on how to address the vulnerabilities exposed by the application of guidewords. Addressing the vulnerabilities comprises:
a. Accept: Acknowledge the vulnerability and assess the risk with respect to the security objectives. Accept the risk of an attack if the vulnerability is beyond the scope of security objectives; otherwise thwart the attack
b. Detect: Record an attack if the vulnerability gets exploited. Usually, the vulnerabilities that may fall into this category are acceptable (refer to Accept).
c. Thwart: Put specific measures in place to either, completely eliminate the attack, or reduce the impact of an attack to an acceptable level
4.3 Tuning and Adaptability
When applying HazOp to Intel® VT-d, we determined that guidewords needed to be properly aligned with the conditions in order to correctly analyze our UCs and derive threats. We decided to create shortcuts:
REPEAT Actor performs the same action
multiple times PRESENT/NOT
PRESENT
Actor tries to access resources that may or may not be present on the system
These shortcuts allowed us combine guidewords and conditions in a single structure. REPEAT allowed us to think about scenarios where an action is carried
out multiple times consecutively (could be thought of as an extension of guideword MORE). In particular, it helped us go over two scenarios: 1) Intel® VT-d tables are full and the eviction logic kicks in, and 2) a device is already assigned to a domain but the hypervisor requests the same assignment for a second time – or a removed device is requested to be removed again from a domain. In the case of PRESENT /NOT PRESENT we captured the condition of operating on objects that may be logically present or not. For instance, a test was written that tried to remove domains that had already been removed, looking for memory handling issues. It also allowed us to define a test to create domains using the same Domain ID in order to discover potential collision problems in the hardware when Intel® VT-d tables are traversed (we were in fact trying to infer, experimentally, how the hardware handled Domain IDs beyond the 8-bit limit; for instance, truncation). Through these test cases we learned how the hardware handles each identifiers in order to access Intel® VT-d root tables and how an invalid Domain ID is decoded. It also helped us validate that aliasing attacks are not possible in the Intel® VT-d domain that we evaluated.
4.4 Efficiency
In the case of the hardware analysis of Intel® VT-d in our CPUs, security objectives had not been defined. The use of HazOp allowed us to derive 15 different security objectives that guided the iterative execution of HazOp over the Intel® VT-d UCs. With the use of existing validation tools, 12 security test cases were implemented, which provided coverage for 80% of the security objectives and allowed the product team to verify absence of vulnerability on an early stepping of the CPU. In a matter of days, HazOp had helped us identify security objectives, threats and penetration testing scenarios. Compared to less structured techniques used in the past, HazOp allowed us to speed up threat modeling (see Figure 2). In previous projects, like the security evaluation of HTTP and TLS stacks, the team had to brainstorm to derive test scenarios. Different online resources had to be reviewed in order to come up with the specific threats the team will consider in their testing. This approach was based on interface exposure and analysis of privilege levels. Although it allowed us to identify some vulnerabilities in the code, it was significantly time consuming and lacked organization.
The Intel® RPAT analysis resulted in the identification of numerous abuse-test cases for
penetration testing which provided coverage for the main threats identified with HazOp.
Figure 2: Test derivation efficiency (efficiency = no. of test cases / identification time in weeks)
In all instances, when compared to more traditional techniques, HazOp proved a more efficient method to perform threat modeling. The number of test cases generated (Table 4) in each project, constitutes considerable progress from the utilization of other techniques. HazOp helped us change that by showing us a step in the right direction that reduces the amount of time invested in threat modeling by 50%+, while contributing key test cases that validate the security of the product.
Table 4: Applicability of HazOp Security Tests Derived Security Objectives Derived Intel® VT-d 17 Yes
Intel® RPAT 12 Yes
5 Conclusion
The role of security analysis is becoming increasingly important in the computing industry as complexity is added to platforms and product environments assume higher risks. We have shown how HazOp accelerates security analysis and is applicable to hardware as well as software and firmware technologies. We also showed that the HazOp methodology is SDL-checkpoint agnostic in that it can be used to evaluate architecture, design as well as implementation targets effectively. HazOp was applied on different projects in order to identify threats, define security requirements and generate penetration-testing scenarios by systematically matching guidewords to use cases readily available in the documentation of platforms and product features. Throughout these projects we discovered that the technique is flexible enough as to allow the
incorporation of new guidewords to accommodate special product needs. This paper proposed a more rigorous approach to carrying out security analysis of software and hardware which results in the correct identification of security issues that need to be addressed before product release. The authors hope that the cases presented here will help the reader apply HazOp more effectively to the study of product security, and that this method will eventually become an integral part of the security analysis of any computing product.
References:
[1] Howard, M., “The Trustworthy Computing Security Development Lifecycle”, Microsoft Software Development Network Magazine, 2005
[2] Srivatanakul, T., Clark, J. A., and Polack, F., “Writing Effective Security Abuse Cases”, University of York TR YCS-2004-375. 2004 [3] Koornneef, F., Van der Meulen, M., “HAZOP
Analysis of Formal models of Safety-critical Interactive Systems”, SAFECOMP 2000, vol. 1943 of LCNS, Springer, 2000
[4] Galluzzo, C., “The Implementation of the Product Life Cycle at Intel; An Examination in the Use of Change Agency to Achieve Cultural Change and Business Results”, Mgmnt. of Eng. and Tech. ’07, Portland, OR, Aug. 2007 [5] Hernan, S., Lambert, S., Ostwald, T., and
Shostack, A., “Uncover Security Design Flaws Using the STRIDE Approach”, Microsoft Development Network, November, 2006
[6] Schneier, B., “Attack Trees”, Dr. Dobb's Journal, Vol. 24, pp.12-16, December 1999 [7] “Microsoft SDL Threat Modeling Tool”,
Microsoft Development Network, Security Development Center, v. 3.1.4
[8] Schwarz, B., Chen, H., Wagner, D., Morrison, G., West, J., Lin, J., and Tu, W., “Model Checking an Entire Linux Distribution for Security Violations”, Annual Computer Security Applications Conference, 2005
[9] “Intel® Remote PC Assist Technology”, Intel
Platform Extension Services, http://www.intel.com/technology/product/remo
tepcassist
[10] “Intel® Active Management Technology”, Intel Corp. 2007, http://www.intel.com/vpro [11] “Intel Virtualization Technology”, Intel
Technology Journal, Vol.10, issue 3, 2006 [12] Plankers, B, “VM Escape & VMware Critical
vmkernel Updates”, SANS Newsbites Newsletter, September, 2007
