DETAILED ACTION
1. Claims 1-22 are pending.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
2. Claims 1-3 and 5-6 are rejected under 35 U.S.C. 103 as being unpatentable over Kundu et al. (US 20190044945 A1) in further view of Klein et al. (Klein, Gerwin & Andronick, June & Elphinstone, Kevin & Murray, Toby & Sewell, Thomas & Kolanski, Rafal & Heiser, Gernot. (2014). Comprehensive Formal Verification of an OS Microkernel. ACM Transactions on Computer Systems (TOCS). 32. 10.1145/2560537.) in further view of Nanda et al. (US 11,216,413 B1).
3. Regarding claim 1, Kundu et al. teaches a computing device ([0020]: “FIG. 11 depicts a block diagram of internal and external components of a computing device, in accordance with an embodiment of the present invention.”), comprising:
A plurality of hardware resources including a set of one or more hardware processors ([0005]: “Within multi-node server architectures, the node is defined as a unit of hardware with a processor; memory; and internally and externally connected IO devices. Multiple units of such hardware are interconnected with inter-node cables (e.g., SMP cables).“), memory ([0005]: “Within multi-node server architectures, the node is defined as a unit of hardware with a processor; memory;“), and storage devices ([0092]: “Memory 1106 and persistent storage 1108 are computer readable storage media. In this embodiment, memory 1106 includes random access memory (RAM) 1114 and cache memory 1116. In general, memory 1106 can include any suitable volatile or non-volatile computer readable storage media.”), wherein the storage devices include instructions ([0093]: “in addition to a magnetic hard disk drive, persistent storage 1108 can include a solid state hard drive, a semiconductor storage device, read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, or any other computer readable storage media that is capable of storing program instructions or digital information.”; [0099]: “The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.”) that when executed by the set of hardware processors, cause the computing device to operate a virtualized system ([0104]: “These computer readable program instructions… which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. “; [0003]: “There are different kinds of virtual machines, each with different functions. System VMs (also termed full virtualization VMs) act as a substitute for a real machine by providing functionalities needed to execute entire operating systems... Some VMs, such as QEMU, are designed to also emulate different architectures while performing the execution of software applications and operating systems written for another CPU or architecture. Operating-system-level (OSL) virtualization allows the resources of a computer to be partitioned via kernel support for multiple isolated user space instances, while physically resembling and feeling like real machines to the end users. OSL virtualization is typically referred to as ‘containers’.”; [0004]: “A hypervisor is computer software, firmware, or hardware that creates and runs virtual machines. The hypervisor uses native execution to share and manage hardware. Thus, hypervisor(s) allow for multiple environments which are isolated from one another, yet exist on the same physical machine. Modern hypervisors use hardware-assisted virtualization and virtualization-specific hardware, primarily from the host CPUs. A hypervisor may be referred to as a virtual machine monitor (VMM). A computer on which a hypervisor runs one or more virtual machines is called a host machine. Each virtual machine is called a guest machine. The hypervisor presents the guest operating systems with a virtual operating platform and manages the execution of the guest operating systems. Multiple instances of a variety of operating systems may share the virtualized hardware resources. In contrast, OSL virtualization, (e.g., the containers mentioned above) must share a single kernel. However, the guest operating systems can differ in user space.”), the virtualized system including:
A set of one or more virtual machines (VMs) that execute one or more guest operating systems ([0004]: “Each virtual machine is called a guest machine. The hypervisor presents the guest operating systems with a virtual operating platform and manages the execution of the guest operating systems. Multiple instances of a variety of operating systems may share the virtualized hardware resources. In contrast, OSL virtualization, (e.g., the containers mentioned above) must share a single kernel. However, the guest operating systems can differ in user space.”; [0011]: “FIG. 2 is a functional block diagram illustrating a multi-node system in terms of virtual machines and hypervisors, in accordance with an embodiment of the present invention”; [0024]: “Components of data processing environment 100 can be tied to one or more virtual machines. Each of the virtual machines can be on the same or different cloud platform”; [0035]: “In an exemplary embodiment, there are two hypervisors—hypervisors 205A and 205B—and two virtual machines—guest virtual machine (VM) 210A and guest VM 210B (A set of one or more VMs that execute one or more guest operating systems), as illustrated in hypervisor-virtual machine environment 200.”);
A set of one or more virtual machine monitors (VMMs) corresponding to the set of one or more VMs respectively ([0004]: “A hypervisor is computer software, firmware, or hardware that creates and runs virtual machines. The hypervisor uses native execution to share and manage hardware. Thus, hypervisor(s) allow for multiple environments which are isolated from one another, yet exist on the same physical machine. Modern hypervisors use hardware-assisted virtualization and virtualization-specific hardware, primarily from the host CPUs. A hypervisor may be referred to as a virtual machine monitor (VMM)... The hypervisor presents the guest operating systems with a virtual operating platform and manages the execution of the guest operating systems.”. All VMs run on a hypervisor, i.e. VMM; [0035]: “In an exemplary embodiment, there are two hypervisors—hypervisors 205A and 205B (A set of one or more VMMs corresponding to the set of one or more VMs. Hypervisors are VMMs)—and two virtual machines—guest virtual machine (VM) 210A and guest VM 210B, as illustrated in hypervisor-virtual machine environment 200. Hypervisor 205A is connected to and manages guest VM 210A while hypervisor 205B is connected to and manages guest VM 210B”), wherein a particular VMM manages interactions between the corresponding VM and physical resources of the computing device ([0004]: “The hypervisor (VMM) uses native execution to share and manage hardware... Modern hypervisors use hardware-assisted virtualization and virtualization-specific hardware, primarily from the host CPUs. A hypervisor may be referred to as a virtual machine monitor (VMM)… The hypervisor presents the guest operating systems with a virtual operating platform and manages the execution of the guest operating systems. Multiple instances of a variety of operating systems may share the virtualized hardware resources (Physical resources of the computing device).”; [0035]: “Hypervisor 205A is connected to and manages guest VM 210A while hypervisor 205B is connected to and manages guest VM 210B (Managing the VMs includes managing how the VMs interact with the physical resources of the hosting device. The device which hosts the VMs are the computing device) System call interception unit 220A, communication tagging unit 230A, causality analysis unit 225A, and access control unit 215A are components contained within hypervisor 205A. System call interception unit 220B, communication tagging unit 230B, causality analysis unit 225B, and access control unit 215B are contained within hypervisor 205B.”);
An isolated environment ([0003]: “Operating-system-level (OSL) virtualization allows the resources of a computer to be partitioned via kernel support for multiple isolated user space instances, while physically resembling and feeling like real machines to the end users. OSL virtualization is typically referred to as “containers”.”; [0004]: “Thus, hypervisor(s) allow for multiple environments which are isolated from one another, yet exist on the same physical machine.”), the isolated environment including:
A policy manager that manages a set of one or more policies for the virtualized system ([0029]: “ In an exemplary embodiment, system management module 110 (Policy manager) can work in conjunction with existing intrusion prevention solutions in order to provide real-time access policy enforcement of sensitive data against an unauthorized remote entity that arrives through distributed hypervisor components (e.g., components 125A, 125B, 125C, and 125D).“) including installing the set of policies to a policy enforcement point ([0028]: “ system management module 110 propagates (Installing) the info (The set of policies) to all of hypervisors (To a policy enforcement point. The policy enforcement point is considered the policy enforcer within the hypervisor as described below) within a system. Thus, system management module 110 imparts the following capabilities within the target server: (i) real-time detection of attempts to access restricted resources and (ii) denial of unauthorized entities attempting to access the restricted resources. FIG. 1 describes an instance where there is a single target server for the ease of understanding. In other embodiments, a user can specify multiple target servers.”; [0033]: “system management module 110 works in conjunction with a system which includes: … a policy enforcer (Policy enforcement point) (e.g., component 125D) that decides whether to allow or block the READ system call from returned results.”.), wherein the set of policies includes one or more zero trust policies ([0028]: “Thus, system management module 110 imparts the following capabilities within the target server: (i) real-time detection of attempts to access restricted resources and (ii) denial of unauthorized entities attempting to access the restricted resources”; [0066]: “In step 725, system management module 110 invokes one or more hypervisors to deny access to the restricted resource and raise an alarm upon system management module 110 determining that the attempt to access the restricted resource is not authorized (Example of a zero trust policy). In an exemplary embodiment, an unauthorized end-user/entity associated with an unauthorized process (e.g., process 105B in FIG. 1) is denied access to the restricted resource within the target server”);
And the policy enforcement point enforces the set of policies ([0029]: “system management module 110 can work in conjunction with existing intrusion prevention solutions in order to provide real-time access policy enforcement (Policy enforcement is done via the policy enforcer of a hypervisor. The policy enforcer is also considered the policy enforcement point.) of sensitive data against an unauthorized remote entity that arrives through distributed hypervisor components (e.g., components 125A, 125B, 125C, and 125D) “; [0036]: “Policy enforcer (e.g., access control units 215A-B) is a component of a hypervisor which is responsible for allowing or disallowing the READ system call based on a configured security policy (Enforces the set of policies)”).
However, Kundu et al. does not explicitly teach a formally verified microkernel running in a most privileged level to abstract hardware resources of the computing device, and an isolated environment that is addressable only from the formally verified microkernel.
But Klein et al. teaches formally verifying a microkernel running in a most privileged level (Introduction: “This article presents a detailed coverage of the comprehensive formal verification of the seL4 microkernel… The target of our verification, the kernel, is the most critical part of a system, which is our motivation for starting system verification with this component. The customary definition of a kernel is the software that executes in the privileged mode of the hard-ware (The kernel is running in a most privileged level)… The seL4 microkernel is a member of the L4 microkernel family [Liedtke 1996], designed for providing provably strong security mechanisms while retaining the high performance that is customary in the L4 family and considered essential for real-world use ”) to abstract hardware resources of the computing device (2.1. seL4 Programming Model: “seL4 is a third-generation microkernel, loosely similar to Coyotos [2008] and Nova [Steinberg and Kauer 2010]). It is broadly based on L4 [Liedtke 1996] and influenced by EROS [Shapiro et al. 1999]. Like L4 it features abstractions for virtual address spaces, threads, IPC (Abstracts hardware resources) and, unlike most earlier L4 kernels, an explicit in-kernel memory management model and capabilities for authorization… Virtual address spaces are formed by explicit manipulation of virtual-memory related kernel objects: PageDirectories, PageTables, ASIDPools1 and Frames (mappable physical memory). As such, address spaces have no kernel-defined structure (except for a protected region reserved for the seL4 kernel itself). Whether the user level system is Exokernel like, a multi-server, or a para-virtualised monolithic OS is determined by user-level via a map and unmap interface to Frames and PageTables. The distribution of authority to the kernel virtual memory (VM) objects ultimately determines the scope of influence over virtual and physical memory. Threads are the active entity in seL4. By associating a CNode and a virtual address space with a thread, user-level policies create high-level abstractions, such as processes or virtual machines.”).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the invention of Kundu et al. with the teachings of Klein et al. such that the virtualized system includes a formally verified microkernel running in a most privileged level to abstract hardware resources of the computing device by applying the formal microkernel verification method to the microkernels used in the operating systems of Kundu et al. One would be motivated to do so to minimize potential bugs as taught by Klein et al. (Introduction: “With truly small kernels it becomes possible to take security and robustness further, to the point where it is possible to guarantee the absence of bugs [Tuch et al. 2005; Hohmuth and Tews 2005; Seshadri et al. 2007; Elphinstone et al. 2007] and to establish the presence of high-level security properties [Klein et al. 2011; Sewell et al. 2011; Murray et al. 2013; Sewell et al. 2013]. This can be achieved by formal, machine-checked verification, providing mathematical proof that firstly the kernel implementation is consistent with its specification and free from programmer-induced implementation defects, and secondly that the specification satisfies desirable high level properties that carry through to the code and binary level.”).
Moreover, it would have also been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to further modify the invention of Kundu et al. such that the isolated environments of Kundu et al. are addressable only from the formally verified microkernel to enforce isolation and improve security as taught by Klein et al. (Introduction: “a proof of information-flow noninterference, which shows that seL4 can be configured as a separation kernel to provide strong isolation [Murray et al. 2013]”; 5.1. Access Control Model: “Access control is one of the primary security functions that OS kernels provide. It is used to enforce high-level security properties like authority confinement, integrity and confidentiality on untrusted subjects, that is, those that cannot be relied upon to behave securely.”; 6.2. Timeliness Analysis: “Highly critical code is subject to strict assurance and certification requirements. It is usually also small and relatively simple, which increases the likelihood of correct operation. Less critical code, however, tends to be more complex and is subject to less stringent or no certification. In a mixed-criticality system it must be possible to certify the most critical code without considering any of the less-critical code. Mixed-criticality systems are therefore only possible if the highly critical code is strongly isolated from any less-critical code. The isolation is as critical as the highly critical code itself, and therefore subject to the same assurance and certification requirements. seL4 (seL4 is the microkernel), as described so far, provides strong spatial isolation. To make it an acceptable platform for mixed-criticality systems, it must also provide strong temporal isolation. Specifically, it must be possible to analyse the timeliness of execution of the highly critical code without making any assumptions on the behaviour of the less critical code.”).
However, Kundu et al. modified by Klein et al. do not explicitly teach the isolated environment includes a confidence level determination engine that calculates a confidence level for a system or user action based at least on inputs including identity information, and provides the calculated confidence level to the policy manager, wherein the policy manager updates one or more of the set of policies based on the provided confidence level.
But Nanda et al. teaches a confidence level determination engine that calculates a confidence level (Col. 4, lines 15-18: “The metadata-based data set operational signature generator 114 (Confidence level determination engine) is configured to generate data set operational signatures for respective ones of at least a subset of the data sets based at least in part on the obtained metadata.”; Col. 15, lines 36-44: “Step 426 involves determining confidence factors (Confidence levels) for the data set operational signatures. As mentioned previously, each data set operational signature may include a corresponding confidence factor (Includes a confidence level) vector providing different confidence factors for each of a plurality of possible data set management operations. Again, as in other steps of the process 421, determination of confidence factors in step 426 may be based at least in part on policy information provided by the data management policy engine 415.”) for a system or user action (Col. 12, lines 32-36: “For example, one or more particular management operations (System or user action) may be automatically performed for the corresponding data set only if the associated one or more confidence factors are above respective designated thresholds “; Col. 14, lines 3-15: “mapping between levels is implemented in the FIG. 3 embodiment. For example, as illustrated generally by the upward-directed curved arrows at the far right side of the figure, such inter-level mapping in the present embodiment includes mapping of data sets 302 and 304 at the data set level to corresponding operational signatures and confidence factors 306 and 308 at the operational signature and confidence factor level, and mapping of operational signatures and confidence factors 306 and 308 at the operational signature and confidence factor level to corresponding management operations and policies (Confidence levels are calculated for management operations. Management operations are examples of system/user actions) 310 and 312 at the management operation level. ”; Col. 15, lines 36-44: “Step 426 involves determining confidence factors for the data set operational signatures. As mentioned previously, each data set operational signature may include a corresponding confidence factor vector providing different confidence factors for each of a plurality of possible data set management operations. Again, as in other steps of the process 421, determination of confidence factors in step 426 may be based at least in part on policy information provided by the data management policy engine 415.”), and
provides the calculated confidence level to a policy manager (Col. 15, lines 16-19: “Step 422 involves collecting metadata for data sets, and is illustratively performed by the DAC 408 and the relativistic data set retriever 412, utilizing management policy information provided by the data management policy engine 415 (Policy manager)”; Col. 15, lines 60-67: “data management policies provided by the data management policy engine 415 may play a role not only in determining similar data sets, but… determining the particular data set management operations that are performed based at least in part on the operational signatures and confidence factors (Based on the confidence factors means the calculated confidence levels are provided to a policy manager since the policy manager uses said confidence levels, i.e. the data management policy engine 415)”), and
Updating one or more policies based on the provided confidence level (Col. 14, lines 16-26: “Machine learning engine 320 of the machine learning level can control various features of each of the underlying levels. For example, the machine learning engine 320 can adjust data set management policies (Updating one or more policies) at the management operation level, can adjust operational or target signatures at the operational signature and confidence factor level, and can adjust data set recommendations, classifications and associated metadata at the data set level, as illustrated generally by the downward-directed curved arrows exiting the machine learning engine 320 at the far left side of the figure.”; Col. 14, lines 27-37: “Machine learning engine 320 can be configured to carry out additional or alternative functionality in the system 300. For example, as indicated previously herein, similar data sets may be identified prior to generation of operational signatures, while additionally or alternatively operational signatures may be used to identify similar data sets. To illustrate the latter approach, an additional curved arrow is directed from operational signatures and confidence factors 306 to data sets 302 and is associated with generation of data set similarity measures”. The machine learning engine updates policies and is trained on data sets containing the confidence levels. So, it is considered to be based on provided confidence levels; See FIG. 3; Col. 5, lines 44-53: “The machine learning engine 120 of the processing platform 105 is configured to adjust at least one of the data set operational signature, the target signature and the data set management policy over time through machine learning based at least in part on user interaction with the given data set (User interactions with the given data set is influenced by confidence factors. Hence, when the machine learning engine adjusts a policy based on user factors it is also based on the calculated confidence levels). Numerous other types of features and functionality of the components 112, 114 and 116 of the data set management process 118 can similarly be adjusted over time through machine learning implemented by machine learning engine 120.”).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to further modify the invention of Kundu et al. modified by Klein et al. with the teachings of Nanda et al. such that an isolated environment of Kundu et al. includes a confidence level determination engine that calculates a confidence level for a system or user action based at least on inputs including identity information to add an additional layer of authentication such that an action may be denied if the confidence level does not meet a required threshold as taught in Nandu et al. (Col. 12, lines 32-45: “one or more particular management operations may be automatically performed for the corresponding data set only if the associated one or more confidence factors are above respective designated thresholds. As indicated previously, the one or more confidence factors in such an arrangement thereby illustratively comprise a vector of one or more confidence factors each controlling automatic performance of a corresponding one of the one or more particular management operations associated with the data set operational signature. The automatic performance of one or more data set management operations in this step is illustratively controlled by the data set management operation controller 116 of processing platform 105.”). One would be motivated to do so reduce the false positive rates for intrusion detection as described in Kundu et al. ([0029]: “Furthermore, anomaly, taint-tracking, learning pattern, and mis-use detection techniques (which detect unfamiliar access patterns in order to discover intrusion) are marred by the following: … exhibiting high false positive rates (e.g., deeming an event to be an intrusion when the event is not an intrusion).”).
Moreover, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to further modify the invention of Kundu et al. with the teachings Nanda et al. to provide the calculated confidence level to the policy manager by propagating the calculated confidence level in addition to the other propagated information used for policy enforcement taught in Kundu et al. ([0039]: “as depicted in FIG. 2, system management module 110 achieves real-time detection of an entity, which is unauthorized to access resources residing in guest VMs 210A and 210B. Furthermore, system management module 110 instructs/invokes the units of hypervisors 205A and 205B to: (i) run programs which associate threads to the identity of the end-user (i.e., the identity of the originating entity attempting unauthorized access to a restricted resource of the target server, such as process 105B in FIG. 1); (ii) propagate this information during network communication …”; [0041]: “In an exemplary embodiment, system management module 110 works in conjunction with: (i) hypervisors 315A, 315B, and 315C; and (ii) virtual machines (VMs) 310A, 310B, and 310C which propagates the user identity via thread info and network annotation, as illustrated in hypervisor-virtual machine environment 300.”). Propagating the calculated confidence factors in Nanda et al. to the hypervisors containing the policy enforcer in Kundu et al. is considered providing the calculated confidence level to the policy. Further, it would have been obvious to one of ordinary skill in the art, to modify the invention of Kundu et al. with the teachings of Nanda et al. such that the policy manager updates one or more of the set of policies based on the provided confidence level the set of policies based on the provided confidence level by incorporating a machine learning engine as taught in Nanda et al., and adding the program instructions for adjusting management policies, via the machine learning engine, to the program instructions of the policy enforcer in Kundu et al.
One would be motivated to perform the above modifications to dynamically adjust policies to match patterns associated with user interactions as taught in Nanda et al. (Col. 7, lines 5-14: “Such machine learning techniques illustratively utilize feedback derived at least in part from user interaction with particular data sets and associated management operations. By way of example, machine learning or related approaches can be used to analyze dynamic changes in utilization of a given data set over all or part of the lifecycle to date of that data set. This can involve tagging data sets with their current position in the lifecycle or adjusting their operational signatures directly based on lifecycle position or history.”) to improve security and decrease the false positive rates for intrusion detection described by Kundu et al. above. For example, denying access to a hacked user account being used in a foreign location or adjusting a policy to allow a user to access resources when said user moves to a new location after said user has authenticated once in the new location.
However, Kundu et al. modified by Klein et al. and Nanda et al. do not explicitly teach the confidence level is calculated based at least on inputs including identity information.
But Kundu et al. teaches identity information as metadata ([0036]: “a causality analyzer (e.g., causality analysis units 225A-B) is a component of a hypervisor which analyzes collected system calls and builds mapping of all RECV and SEND system calls to use in the discovery of the (originating) user identity. In an exemplary embodiment, a message enricher (e.g., communication tagging units 230A-B) is a component of a hypervisor which observes all of the incoming/outgoing messages of VMs and adds metadata that indicates the identity of the original requester is.“; [0025]: “Front-end node 120 is defined as a unit of hardware with a processor; memory; and internally and externally connected IO devices to a multi-node server… network nodes are host computers (i.e., Internet nodes) identified by an IP address (IP address is another type of identity information) and all hosts are physical network nodes.” [0043]: “system management module 110 determines the client address of a thread while annotating RECV and SEND events in combination with the determined client address of the thread. The client address is a client IP address which can be associated a thread ID, wherein each thread ID is an integer value”), and
Nanda et al. teaches the confidence levels are calculated based on metadata (Col. 2, lines 48-49: “a metadata-based data set operational signature generator 114”; Col. 12, lines 14-28: “The operational signatures are illustratively generated in the metadata-based data set operational signature generator 114 of processing platform 105... Accordingly, it is to be appreciated that a single confidence factor may be associated with multiple management operations, or multiple confidence factors may be associated with a single management operation, in some illustrative embodiments.”).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to further modify the invention of Kundu et al. modified by Klein et al. and Nanda et al. such that the confidence levels are calculated based at least on inputs including identity information by adding the identity information, taught in Kundu et al., to the metadata used in creating the confidence factors taught in Nanda et al. One would be motivated to do so to ensure certain operations associated with resource access may only be permitted if a confidence threshold is met as taught in Nanda et al. (Col. 12, 32-36: “one or more particular management operations may be automatically performed for the corresponding data set only if the associated one or more confidence factors are above respective designated thresholds”).
For example, while being logged into the correct account is one criteria for being granted resource access, being in the incorrect geographic region may cause the confidence factor to be below the required threshold, leading to an access denial. Determining a user’s common geographic region or location can be done by using the client’s IP address which Is also considered identity information in Kundu et al. ([0043]: “system management module 110 determines the client address of a thread while annotating RECV and SEND events in combination with the determined client address of the thread. The client address is a client IP address which can be associated a thread ID, wherein each thread ID is an integer value”). One would be motivated to perform the above modifications to improve the accuracy of determining unauthorized access by using geographic access points and reduce the false positive rate for intrusion detection as taught in Kundu et al. ([0029]: “mis-use detection techniques (which detect unfamiliar access patterns in order to discover intrusion)… the functions and characteristics of system management module 110 lead to: (i) the detection of unauthorized attempt(s) to access the terminal node which originated from other nodes that are multiple hops away from the terminal node in real-time; (ii) the occlusion of unauthorized access to the terminal node (i.e., preventing unauthorized access); and (iii) the reduction of false-positive results.”), by using user interaction patterns as taught in Nanda et al. above.
4. Regarding claim 2, Kundu et al. modified by Klein et al. and Nanda et al. teaches the computing device of claim 1,
Kundu et al. teaches wherein the identity information includes identity of the computing device, identity of the virtual machine associated with the system or user action, identity of the guest operating system associated with the system or user action, identity of an application associated with the system or user action ([0027]: “all of the applications run inside virtual machines, which are controlled by the hypervisor (which is not explicitly shown in FIG. 1). These virtual machines may reside on the same cloud or different cloud platform as each other. By virtue of system management module 110 managing hypervisors, the applications controlled by the hypervisors are also controlled by system management module 110.”; [0030]: “Process 105A, process 105B, and process 105C are processes (i.e., a dynamic real-time representation of a computing operation or a program (Application) that has been executed on virtual machines) (Processes are applications)… each process is associated with an entity that is an end-user, wherein each end-user is associated with a virtual machine”; [0031]: “Process 105B may also be referred to as the “Joker” process that is attempting an unauthorized access to a target server, which contains a restricted resource of interest to the Joker… message 145 indicates to an end-user in the user interface that: (i) “illegal access detected” and (ii) the identity of the originating entity (i.e., the process identity of the Joker/process 105B) (Identity of an application associated with a system or user action) attempting the unauthorized access to a resource within a virtual machine”. ), and/or identity of a user associated with the system or user action ([0036]: “In an exemplary embodiment, a VM introspector (e.g., system call interception units 220A-B) is a component of a hypervisor which is in charge of intercepting system calls of all the guest VMs and maintaining those records in the hypervisor's memory for causality analysis in real-time. In an exemplary embodiment, a causality analyzer (e.g., causality analysis units 225A-B) is a component of a hypervisor which analyzes collected system calls and builds mapping of all RECV and SEND system calls to use in the discovery of the (originating) user identity (User identity is identity of a user associated with the system/user action). In an exemplary embodiment, a message enricher (e.g., communication tagging units 230A-B) is a component of a hypervisor which observes all of the incoming/outgoing messages of VMs and adds metadata that indicates the identity of the original requester (Identity of the computing device) is.“).
5. Regarding claim 3, Kundu et al. modified by Klein et al. and Nanda et al. teaches the computing device of claim 1.
However, Kundu et al. modified by Klein et al. and Nanda et al. do not explicitly teach wherein the confidence level calculation is further based on permissions information including user permissions, guest permissions, device permissions, and/or application permissions.
But Nanda et al. teaches wherein the confidence level calculation is based on metadata (Abstract: “The processing platform is configured to obtain metadata characterizing a plurality of data sets, to generate data set operational signatures for respective ones of at least a subset of the data sets based at least in part on the obtained metadata”; Col. 15, line 16: “Step 422 involves collecting metadata for data sets”; Col. 15, lines 20-22: “Step 424 involves generating metadata-based data set operational signatures utilizing the metadata collected in step 422.”; Col. 15, lines 36-44: “Step 426 involves determining confidence factors for the data set operational signatures. As mentioned previously, each data set operational signature may include a corresponding confidence factor vector providing different confidence factors for each of a plurality of possible data set management operations. Again, as in other steps of the process 421, determination of confidence factors in step 426 may be based at least in part on policy information provided by the data management policy engine 415.”), and
Kundu et al. teaches permissions information including user permissions, guest permissions, device permissions, and/or application permissions as metadata ([0037]: “The configured security policy indicates the conditions and entities which are granted permission to access and not granted permission to access resources on a virtual machine. If the user identity of the thread that issues READ is on the blacklist (i.e., not granted permission to access restricted resources within the target server or virtual machine), system management module 110 changes the system call's return value to −1. Therefore, the entity associated with the user identity of the thread on the blacklist is unable to access restricted resources within the target server or virtual machine.”; [0032]: “In an exemplary embodiment, the functions performed by system management module 110 include: (i) handling/private hypervisor-to-hypervisor message(s) for delivering the user ID between SEND and RECV events; (ii) constructing a data structure that captures the association of thread to the user ID; (iii) generating the metadata that holds user ID; “. The user ID corresponds to the metadata that has permissions information including user permissions since the user ID is used to determine what permissions a user has (e.g. whether a user is on a blacklist); [0037]: “If the user identity of the thread that issues READ is on the blacklist (i.e., not granted permission to access restricted resources within the target server or virtual machine), system management module 110 changes the system call's return value to −1. Therefore, the entity associated with the user identity of the thread on the blacklist (Permission information includes user permissions) is unable to access restricted resources within the target server or virtual machine.”).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, that the confidence level calculation is further based on permissions information including user permissions, guest permissions, device permissions, and/or application permissions by including a user ID in the metadata used for calculating the confidence factors in Nanda et al. such that the confidence factors are calculated based on user permissions. One would be motivated to do so to dynamically change management policies based on user interactions as taught in Nanda et al. (Col. 5, lines 49-53: “Numerous other types of features and functionality of the components 112, 114 and 116 of the data set management process 118 can similarly be adjusted over time through machine learning implemented by machine learning engine 120.”) since user permissions may also be changed dynamically. For example, a user being placed on a blacklist as taught in Kundu et al. ([0037]: “If the user identity of the thread that issues READ is on the blacklist (i.e., not granted permission to access restricted resources within the target server or virtual machine), system management module 110 changes the system call's return value to −1.“).
6. Regarding claim 5, Kundu et al. modified by Klein et al. and Nanda et al. teaches the computing device of claim 1
Kundu et al. teaches wherein the policy enforcement point includes an active security policy enforcer that uses virtual machine introspection (VMI) ([0013]: “FIG. 4 is a functional block diagram illustrating a virtual machine introspection mechanism”; [0046]: “The VM introspection mechanism is rendered operable by virtue of system management module 110 working in conjunction with the components of the hypervisors.”; [0036]: “ a VM introspector (e.g., system call interception units 220A-B) is a component of a hypervisor which is in charge of intercepting system calls of all the guest VMs and maintaining those records in the hypervisor's memory for causality analysis in real-time… Policy enforcer (e.g., access control units 215A-B) is a component of a hypervisor which is responsible for allowing or disallowing the READ system call based on a configured security policy (Policy enforcer makes decisions based on the system calls collected by the introspection mechanism. The policy enforcer is considered to be both the enforcement point and the active security policy enforcer. Since it makes decisions based on the system calls intercepted by the VM introspector above, it uses virtual machine introspection.”)
for introspection of at least some of the hardware resources including one or more hardware processors ([0036]: “a VM introspector (e.g., system call interception units 220A-B) is a component of a hypervisor“; [0047]: “There are known techniques for intercepting syscalls and invocations such as: virtualization (i.e., an interface to the VM that does not differ from the underlying hardware); para-virtualization (i.e., an interface to the VM that differs from that of the underlying hardware); kernel-based virtual machine (i.e., a virtualization infrastructure that turns a kernel design into a hypervisor); and Xen (i.e., a hypervisor using a microkernel design that provides services which allow multiple computer operating systems to execute functions on the same computer hardware concurrently).”; [0063]: “ the VM introspection mechanism, system management module 110 is able to monitor events (e.g., system call functions related to network and storage access) (Hardware resources) occurring within the system through the invoked hypervisor in real-time.”; [0065]: “the restricted resource within the target server are within a system where: (i) the VM introspection mechanism has been activated and (ii) system events have been monitored.”; [0093]: “Program instructions and data used to practice embodiments of the present invention may be stored in persistent storage 1108 for execution and/or access by one or more of the respective computer processors 1104”. Processors are used to carry out the above system events.) and
enforces the set of policies based at least in part on the introspection ([0036]: “a VM introspector (e.g., system call interception units 220A-B) is a component of a hypervisor which is in charge of intercepting system calls of all the guest VMs and maintaining those records in the hypervisor's memory for causality analysis in real-time... Policy enforcer (e.g., access control units 215A-B) is a component of a hypervisor which is responsible for allowing or disallowing (Enforces the set of policies) the READ system call based on a configured security policy.”; [0062]: “In step 705, system management module 110 invokes one or more hypervisors to activate the VM introspection mechanism within a system… the VM introspection mechanism is implemented on a system containing hypervisors and virtual machines that can be managed, monitored, and examined by system management module 110.”; [0065]: “In step 720, system management module 110 determines whether or not the attempt to access the restricted resource is authorized upon system management module 110 detecting attempts to access the restricted resource. As stated with respect to step 720, the restricted resource within the target server are within a system where: (i) the VM introspection mechanism has been activated and (ii) system events have been monitored.”; [0066]: “In step 725, system management module 110 invokes one or more hypervisors to deny access to the restricted resource and raise an alarm upon system management module 110 determining that the attempt to access the restricted resource is not authorized.”; [0067]: “In step 730, system management module 110 invokes one or more hypervisors to permit access to the restricted resource upon system management module 110 determining that the attempt to access the restricted resource is authorized”. The steps above are done via the policy enforcer in the hypervisors. It is done based on the introspection as it is the introspector that gathers the system call information.).
7. Regarding claim 6, Kundu et al. modified by Klein et al. and Nanda et al. teaches the computing device of claim 1
Klein et al. teaches wherein the formally verified microkernel controls access to the hardware resources using explicit authorization (1. Introduction: “The seL4 microkernel is a member of the L4 microkernel family [Liedtke 1996], designed for providing provably strong security mechanisms while retaining the high performance that is customary in the L4 family and considered essential for real-world use”; 2.1. seL4 Programming Model: “Like L4, it features abstractions for virtual address spaces, threads, IPC, and, unlike most earlier L4 kernels, an explicit in-kernel memory management model (Memory management means access to hardware resources such as storage) and capabilities for authorization.”; 2.3. Formal Verification: “Authority confinement in a dynamic capability system means that authority cannot be escalated or transferred to another entity without explicit authorisation.”; 5.1. Access Control Model: “Access control is one of the primary security functions that OS kernels provide. It is used to enforce high-level security properties like authority confinement, integrity and confidentiality on untrusted subjects, that is, those that cannot be relied upon to behave securely… An access-control system controls the access of subjects to objects [Lampson 1971], by restricting the operations that subjects may perform on objects in each state of the system. In seL4, the subjects are threads, and the objects are all kernel objects, including memory pages and threads themselves (Hardware resources). The part of the system state used to make access control decisions is called the protection state. It is this state that our access-control model captures”).
8. Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Kundu et al. in further view of Klein et al. in further view of Nanda et al., as applied to claim 1, in further view of Bernhard et al. (Bernhard Jansen, Hari-Govind V. Ramasamy, and Matthias Schunter. 2008. Policy enforcement and compliance proofs for Xen virtual machines. In Proceedings of the fourth ACM SIGPLAN/SIGOPS international conference on Virtual execution environments (VEE '08). Association for Computing Machinery, New York, NY, USA, 101–110. https://doi.org/10.1145/1346256.1346271).
9. Regarding claim 4, Kundu et al. modified by Klein et al. and Nanda et al. teaches the computing device of claim 1.
However, Kundu et al. modified by Klein et al. and Nanda et al. do not explicitly teach wherein the confidence level calculation is further based on integrity information including occurrences when system elements have attempted to circumvent a policy configuration.
But Kundu et al. teaches using a Xen hypervisor ([0047]: “There are known techniques for intercepting syscalls and invocations such as: … Xen (i.e., a hypervisor using a microkernel design that provides services which allow multiple computer operating systems to execute functions on the same computer hardware concurrently). In some embodiments, these known techniques can operate in conjunction with system management module 110, virtual machines, and hypervisors in order to detect unauthorized access attempts to restricted resources on a target server.”) and
Bernhard et al. teaches using integrity information for security management of virtual machines and to improve policy enforcement via a Xen hypervisor (1. Introduction: “We are interested in the security management of virtual machines, i.e., the protection, enforcement, and verification of the security of virtual machines. Security management is a non-trivial problem even in traditional nonvirtualized environments… we describe an integrity architecture called PEV (which stands for protection, enforcement, and verification) and associated protocols. The architecture incorporates integrity protection and verification as part of the virtualization software itself, and at the same time enhances its policy enforcement capabilities. We describe a prototype realization of our architecture using the Xen hypervisor [6]. We demonstrate the policy enforcement and compliance checking capabilities of our prototype through multiple use cases.”; 3. Formal Integrity Model for Virtual Machines: “The TCB periodically logs the integrity state of the rest of the system. The log repository contains a record of the integrity history of the system, and is secure write-only, i.e., log entries, once written, cannot be modified or removed by any entity in the rest of the system… The compliance proof involves showing that correct policies and healthy policy enforcement mechanisms are in place”; 3.2 Generalized Attestation to Verify Integrity: “The protocol allows the verifier to query and reliably obtain the measurement values for the system stored in the PCRs of the TPM. Reliable reporting of the measurement values is due to the signing of the values by the TPM, which is trusted by the verifier. Based on these values, the verifier can assesses the integrity state and the trustworthiness of the system. We generalize attestation so that the verifier can specify which aspects of the system’s integrity state are of interest to her”).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to further modify the invention of Kundu et al. modified by Klein et al. and Nanda et al. with the teachings of Bernhard et al. such that the confidence level calculation is further based on integrity information including occurrences when system elements have attempted to circumvent a policy configuration. This may be accomplished by including both the integrity state and the integrity history of a system, as taught by Bernhard et al., in the metadata used for generating the confidence factors (i.e. confidence levels) as taught by Nanda et al. The integrity state is considered the integrity information and the integrity history is information that includes occurrences when system elements have attempted to circumvent a policy configuration.
One would be motivated to do so to determine when a user should be placed on a blacklist as taught in Kundu et al. ([0037]: “If the user identity of the thread that issues READ is on the blacklist (i.e., not granted permission to access restricted resources within the target server or virtual machine), system management module 110 changes the system call's return value to −1. Therefore, the entity associated with the user identity of the thread on the blacklist is unable to access restricted resources within the target server or virtual machine.”) by using the integrity information such as integrity history to identify a pattern of policy violations. One would be motivated to blacklist a user based on the integrity history to prevent a user from continuously performing malicious activities such as policy violations.
10. Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Kundu et al. in further view of Klein et al. in further view of Nanda et al., as applied to claim 1, in further view of Raju et al. (https://www.moritz.systems/blog/an-introduction-to-formal-verification/).
11. Regarding claim 7, Kundu et al. modified by Klein et al. and Nanda et al. teaches the computing device of claim 1.
However, Kundu et al. modified by Klein et al. and Nanda et al. do not explicitly teach wherein the policy manager and the confidence level determination engine are formally verified.
But Raju et al. teaches to formally verify software to ensure secure, efficient, and resilient code (Why do systems need Formal Verification?: “With the ever increasing complexity of software and the layers of abstraction, we have reached a time when writing secure, efficient and resilient code requires some level of formal verification to be done, if not for the whole software at least for the important sub-systems involved.“).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to further modify the invention of Kundu et al. modified by Klein et al. and Nanda et al. such that the policy manager and the confidence level determination engine are formally verified to ensure the software used to implement the policy manager and the confidence determination engine are secure to detect potential security vulnerabilities and handle potential runtime errors as taught in Raju et al. (Why do systems need Formal Verification?: “With the ever increasing complexity of software and the layers of abstraction, we have reached a time when writing secure, efficient and resilient code requires some level of formal verification to be done, if not for the whole software at least for the important sub-systems involved.“).
12. Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Kundu et al. in further view of Klein et al. in further view of Nanda et al., as applied to claim 1, in further view of Sharma (https://www.serverwatch.com/guides/software-defined-networking-advantages/).
13. Regarding claim 8, Kundu et al. modified by Klein et al. and Nanda et al. teaches the computing device of claim 1.
However, Kundu et al. modified by Klein et al. and Nanda et al. do not explicitly teach wherein one of the one or more VMs is a system VM that supports execution of a software defined networking (SDN) connection application that connects to an SDN solution.
But Sharma teaches using software defined networking (SDN) for isolating virtual machines, cost reduction, and to reduce complexity in isolation methods, and reduce complexity of packet forwarding for virtual machines(Paragraph 1: “Data center owners of all types can find many advantages in Software-Defined Networking (SDN). And, if you are a cloud service provider and want to ensure customers can move their virtualized workloads without requiring much planning, the advantages of Software-Defined Networking SDN may be the answer to your prayers. SDN not only reduces the complexity seen in today’s networks but also helps Cloud service providers host millions of virtual networks without the need for common separation isolation methods such as virtual local area networks (VLAN). SDN also enables network administrators to manage network services from a central management tool by virtualizing physical network connectivity into logical network connectivity.”; The Benefits of Software-Defined Networking (SDN): “since SDN supports Layer 1 through Layer 3 networking models, there’s no need to buy expensive networking devices. In other words, the use of SDN in a production environment can help reduce the costs involved in purchasing expensive hardware… Since most of the networking is done at the SDN, it is easy for service providers to isolate the customer virtual machines from other customers by using various isolation methods available in the SDN…. SDN can help you forward the virtual packets to a software or physical device running on the network. For example, if a virtual machine needs to access the internet, it becomes easy for virtual administrators to provide the necessary configuration to the virtual machine with minimal effort.“).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to further modify the invention of Kundu et al. modified by Klein et al. and Nanda et al. such that one of the one or more VMs is a system VM that supports execution of a software defined networking (SDN) connection application that connects to an SDN solution to reduce the complexity of creating the isolated environments in Kundu et al. and to make it easier to configure packet forwarding for virtual machines as taught by Sharma (Overhead reduction: “Since most of the networking is done at the SDN, it is easy for service providers to isolate the customer virtual machines from other customers by using various isolation methods available in the SDN.”; Managing Virtual Packet Forwarding: “SDN can help you forward the virtual packets to a software or physical device running on the network. For example, if a virtual machine needs to access the internet, it becomes easy for virtual administrators to provide the necessary configuration to the virtual machine with minimal effort.”).
14. Claims 9-11, 13-18, and 20-22 are rejected under 35 U.S.C. 103 as being unpatentable over Kundu et al. (US 20190044945 A1) in further view of Klein et al. (Klein, Gerwin & Andronick, June & Elphinstone, Kevin & Murray, Toby & Sewell, Thomas & Kolanski, Rafal & Heiser, Gernot. (2014). Comprehensive Formal Verification of an OS Microkernel. ACM Transactions on Computer Systems (TOCS). 32. 10.1145/2560537.) in further view of equiinet (https://web.archive.org/web/20220122093628/https://www.equiinet.com/post/types-of-hypervisors) in further view of Dahlin et al. (Dahlin, Mike & Johnson, Ryan & Krug, Robert & Mccoyd, Michael & Young, William. (2011). Toward the Verification of a Simple Hypervisor. Electronic Proceedings in Theoretical Computer Science. 70. 10.4204/EPTCS.70.3.) in further view of Nanda et al. (US 11216413 B1).
15. Regarding claim 9, Kundu et al. teaches a method (Abstract: “Embodiments of the present invention provide systems and methods for thwarting attempts at the unauthorized access to the restricted resources within the target server in a multi-node system.”) in a computing device, comprising:
Executing a plurality of virtual machine monitors (VMMs) ([0004]: “A hypervisor may be referred to as a virtual machine monitor (VMM).”; [0035]: “ In an exemplary embodiment, there are two hypervisors—hypervisors 205A and 205B”),
Wherein each of the plurality of VMMs support execution of a different guest operating system running in a different virtual machine (VM) ([0004]: “ Each virtual machine is called a guest machine. The hypervisor presents the guest operating systems with a virtual operating platform and manages the execution of the guest operating systems.“; [0035]: “In an exemplary embodiment, there are two hypervisors—hypervisors 205A and 205B—and two virtual machines—guest virtual machine (VM) 210A and guest VM 210B, as illustrated in hypervisor-virtual machine environment 200. Hypervisor 205A is connected to and manages guest VM 210A while hypervisor 205B is connected to and manages guest VM 210B. (A hypervisor is a VMM)”),
Wherein a particular VMM manages interactions between a corresponding VM and hardware resources of the computing device ([0004]: “The hypervisor (VMM) uses native execution to share and manage hardware... Modern hypervisors use hardware-assisted virtualization and virtualization-specific hardware, primarily from the host CPUs. A hypervisor may be referred to as a virtual machine monitor (VMM)… The hypervisor presents the guest operating systems with a virtual operating platform and manages the execution of the guest operating systems. Multiple instances of a variety of operating systems may share the virtualized hardware resources (Physical resources of the computing device).”; [0035]: “Hypervisor 205A is connected to and manages guest VM 210A while hypervisor 205B is connected to and manages guest VM 210B. System call interception unit 220A, communication tagging unit 230A, causality analysis unit 225A, and access control unit 215A are components contained within hypervisor 205A. System call interception unit 220B, communication tagging unit 230B, causality analysis unit 225B, and access control unit 215B are contained within hypervisor 205B. In this exemplary embodiment, hypervisor 205A communicates with hypervisor 205B via non-transitory signals.”);
Detecting through one of the VMMs, a system or user action on the computing device ([0036]: “In an exemplary embodiment, a VM introspector (e.g., system call interception units 220A-B) is a component of a hypervisor (VMM) which is in charge of intercepting system calls of all the guest VMs (Detecting through one of the VMMs (i.e. hypervisor) a system or user action) and maintaining those records in the hypervisor's memory for causality analysis in real-time”).
However, Kundu et al. does not explicitly teach executing a formally verified microkernel in a most privileged level to abstract hardware resources of the computing device.
But Klein et al. teaches to formally verify a microkernel running in a most privileged level (Introduction: “This article presents a detailed coverage of the comprehensive formal verification of the seL4 microkernel… The target of our verification, the kernel, is the most critical part of a system, which is our motivation for starting system verification with this component. The customary definition of a kernel is the software that executes in the privileged mode of the hard-ware (The kernel is running in a most privileged level)… The seL4 microkernel is a member of the L4 microkernel family [Liedtke 1996], designed for providing provably strong security mechanisms while retaining the high performance that is customary in the L4 family and considered essential for real-world use ”) to abstract hardware resources of the computing device (2.1. seL4 Programming Model: “seL4 is a third-generation microkernel, loosely similar to Coyotos [2008] and Nova [Steinberg and Kauer 2010]). It is broadly based on L4 [Liedtke 1996] and influenced by EROS [Shapiro et al. 1999]. Like L4 it features abstractions for virtual address spaces, threads, IPC (Abstracts hardware resources of the computing device) and, unlike most earlier L4 kernels, an explicit in-kernel memory management model and capabilities for authorization… Virtual address spaces are formed by explicit manipulation of virtual-memory related kernel objects: PageDirectories, PageTables, ASIDPools1 and Frames (mappable physical memory). As such, address spaces have no kernel-defined structure (except for a protected region reserved for the seL4 kernel itself). Whether the user level system is Exokernel like, a multi-server, or a para-virtualised monolithic OS is determined by user-level via a map and unmap interface to Frames and PageTables. The distribution of authority to the kernel virtual memory (VM) objects ultimately determines the scope of influence over virtual and physical memory. Threads are the active entity in seL4. By associating a CNode and a virtual address space with a thread, user-level policies create high-level abstractions, such as processes or virtual machines.”).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the invention of Kundu et al. with the teachings of Klein et al. to execute a formally verified microkernel running in a most privileged level to abstract hardware resources of the computing device by applying the formal microkernel verification method to the microkernels used in the operating systems of Kundu et al. One would be motivated to do so to minimize potential bugs as taught by Klein et al. (Introduction: “With truly small kernels it becomes possible to take security and robustness further, to the point where it is possible to guarantee the absence of bugs [Tuch et al. 2005; Hohmuth and Tews 2005; Seshadri et al. 2007; Elphinstone et al. 2007] and to establish the presence of high-level security properties [Klein et al. 2011; Sewell et al. 2011; Murray et al. 2013; Sewell et al. 2013]. This can be achieved by formal, machine-checked verification, providing mathematical proof that firstly the kernel implementation is consistent with its specification and free from programmer-induced implementation defects, and secondly that the specification satisfies desirable highlevel properties that carry through to the code and binary level.”).
However, Kundu et al. modified by Klein et al. do not explicitly teach wherein each of the plurality of VMMs runs as a user-level application in a different address space on top of the formally verified microkernel.
However equiinet teaches to use a VMM that runs as a user-level application to reduce costs and increase installation simplicity (Type 2: “Type 2 hypervisors are much less expensive and much easier to install than type 1 hypervisors because they run on the server’s preexisting operating system. These are called ‘hosted’ hypervisors. If the hypervisor is a mattress protector, then the original operating system is a cushiony mattress topper placed underneath it. From there, another instance of the original operating system is installed directly to the hypervisor, and other instances of operating systems can be installed there, as well. Once again, the instances of applications are installed to those individual operating systems.”).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the invention of Kundu et al. modified by Klein et al. such that the hypervisors, i.e. VMMs, in Kundu et al. runs as a user-level application by ensuring said hypervisors are type 2 hypervisors to reduce costs as taught by equiinet (Type 2: “Type 2 hypervisors are much less expensive and much easier to install than type 1 hypervisors because they run on the server’s preexisting operating system.”).
However, Kundu et al. modified by Klein et al. and equiinet do not explicitly teach the VMMs will run in a different address space on top of the formally verified microkernel.
But Klein et al. teaches user-level components have their own virtual address spaces (2.1. seL4 Programming Model: “Virtual Address Spaces are formed by explicit manipulation of virtual-memoryrelated kernel objects: PageDirectories, PageTables, ASIDPools1 and Frames (mappable physical memory). As such, address spaces have no kernel-defined structure (except for a protected region reserved for the seL4 kernel itself) (This means the microkernel, i.e. the seL4 kernel, is in a different address space from user-level components)… Threads are the active entity in seL4. By associating a CNode and a virtual address space with a thread, user-level policies create high-level abstractions, such as processes or virtual machines.”).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, that after modifying the invention of Kundu et al. modified by Klein et al. and equiinet such that the hypervisors in Kundu et al. are type 2 hypervisors, the hypervisors, i.e. the VMMs will run in a different address space on top of the formally verified microkernel as user-level components have their own virtual address space and the microkernel has a protected region of memory reserved for itself as taught in Kelin et al. above.
Further, Kundu et al. modified by Klein et al. and equiinet do not explicitly teach wherein the plurality of the VMMs are formally verified.
But Dahlin et al. teaches to formally verify hypervisors (i.e. VMMs) to ensure the reliability of VMMs (1. Introduction: “Platform virtualization promises significant benefits in security, efficiency, dependability and cost [11]. Achieving these benefits depends upon the reliability of the virtual machine monitors (hypervisors) (VMMs) that provide them. We believe that providing high assurance of the properties of a system as complex as a hypervisor requires a rigorous formal analysis (Formal verification), stretching from the desired security properties at the top, down to the physical hardware and implementation code at the bottom… For the purposes of this paper, a hypervisor, also called a virtual machine monitor (VMM), is a software system that virtualizes some system resources of the host computer and makes them available to one or more guests.”).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to further modify the invention of Kundu et al. modified by Klein et al. and equiinet with the teachings of Dahlin et al. such that the plurality of VMMs are formally verified to ensure the reliability of said VMMs as taught by Dahlin et al. (1. Introduction: “Platform virtualization promises significant benefits in security, efficiency, dependability and cost [11]. Achieving these benefits depends upon the reliability of the virtual machine monitors (hypervisors) (VMMs) that provide them. We believe that providing high assurance of the properties of a system as complex as a hypervisor requires a rigorous formal analysis (Formal verification)”).
However, Kundu et al. modified by Klein et al. and equiinet and Dahlin et al. to calculate a confidence level for the system or user action based at least on inputs including identity information; and using the calculated confidence level for enforcement of a zero trust policy on the computing device.
But Nanda et al. teaches calculating a confidence level for the system or user action for a system or user action (Col. 15, lines 36-44: “Step 426 involves determining confidence factors (Confidence levels) for the data set operational signatures. As mentioned previously, each data set operational signature may include a corresponding confidence factor vector providing different confidence factors for each of a plurality of possible data set management operations. Again, as in other steps of the process 421, determination of confidence factors in step 426 may be based at least in part on policy information provided by the data management policy engine 415.”; Col. 12, lines 32-36: “For example, one or more particular management operations may be automatically performed for the corresponding data set only if the associated one or more confidence factors are above respective designated thresholds “; Col. 14, lines 3-15: “mapping between levels is implemented in the FIG. 3 embodiment. For example, as illustrated generally by the upward-directed curved arrows at the far right side of the figure, such inter-level mapping in the present embodiment includes mapping of data sets 302 and 304 at the data set level to corresponding operational signatures and confidence factors 306 and 308 at the operational signature and confidence factor level, and mapping of operational signatures and confidence factors 306 and 308 at the operational signature and confidence factor level to corresponding management operations and policies (Confidence levels are calculated for system/user actions. Management operations are considered system/user actions) 310 and 312 at the management operation level. ”; Col. 15, lines 36-44: “Step 426 involves determining confidence factors for the data set operational signatures. As mentioned previously, each data set operational signature may include a corresponding confidence factor vector providing different confidence factors for each of a plurality of possible data set management operations (Management operations correspond to a system/user action). Again, as in other steps of the process 421, determination of confidence factors in step 426 may be based at least in part on policy information provided by the data management policy engine 415.”),
using the calculated confidence level to prevent performance of certain operations (Col. 12, lines 32-36: “For example, one or more particular management operations may be automatically performed for the corresponding data set only if the associated one or more confidence factors are above respective designated thresholds”) and
Kundu et al. teaches using identity information such as client IP addresses to identify unusual access patterns ([0029]: “ mis-use detection techniques (which detect unfamiliar access patterns in order to discover intrusion)… the functions and characteristics of system management module 110 lead to: (i) the detection of unauthorized attempt(s) to access the terminal node which originated from other nodes that are multiple hops away from the terminal node in real-time”).
Further, Nanda et al. teaches the confidence levels are calculated based on metadata (Col. 2, lines 48-49: “a metadata-based data set operational signature generator 114”; Col. 12, lines 14-28: “The operational signatures are illustratively generated in the metadata-based data set operational signature generator 114 of processing platform 105... Accordingly, it is to be appreciated that a single confidence factor may be associated with multiple management operations, or multiple confidence factors may be associated with a single management operation, in some illustrative embodiments.”).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to further modify the invention of Kundu et al. modified by Klein et al. and equiinet and Dahlin et al. with the teachings of Nanda et al. to calculate a confidence level for the system or user action to improve safety when automating management operations as taught in Nandu et al. (Col. 12, lines 32-45: “one or more particular management operations may be automatically performed for the corresponding data set only if the associated one or more confidence factors are above respective designated thresholds. As indicated previously, the one or more confidence factors in such an arrangement thereby illustratively comprise a vector of one or more confidence factors each controlling automatic performance of a corresponding one of the one or more particular management operations associated with the data set operational signature. The automatic performance of one or more data set management operations in this step is illustratively controlled by the data set management operation controller 116 of processing platform 105.”). It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, that the above calculation is based at least on inputs including identity information by adding the identity information, taught in Kundu et al., to the metadata used in creating the confidence factors in Nanda et al. One would be motivated to do so to ensure certain operations associated with resource access may only be permitted if a confidence threshold is met as taught in Nanda et al. (Col. 12, 32-36: “one or more particular management operations may be automatically performed for the corresponding data set only if the associated one or more confidence factors are above respective designated thresholds”).
For example, while being logged into the correct account is one criteria for being granted resource access, being in the incorrect geographic region may cause the confidence factor to be below the required threshold, leading to an access denial. Determining a user’s common geographic region or location can be done by using the client’s IP address which Is also considered identity information in Kundu et al. ([0043]: “system management module 110 determines the client address of a thread while annotating RECV and SEND events in combination with the determined client address of the thread. The client address is a client IP address which can be associated a thread ID, wherein each thread ID is an integer value”). One would be motivated to perform the above modifications to improve the accuracy of determining unauthorized access by using geographic access points, as taught in Kundu et al. ([0029]: “mis-use detection techniques (which detect unfamiliar access patterns in order to discover intrusion)… the functions and characteristics of system management module 110 lead to: (i) the detection of unauthorized attempt(s) to access the terminal node which originated from other nodes that are multiple hops away from the terminal node in real-time; (ii) the occlusion of unauthorized access to the terminal node (i.e., preventing unauthorized access); and (iii) the reduction of false-positive results.”), by using user interaction patterns as taught in Nanda et al. above.
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the invention of Kundu et al. modified by Klein et al. and equiinet and Dahlin et al. with the teachings of Nanda et al. to use the calculated confidence level for enforcement of a zero trust policy on the computing device to prevent unauthorized access of resources when the confidence threshold in Nanda et al. is not met.
One would be motivated to do perform the above modifications to prevent access to resources when unusual access patterns are detected that lowers the confidence factor score. This may be an unusual access location as taught in Khundu et al. ([0029]: “mis-use detection techniques (which detect unfamiliar access patterns in order to discover intrusion)“) which may add an additional layer of authentication beyond a user ID as the sole authentication method.
16. Regarding claim 10, Kundu et al. modified by Klein et al., equiinet, Dahlin et al. and Nanda et al. teaches the method of claim 9,
Kundu et al. teaches wherein the identity information includes identity of the computing device, identity of the virtual machine associated with the system or user action, identity of the guest operating system associated with the system or user action ([0027]: “all of the applications run inside virtual machines, which are controlled by the hypervisor (which is not explicitly shown in FIG. 1). These virtual machines may reside on the same cloud or different cloud platform as each other. By virtue of system management module 110 managing hypervisors, the applications controlled by the hypervisors are also controlled by system management module 110.”; [0030]: “Process 105A, process 105B, and process 105C are processes (i.e., a dynamic real-time representation of a computing operation or a program (Application) that has been executed on virtual machines) (Processes are applications)… each process is associated with an entity that is an end-user, wherein each end-user is associated with a virtual machine”; [0031]: “Process 105B may also be referred to as the “Joker” process that is attempting an unauthorized access to a target server, which contains a restricted resource of interest to the Joker… message 145 indicates to an end-user in the user interface that: (i) “illegal access detected” and (ii) the identity of the originating entity (i.e., the process identity of the Joker/process 105B) (Identity of an application associated with a system or user action) attempting the unauthorized access to a resource within a virtual machine”. ), and/or identity of a user associated with the system or user action ([0036]: “In an exemplary embodiment, a VM introspector (e.g., system call interception units 220A-B) is a component of a hypervisor which is in charge of intercepting system calls of all the guest VMs and maintaining those records in the hypervisor's memory for causality analysis in real-time. In an exemplary embodiment, a causality analyzer (e.g., causality analysis units 225A-B) is a component of a hypervisor which analyzes collected system calls and builds mapping of all RECV and SEND system calls to use in the discovery of the (originating) user identity (User identity is identity of a user associated with the system/user action). In an exemplary embodiment, a message enricher (e.g., communication tagging units 230A-B) is a component of a hypervisor which observes all of the incoming/outgoing messages of VMs and adds metadata that indicates the identity of the original requester (Identity of the computing device) is.“).
17. Regarding claim 11, Kundu et al. modified by Klein et al., equiinet, Dahlin et al. and Nanda et al. teaches the method of claim 9,
However, Kundu et al. modified by Klein et al., equiinet, Dahlin et al. and Nanda et al. do not explicitly teach wherein calculating the confidence level for the system or user action is further based on permissions information including user permissions, guest permissions, device permissions, and/or application permissions.
But Nanda et al. teaches wherein the confidence level calculation is based on metadata (Abstract: “The processing platform is configured to obtain metadata characterizing a plurality of data sets, to generate data set operational signatures for respective ones of at least a subset of the data sets based at least in part on the obtained metadata”; Col. 15, line 16: “Step 422 involves collecting metadata for data sets”; Col. 15, lines 20-22: “Step 424 involves generating metadata-based data set operational signatures utilizing the metadata collected in step 422.”; Col. 15, lines 36-44: “Step 426 involves determining confidence factors for the data set operational signatures. As mentioned previously, each data set operational signature may include a corresponding confidence factor vector providing different confidence factors for each of a plurality of possible data set management operations. Again, as in other steps of the process 421, determination of confidence factors in step 426 may be based at least in part on policy information provided by the data management policy engine 415.”), and
Kundu et al. teaches permissions information including user permissions, guest permissions, device permissions, and/or application permissions as metadata ([0037]: “The configured security policy indicates the conditions and entities which are granted permission to access and not granted permission to access resources on a virtual machine. If the user identity of the thread that issues READ is on the blacklist (i.e., not granted permission to access restricted resources within the target server or virtual machine), system management module 110 changes the system call's return value to −1. Therefore, the entity associated with the user identity of the thread on the blacklist is unable to access restricted resources within the target server or virtual machine.”; [0032]: “In an exemplary embodiment, the functions performed by system management module 110 include: (i) handling/private hypervisor-to-hypervisor message(s) for delivering the user ID between SEND and RECV events; (ii) constructing a data structure that captures the association of thread to the user ID; (iii) generating the metadata that holds user ID; “. The user ID corresponds to the metadata that has permissions information including user permissions since the user ID is used to determine what permissions a user has (e.g. whether a user is on a blacklist)).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, that the confidence level calculation is further based on permissions information including user permissions, guest permissions, device permissions, and/or application permissions by including a user ID in the metadata used for calculating the confidence factors in Nanda et al. such that the confidence factors are calculated based on user permissions. One would be motivated to do so to dynamically change management policies based on user interactions as taught in Nanda et al. (Col. 5, lines 49-53: “Numerous other types of features and functionality of the components 112, 114 and 116 of the data set management process 118 can similarly be adjusted over time through machine learning implemented by machine learning engine 120.”) since user permissions may also be changed dynamically. For example, a user being placed on a blacklist as taught in Kundu et al. ([0037]: “If the user identity of the thread that issues READ is on the blacklist (i.e., not granted permission to access restricted resources within the target server or virtual machine), system management module 110 changes the system call's return value to −1.“).
18. Regarding claim 13, Kundu et al. modified by Klein et al., equiinet, Dahlin et al. and Nanda et al. teaches the method of claim 9,
Klein et al. teaches wherein the formally verified microkernel controls access to the hardware resources using explicit authorization (1. Introduction: “The seL4 microkernel is a member of the L4 microkernel family [Liedtke 1996], designed for providing provably strong security mechanisms while retaining the high performance that is customary in the L4 family and considered essential for real-world use”; 2.1. seL4 Programming Model: “Like L4, it features abstractions for virtual address spaces, threads, IPC, and, unlike most earlier L4 kernels, an explicit in-kernel memory management model (Memory management means access to hardware resources such as storage) and capabilities for authorization.”; 2.3. Formal Verification: “Authority confinement in a dynamic capability system means that authority cannot be escalated or transferred to another entity without explicit authorisation.”; 5.1. Access Control Model: “Access control is one of the primary security functions that OS kernels provide. It is used to enforce high-level security properties like authority confinement, integrity and confidentiality on untrusted subjects, that is, those that cannot be relied upon to behave securely… An access-control system controls the access of subjects to objects [Lampson 1971], by restricting the operations that subjects may perform on objects in each state of the system. In seL4, the subjects are threads, and the objects are all kernel objects, including memory pages and threads themselves (Hardware resources). The part of the system state used to make access control decisions is called the protection state. It is this state that our access-control model captures”).
19. Regarding claim 14, Kundu et al. modified by Klein et al., equiinet, Dahlin et al. and Nanda et al. teaches the method of claim 9.
However, Kundu et al. modified by Klein et al., equiinet, Dahlin et al. and Nanda et al. do not explicitly teach wherein calculating the confidence level for the system or user action is performed for each system call.
But Kundu et al. teaches policy enforcement is done for each system call ([0036]: “ Policy enforcer (e.g., access control units 215A-B) is a component of a hypervisor which is responsible for allowing or disallowing the READ system call based on a configured security policy.”; [0037]: “If the user identity of the thread that issues READ is on the blacklist (i.e., not granted permission to access restricted resources within the target server or virtual machine), system management module 110 changes the system call's return value to −1 (Example of policy enforcement. This has to be done for each system call to ensure a system call associated with a blacklisted user is not granted permission.). Therefore, the entity associated with the user identity of the thread on the blacklist is unable to access restricted resources within the target server or virtual machine.”; [0066]: “In step 725, system management module 110 invokes one or more hypervisors to deny access to the restricted resource and raise an alarm upon system management module 110 determining that the attempt to access the restricted resource is not authorized.“; [0038]: “More specifically, system call interception units 210A and 210B capture input/output (I/O) systems calls from guest VMs 210A and 210B, respectively. Access control units 215A and 215B raise an alarm upon detecting unauthorized attempts to access resources residing in guest VMs 210A and 210B, respectively”).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, that calculating the confidence level for the system or user action is performed for each system call as policy enforcement is performed for each system call as taught in Kundu et al. above. Moreover, one would be motivated to calculate a confidence level for each system call to deny access to resources if the confidence level does not meet a threshold as taught in Nanda et al. to improve detection of unauthorize access, such as access from an unknown location, and to reduce false positives as taught in Kundu et al. ([0029]: “the functions and characteristics of system management module 110 lead to: … the reduction of false-positive results (Confidence levels may be used to further reduce false positive results)”).
20. Regarding claim 15, Kundu et al. modified by Klein et al., equiinet, Dahlin et al. and Nanda et al. teaches the method of claim 9
Nanda et al. teaches updating a policy based on the calculated confidence level (Col. 14, lines 16-26: “Machine learning engine 320 of the machine learning level can control various features of each of the underlying levels. For example, the machine learning engine 320 can adjust data set management policies at the management operation level, can adjust operational or target signatures at the operational signature and confidence factor level, and can adjust data set recommendations, classifications and associated metadata at the data set level, as illustrated generally by the downward-directed curved arrows exiting the machine learning engine 320 at the far left side of the figure.”; Col. 14, lines 27-37: “Machine learning engine 320 can be configured to carry out additional or alternative functionality in the system 300. For example, as indicated previously herein, similar data sets may be identified prior to generation of operational signatures, while additionally or alternatively operational signatures may be used to identify similar data sets. To illustrate the latter approach, an additional curved arrow is directed from operational signatures and confidence factors 306 to data sets 302 and is associated with generation of data set similarity measures”. The machine learning engine updates policies and is trained on data sets containing the confidence levels. So, it is considered to be based on provided confidence levels; See FIG. 3; Col. 5, lines 44-53: “The machine learning engine 120 of the processing platform 105 is configured to adjust at least one of the data set operational signature, the target signature and the data set management policy over time through machine learning based at least in part on user interaction with the given data set (User interactions with the given data set is influenced by confidence factors. Hence, when the machine learning engine adjusts a policy based on user factors it is also based on the calculated confidence levels). Numerous other types of features and functionality of the components 112, 114 and 116 of the data set management process 118 can similarly be adjusted over time through machine learning implemented by machine learning engine 120.”).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to further modify the invention of Kundu et al. modified by Klein et al., equiinet, Dahlin et al. and Nanda et al. to update a zero trust policy on the computing device based on the calculated confidence level. This may be accomplished by propagating the calculated confidence level in addition to the other propagated information used for policy enforcement taught in Kundu et al. ([0039]: “as depicted in FIG. 2, system management module 110 achieves real-time detection of an entity, which is unauthorized to access resources residing in guest VMs 210A and 210B. Furthermore, system management module 110 instructs/invokes the units of hypervisors 205A and 205B to: (i) run programs which associate threads to the identity of the end-user (i.e., the identity of the originating entity attempting unauthorized access to a restricted resource of the target server, such as process 105B in FIG. 1); (ii) propagate this information during network communication”; [0041]: “In an exemplary embodiment, system management module 110 works in conjunction with: (i) hypervisors 315A, 315B, and 315C; and (ii) virtual machines (VMs) 310A, 310B, and 310C which propagates the user identity via thread info and network annotation, as illustrated in hypervisor-virtual machine environment 300.”). Propagating the calculated confidence factors in Nanda et al. to the hypervisors containing the policy enforcer in Kundu et al. is considered providing the calculated confidence level to the policy.
Further, the updating may be done by incorporating the machine learning engine taught in Nanda et al. in the invention of Kundu et al. and adding the program instructions for adjusting management policies as taught in Nanda et al., via the machine learning engine, to the program instructions of the policy enforcer in Kundu et al. One would be motivated to do so to dynamically adjust policies to match patterns associated with user interactions as taught in Nanda et al. (Col. 7, lines 5-14: “Such machine learning techniques illustratively utilize feedback derived at least in part from user interaction with particular data sets and associated management operations. By way of example, machine learning or related approaches can be used to analyze dynamic changes in utilization of a given data set over all or part of the lifecycle to date of that data set. This can involve tagging data sets with their current position in the lifecycle or adjusting their operational signatures directly based on lifecycle position or history.”).
For example, in Kundu et al., a policy may be to deny unauthorized access to resources ([0028]: “denial of unauthorized entities attempting to access the restricted resources”). It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to adjust such a policy based on a machine learning engine as taught in Nanda et al. using a user’s geographic location. For example, data may be collected based on a user’s resource access history such that an access policy may be adjusted over time, as taught in Nanda et al. (Col. 7, lines 5-8: “ Such machine learning techniques illustratively utilize feedback derived at least in part from user interaction with particular data sets and associated management operations”) to deny entities attempting to access said resources from a foreign location. The above is one example of an unfamiliar access pattern used to discover intrusion as taught in Kundu et al. ([0029]: “anomaly, taint-tracking, learning pattern, and mis-use detection techniques (which detect unfamiliar access patterns in order to discover intrusion)”. New geographic access locations is an example of unfamiliar access patterns).
21. Regarding claim 16, it is a media/product type claim with similar limitations as claim 9 above. Therefore, it is rejected under the same rationale.
22. Regarding claim 17, it is a media/product type claim with similar limitations as claim 10 above. Therefore, it is rejected under the same rationale.
23. Regarding claim 18, it is a media/product type claim with similar limitations as claim 11 above. Therefore, it is rejected under the same rationale.
24. Regarding claim 20, it is a media/product type claim with similar limitations as claim 13 above. Therefore, it is rejected under the same rationale.
25. Regarding claim 21, it is a media/product type claim with similar limitations as claim 14 above. Therefore, it is rejected under the same rationale.
26. Regarding claim 22, it is a media/product type claim with similar limitations as claim 15 above. Therefore, it is rejected under the same rationale.
27. Claims 12 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Kundu et al. in further view of Klein et al. in further view of equiinet in further view of Dahlin et al. in further view of Nanda et al., as applied to claim 9, in further view of Bernhard et al. (Bernhard Jansen, Hari-Govind V. Ramasamy, and Matthias Schunter. 2008. Policy enforcement and compliance proofs for Xen virtual machines. In Proceedings of the fourth ACM SIGPLAN/SIGOPS international conference on Virtual execution environments (VEE '08). Association for Computing Machinery, New York, NY, USA, 101–110. https://doi.org/10.1145/1346256.1346271).
28. Regarding claim 12, Kundu et al. modified by Klein et al., equiinet, Dahlin et al. and Nanda et al. teaches the method of claim 9,
However, Kundu et al. modified by Klein et al., equiinet, Dahlin et al. and Nanda et al. do not explicitly teach wherein the confidence level calculation is further based on integrity information including occurrences when system elements have attempted to circumvent a policy configuration.
But Kundu et al. teaches using a Xen hypervisor ([0047]: “There are known techniques for intercepting syscalls and invocations such as: … Xen (i.e., a hypervisor using a microkernel design that provides services which allow multiple computer operating systems to execute functions on the same computer hardware concurrently). In some embodiments, these known techniques can operate in conjunction with system management module 110, virtual machines, and hypervisors in order to detect unauthorized access attempts to restricted resources on a target server.”) and
Bernhard et al. teaches using integrity information for security management of virtual machines and to improve policy enforcement using a Xen hypervisor (1. Introduction: “We are interested in the security management of virtual machines, i.e., the protection, enforcement, and verification of the security of virtual machines. Security management is a non-trivial problem even in traditional nonvirtualized environments… we describe an integrity architecture called PEV (which stands for protection, enforcement, and verification) and associated protocols. The architecture incorporates integrity protection and verification as part of the virtualization software itself, and at the same time enhances its policy enforcement capabilities. We describe a prototype realization of our architecture using the Xen hypervisor [6]. We demonstrate the policy enforcement and compliance checking capabilities of our prototype through multiple use cases.”; 3. Formal Integrity Model for Virtual Machines: “The TCB periodically logs the integrity state of the rest of the system. The log repository contains a record of the integrity history of the system, and is secure write-only, i.e., log entries, once written, cannot be modified or removed by any entity in the rest of the system… The compliance proof involves showing that correct policies and healthy policy enforcement mechanisms are in place”; 3.2 Generalized Attestation to Verify Integrity: “The protocol allows the verifier to query and reliably obtain the measurement values for the system stored in the PCRs of the TPM. Reliable reporting of the measurement values is due to the signing of the values by the TPM, which is trusted by the verifier. Based on these values, the verifier can assesses the integrity state and the trustworthiness of the system. We generalize attestation so that the verifier can specify which aspects of the system’s integrity state are of interest to her”).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to further modify the invention of Kundu et al. modified by Klein et al., equiinet, Dahlin et al. and Nanda et al. with the teachings of Bernhard et al. such that the confidence level calculation is further based on integrity information including occurrences when system elements have attempted to circumvent a policy configuration. This may be accomplished by including both the integrity state and the integrity history of a system, as taught by Bernhard et al., in the metadata used for generating the operational signatures containing the confidence factors (i.e. confidence levels) in Nanda et al. The integrity state is considered the integrity information and the integrity history is information that includes occurrences when system elements have attempted to circumvent a policy configuration.
One would be motivated to do so to determine when a user should be placed on a blacklist as taught in Kundu et al. ([0037]: “If the user identity of the thread that issues READ is on the blacklist (i.e., not granted permission to access restricted resources within the target server or virtual machine), system management module 110 changes the system call's return value to −1. Therefore, the entity associated with the user identity of the thread on the blacklist is unable to access restricted resources within the target server or virtual machine.”) by using the integrity information such as integrity history to identify a pattern of policy violations. One would be motivated to blacklist a user based on the integrity history to prevent a user from continuously performing malicious activities such as policy violations.
29. Regarding claim 19, it is a media/product type claim with similar limitations as claim 12 above. Therefore, it is rejected under the same rationale.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to EDWARD J LI whose telephone number is (571)272-7695. The examiner can normally be reached Monday-Friday 9:00-5:30.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kevin Young can be reached on (571) 270-3180. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/EDWARD JIANDE LI/Examiner, Art Unit 2194
/KEVIN L YOUNG/Supervisory Patent Examiner, Art Unit 2194
Prosecution Insights