DETAILED ACTION
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 . In communications filed on 07/28/2026. Claims 1, 3, and 8-11 are amended. Claim 13 is cancelled. Claims 1-12 are pending in this examination.
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 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. This examination is in response to US Patent Application No. 18/841,958.
Examiner Note
This non-final office action is a re-open for the last office action for claim set filed on 07/28/2026.
The independent claim 12 needs to be written in independent claim format which includes all the limitations of the claim 1.
Claim Rejections - 35 USC § 103
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 of this title, 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Frist set of rejections:
Claims 1-12 are rejected under 35 U.S.C. 103 as being unpatentable over Dalton ( US2003/0172109), and in view of Amarasinghe ( US2006/0277536).
Regarding claim 1, Dalton discloses a method for detecting an attempted computer attack implemented by a computer of a fleet of computers, said attack exploiting a vulnerability of a function to be protected executing in a process of a user space of said computer, a launching of the execution of said function to be protected resulting in the execution, before said attack, of a function of a kernel, said method including
[0005] Increasingly, single machines are being used to host multiple services concurrently (e.g. ISP, ASP, xSP service provision), and it is therefore becoming increasingly important that not only is the security of the host platform protected from application compromise attacks, but also that the applications are adequately protected from each other in the event of an attack.
[0014] With containment, misuse of privilege to gain direct access to protected system resources has much less serious consequences than without containment, because even if an attacker makes use of an application privilege, the resources that can be accessed are bounded by what has been made available in the application's container. Similarly, in the case of unprotected resources, using containment, access to the network from an application can be blocked or at least very tightly controlled. With regard to the supply of false security decision making information, containment mitigates the potential damage caused by ensuring that the only access to support services is from legitimate clients, i.e. the application services, thereby limiting the exposure of applications to attack.
[0022] there is provided an operating system for supporting a plurality of applications, the operating system further comprising a plurality of access control rules, which may beneficially be added from user space and enforced by means provided in the kernel of the operating system, the access control rules defining the only communication interfaces between selected applications (whether local to or remote from said operating system).
[0118, User space services, such as the web servers shown in FIG. 2, are run unmodified on the platform, but have a compartment label associated with them via the command line interface to the security extensions. The security module 112 is then responsible for applying the mandatory access controls to the user space services based on their applied compartment label. It will be appreciated, therefore, that the user space services can thus be contained without having to modify those services]; and
a mitigation policy identifier corresponding to a mitigation policy declared in a namespace dedicated to security associated with a root process of said computer
[0006] One of the most effective ways of protecting against application compromise at the operating system level is by means of kernel enforced controls, because the controls implemented in the kernel cannot be overridden or subverted from user space by any application or user. In known systems, the controls apply to all applications irrespective of the individual application code quality.[ 0055-0060], [0074] Referring back to the first and second aspects of the present invention, there is defined an operating system which augments each process and network interface with a tag indicating the compartment to which it belongs. In an exemplary embodiment, means provided in the kernel consult a rulebase whenever a process wishes to communicate with another process (in the Linux operating system, by using any of the standard UNIX inter-process communication mechanisms). The communication succeeds only if there is a matching rule in the rulebase. In the preferred embodiment, the rulebase resides in the kernel, but as explained above, to be more practical, it is preferably able to be initialized and dynamically maintained and queried by an administrative program, preferably in user-space.
[0075, Thus, in accordance with a fifth aspect of the present invention, there is provided an operating system comprising a kernel including means for storing a rulebase consisting of one or more rules defining permitted communication paths between system objects, and user-operable means for adding, deleting and/or listing such rules]; and
installing, in said kernel, a mitigation policy corresponding to said mitigation policy identifier
[0018] The containment property is usually achieved through a combination of Mandatory Access controls (MAC), and Privileges. MAC protection schemes enforce a particular policy of access control to the system resources such as files, processes and network connections. This policy is enforced by the kernel and cannot be overridden by a user or compromised application.
0074] Referring back to the first and second aspects of the present invention, there is defined an operating system which augments each process and network interface with a tag indicating the compartment to which it belongs. In an exemplary embodiment, means provided in the kernel consult a rulebase whenever a process wishes to communicate with another process (in the Linux operating system, by using any of the standard UNIX inter-process communication mechanisms). The communication succeeds only if there is a matching rule in the rulebase. In the preferred embodiment, the rulebase resides in the kernel, but as explained above, to be more practical, it is preferably able to be initialized and dynamically maintained and queried by an administrative program, preferably in user-space.
[0075] Thus, in accordance with a fifth aspect of the present invention, there is provided an operating system comprising a kernel including means for storing a rulebase consisting of one or more rules defining permitted communication paths between system objects, and user-operable means for adding, deleting and/or listing such rules.
[0223, This approach is implemented as a series of patches to standard operating system (in this case, Linux) kernel sources. There is also a dynamically loadable kernel module that hosts the logic required to maintain tables of rules an also acts as an interface between the kernel and user-space configuration utilities. The kernel module is inserted early in the boot-sequence and immediately enforces a restrictive security model in the absence of any defined rules. Prior to this, the kernel enforces a limited security model designed to allow proper booting with all processes being spawned in the default compartment 0 that is functional but essentially useless for most purposes. Once the kernel module is loaded, the kernel switches from its built-in model to the one in the module. Containment is achieved by tagging kernel resources and partitioning access to these depending on the value of the tags and any rules which may have been defined]; and
executing said mitigation policy in said kernel, said mitigation policy associated with said function of said kernel and loaded into a kernel namespace associated with said process and dedicated to security
[0074] Referring back to the first and second aspects of the present invention, there is defined an operating system which augments each process and network interface with a tag indicating the compartment to which it belongs. In an exemplary embodiment, means provided in the kernel consult a rulebase whenever a process wishes to communicate with another process (in the Linux operating system, by using any of the standard UNIX inter-process communication mechanisms). The communication succeeds only if there is a matching rule in the rulebase. In the preferred embodiment, the rulebase resides in the kernel, but as explained above, to be more practical, it is preferably able to be initialized and dynamically maintained and queried by an administrative program, preferably in user-space.
[0075, Thus, in accordance with a fifth aspect of the present invention, there is provided an operating system comprising a kernel including means for storing a rulebase consisting of one or more rules defining permitted communication paths between system objects, and user-operable means for adding, deleting and/or listing such rules]; and
and, in response to detection by said mitigation policy during its execution of an attack vector supported by said policy and targeting said function to be protected
[0006, One of the most effective ways of protecting against application compromise at the operating system level is by means of kernel enforced controls, because the controls implemented in the kernel cannot be overridden or subverted from user space by any application or user. In known systems, the controls apply to all applications irrespective of the individual application code quality]; and
sending to said security management server a message including a data representative of said process in order to notify the security management server of the detection, by said mitigation policy, of the attack vector targeting said function to be protected.
[0007] There are two basic requirements at the system level in order to adequately protect against application compromise and its effects. Firstly, the application should be protected against attack to the greatest extent possible, exposed interfaces to the application should be as narrow as possible and access to such interfaces should be well controlled. Secondly, the amount of damage which a compromised application can do to the system should be limited to the greatest possible extent.
[0008] In a known system, the above two requirements are achieved by the abstract property of "containment". An application is contained if it has strict controls placed on which resources it can access and what type of access it has, even when the application has been compromised. Containment also protects an application from external attack and interference. Thus, the containment property has the potential to at least mitigate many of the potential exploitative actions of an attacker.
[0248, There are also a number of disadvantages and/or issues to be considered in connection with this approach. Firstly, maintaining true synchronous state with respect to the running processes is difficult for various reasons that are mostly due to the lack of a comprehensive kernel event notification mechanism. For example, there is no formal mechanism for catching the situation where processes exit abnormally, e.g. due to SIGSEGV, SIGBUS, etc. One proposed solution to this problem involves a small source code modification to do_exit( ) to provide a callback to catch such cases. In one exemplary embodiment, a kernel-level reaper thread may be used to monitor the global tasklist and perform garbage collecting on dead PID's. This introduces a small window of insecurity which is somewhat offset by the fact that PID's cycle upwards and the possibility of being reassigned a previously used PID within a single cycle of the reaper thread is relatively small].
Dalton does not explicitly disclose ; however, Amarasinghe discloses receiving, from a security management server [ see FIG. 2, [0052-0053, FIG. 2 illustrates processes for deploying a constraint. Multiple business models may be employed for providing constraint injection software as well as constraints to a customer 240 to protect customer's software. The constraint injection software provides a framework for using the constraints. In one approach, a security laboratory 210 develops the constraint injection software 220 and delivers it directly to the customer 240… 0053] Delivery of the constraints 235, such as in the form of libraries, can also take multiple paths. For example, the security laboratory 210 can deliver the constraints directly to the customer 240. Or, the security laboratory 210 can deliver the constraints to the OEM software vendor 215 which, in turn, delivers the constraints to the customer 240. In another approach, the security laboratory can provide tools for developing and delivering the constraints 225 to the OEM software vendor 215 or to a constraint developer 230. Either of these entities can use the tools to prepare the constraints 235 and deliver them to the customer 240 as a service. The security laboratory 210 optionally uses the help of a vulnerability information provider 205 in multiple stages of constraint creation to develop the constraints. The vulnerability information provider 205 can be individuals or companies who reverse engineer programs and/or track and analyze the information on vulnerabilities to help the constraint developer 230 create the constraints], and [ see FIG. 4a , [0065] FIG. 4a illustrates an information flow of a constraint injection system. The constraints can be developed by an authorized security laboratory 410( equated to security management server), for instance. In particular, individual constraints 412( equated to mitigation policy) and constraint information files 414, which together make up the constraints (e.g., constraint 235 in FIG. 2), can be developed. Additional details regarding constraints are discussed further below. When a new constraint is required, it is developed and made available to users. The security laboratory 410 can deliver a constraint to the customer's Enterprise Network Operating Center (NOC) such as by downloading the constraint to a central controller 420 at the customer site. The central controller 420 manages the constraints and deploys them to end-points, e.g., servers, user desktops or other computers, at the enterprise.
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 teaching of Dalton by incorporating “security laboratory which develops the constraint”, as taught by Amarasinghe. One could have been motivated to do so in order to implement multiple business models to be employed for providing constraint injection software as well as constraints to a customer to protect customer's software. The constraint injection software provides a framework for using the constraints [ Amarasinghe , 0052-0052, FIG.2].
Regarding claim 2, Dalton discloses, wherein the execution of said function to be protected leads to the execution of another function of said user space which leads to the execution of said function of the kernel.
[0022], there is provided an operating system for supporting a plurality of applications, the operating system further comprising a plurality of access control rules, which may beneficially be added from user space and enforced by means provided in the kernel of the operating system, the access control rules defining the only communication interfaces between selected applications (whether local to or remote from said operating system).
[0118] User space services, such as the web servers shown in FIG. 2, are run unmodified on the platform, but have a compartment label associated with them via the command line interface to the security extensions. The security module 112 is then responsible for applying the mandatory access controls to the user space services based on their applied compartment label. It will be appreciated, therefore, that the user space services can thus be contained without having to modify those services.
Regarding claim 3, Dalton discloses wherein the message sent to the security management server additionally includes context information characterizing an attacked container of said computer.
[0005] Increasingly, single machines are being used to host multiple services concurrently (e.g. ISP, ASP, xSP service provision), and it is therefore becoming increasingly important that not only is the security of the host platform protected from application compromise attacks, but also that the applications are adequately protected from each other in the event of an attack.
[0014] With containment, misuse of privilege to gain direct access to protected system resources has much less serious consequences than without containment, because even if an attacker makes use of an application privilege, the resources that can be accessed are bounded by what has been made available in the application's container. Similarly, in the case of unprotected resources, using containment, access to the network from an application can be blocked or at least very tightly controlled. With regard to the supply of false security decision making information, containment mitigates the potential damage caused by ensuring that the only access to support services is from legitimate clients, i.e. the application services, thereby limiting the exposure of applications to attack.
Examiner Note: furthermore, Amarasinghe discloses [ [0047] Primary types of constraints include: 1) constraints targeting a known vulnerability, attack or a program bug, 2) general constraints that can address a wide range of problems or enforce lockdowns or other policies (these constraints may require configuration, tuning or training), and 3) built-in constraints delivered with the constraint injection system that protect against known vulnerabilities and enforce accepted policies.
Regarding claim 4, Dalton does not explicitly disclose, however, Amarasinghe discloses wherein said security server is configured to send the mitigation policy identifier to a plurality of computers of said fleet of computers.
[0065, The security laboratory 410 can deliver a constraint to the customer's Enterprise Network Operating Center (NOC) such as by downloading the constraint to a central controller 420 at the customer site. The central controller 420 manages the constraints and deploys them to end-points, e.g., servers, user desktops or other computers, at the enterprise. Typically, an enterprise will have a number of servers and host computers such as desktop computers, laptops, mobile devices and the like which enable the enterprise users to run applications which are protected by the constraints].
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 teaching of Dalton by incorporating “security laboratory which develops the constraint”, as taught by Amarasinghe. One could have been motivated to do so in order to implement multiple business models to be employed for providing constraint injection software as well as constraints to a customer to protect customer's software. The constraint injection software provides a framework for using the constraints [ Amarasinghe , 0052-0052, FIG.2].
Regarding claim 5, Dalton discloses, wherein said installation step includes: sending a request including said mitigation policy identifier to a security server; obtaining, in response to the request, a file describing said mitigation policy; obtaining an object code of the mitigation policy identified in said description file; generating an executable code of said mitigation policy from said object code; and installing the executable code in said kernel.
[0074] Referring back to the first and second aspects of the present invention, there is defined an operating system which augments each process and network interface with a tag indicating the compartment to which it belongs. In an exemplary embodiment, means provided in the kernel consult a rulebase whenever a process wishes to communicate with another process (in the Linux operating system, by using any of the standard UNIX inter-process communication mechanisms). The communication succeeds only if there is a matching rule in the rulebase. In the preferred embodiment, the rulebase resides in the kernel, but as explained above, to be more practical, it is preferably able to be initialized and dynamically maintained and queried by an administrative program, preferably in user-space.
[0075] Thus, in accordance with a fifth aspect of the present invention, there is provided an operating system comprising a kernel including means for storing a rulebase consisting of one or more rules defining permitted communication paths between system objects, and user-operable means for adding, deleting and/or listing such rules.
[0223] This approach is implemented as a series of patches to standard operating system (in this case, Linux) kernel sources. There is also a dynamically loadable kernel module that hosts the logic required to maintain tables of rules an also acts as an interface between the kernel and user-space configuration utilities. The kernel module is inserted early in the boot-sequence and immediately enforces a restrictive security model in the absence of any defined rules. Prior to this, the kernel enforces a limited security model designed to allow proper booting with all processes being spawned in the default compartment 0 that is functional but essentially useless for most purposes. Once the kernel module is loaded, the kernel switches from its built-in model to the one in the module. Containment is achieved by tagging kernel resources and partitioning access to these depending on the value of the tags and any rules which may have been defined.
Examiner Note: furthermore, Amarasinghe discloses[see FIG. 1, [0048] FIG. 1 illustrates processes for developing a constraint. One path begins when a proof of concept exploit is released (step 105) by a researcher, for instance. A proof of concept exploit provides evidence that a particular vulnerability exists in software, and demonstrates that an exploit is feasible. However, the proof of concept can be used as a road map by attackers to build an attack. At step 110, the exploit code is acquired, such as by a security laboratory, and the exploit activity is traced (step 115) using tools to analyze the exploit and its manifestation during an attack. A trace is a detailed record of the steps a computer program executes. Subsequently, the vulnerability is identified (step 135)], and [ [0050] In a third path, when an attack is released (step 160), the attack is acquired (step 165) and its activities are traced (step 170) by observing what it does when attacking a controlled, vulnerable system. Subsequently, the vulnerability is identified (step 135). Typically, when an attack is released, news of the release is publicized as a warning to others by customers, software vendors, software security industry groups and sometimes the general news media. In other cases, customers may choose to handle attacks privately to avoid negative publicity], and [0051] Thus, in all three paths, after an analysis is performed, the vulnerability is identified (step 135), and a constraint can be developed to detect the vulnerability and remediate against it (step 140). The constraint code can be ported to different versions of the module that is patched (step 145). That is, multiple versions of the same software can exist in deployment. Some of these differences are not customer visible (for example, an earlier patch was applied or not). Each version typically has one or two slightly different files. Thus, a patch should be ported to all the versions of a file that might be running in a customer machine. The constraints are extensively tested (step 150) before being released, e.g., to customers (step 155)
Regarding claim 6, Dalton does not explicitly disclose, however, Amarasinghe discloses wherein sending said at least one message to the security management server is implemented from said user space in response to said kernel sending a signal to said user space in order to notify said detection of said attack vector.[see FIG. 1, [0048] FIG. 1 illustrates processes for developing a constraint. One path begins when a proof of concept exploit is released (step 105) by a researcher, for instance. A proof of concept exploit provides evidence that a particular vulnerability exists in software, and demonstrates that an exploit is feasible. However, the proof of concept can be used as a road map by attackers to build an attack. At step 110, the exploit code is acquired, such as by a security laboratory, and the exploit activity is traced (step 115) using tools to analyze the exploit and its manifestation during an attack. A trace is a detailed record of the steps a computer program executes. Subsequently, the vulnerability is identified (step 135)], and [ [0050] In a third path, when an attack is released (step 160), the attack is acquired (step 165) and its activities are traced (step 170) by observing what it does when attacking a controlled, vulnerable system. Subsequently, the vulnerability is identified (step 135). Typically, when an attack is released, news of the release is publicized as a warning to others by customers, software vendors, software security industry groups and sometimes the general news media. In other cases, customers may choose to handle attacks privately to avoid negative publicity], and [0051] Thus, in all three paths, after an analysis is performed, the vulnerability is identified (step 135), and a constraint can be developed to detect the vulnerability and remediate against it (step 140). The constraint code can be ported to different versions of the module that is patched (step 145). That is, multiple versions of the same software can exist in deployment. Some of these differences are not customer visible (for example, an earlier patch was applied or not). Each version typically has one or two slightly different files. Thus, a patch should be ported to all the versions of a file that might be running in a customer machine. The constraints are extensively tested (step 150) before being released, e.g., to customers (step 155)], and [0078, Abstract].
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 teaching of Dalton by incorporating “Constraint library”, as taught by Amarasinghe. One could have been motivated to do so in order The constraint code can access a library of detector and remediator functions to detect various attacks and remediate against them. [ Amarasinghe , Abstract].
Regarding claim 7, Dalton does not explicitly disclose, however, Amarasinghe discloses, wherein said at least one message includes at least one piece of information among: an identifier of said computer; a data representative of said namespace associated with said process and dedicated to security; an identifier of said vulnerability; a time at which the execution of the mitigation policy has been triggered [see FIG. 1, [0048] FIG. 1 illustrates processes for developing a constraint. One path begins when a proof of concept exploit is released (step 105) by a researcher, for instance. A proof of concept exploit provides evidence that a particular vulnerability exists in software, and demonstrates that an exploit is feasible. However, the proof of concept can be used as a road map by attackers to build an attack. At step 110, the exploit code is acquired, such as by a security laboratory, and the exploit activity is traced (step 115) using tools to analyze the exploit and its manifestation during an attack. A trace is a detailed record of the steps a computer program executes. Subsequently, the vulnerability is identified (step 135)], and [ [0050] In a third path, when an attack is released (step 160), the attack is acquired (step 165) and its activities are traced (step 170) by observing what it does when attacking a controlled, vulnerable system. Subsequently, the vulnerability is identified (step 135). Typically, when an attack is released, news of the release is publicized as a warning to others by customers, software vendors, software security industry groups and sometimes the general news media. In other cases, customers may choose to handle attacks privately to avoid negative publicity], and [0051] Thus, in all three paths, after an analysis is performed, the vulnerability is identified (step 135), and a constraint can be developed to detect the vulnerability and remediate against it (step 140). The constraint code can be ported to different versions of the module that is patched (step 145). That is, multiple versions of the same software can exist in deployment. Some of these differences are not customer visible (for example, an earlier patch was applied or not). Each version typically has one or two slightly different files. Thus, a patch should be ported to all the versions of a file that might be running in a customer machine. The constraints are extensively tested (step 150) before being released, e.g., to customers (step 155)
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 teaching of Dalton by incorporating “Constraint library”, as taught by Amarasinghe. One could have been motivated to do so in order The constraint code can access a library of detector and remediator functions to detect various attacks and remediate against them. [ Amarasinghe , Abstract].
Regarding claims 8, 10-12 , these claims are interpreted and rejected for the same rational set forth in claim 1.
Regarding claim 9, Dalton does not explicitly disclose , however, Amarasinghe discloses sending to a plurality of computers in the fleet of computers, said identifier of the mitigation policy
[ see FIG. 2, [0052-0053, FIG. 2 illustrates processes for deploying a constraint. Multiple business models may be employed for providing constraint injection software as well as constraints to a customer 240 to protect customer's software. The constraint injection software provides a framework for using the constraints. In one approach, a security laboratory 210 develops the constraint injection software 220 and delivers it directly to the customer 240… 0053] Delivery of the constraints 235, such as in the form of libraries, can also take multiple paths. For example, the security laboratory 210 can deliver the constraints directly to the customer 240. Or, the security laboratory 210 can deliver the constraints to the OEM software vendor 215 which, in turn, delivers the constraints to the customer 240. In another approach, the security laboratory can provide tools for developing and delivering the constraints 225 to the OEM software vendor 215 or to a constraint developer 230. Either of these entities can use the tools to prepare the constraints 235 and deliver them to the customer 240 as a service. The security laboratory 210 optionally uses the help of a vulnerability information provider 205 in multiple stages of constraint creation to develop the constraints. The vulnerability information provider 205 can be individuals or companies who reverse engineer programs and/or track and analyze the information on vulnerabilities to help the constraint developer 230 create the constraints], and [ see FIG. 4a , [0065] FIG. 4a illustrates an information flow of a constraint injection system. The constraints can be developed by an authorized security laboratory 410( equated to security management server), for instance. In particular, individual constraints 412( equated to mitigation policy) and constraint information files 414, which together make up the constraints (e.g., constraint 235 in FIG. 2), can be developed. Additional details regarding constraints are discussed further below. When a new constraint is required, it is developed and made available to users. The security laboratory 410 can deliver a constraint to the customer's Enterprise Network Operating Center (NOC) such as by downloading the constraint to a central controller 420 at the customer site. The central controller 420 manages the constraints and deploys them to end-points, e.g., servers, user desktops or other computers, at the enterprise.
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 teaching of Dalton by incorporating “security laboratory which develops the constraint”, as taught by Amarasinghe. One could have been motivated to do so in order to implement multiple business models to be employed for providing constraint injection software as well as constraints to a customer to protect customer's software. The constraint injection software provides a framework for using the constraints [ Amarasinghe , 0052-0052, FIG.2].
Second set of rejections:
Claims 1, 8, 10-12 are rejected under 35 U.S.C. 103 as being unpatentable over Okihara ( US2016/0259944), and in view of (US2022/0114009) issued to Ismael.
Regarding claims 1, 8, and 10-12, Okihara discloses A method for detecting an attempted computer attack implemented by a computer of a fleet of computers, said attack exploiting a vulnerability of a function to be protected executing in a process of a user space of said computer, a launching of the execution of said function to be protected resulting in the execution, before said attack, of a function of a kernel, said method including:
[0035] If the policy processor 114 has an interface, such as a keyboard or a mouse, or a network, the policy processor 114 may be taken over by the malicious person. Therefore, in this embodiment, the policy processor 114 functions as a kernel thread of the OS 110 which does not have a user interface. A target of access and processes to be controlled by the mandatory access control is a program included in a user space, such as an application and a command of the OS 110. The kernel thread is a function processed in a kernel space which is different from the user space. Therefore, it is difficult for a user to access the kernel space unless a user interface for access from the user space is explicitly implemented. Accordingly, a take-over by the malicious person may be prevented.
[0058] In the first embodiment, the access log is analyzed first. Then, in a case where it is determined that a specific application is attacked, a policy of the application is updated or newly generated using a kernel thread. In a second embodiment, in a case where an application does not cope with newly-detected vulnerability, a policy is updated or newly generated in accordance with the newly-detected vulnerability using a kernel thread], and [0008]; and
a mitigation policy identifier corresponding to a mitigation policy declared in a namespace dedicated to security associated with a root process of said computer
[see FIG 2A, and 4, [0035, If the policy processor 114 has an interface, such as a keyboard or a mouse, or a network, the policy processor 114 may be taken over by the malicious person. Therefore, in this embodiment, the policy processor 114 functions as a kernel thread of the OS 110 which does not have a user interface. A target of access and processes to be controlled by the mandatory access control is a program included in a user space, such as an application and a command of the OS 110. The kernel thread is a function processed in a kernel space which is different from the user space. Therefore, it is difficult for a user to access the kernel space unless a user interface for access from the user space is explicitly implemented. Accordingly, a take-over by the malicious person may be prevented], and [0040] In step S402, the policy processor 114 of FIG. 2A determines whether the mandatory access control is to be performed. When the mandatory access control is to be performed (YES), the process proceeds to step S403. In step S403, the policy processor 124 of FIG. 2A inputs policies of applications from the policy DB 113 and supplies the policies to the access controller 115]; and
executing said mitigation policy in said kernel, said mitigation policy associated with said function of said kernel and loaded into a kernel namespace associated with said process and dedicated to security
[0034] The policy processor 114 performs the following process when receiving the access log analysis result from the vulnerability information analyzer 118 or a system call from one of the applications 111 to be controlled and the process information 117. When receiving the access log analysis result, the policy processor 114 updates or newly generates a policy in accordance with the analysis result and supplies the policy to a policy DB 113. On the other hand, when receiving the system call and the process information 117, the policy processor 114 supplies a policy corresponding to the system call to an access controller 115. Here, the process information 117 is illustrated in FIG. 2B. “Status” in a first line indicates information on a process, and “sleeping” indicating a dormant state, “running” indicating an execution state, or the like is assigned as “Status”. “Pid” in a second line indicates an identifier of a process, and “Cmdline” in a third line indicates a path of an execution file.
[0035] If the policy processor 114 has an interface, such as a keyboard or a mouse, or a network, the policy processor 114 may be taken over by the malicious person. Therefore, in this embodiment, the policy processor 114 functions as a kernel thread of the OS 110 which does not have a user interface. A target of access and processes to be controlled by the mandatory access control is a program included in a user space, such as an application and a command of the OS 110. The kernel thread is a function processed in a kernel space which is different from the user space. Therefore, it is difficult for a user to access the kernel space unless a user interface for access from the user space is explicitly implemented. Accordingly, a take-over by the malicious person may be prevented.
[0058, In the first embodiment, the access log is analyzed first. Then, in a case where it is determined that a specific application is attacked, a policy of the application is updated or newly generated using a kernel thread. In a second embodiment, in a case where an application does not cope with newly-detected vulnerability, a policy is updated or newly generated in accordance with the newly-detected vulnerability using a kernel thread]; and
and, in response to detection by said mitigation policy during its execution of an attack vector supported by said policy and targeting said function to be protected
[0055, In step S305, the policy processor 114 illustrated in FIG. 2A determines whether the application in which the abnormality is detected has a policy. When the application has a policy (YES), the process proceeds to step S306 where the policy processor 114 illustrated in FIG. 2A updates the policy and terminates the process. There are two updating methods. First, only rules in which access to a file which has been abnormally accessed and access from an IP address corresponding to abnormal access are refused are added. Assuming that the policy 601 of FIG. 6A is an original policy, rules 602b and 602c of FIG. 6B are added. When “deny” is described in a leading portion of a rule, a negative rule is made. Note that the rule 602c refuses “all” access from the IP address “XXX.XXX.XXX.YYY”. The other of the two updating methods is a method for enlarging a range to be refused and adding a rule. If access to a folder including a file which is abnormally accessed is to be refused or an IP address which made abnormal access is detected, only a rule in which all external IP addresses are refused is added. Assuming that the policy 601 of FIG. 6A is an original policy, rules 603b and 603c of FIG. 6C are added. Note that the rule 603c refuses “all” access from all external IP addresses “OUTSIDE_IP_ALL”. Furthermore, other updating methods may be appropriately employed]; and
sending to said security management server a message including a data representative of said process in order to notify the security management server of the detection, by said mitigation policy, of the attack vector targeting said function to be protected.
[0055, In step S305, the policy processor 114 illustrated in FIG. 2A determines whether the application in which the abnormality is detected has a policy. When the application has a policy (YES), the process proceeds to step S306 where the policy processor 114 illustrated in FIG. 2A updates the policy and terminates the process. There are two updating methods. First, only rules in which access to a file which has been abnormally accessed and access from an IP address corresponding to abnormal access are refused are added. Assuming that the policy 601 of FIG. 6A is an original policy, rules 602b and 602c of FIG. 6B are added. When “deny” is described in a leading portion of a rule, a negative rule is made. Note that the rule 602c refuses “all” access from the IP address “XXX.XXX.XXX.YYY”. The other of the two updating methods is a method for enlarging a range to be refused and adding a rule. If access to a folder including a file which is abnormally accessed is to be refused or an IP address which made abnormal access is detected, only a rule in which all external IP addresses are refused is added. Assuming that the policy 601 of FIG. 6A is an original policy, rules 603b and 603c of FIG. 6C are added. Note that the rule 603c refuses “all” access from all external IP addresses “OUTSIDE_IP_ALL”. Furthermore, other updating methods may be appropriately employed].
While Okihara discloses installing, in said kernel, a mitigation policy corresponding to said mitigation policy identifier
[see FIG 2A, and 4, [0035, If the policy processor 114 has an interface, such as a keyboard or a mouse, or a network, the policy processor 114 may be taken over by the malicious person. Therefore, in this embodiment, the policy processor 114 functions as a kernel thread of the OS 110 which does not have a user interface. A target of access and processes to be controlled by the mandatory access control is a program included in a user space, such as an application and a command of the OS 110. The kernel thread is a function processed in a kernel space which is different from the user space. Therefore, it is difficult for a user to access the kernel space unless a user interface for access from the user space is explicitly implemented. Accordingly, a take-over by the malicious person may be prevented], and [0040] In step S402, the policy processor 114 of FIG. 2A determines whether the mandatory access control is to be performed. When the mandatory access control is to be performed (YES), the process proceeds to step S403. In step S403, the policy processor 124 of FIG. 2A inputs policies of applications from the policy DB 113 and supplies the policies to the access controller 115]; and
Okihara does not explicitly discloses, however, Ismael discloses receiving, from a security management server, a mitigation policy identifier, installing, in said kernel, a mitigation policy corresponding to said mitigation policy identifier Ismael discloses [¶92, In an embodiment, upon the start of the policy manager 122 or after the policy configuration is received by the policy manager 122, the policy manager 122 pushes a policy to a particular one of the active security policy enforcers 117A-117N for which the process allow list is to apply. The decision on what guest operating system or application for which the policy is to apply may depend on the configuration of the computing device 100. For the purposes of this example, the policy manager 122 pushes a process allow list policy to the active security policy enforcer 117A. The policy manager 122 may also push the profile of the target system to the active security policy enforcer 117A, which defines information such as the location of functions within the target kernel], and [ see FIG.1 and corresponding text for more details].
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 teaching of Okihara by incorporating “policy manager and active security policy enforcer”, as taught by Ismael. One could have been motivated to do so in order for the active security and policy enforcement continuously monitors for semantic behavior detection or policy violations and enforces the policies at the virtualization layer, the policy manager 122 push the profile of the target system to the active security policy enforcer 117A, which defines information such as the location of functions within the target kernel [ Ismael, ¶¶6, 92, FIG.1].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's
disclosure.
See submitted 892 for more relevant references.
Doukhvalov ( US20170005983) [0070] The transmission of the message is monitored as follows: [0071] entity B 202 requests transmission of the message to entity C 203 by calling up a function of the operating system's kernel; [0072] the microkernel compares entity's C 203 gateway C 213 with the entity; [0073] gateway C 213 reflects the request onto the security policies; [0074] gateway C 213 calls the security server 210, transmitting references to policies, the SIDs of the security contexts of entity B 202 and of entity C 203, and the selected parameters of the message (which the policies may need) for the computation of a security verdict; [0075] the security server 210 computes the verdict; [0076] if the verdict is positive, the transmission of the message is permitted; [0077] in the opposite case, the transmission of the message is forbidden, and an error message is returned.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHAHRIAR ZARRINEH whose telephone number is (571)272-1207. The examiner can normally be reached Monday-Friday, 8:30am-5:30pm.
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, Jorge Ortiz-Criado can be reached at 571-272-7624. 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.
/SHAHRIAR ZARRINEH/Primary Examiner, Art Unit 2496
Prosecution Insights