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 .
Response to Amendment
Applicant’s amendment filed 08 September 2025 has been entered. Applicant amended claims 1, 11, and 18. Accordingly, claims 1-20 remain pending.
Response to Arguments
Applicant's arguments filed 08 September 2025 pertaining to the prior art Chari does not teach the limitations of determine an over-privileged access permissions of the role by comparing the permissible scope for the system defined by the set of security rules stored in the policy engine with the set of effective access permissions determined by the set of security policies” have been fully considered but they are not persuasive. The generality of the claim limitations does not prevent the prior art Chari. Chari discloses in paragraph 96 [c]onsistency of Mined Roles: before comparing the roles mined from usage logs with the groups in the security policy (thus the roles obtained from the model/rules are compared with the groups in the security policy), it is preferable to ensure that the roles obtained are consistent over time. To validate this, generative models [models are based on stored rules/equations] are generated from access logs across different periods in time and the similarity between these models is evaluated. Paragraph 97 discloses the probability distribution of the mined roles over permissions for a model m. .PHI..sub.p,q will be used to denote the probability distribution for the p-th model generated from the q-th period (1.ltoreq.p.ltoreq.10 and 1.ltoreq.q.ltoreq.4 in this experiment). For validation, the models within each period were compared as well the models for different time periods. Therefore, these models are based on rules stored in memory of the policy engine (the policy engine is the computing device in Figure 2, see office action). Paragraph 86 discloses when there are multiple policy items that all pertain to the same action on the same resource that return different decisions, there are precedence rules that determine which rule gets evaluated or how the decisions of the rules are combined to produce a final decision. Paragraph 22 further reveals analytics compares the constructs, such as groups or roles, inferred from the usage of permissions[rules], with the corresponding constructs in the policy[security policy] to estimate how closely the policy matches current usage.
Applicant’s arguments with respect to the independent claim(s) and the limitations of “wherein the policy engine is separated from the IAM system and the set of effective access permissions is generated without submitted a request to the IAM system” have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. As disclosed in the current office action the prior art Baghani teaches the limitations of wherein the policy engine is separated from the IAM system and the set of effective access permissions is generated without submitted a request to the IAM system.
Specification
Applicant is reminded of the proper language and format for an abstract of the disclosure.
The abstract should be in narrative form and generally limited to a single paragraph on a separate sheet within the range of 50 to 150 words in length. The abstract should describe the disclosure sufficiently to assist readers in deciding whether there is a need for consulting the full patent text for details.
The language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, “The disclosure concerns,” “The disclosure defined by this invention,” “The disclosure describes,” etc. In addition, the form and legal phraseology often used in patent claims, such as “means” and “said,” should be avoided.
The abstract of the disclosure is objected to because the abstract should avoid phrases which can be implied such as “Disclosed herein…”. A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b).
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, 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.
Claims 1-7, 11-16 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Kruse et al US 10122757B1 (hereinafter Kruse), in view of Baghani et al US 11397794 (hereinafter Baghani), and in further view of Chari et al US 20140359695 A1( hereinafter Chari).
Regarding claim 1, Kruse teaches [a]n apparatus for managing system resources in an identity and access management (IAM) system (Device that hosts the service in FIG. 2 as a whole), the apparatus comprising: a storage device configured to store a set of security rules that defines a permissible scope for a system resource managed by the IAM system (Figure 2, reference number 218 “Policy Repository”. Column 4, lines 16-38 disclose access control policies may be maintained by a policy management service and may be stored in a policy repository. The policies may, for example, be utilized to establish, for one or more users, a level of access to one or more resources provisioned by or for the organization and, generally, access rights with respect to the one or more resources provisioned by/for the organization); and
a policy engine (Figure 2, reference number 210 “Service Frontend”, reference number 216 “Authentication Service”, and reference number 220 “Policy Management Service” as a whole) operated by a processor (Column 22, lines 52-58 reveal each server include an operating system that provides executable program instructions for the general administration and operation of that server and typically will include a computer-readable storage medium (e.g., a hard disk, random access memory, read only memory, etc.) storing instructions that, when executed by a processor of the server, allow the server to perform its intended functions) communicatively coupled to the storage device (Figure 2 reveals reference number 218 “Policy Repository” is communicatively coupled to the reference number 210 “Service Frontend”, reference number 216 “Authentication Service”, and reference number 220 “Policy Management Service”), and the policy engine is configured to (Column 22, lines 52-58 reveal each server include an operating system that provides executable program instructions).
Kruse does not teach wherein the policy engine is separated from the IAM system; generate a set of effective access permissions for the system resource, wherein the set of effective access permissions is determined by a set of security policies associated with a role in the IAM system, wherein the set of effective access permissions is generated without submitting a request to the IAM system; determine an over-privileged access permission of the role by comparing the permissible scope for the system resource defined by the set of security rules stored in the policy engine with the set of effective access permissions determined by the set of security policies; and determine a compliance status of the role to be non-compliant in response to a determination of the over-privileged access permission of the role.
Baghani teaches wherein the policy engine is separated from the IAM system (Figure 1 reveals policy engine depicted as reference number 130 is separated from the IAM system depicted as reference number 150); generate a set of effective access permissions for the system resource, wherein the set of effective access permissions is determined by a set of security policies associated with a role in the IAM system, wherein the set of effective access permissions is generated without submitting a request to the IAM system (Column 5, lines 30-57 disclose the permission generation module generates permission for different instances of resources. The permission generated depends/is determined by the type of resource, the type of access [thus security rules/policies], and the permission generator generates the access policies for each resource in a textual format, and the different generated access policies may be concatenated or combined to produce an overall access policy for the role. As shown in Figure 1 and column 5, lines 30-57, the generated permission are obtain without the submission of a request); set of security rules stored in the policy engine (Column 5, lines 47-57 disclose access policy templates/rules are stored as text files in a data store. Figure 1 reveals the access policy are stored in repository of the role manager 130/policy engine).
It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to modify the policy engine in Kruse’s teachings of an apparatus for managing system resource with Baghani’s teachings of the policy engine and permission generations to improve the overall security of system and to have only the minimal amount of privileges needed for each code segment. In this manner, the code segments are not granted with excessively broad permissions (which may create unintended security risks), and the overall security of the system can be more easily achieved (Column 2, lines 38-42 and Column 3, lines 59+ to Column 4, line 1 of Baghani).
The combination of Kruse in view of Baghani does not teach; however, in analogous art, Chari teaches determine an over-privileged access permission of the role by comparing the permissible scope for the system resource defined by the set of security rules stored in the policy engine with the set of effective access permissions determined by the set of security policies (Paragraph 96 discloses [c]onsistency of Mined Roles: before comparing the roles mined from usage logs with the groups in the security policy, it is preferable to ensure that the roles obtained are consistent over time[inconsistent roles can infer over-privilege access permission]. To validate this, generative models [models are based on stored roles] are generated from access logs across different periods in time and the similarity between these models is evaluated. Paragraph 97 discloses the probability distribution of the mined roles over permissions for a model m. .PHI..sub.p,q will be used to denote the probability distribution for the p-th model generated from the q-th period (1.ltoreq.p.ltoreq.10 and 1.ltoreq.q.ltoreq.4 in this experiment). For validation, the models within each period were compared as well the models for different time periods. Paragraph 86 discloses when there are multiple policy items that all pertain to the same action on the same resource that return different decisions, there are precedence rules that determine which rule gets evaluated or how the decisions of the rules are combined to produce a final decision. Paragraph 22 reveals analytics compares the constructs, such as groups or roles, inferred from the usage of permissions[rules], with the corresponding constructs in the policy[security policy] to estimate how closely the policy matches current usage. Paragraph 100 discloses by evaluating how the distance between these two models increases or decreases over time, one can measure the change in user behavioral roles); and determine a compliance status of the role to be non-compliant in response to a determination of the over-privileged access permission of the role (Paragraph 100 discloses by evaluating how the distance between these two models increases or decreases over time, one can measure the change in user behavioral roles. If the distance exceeds some threshold, t, then the user population has changed (and the groups and roles in the security policy are considered non-compliant and can be marked as such) and to maintain in compliance the behavioral shift must be corrected or the behavioral changes should correspond with a change in the security policy. While the roles of the user population remain stable, we do not expect extensive changes in the security policy).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention to combine the teachings of Kruse’s policy engine in view of Baghani’s teachings of the policy engine and permission generations with Chari by incorporating Chari's teachings of over-privileged aspect of the access control to reduce security risks and protect resources.
Regarding claim 2, the combination of Kruse in view of Baghani and Chari teaches wherein the apparatus further comprises a display device coupled to the processor and the storage device and configured to display a graphical user interface (GUI), and wherein the policy engine is configured to display on the GUI the role and the compliance status of the role (Chari: Paragraph 136 reveal apparatus 1000 can be configured to implement one or more of the steps of methodology 100 of FIG. 1 for managing a security policy having multiple policy items, methodology 700 of FIG. 7 for identifying over provisioning (i.e., over-provisioned permissions, users, and groups) in a security policy based on usage logs, methodology 800 of FIG. 8 for identifying overly permissive policy items in a security policy based on usage logs and/or methodology 900 of FIG. 9 for determining whether groups in the security policy match roles inferred from usage (e.g., using role mining). Paragraph 141, display 1040 is any type of display suitable for interacting with a human user of apparatus 1000. Generally, display 1040 is a computer monitor or other similar display. Figure 10 reveals apparatus 1000 comprises a processor 1020 and memory 1030).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention to combine the teachings of Kruse’s policy engine in view of Baghani’s teachings of the policy engine and permission generations with Chari, by incorporating Chari's teachings of displaying findings to graphical user interface (GUI) as a way to notify security services and for relative mitigation/remedial action.
Regarding claim 3, the combination of Kruse in view of Baghani and Chari teaches wherein to determine the compliance status of the role to be non-compliant, the policy engine is configured to identify the over-privileged access permission in response to a scope of a name for the system resource defined by the set of effective access permissions exceeding the permissible scope of the name for the system resource defined by the set of security rules, or a scope of a name for the role defined by the set of effective access permissions exceeding the permissible scope of the name for the role defined by the set of security rules (Chari: Paragraphs 113-121 disclose identifying over-provisioning (i.e., over-provisioned permissions, users, and groups) in a security policy based on usage logs. The details of identifying over-provisioned permissions, over-provisioned users, and over-provisioned groups were provided above. Methodology 700 provides one exemplary flow of how the over-provisioning analysis).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention to combine the teachings of Kruse’s policy engine in view of Baghani’s teachings of the policy engine and permission generations with Chari, by incorporating Chari's teachings of finding over-provisioned users, the permissions for which the users are over-provisioned to notify security services and for relative mitigation/remedial action.
Regarding claim 4, the combination of Kruse in view of Baghani and Chari teaches wherein the compliance status is determined to be non-compliant without the role submitting a request to the IAM system for access to the system resource (Chari: Paragraphs 0121, 0123, 0133, 0134 and 0136 disclose …, apparatus 1000 can be configured to implement one or more of the steps of methodology 100 of FIG. 1 for managing a security policy having multiple policy items, methodology 700 of FIG. 7 for identifying over provisioning (i.e., over-provisioned permissions, users, and groups) in a security policy based on usage logs, methodology 800 of FIG. 8 for identifying overly permissive policy items in a security policy based on usage logs and/or methodology 900 of FIG. 9 for determining whether groups in the security policy match roles inferred from usage (e.g., using role mining)).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention to combine the teachings of Kruse’s policy engine in view of Baghani’s teachings of the policy engine and permission generations with Chari, by incorporating Chari's teachings of finding over-provisioned users/permissions through log data.
Regarding claim 5, the combination of Kruse in view of Baghani and Chari teaches wherein the policy engine is further configured to determine the compliance status of the role to be compliant in response to no over-privileged access permission for the role is determined (Chari: Paragraph 133 discloses the policy items in the security policy are weighted using the logs (i.e. SO as to indicate, based on actual usage, which of the policy items were used more than others, and vice-a-versa). In step 914, the groups (extracted in step 910) are compared with the inferred (e.g., mined) roles (from step 906) and in step 916 a determination is made, for each group from the security policy, whether the group has a matching role. Paragraph 134 discloses [i]f the group has a matching role, then as per step 918, the usage (based on the log data from step 902) is in compliance with the group).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention to combine the teachings of Kruse’s policy engine in view of Baghani’s teachings of the policy engine and permission generations with Chari, by incorporating Chari's teachings of finding over-provisioned users/permissions through log data.
Regarding claim 6, the combination of Kruse in view of Baghani and Chari teaches wherein the policy engine is further configured to: generate a notification to the role in response to the compliance status of the role being non-compliant (Chari: Paragraph 100 discloses by evaluating how the distance between these two models increases or decreases over time, one can measure the change in user behavioral roles. If the distance exceeds some threshold, t, then the user population has changed (and the groups and roles in the security policy are considered non-compliant and can be marked as such) and to maintain in compliance the behavioral shift must be corrected or the behavioral changes should correspond with a change in the security policy. While the roles of the user population remain stable, we do not expect extensive changes in the security policy).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention to combine the teachings of Kruse’s policy engine in view of Baghani’s teachings of the policy engine and permission generations with Chari, by incorporating Chari's teachings of notification to notify security services and for relative mitigation/remedial action.
Regarding claim 7, the combination of Kruse in view of Baghani and Chari teaches wherein the policy engine is further configured to: generate a remediation security policy for correcting the set of security policies that generates the set of effective access permissions; and transmit, to the role, an indication of the remediation policy (Chari: Paragraph 113 and 115 disclose identified policy overprovisioning: When confidentiality of the resources is important, the over provisioned policy items should be eliminated to reduce the risk of disclosure. For instance, non-relevant policy items should be eliminated. In some domains some authorizations are used seasonally, or availability of access is important, and it may be necessary to maintain the over provisioned policy items. One possible mitigating measure if to perform audits when the overprovisioned authorizations are used. With regard to over-provisioned users, the permissions for which the users are over-provisioned (i.e., the permissions which the users do not use, or use less than a pre-determined threshold number of times during a given time period--see above) should be revoked to maintain least privilege. With regard to over-provisioned groups, the users that are over-provisioned with respect to the permissions of the group can be removed from the over-provisioned groups to maintain least privilege. Further, one can revoke any of the permissions from the over-provisioned groups of users that are not used by a pre-determined fraction of the users in the over provisioned groups. Paragraph 116 discloses identify overly generic policy items: Similar to the identified policy overprovisioning, when confidentiality is important, the overly generic policy items should be replaced with finer grained policy items. If availability is important, it may be desirable to maintain the overly generic policy items, or find an intermediate state. Overly permissive policy items (identified as described above) can be rewritten to only apply to a minimal set of permissions that are actually accessed in a given period of time SO as to maintain least privilege).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention to combine the teachings of Kruse’s policy engine in view of Baghani’s teachings of the policy engine and permission generations with Chari, by incorporating Chari's teachings of remediation security policy to guide security services and for relative mitigation/remedial action.
Regarding claim 11, Kruse teaches a method (Figure 5 reveals a method); a policy engine (Figure 2, reference number 210 “Service Frontend”, reference number 216 “Authentication Service”, and reference number 220 “Policy Management Service” as a whole) operated by a processor (Column 22, lines 52-58 reveal each server include an operating system that provides executable program instructions for the general administration and operation of that server and typically will include a computer-readable storage medium (e.g., a hard disk, random access memory, read only memory, etc.) storing instructions that, when executed by a processor of the server, allow the server to perform its intended functions).
Kruse does not teach wherein the policy engine is separated from the IAM system; generating, by the policy engine, a set of effective access permissions for the system resource, wherein the set of effective access permissions is determined by a set of security policies associated with a role in the IAM system, and the set of effective access permissions is generated without submitting a request to the IAM system; determining, by the policy engine, an over-privileged access permission of the role by comparing the permissible scope for the system resource defined by the set of security rules stored in the policy engine with the set of effective access permissions determined by the set of security policies; and determining, by the policy engine, a compliance status of the role to be non-compliant in response to a determination of the over-privileged access permission of the role.
Baghani teaches wherein the policy engine is separated from the IAM system (Figure 1 reveals policy engine depicted as reference number 130 is separated from the IAM system depicted as reference number 150); generate, by a policy engine, a set of effective access permissions for the system resource, wherein the set of effective access permissions is determined by a set of security policies associated with a role in the IAM system, wherein the set of effective access permissions is generated without submitting a request to the IAM system (Column 5, lines 30-57 disclose the permission generation module[part of the policy engine] generates permission for different instances of resources. The permission generated depends/is determined by the type of resource, the type of access [thus security rules/policies], and the permission generator generates the access policies for each resource in a textual format, and the different generated access policies may be concatenated or combined to produce an overall access policy for the role. As shown in Figure 1 and column 5, lines 30-57, the generated permission are obtain without the submission of a request); set of security rules stored in the policy engine (Column 5, lines 47-57 disclose access policy templates/rules are stored as text files in a data store. Figure 1 reveals the access policy are stored in repository of the role manager 130/policy engine).
It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to modify the policy engine in Kruse’s teachings of an apparatus for managing system resource with Baghani’s teachings of the policy engine and permission generations to improve the overall security of system and to have only the minimal amount of privileges needed for each code segment. In this manner, the code segments are not granted with excessively broad permissions (which may create unintended security risks), and the overall security of the system can be more easily achieved. (Column 2, lines 38-42 and Column 3, lines 59+ to Column 4, line 1 of Baghani).
The combination of Kruse in view of Baghani does not teach; however, in analogous art, Chari teaches determining, by a policy engine (Figure 10, reference number 1020), an over-privileged access permission of the role by comparing the permissible scope for the system resource defined by the set of security rules stored in the policy engine with the set of effective access permissions determined by the set of security policies (Paragraph 96 discloses [c]onsistency of Mined Roles: before comparing the roles mined from usage logs with the groups in the security policy, it is preferable to ensure that the roles obtained are consistent over time. To validate this, generative models [models are based on stored roles] are generated from access logs across different periods in time and the similarity between these models is evaluated. Paragraph 97 discloses the probability distribution of the mined roles over permissions for a model m. .PHI..sub.p,q will be used to denote the probability distribution for the p-th model generated from the q-th period (1.ltoreq.p.ltoreq.10 and 1.ltoreq.q.ltoreq.4 in this experiment). For validation, the models within each period were compared as well the models for different time periods. Paragraph 86 discloses when there are multiple policy items that all pertain to the same action on the same resource that return different decisions, there are precedence rules that determine which rule gets evaluated or how the decisions of the rules are combined to produce a final decision. Paragraph 22 reveals analytics compares the constructs, such as groups or roles, inferred from the usage of permissions[rules], with the corresponding constructs in the policy[security policy] to estimate how closely the policy matches current usage); and determine, by a policy engine(Figure 10, reference number 1020), a compliance status of the role to be non-compliant in response to a determination of the over-privileged access permission of the role (Paragraph 100 discloses by evaluating how the distance between these two models increases or decreases over time, one can measure the change in user behavioral roles. If the distance exceeds some threshold, t, then the user population has changed (and the groups and roles in the security policy are considered non-compliant and can be marked as such) and to maintain in compliance the behavioral shift must be corrected or the behavioral changes should correspond with a change in the security policy. While the roles of the user population remain stable, we do not expect extensive changes in the security policy).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention to combine the teachings of Kruse’s policy engine in view of Baghani’s teachings of the policy engine and permission generations with Chari by incorporating Chari's teachings of over-privileged aspect of the access control to reduce security risks and protect resources.
Regarding claim 12, the combination of Kruse in view of Baghani and Chari teaches displaying, on a graphical user interface (GUI) of a display device coupled to the processor, the role and the compliance status of the role (Chari: Paragraph 136 reveal apparatus 1000 can be configured to implement one or more of the steps of methodology 100 of FIG. 1 for managing a security policy having multiple policy items, methodology 700 of FIG. 7 for identifying over provisioning (i.e., over-provisioned permissions, users, and groups) in a security policy based on usage logs, methodology 800 of FIG. 8 for identifying overly permissive policy items in a security policy based on usage logs and/or methodology 900 of FIG. 9 for determining whether groups in the security policy match roles inferred from usage (e.g., using role mining). Paragraph 141, display 1040 is any type of display suitable for interacting with a human user of apparatus 1000. Generally, display 1040 is a computer monitor or other similar display. Figure 10 reveals apparatus 1000 comprises a processor 1020 and memory 1030).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention to combine the teachings of Kruse’s policy engine in view of Baghani’s teachings of the policy engine and permission generations with Chari, by incorporating Chari's teachings of displaying findings to graphical user interface (GUI) as a way to notify security services and for relative mitigation/remedial action.
Regarding claim 13, the combination of Kruse in view of Baghani and Chari teaches wherein the determining the over-privileged access permission of the role comprises identifying the over-privileged access permission in response to a scope of a name for the system resource defined by the set of effective access permissions exceeding the permissible scope of the name for the system resource defined by the set of security rules, or a scope of a name for the role defined by the set of effective access permissions exceeding the permissible scope of the name for the role defined by the set of security rules (Chari: Paragraphs 113-121 disclose identifying over-provisioning (i.e., over-provisioned permissions, users, and groups) in a security policy based on usage logs. The details of identifying over-provisioned permissions, over-provisioned users, and over-provisioned groups were provided above. Methodology 700 provides one exemplary flow of how the over-provisioning analysis).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention to combine the teachings of Kruse’s policy engine in view of Baghani’s teachings of the policy engine and permission generations with Chari, by incorporating Chari's teachings of finding over-provisioned users, the permissions for which the users are over-provisioned to notify security services and for relative mitigation/remedial action.
Regarding claim 14, the combination of Kruse in view of Baghani and Chari teaches wherein the compliance status is determined to be non-compliant without the role submitting a request to the IAM system for access to the system resource (Chari: Paragraphs 0121, 0123, 0133, 0134 and 0136 disclose …, apparatus 1000 can be configured to implement one or more of the steps of methodology 100 of FIG. 1 for managing a security policy having multiple policy items, methodology 700 of FIG. 7 for identifying over provisioning (i.e., over-provisioned permissions, users, and groups) in a security policy based on usage logs, methodology 800 of FIG. 8 for identifying overly permissive policy items in a security policy based on usage logs and/or methodology 900 of FIG. 9 for determining whether groups in the security policy match roles inferred from usage (e.g., using role mining)).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention to combine the teachings of Kruse’s policy engine in view of Baghani’s teachings of the policy engine and permission generations with Chari, by incorporating Chari's teachings of finding over-provisioned users/permissions through log data.
Regarding claim 15, the combination of Kruse in view of Baghani and Chari teaches determining the compliance status of the role to be compliant in response to no over-privileged access permission for the role is determined (Chari: Paragraph 133 discloses the policy items in the security policy are weighted using the logs (i.e. SO as to indicate, based on actual usage, which of the policy items were used more than others, and vice-a-versa). In step 914, the groups (extracted in step 910) are compared with the inferred (e.g., mined) roles (from step 906) and in step 916 a determination is made, for each group from the security policy, whether the group has a matching role. Paragraph 134 discloses [i]f the group has a matching role, then as per step 918, the usage (based on the log data from step 902) is in compliance with the group).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention to combine the teachings of Kruse’s policy engine in view of Baghani’s teachings of the policy engine and permission generations with Chari, by incorporating Chari's teachings of finding over-provisioned users/permissions through log data.
Regarding claim 16, the combination of Kruse in view of Baghani and Chari teaches generating a notification to the role in response to the compliance status of the role being non-compliant (Chari: Paragraph 100 discloses by evaluating how the distance between these two models increases or decreases over time, one can measure the change in user behavioral roles. If the distance exceeds some threshold, t, then the user population has changed (and the groups and roles in the security policy are considered non-compliant and can be marked as such) and to maintain in compliance the behavioral shift must be corrected or the behavioral changes should correspond with a change in the security policy. While the roles of the user population remain stable, we do not expect extensive changes in the security policy).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention to combine the teachings of Kruse’s policy engine in view of Baghani’s teachings of the policy engine and permission generations with Chari, by incorporating Chari's teachings of notification to notify security services and for relative mitigation/remedial action.
As to claim 18, Kruse teaches a non-transitory computer-readable medium storing instructions, the instructions, when executed by a processor, cause the processor to perform operations comprising (Column 25, lines 50-63 disclose processes described may be performed under the control of one or more computer systems configured with executable instructions and may be implemented as code (e.g., executable instructions, one or more computer programs or one or more applications) executing collectively on one or more processors, by hardware or combinations thereof. The code may be stored on a computer-readable storage medium, for example, in the form of a computer program comprising a plurality of instructions executable by one or more processors. The computer-readable storage medium may be non-transitory): a policy engine (Figure 2, reference number 210 “Service Frontend”, reference number 216 “Authentication Service”, and reference number 220 “Policy Management Service” as a whole) operated by a processor (Column 22, lines 52-58 reveal each server include an operating system that provides executable program instructions for the general administration and operation of that server and typically will include a computer-readable storage medium (e.g., a hard disk, random access memory, read only memory, etc.) storing instructions that, when executed by a processor of the server, allow the server to perform its intended functions) communicatively coupled to the storage device (Figure 2 reveals reference number 218 “Policy Repository” is communicatively coupled to the reference number 210 “Service Frontend”, reference number 216 “Authentication Service”, and reference number 220 “Policy Management Service”).
Kruse does not teach wherein the policy engine is separated from the IAM system; generating, by the policy engine, a set of effective access permissions for the system resource, wherein the set of effective access permissions is determined by a set of security policies associated with a role in the IAM system, and the set of effective access permissions is generated without submitting a request to the IAM system; determining, by the policy engine, an over-privileged access permission of the role by comparing the permissible scope for the system resource defined by the set of security rules stored in the policy engine with the set of effective access permissions determined by the set of security policies; and determining, by the policy engine, a compliance status of the role to be non-compliant in response to a determination of the over-privileged access permission of the role.
Baghani teaches wherein the policy engine is separated from the IAM system (Figure 1 reveals policy engine depicted as reference number 130 is separated from the IAM system depicted as reference number 150); generate, by a policy engine, a set of effective access permissions for the system resource, wherein the set of effective access permissions is determined by a set of security policies associated with a role in the IAM system, wherein the set of effective access permissions is generated without submitting a request to the IAM system (Column 5, lines 30-57 disclose the permission generation module[part of the policy engine] generates permission for different instances of resources. The permission generated depends/is determined by the type of resource, the type of access [thus security rules/policies], and the permission generator generates the access policies for each resource in a textual format, and the different generated access policies may be concatenated or combined to produce an overall access policy for the role. As shown in Figure 1 and column 5, lines 30-57, the generated permission are obtain without the submission of a request); set of security rules stored in the policy engine (Column 5, lines 47-57 disclose access policy templates/rules are stored as text files in a data store. Figure 1 reveals the access policy are stored in repository of the role manager 130/policy engine).
It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to modify the policy engine in Kruse’s teachings of an apparatus for managing system resource with Baghani’s teachings of the policy engine and permission generations to improve the overall security of system and to have only the minimal amount of privileges needed for each code segment. In this manner, the code segments are not granted with excessively broad permissions (which may create unintended security risks), and the overall security of the system can be more easily achieved. (Column 2, lines 38-42 and Column 3, lines 59+ to Column 4, line 1 of Baghani).
The combination of Kruse in view of Baghani does not teach; however, in analogous art, Chari teaches determining, by a policy engine (Figure 10, reference number 1020), an over-privileged access permission of the role by comparing the permissible scope for the system resource defined by the set of security rules stored in the policy engine with the set of effective access permissions determined by the set of security policies (Paragraph 96 discloses [c]onsistency of Mined Roles: before comparing the roles mined from usage logs with the groups in the security policy, it is preferable to ensure that the roles obtained are consistent over time. To validate this, generative models [models are based on stored roles] are generated from access logs across different periods in time and the similarity between these models is evaluated. Paragraph 97 discloses the probability distribution of the mined roles over permissions for a model m. .PHI..sub.p,q will be used to denote the probability distribution for the p-th model generated from the q-th period (1.ltoreq.p.ltoreq.10 and 1.ltoreq.q.ltoreq.4 in this experiment). For validation, the models within each period were compared as well the models for different time periods. Paragraph 86 discloses when there are multiple policy items that all pertain to the same action on the same resource that return different decisions, there are precedence rules that determine which rule gets evaluated or how the decisions of the rules are combined to produce a final decision. Paragraph 22 reveals analytics compares the constructs, such as groups or roles, inferred from the usage of permissions[rules], with the corresponding constructs in the policy[security policy] to estimate how closely the policy matches current usage); and determine, by a policy engine(Figure 10, reference number 1020), a compliance status of the role to be non-compliant in response to a determination of the over-privileged access permission of the role (Paragraph 100 discloses by evaluating how the distance between these two models increases or decreases over time, one can measure the change in user behavioral roles. If the distance exceeds some threshold, t, then the user population has changed (and the groups and roles in the security policy are considered non-compliant and can be marked as such) and to maintain in compliance the behavioral shift must be corrected or the behavioral changes should correspond with a change in the security policy. While the roles of the user population remain stable, we do not expect extensive changes in the security policy).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention to combine the teachings of Kruse’s policy engine in view of Baghani’s teachings of the policy engine and permission generations with Chari by incorporating Chari's teachings of over-privileged aspect of the access control to reduce security risks and protect resources.
Regarding claim 19, the combination of Kruse in view of Baghani and Chari teaches wherein the determining the over-privileged access permission of the role comprises identifying the over-privileged access permission in response to a scope of a name for the system resource defined by the set of effective access permissions exceeding the permissible scope of the name for the system resource defined by the set of security rules, or a scope of a name for the role defined by the set of effective access permissions exceeding the permissible scope of the name for the role defined by the set of security rules (Chari: Paragraphs 113-121 disclose identifying over-provisioning (i.e., over-provisioned permissions, users, and groups) in a security policy based on usage logs. The details of identifying over-provisioned permissions, over-provisioned users, and over-provisioned groups were provided above. Methodology 700 provides one exemplary flow of how the over-provisioning analysis).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention to combine the teachings of Kruse’s policy engine in view of Baghani’s teachings of the policy engine and permission generations with Chari, by incorporating Chari's teachings of finding over-provisioned users, the permissions for which the users are over-provisioned to notify security services and for relative mitigation/remedial action.
Regarding claim 20, the combination of Kruse in view of Baghani and Chari teaches wherein the compliance status is determined to be non-compliant without the role submitting a request to the IAM system for access to the system resource (Chari: Paragraphs 0121, 0123, 0133, 0134 and 0136 disclose …, apparatus 1000 can be configured to implement one or more of the steps of methodology 100 of FIG. 1 for managing a security policy having multiple policy items, methodology 700 of FIG. 7 for identifying over provisioning (i.e., over-provisioned permissions, users, and groups) in a security policy based on usage logs, methodology 800 of FIG. 8 for identifying overly permissive policy items in a security policy based on usage logs and/or methodology 900 of FIG. 9 for determining whether groups in the security policy match roles inferred from usage (e.g., using role mining)).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention to combine the teachings of Kruse’s policy engine in view of Baghani’s teachings of the policy engine and permission generations with Chari, by incorporating Chari's teachings of finding over-provisioned users/permissions through log data.
Claims 8-10 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Kruse in view of Baghani and Chari as applied to the claims above, and further in view of Cook et al WO 2022125760 A1 (hereinafter Cook).
Regarding claim 8, the combination of Kruse in view of Baghani and Chari teaches all of the limitations of claim 1, respectively, as shown above. The combination of Kruse in view of Baghani and Chari does not explicitly teach wherein the set of security policies is stored in a cloud storage, the set of security policies is specified by a markup language, and the set of security policies includes an identity-based policy, a resource-based policy, a permissions boundary, an organizational service control policy (SCP), an access control list, or a session policy. However, in an analogous art, Cook teaches wherein the set of security policies is stored in a cloud storage, the set of security policies is specified by a markup language, and the set of security policies includes an identity-based policy, a resource-based policy, a permissions boundary, an organizational service control policy (SCP), an access control list, or a session policy (Paragraph 2 discloses user access to system resources using appropriate permissions; paragraph 18 discloses these users can be associated with the same account, a different account, a service, or an external identity authenticated by a supported identity provider (e.g., a corporate directory or a Security Assertion Markup Language [SAML] provider)).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention to combine the teachings of Kruse’s policy engine in view of Baghani’s teachings of the policy engine and permission generations and Chari's teachings of over-privileged aspect of the access control with Cook's teachings of markup language element making policies can be expressed in a language-independent format.
Regarding claim 9, the combination of Kruse in view of Baghani and Chari teaches all of the limitations of claims 1 as shown above. The combination of Kruse in view of Baghani and Chari does not explicitly teach wherein the set of security policies includes an action to be performed on the system resource, and an effect to indicate Allow or Deny of the action to be performed on the system resource. However, in an analogous art, Cook teaches wherein the set of security policies includes an action to be performed on the system resource, and an effect to indicate Allow or Deny of the action to be performed on the system resource (Paragraph 2 discloses user access to system resources using appropriate permissions; paragraph 17 reveal [t[he access control analyzer 100 may be implemented in a provider network 190 that provides access to services and resources 170. The provider network 190 may include an access control policy manager 160 that is usable to grant or deny access to the services and resources 170. For example, the policy manager 160 may be used to approve or deny access requests 155 from an entity referred to as a principal 150. The policy manager 160 may use a set of access control policies 165 to determine whether to allow or deny a particular access request. Principals and policies are discussed in greater detail with reference to FIG.2; paragraph 18 further disclose [a[ccess control in the provider network 190 may be implemented using concepts of accounts, users within accounts, and federations of accounts from third-party identity providers for authentication of identities. Access control in the provider network 190 may be implemented using concepts of roles, assumption of roles, and a general-purpose policy language to specify which resources and services these identities can access and under which conditions, e.g., using the policies 165. A role may represent an identity with associated permission policies which dictate what the role can and cannot do. In some embodiments, instead of being uniquely associated with one person, a role may be assumable by principals such as users, other roles, services, or resources (e.g., compute instances). These users can be associated with the same account, a different account, a service, or an external identity authenticated by a supported identity provider (e.g., a corporate directory or a Security Assertion Markup Language [SAML] provider)).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention to combine the teachings of Kruse’s policy engine in view of Baghani’s teachings of the policy engine and permission generations and Chari's teachings of over-privileged aspect of the access control with Cook by incorporating Cook's teachings of performing specific action when action is performed on system resources to protect system resources.
Regarding claim 10, the combination of Kruse in view of Baghani, Chari, and Cook teaches wherein the action includes a read-only action, a view action, an update action, a write action, or a delete action (Cook: Paragraph 52 reveals action of read-only, wherein audit’s identity policy grants access to the Assume role API on Read-only due to identity policy for the role audit. Paragraph 57 discloses the actions of read, updated, or detected that represents operations that can be performed on a resource).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention to combine the teachings of Kruse’s policy engine in view of Baghani’s teachings of the policy engine and permission generations and Chari's teachings of over-privileged aspect of the access control with Cook by incorporating Cook's teachings of performing specific action when action is performed on system resources to protect system resources
Regarding claim 17, the combination of Kruse in view of Baghani and Chari teaches all of the limitations of claim 11, respectively, as shown above. The combination of Kruse in view of Baghani and Chari does not explicitly teach wherein the set of security policies is stored in a cloud storage, the set of security policies is specified by a markup language, and the set of security policies includes an identity-based policy, a resource-based policy, a permissions boundary, an organizational service control policy (SCP), an access control list, or a session policy. However, in an analogous art, Cook teaches wherein the set of security policies is stored in a cloud storage, the set of security policies is specified by a markup language, and the set of security policies includes an identity-based policy, a resource-based policy, a permissions boundary, an organizational service control policy (SCP), an access control list, or a session policy (Paragraph 2 discloses user access to system resources using appropriate permissions; paragraph 18 discloses these users can be associated with the same account, a different account, a service, or an external identity authenticated by a supported identity provider (e.g., a corporate directory or a Security Assertion Markup Language [SAML] provider)).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention to combine the teachings of Kruse’s policy engine in view of Baghani’s teachings of the policy engine and permission generations and Chari's teachings of over-privileged aspect of the access control with Cook's teachings of markup language element making policies can be expressed in a language-independent format.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure: Morin et al WO 2019244036 (hereinafter Morin).
Morin teaches determining an over-privilege access permission by comparing the permissible scope of the system resource with the set of effective access permissions (Figure 6, reference numbers 606, 608, and 612. These steps disclose comparing the list of entitlements/permissible score of the system resource with list of role entitlements/access permissions ) as recited in claims 1, 11, and 18.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FELICIA FARROW whose telephone number is (571)272-1856. The examiner can normally be reached M - F 7:30am-4:00pm (EST).
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, Alexander Lagor can be reached at (571)270-5143. 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.
/F.F/ Examiner, Art Unit 2437
/ALI S ABYANEH/ Primary Examiner, Art Unit 2437
Prosecution Insights