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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 03/18/2026 has been entered.
Response to Amendment
Examiner has fully considered Applicant’s amendments to Claims in the arguments filed on 03/18/2026. Claims 1-9 and 12 are amended. Claims 10-11 and 13-20 have been cancelled. Claims 21-31 are newly added. Claims 1-9, 12, and 21-31 are pending in the application.
Response to Arguments
Applicant arguments filed 03/18/2026 with respect to the outstanding 35 USC 101 rejections have been fully considered, but they are not persuasive. The outstanding 35 USC 101 rejections are upheld herein with updated rationale provided.
Applicant’s arguments filed 03/18/2026 with respect to the outstanding 35 USC 103 rejections have been fully considered and are persuasive. Therefore, the rejections have been withdrawn. However, upon further consideration, new grounds of rejection are made in view of newly applied references from Hecht (US 20210194911 A1) and Sites et al. (US 10992699 B1) in addition to the previously applied reference from Kirti. The new grounds of rejection are highlighted below.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 USC 101 because the claimed invention is directed to abstract ideas without significantly more.
Amended Claim 1 is directed to a computer-implemented method substantially including steps of calculating an access pillar value, calculating an influence pillar value, computing an impact risk, identifying a human user account as a source of insider risk, and taking a cybersecurity action – each of the steps performed automatically by a computing system. The recited method is a process which falls within one of the statutory categories.
Claim 1 recites judicial exceptions in the calculating, computing, and identifying steps of the method. These processes, under broadest reasonable interpretation, cover performance of the limitations in the mind except for the recitation of generic computer components. That is, the recited limitations “calculating an access pillar value”, “calculating an influence pillar value”, “computing an impact risk”, and “identifying the human user account as a source of insider security risk” are mental processes that, under their broadest reasonable interpretation, can be interpreted as computation steps performed in the mind. Therefore, the claim, as a whole, represents an abstract idea as it only covers performance of the data gathering and storing processes except for the recitation of generic computer components.
These judicial exceptions are not integrated into a practical application. Additional elements of the claim include a computer, the human user account, various criteria and data involved in calculating the values/risk, and the step for taking the cybersecurity action. The computer is recited at a high level of generality and does not serve to integrate the abstract ideas into a practical application by mere performance of the mental processes listed above. The human user account remains the entity being evaluated by performance of the mental processes, and does not integrate the abstract ideas into a practical application. Further, the additional data used in the calculations of the access and pillar values suggests mere data gathering to assist in the performance of the judicial exceptions. While the step for taking a cybersecurity action does represent a remediation aspect against a potential cybersecurity threat, the cybersecurity action is recited broadly such that it does not preclude the action from being performed in the mind. For example, upon identifying a human user account as a source of insider security risk, a human actor could manually disconnect a device associated with the human user account, or the like. Overall, these additional elements do not serve to integrate the abstract ideas into a practical application because they do not impose any meaningful limits on practicing the abstract ideas.
The claim does not incorporate the additional elements in a manner that is sufficient to amount to significantly more than the judicial exceptions. The elements do not meaningfully connect the abstract calculating, computing, and identifying steps to the operation of the computer , nor to the cybersecurity action step after the calculations/computations are performed. Therefore, nothing in the claim adds significantly more than the abstract ideas, and the claim is ineligible.
A similar rejection applies to the newly added corresponding device claim 21, which includes further additional elements of a computing device, a memory, instructions, and a processor. The active steps performed by the process of the insider risk management computing system are the same computing and adjusting steps of Claim 1, except for the added detail that the cybersecurity action is performed to prevent exfiltration of data by the human user account. However, as discussed above, the particular action achieving this result is not described with detail sufficient to amount to significantly more than the judicial exceptions. In summary, these elements are also recited at a high level of generality and do not serve to integrate the abstract ideas into a practical application.
A similar rejection applies to the newly added corresponding computer-readable storage device claim 27, which includes further additional elements of a computer-readable storage device, instructions, and a processor. However, these elements are also recited at a high level of generality and do not serve to integrate the abstract ideas into a practical application.
In view of the above, independent claims 1, 21, and 27 remain ineligible.
Claims 2-9, 12, and 22-26, and 28-31 are also rejected due to their respective dependence on claims 1, 21, and 27.
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.
Claim(s) 1-7, 21-25, 27, and 31 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hecht (US 20210194911 A1), hereinafter Hecht, in view of Sites et al. (US 10992699 B1), hereinafter Sites, and Kirti et al. (US 20180375886 A1), hereinafter Kirti.
Regarding Claim 1:
Hecht teaches A computer-implemented method comprising: based on at least one access signal, automatically calculating an access pillar value associated with a human user account, the access pillar value representing an access authorization of the human user account which authorizes the human user account to access a computing system (Hecht – Paragraph [0030]: In accordance with disclosed techniques, a system may have multiple users, applications, or other types of identities attempting to access a secure resource, such as a cloud computing resource. As discussed further below, an identity may be a user account, machine account, application account, virtual computing resource instance, serverless code instance, or any other type of account that may be associated with a particular user, machine, or application in a computer network. An identity may also be used to gain access to resources of a local machine or computing device, such as a locally installed application or remote desktop. An identity may access the resource using a client computing device, virtual computing instance, or other type of computing resource. In order to grant access to the identity, the resource or another part of the computing system may require authorization and/or authentication of the identity; and Paragraph [0034]: In the disclosed embodiments, techniques of analyzing and addressing least-privilege security threats on a composite basis are described. In some embodiments, a least-privilege damage score may be calculated that quantifies the threat that an unused permission poses to a secure entity or environment. In other embodiments, scores for individual permissions may be aggregated to calculate a score for the entity), wherein the access pillar value is calculated based at least on permission of the human user account to access at least one computing system resource of the computing system that the human user account has not previously accessed (Hecht – Paragraph [0057]: process 300 may iterate through a plurality of sub-steps, 304-307, for each permission identified in the list of permissions. In step 304, process 300 may determine if the permission is unused … process 300 may determine that a permission is unused if the permission has never been used before; and Paragraph [0062]: process 300 may calculate a least-privilege damage score for each unused permission; and Paragraph [0063]: process 300 may aggregate all of the unused permissions' damage scores calculated in step 308. In step 310, process 300 may output the entity's least-privilege damage score, calculated from the aggregate of the of the unused permissions' damage scores for the entity. In some embodiments, the permission scores may be weighted when calculating the entity's least-privilege damage score); based on at least the access pillar value [and the influence pillar value], automatically computing an impact risk associated with the human user account (Hecht – Paragraph [0047]: A least-privilege damage score may be a normalized score that quantifies the extent of the security risk associated with specific permissions of an entity, for example a secure network resource, account, application, etc. The score may also correspond to the severity of the risk, the potential damage that could be caused by exploitation of the permission, the impact of a security breach using the permission, the urgency of making a change to address the potential risk of the permission, etc).
Hecht does not expressly teach automatically calculating an influence pillar value associated with the human user account, wherein the influence pillar value is calculated based on at least one influence signal that represents an extent of organizational influence of a human user of the human user account and is calculated based at least on organizational data representing a position of the human user in an organizational hierarchy with respect to other human users.
However, Sites teaches automatically calculating an influence pillar value associated with the human user account (Sites – Col. 2, Line 64-67 and Col. 3, Line 1-3: A system comprising one or more servers can be configured to derive a measure of potential risk with respect to cybersecurity attacks. In embodiments, a risk score (which may also be called a vulnerability score) is used to represent how vulnerable an organization's users are. A risk score may be calculated for an individual user, a group of users, or the organization as a whole.; and Col. 3, Line 29-31: The system may also determine a user job score that indicates the level of risk that a user presents to an organization based on their role in the organization), wherein the influence pillar value is calculated based on at least one influence signal that represents an extent of organizational influence of a human user of the human user account and is calculated based at least on organizational data representing a position of the human user in an organizational hierarchy with respect to other human users (Sites – Col. 20, Line 49-63 and Col. 21, Line 18-28: In some embodiments, an artificial intelligence model configured to determine a job score for a user may consider different features that relate to the user. For example in the context of the present disclosure, individual features or sets of features can be input into an artificial intelligence model … Examples of alternative or additional features that may be fed into one or more artificial intelligence models separately or in combination to determine a job score for a user or a risk score for a user include: … Depth of the user in the organization—The hierarchy above a user's position in an organization (for example a data entry user may be ten organizational levels below the CEO) or the number of people above the user in the organization (for example a user has ten managers above them). Height of the user in an organization—The hierarchy below a user's place (for example a user manages 5 levels down), or how many people are reporting to a user (for example a user manages (directly only, or directly and indirectly) 15 people on a team); based on at least [the access pillar value and] the influence pillar value, automatically computing an impact risk associated with the human user account (Sites – Col. 18, Line 10-25: The job scores of users, for example determined by one or more servers using artificial intelligence, are useful in a security awareness system when determining a user's risk score with respect to cybersecurity threats. A user risk score (which may also be called a vulnerability score) may take into consideration a job score of the user which in some examples is determined by at least the job, position or role that the user has in an organization. The job, position or role that a user has in an organization may be indicative of how frequently the user is presented with a malicious attack, how likely a user is to respond to a malicious attack, or how severe the consequence of the user responding to a malicious attack may be to the organization, which may for example be influenced by how much access the user has to critical systems and servers of their organization).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Hecht, further incorporating Sites to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Site’s teaching of a user risk factor based on that user’s hierarchical position in an organization/enterprise relative to other users into Hecht’s method for calculating user risk based on permissions. This additional consideration helps establish a more complete risk evaluation for determining insider threat potential for users within an organization.
The combination of Hecht and Sites does not expressly teach automatically computing an impact risk associated with the human user account; and in at least one instance: identifying the human user account as a source of insider security risk based at least on the impact risk; and automatically taking at least one cybersecurity action in the computing system, the at least one cybersecurity action protecting the computing system from potential harm by the human user account.
However, Kirti teaches automatically computing an impact risk associated with the human user account (Kirti – Paragraph [0003]: Customers of cloud service providers, which can be referred to as users or tenants, can subscribe to the service provider to obtain access to the particular services provided by the service provider. The service provider can maintain an account for a user or tenant, through which the user and/or tenant can access the provider's services. The service provider can further maintain user accounts that are associated with the tenant, for individual users; and Paragraph [0012]: In various aspects, risk scores indicate a degree of security risk to the tenant from actions performed by a user in using the cloud service. In various aspects, risk scores are computed as a weight sum of risk indicators); and in at least one instance: identifying the human user account as a source of insider security risk based at least on the impact risk (Kirti – Paragraph [0122]: Another example of a threat scenario is an insider threat. Insider threats can refer to security breaches perpetrated by a person from within a network. For example, an employee of an organization, who has been authorized, through the course of employment with the organization, may misuse the authorization and intentionally or unintentionally case a security breach. Detection of an insider threat can involve tracking a user's normal behavior and generating alerts when events or activities associated with the user's account or accounts deviate from the norm; and Paragraph [0199]: FIG. 6 includes a flowchart that illustrates an example of a process 600 for determining privileged users of a cloud service, and managing security risks that the activity of privileged users may cause; and Paragraph [0200]: In some examples, a tenant can be an organization that brings together people and resources to serve a common purpose. Examples of organizations include companies, universities, hospitals, government agencies, and other groups of people and resources; and Paragraph [0209]: At step 610, the process 600 includes determining, using the activity data, one or more risk scores for the one or more users. In various examples, risk scores indicate a degree of security risk to the tenant from actions performed by a user in using the cloud service. Risk scores can be computed for individual users … In some examples, risk scores are computed as a weight sum of risk indicators; and Paragraph [0211]: At step 612, the process 600 includes determining that a risk score for [a] user in the set of users is greater than a threshold. In various examples, the threshold can indicate activity that, when the threshold is exceeded, constitutes a security risk for the tenant. In various examples, the threshold can be associated with … a particular user); and automatically taking at least one cybersecurity action in the computing system, the at least one cybersecurity action protecting the computing system from potential harm by the human user account (Kirti – Paragraph [0212]: At step 614, the process 600 includes determining a security control for the service provider system, wherein the security control is used by the service provider system to configure access to the cloud service. The security control can depend on factors such as the action or actions performed that caused the risk score to exceed the threshold, the resource affected by the actions, threat intelligence, and/or configuration settings associated with the tenant, among other factors. Examples of security controls that can be determined include blocking a user or group of users from using the service, disabling a particular user account with the cloud service, causing the service to send alerts whenever certain users log in and/or perform certain actions, and blocking data from being uploaded to or downloaded from the service, among other controls; and Paragraph [0214]: At step 618, the process 600 includes sending the one or more instructions to the service provider system, wherein the one or more instructions cause the security control to be changed with respect to the user, wherein access to the cloud service by the user is modified due to the change to the security control. In various examples, sending the instructions can include using an authorization assigned to the tenant (e.g., a password, token, or other form of credential), which can enable the security management system to configure the cloud service on behalf of the tenant. In some examples, the instructions are sent to the service provider system for activation by the tenant or the service provider. Once executed, a security risk caused by the privileged user can be monitored, mitigated, and/or stopped).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Hecht and Sites, further incorporating Kirti to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Kirti’s teaching to calculate risk scores for individual users based on a weighted plurality of risk indicators and performing some protective responsive action into Hecht and Sites’s combined method for calculating user risk based on permissions and organizational role. Kirti’s broader risk score determination combines naturally with the more particular risk considerations of Hecht and Sites. One of ordinary skill in the art would find it obvious to factor in the teachings of Hecht and Sites with the methods of Kirti in determining reliable assessments for potential insider risks.
Regarding Claim 2:
The combination of Hecht, Sites, and Kirti teaches The computer-implemented method of claim 1.
Hecht further teaches wherein the at least one access signal represents a count of multiple computing system resources of a specified sensitivity which the human user account is authorized to access (Hecht – Paragraph [0041]: The identity may also have a number of permissions associated with it that, once authenticated, give the identity access to restricted resources or grant the identity the ability to execute code on the resource, etc.; and Paragraph [0047]: in some environments a least-privilege ratio can be calculated that compares the number of unused permissions to the number of total permissions; and Paragraph [0048]: Thus, as illustrated in FIG. 2, for a given permission, a separate sub-score may be calculated based upon the permission's category, the permission's self-frequency, the permission's general frequency, the resource's service, the target resource's type, the resource's sensitivity profile, the resource's size, presence of or possibility of shadow administrators, the permission's frequency in attacks, unusually sensitive target resources, the security status of an entity associated with the permission, etc) and has not actually accessed at a time when the access pillar value is automatically calculated (Hecht – Paragraph [0057]: process 300 may iterate through a plurality of sub-steps, 304-307, for each permission identified in the list of permissions. In step 304, process 300 may determine if the permission is unused … process 300 may determine that a permission is unused if the permission has never been used before).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 3:
The combination of Hecht, Sites, and Kirti teaches The computer-implemented method of claim 1.
Sites further teaches wherein the at least one influence signal represents a title or a role of the human user within an organization represented by the organizational hierarchy; and a count of people who report to the human user within the organization represented by the organizational hierarchy (Sites – Col. 20, Line 49-63 and Col. 21, Line 18-28: In some embodiments, an artificial intelligence model configured to determine a job score for a user may consider different features that relate to the user. For example in the context of the present disclosure, individual features or sets of features can be input into an artificial intelligence model … Examples of alternative or additional features that may be fed into one or more artificial intelligence models separately or in combination to determine a job score for a user or a risk score for a user include: … Depth of the user in the organization—The hierarchy above a user's position in an organization (for example a data entry user may be ten organizational levels below the CEO) or the number of people above the user in the organization (for example a user has ten managers above them). Height of the user in an organization—The hierarchy below a user's place (for example a user manages 5 levels down), or how many people are reporting to a user (for example a user manages (directly only, or directly and indirectly) 15 people on a team).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 4:
The combination of Hecht, Sites, and Kirti teaches The computer-implemented method of claim 1.
Kirti further teaches wherein automatically computing the impact risk includes computing a weighted combination in which the access pillar value has a different weight than the influence pillar value (Kirti - Paragraph [0209]: At step 610, the process 600 includes determining, using the activity data, one or more risk scores for the one or more users … risk scores are computed as a weight sum of risk indicators).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 5:
The combination of Hecht, Sites, and Kirti teaches The computer-implemented method of claim 1.
Kirti further teaches wherein the impact risk is also automatically computed based on an additional pillar value which represents an exfiltration activity of the human user account that involves sending sensitive content outside of the computing system (Kirti – Paragraph [0047]: In some examples, a cloud service can be authorized or unauthorized for use within the organization 130. An authorized service is one that the organization 130 has approved for use … An unauthorized service is one that the organization may not have specifically approved, and that a user is using at the user's own discretion. For example, a user may be using a file sharing service that the organization 130 has not specifically authorized, possibly without the organization 130 being aware that the file sharing service is being used; and Paragraph [0131]: the behavioral analytics engine 304 can include contextual data in the activity profile for a user … Examples of contextual data include … sensitive emails from email servers … contextual data can additionally or alternatively be obtained from client devices used by the user).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 6:
The combination of Hecht, Sites, and Kirti teaches The computer-implemented method of claim 1.
Kirti further teaches further comprising; automatically displaying a human-readable explanation of a computational basis utilized while computing the impact risk (Kirti – Paragraph [0085]: In various implementations, the security management and control system 102 provides an interface 120 through which customers of the security management and control system 102 can use the services of the security management and control system 102. The interface 120 can provide, for example, a graphical user interface (GUI) that can display a control panel or dashboard that enables the organization's administrative users to configure the services of the security management and control system 102. The graphical user interface can further enable the administrative users to view reports of user activity with respect to the services 112a-112b of the service provider 110. The graphical user interface can further provide reports of security events and suggest remediation actions, and/or report on the outcome of remediation actions that the security management and control system 102 automatically performs. The graphical user interface can be implemented, for example, as software application that can be executed on the client devices 106a-106c of the organization 130. Alternatively or additionally, the graphical user interface can be implemented as a web-based interface (e.g., a website)).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 7:
The combination of Hecht, Sites, and Kirti teaches The computer-implemented method of claim 1.
Kirti further teaches wherein automatically taking the at least one cybersecurity action comprises: in a first instance, automatically disabling, automatically suspending, or automatically deleting the human user account; in a second instance, automatically altering membership of the human user account in a computing system security group; and in a third instance, automatically turning on a particular security threat detection mechanism (Kirti – Paragraph [0212]: At step 614, the process 600 includes determining a security control for the service provider system, wherein the security control is used by the service provider system to configure access to the cloud service. The security control can depend on factors such as the action or actions performed that caused the risk score to exceed the threshold, the resource affected by the actions, threat intelligence, and/or configuration settings associated with the tenant, among other factors. Examples of security controls that can be determined include blocking a user or group of users from using the service, disabling a particular user account with the cloud service, causing the service to send alerts whenever certain users log in and/or perform certain actions, and blocking data from being uploaded to or downloaded from the service, among other controls; and Paragraph [0214]: At step 618, the process 600 includes sending the one or more instructions to the service provider system, wherein the one or more instructions cause the security control to be changed with respect to the user, wherein access to the cloud service by the user is modified due to the change to the security control. In various examples, sending the instructions can include using an authorization assigned to the tenant (e.g., a password, token, or other form of credential), which can enable the security management system to configure the cloud service on behalf of the tenant. In some examples, the instructions are sent to the service provider system for activation by the tenant or the service provider. Once executed, a security risk caused by the privileged user can be monitored, mitigated, and/or stopped).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 21:
Hecht teaches a computing device comprising: a digital memory storing instructions; a processor in operable communication with the digital memory; wherein, when executed by the processor, the instructions stored in the digital memory cause the processor to (Hecht – Paragraph [0004]: in an exemplary embodiment, there may be a non-transitory computer readable medium including instructions that, when executed by at least one processor, cause the at least one processor to perform operations for developing composite and permission-based risk assessments for network identities): automatically calculate an access pillar value associated with a human user account based on at least one access signal, the access pillar value representing an access authorization of the human user account which authorizes the human user account to access a managed computing system (Hecht – Paragraph [0030]: In accordance with disclosed techniques, a system may have multiple users, applications, or other types of identities attempting to access a secure resource, such as a cloud computing resource. As discussed further below, an identity may be a user account, machine account, application account, virtual computing resource instance, serverless code instance, or any other type of account that may be associated with a particular user, machine, or application in a computer network. An identity may also be used to gain access to resources of a local machine or computing device, such as a locally installed application or remote desktop. An identity may access the resource using a client computing device, virtual computing instance, or other type of computing resource. In order to grant access to the identity, the resource or another part of the computing system may require authorization and/or authentication of the identity; and Paragraph [0034]: In the disclosed embodiments, techniques of analyzing and addressing least-privilege security threats on a composite basis are described. In some embodiments, a least-privilege damage score may be calculated that quantifies the threat that an unused permission poses to a secure entity or environment. In other embodiments, scores for individual permissions may be aggregated to calculate a score for the entity), wherein the access pillar value is calculated based at least on permission of the human user account to access at least one computing system resource of the managed computing system that the human user account has not previously accessed (Hecht – Paragraph [0057]: process 300 may iterate through a plurality of sub-steps, 304-307, for each permission identified in the list of permissions. In step 304, process 300 may determine if the permission is unused … process 300 may determine that a permission is unused if the permission has never been used before; and Paragraph [0062]: process 300 may calculate a least-privilege damage score for each unused permission; and Paragraph [0063]: process 300 may aggregate all of the unused permissions' damage scores calculated in step 308. In step 310, process 300 may output the entity's least-privilege damage score, calculated from the aggregate of the of the unused permissions' damage scores for the entity. In some embodiments, the permission scores may be weighted when calculating the entity's least-privilege damage score); based on at least the access pillar value [and the influence pillar value], automatically compute an impact risk associated with the human user account (Hecht – Paragraph [0047]: A least-privilege damage score may be a normalized score that quantifies the extent of the security risk associated with specific permissions of an entity, for example a secure network resource, account, application, etc. The score may also correspond to the severity of the risk, the potential damage that could be caused by exploitation of the permission, the impact of a security breach using the permission, the urgency of making a change to address the potential risk of the permission, etc).
Hecht does not expressly teach automatically calculate an influence pillar value associated with the human user account, wherein the influence pillar value is calculated based on at least one influence signal that represents an extent of organizational influence of a human user of the human user account and is calculated based at least on organizational data representing a position of the human user in an organizational hierarchy with respect to other human users.
However, Sites teaches automatically calculate an influence pillar value associated with the human user account (Sites – Col. 2, Line 64-67 and Col. 3, Line 1-3: A system comprising one or more servers can be configured to derive a measure of potential risk with respect to cybersecurity attacks. In embodiments, a risk score (which may also be called a vulnerability score) is used to represent how vulnerable an organization's users are. A risk score may be calculated for an individual user, a group of users, or the organization as a whole.; and Col. 3, Line 29-31: The system may also determine a user job score that indicates the level of risk that a user presents to an organization based on their role in the organization), wherein the influence pillar value is calculated based on at least one influence signal that represents an extent of organizational influence of a human user of the human user account and is calculated based at least on organizational data representing a position of the human user in an organizational hierarchy with respect to other human users (Sites – Col. 20, Line 49-63 and Col. 21, Line 18-28: In some embodiments, an artificial intelligence model configured to determine a job score for a user may consider different features that relate to the user. For example in the context of the present disclosure, individual features or sets of features can be input into an artificial intelligence model … Examples of alternative or additional features that may be fed into one or more artificial intelligence models separately or in combination to determine a job score for a user or a risk score for a user include: … Depth of the user in the organization—The hierarchy above a user's position in an organization (for example a data entry user may be ten organizational levels below the CEO) or the number of people above the user in the organization (for example a user has ten managers above them). Height of the user in an organization—The hierarchy below a user's place (for example a user manages 5 levels down), or how many people are reporting to a user (for example a user manages (directly only, or directly and indirectly) 15 people on a team); based on at least [the access pillar value and] the influence pillar value, automatically compute an impact risk associated with the human user account (Sites – Col. 18, Line 10-25: The job scores of users, for example determined by one or more servers using artificial intelligence, are useful in a security awareness system when determining a user's risk score with respect to cybersecurity threats. A user risk score (which may also be called a vulnerability score) may take into consideration a job score of the user which in some examples is determined by at least the job, position or role that the user has in an organization. The job, position or role that a user has in an organization may be indicative of how frequently the user is presented with a malicious attack, how likely a user is to respond to a malicious attack, or how severe the consequence of the user responding to a malicious attack may be to the organization, which may for example be influenced by how much access the user has to critical systems and servers of their organization).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Hecht, further incorporating Sites to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Site’s teaching of a user risk factor based on that user’s hierarchical position in an organization/enterprise relative to other users into Hecht’s method for calculating user risk based on permissions. This additional consideration helps establish a more complete risk evaluation for determining insider threat potential for users within an organization.
The combination of Hecht and Sites does not expressly teach automatically compute an impact risk associated with the human user account; and in at least one instance: identifying the human user account as a source of insider security risk based at least on the impact risk; and automatically taking at least one cybersecurity action in the computing system, the at least one cybersecurity action protecting the computing system from potential harm by the human user account.
However, Kirti teaches automatically computing an impact risk associated with the human user account (Kirti – Paragraph [0003]: Customers of cloud service providers, which can be referred to as users or tenants, can subscribe to the service provider to obtain access to the particular services provided by the service provider. The service provider can maintain an account for a user or tenant, through which the user and/or tenant can access the provider's services. The service provider can further maintain user accounts that are associated with the tenant, for individual users; and Paragraph [0012]: In various aspects, risk scores indicate a degree of security risk to the tenant from actions performed by a user in using the cloud service. In various aspects, risk scores are computed as a weight sum of risk indicators); and in at least one instance: identifying the human user account as a source of insider security risk based at least on the impact risk (Kirti – Paragraph [0122]: Another example of a threat scenario is an insider threat. Insider threats can refer to security breaches perpetrated by a person from within a network. For example, an employee of an organization, who has been authorized, through the course of employment with the organization, may misuse the authorization and intentionally or unintentionally case a security breach. Detection of an insider threat can involve tracking a user's normal behavior and generating alerts when events or activities associated with the user's account or accounts deviate from the norm; and Paragraph [0199]: FIG. 6 includes a flowchart that illustrates an example of a process 600 for determining privileged users of a cloud service, and managing security risks that the activity of privileged users may cause; and Paragraph [0200]: In some examples, a tenant can be an organization that brings together people and resources to serve a common purpose. Examples of organizations include companies, universities, hospitals, government agencies, and other groups of people and resources; and Paragraph [0209]: At step 610, the process 600 includes determining, using the activity data, one or more risk scores for the one or more users. In various examples, risk scores indicate a degree of security risk to the tenant from actions performed by a user in using the cloud service. Risk scores can be computed for individual users … In some examples, risk scores are computed as a weight sum of risk indicators; and Paragraph [0211]: At step 612, the process 600 includes determining that a risk score for [a] user in the set of users is greater than a threshold. In various examples, the threshold can indicate activity that, when the threshold is exceeded, constitutes a security risk for the tenant. In various examples, the threshold can be associated with … a particular user); and automatically trigger at least one cybersecurity action in the computing system (Kirti – Paragraph [0212]: At step 614, the process 600 includes determining a security control for the service provider system, wherein the security control is used by the service provider system to configure access to the cloud service. The security control can depend on factors such as the action or actions performed that caused the risk score to exceed the threshold, the resource affected by the actions, threat intelligence, and/or configuration settings associated with the tenant, among other factors. Examples of security controls that can be determined include blocking a user or group of users from using the service, disabling a particular user account with the cloud service, causing the service to send alerts whenever certain users log in and/or perform certain actions, and blocking data from being uploaded to or downloaded from the service, among other controls; and Paragraph [0214]: At step 618, the process 600 includes sending the one or more instructions to the service provider system, wherein the one or more instructions cause the security control to be changed with respect to the user, wherein access to the cloud service by the user is modified due to the change to the security control. In various examples, sending the instructions can include using an authorization assigned to the tenant (e.g., a password, token, or other form of credential), which can enable the security management system to configure the cloud service on behalf of the tenant. In some examples, the instructions are sent to the service provider system for activation by the tenant or the service provider. Once executed, a security risk caused by the privileged user can be monitored, mitigated, and/or stopped), the at least one cybersecurity action preventing exfiltration of data outside of the managed computing system by the human user account (Kirti – Paragraph [0047]: An unauthorized service is one that the organization may not have specifically approved, and that a user is using at the user's own discretion. For example, a user may be using a file sharing service that the organization 130 has not specifically authorized, possibly without the organization 130 being aware that the file sharing service is being used; and Paragraph [0048]: For example, the organization 130 can have an authorized web browser application, through which users can access services such as a file sharing service or a database service. In this and other examples, the web browser application can be referred to as an internal application. In some examples, the internal application can operate cooperatively with the cloud services 112a-112b, including, for example, allowing the services 112a-112b to access data, user account information, or other information within the organization 130. Because the internal application is executing within the organization 130 (for example on client devices 106a-106c of the organization 130), the organization 130 can monitor and control usage of the internal application. The organization 130, however, may not be aware of or be able to monitor users' usage, through the internal application, of the services 112a-112b of the service provider 110; and Paragraph [0122]: Another example of a threat scenario is an insider threat. Insider threats can refer to security breaches perpetrated by a person from within a network. For example, an employee of an organization, who has been authorized, through the course of employment with the organization, may misuse the authorization and intentionally or unintentionally case a security breach. Detection of an insider threat can involve tracking a user's normal behavior and generating alerts when events or activities associated with the user's account or accounts deviate from the norm. Metrics can include … sharing an unusually high number of files/folders).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Hecht and Sites, further incorporating Kirti to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Kirti’s teaching to calculate risk scores for individual users based on a weighted plurality of risk indicators and performing some protective responsive action into Hecht and Sites’s combined method for calculating user risk based on permissions and organizational role. Kirti’s broader risk score determination combines naturally with the more particular risk considerations of Hecht and Sites. One of ordinary skill in the art would find it obvious to factor in the teachings of Hecht and Sites with the methods of Kirti in determining reliable assessments for potential insider risks.
Regarding Claim 22:
The combination of Hecht, Sites, and Kirti teaches the computing device of claim 21.
Kirti further teaches wherein the impact risk is further calculated based at least on a success rate of the human user account in accessing other computing system resources of the managed computing system (Kirti – Paragraph [0106]: In various examples, activity data can include various types of information about the user of the service provider's services. For example, activity data associated with user accounts can include information relating to the use of, and/or actions taken with, a user account for a service. In this example, the activity data can include sources of information such as user logs and/or audit trails. More specific types of activity data can include, for example, login and logout statistics (including attempts and successes)).
The motivation to combine the arts is the same as that of Claim 21.
Regarding Claim 23:
The combination of Hecht, Sites, and Kirti teaches the computing device of claim 21.
Hecht further teaches wherein the impact risk is further calculated based at least on criticality of the at least one computing system resource of the managed computing system that the human user account has not actually accessed (Hecht – Paragraph [0048]: Thus, as illustrated in FIG. 2, for a given permission, a separate sub-score may be calculated based upon the permission's category, the permission's self-frequency, the permission's general frequency, the resource's service, the target resource's type, the resource's sensitivity profile, the resource's size, presence of or possibility of shadow administrators, the permission's frequency in attacks, unusually sensitive target resources, the security status of an entity associated with the permission, etc; and Figure 3: Flowchart for calculating an entity’s least-privilege damage score based on unused privileges; and Paragraph [0057]: process 300 may iterate through a plurality of sub-steps, 304-307, for each permission identified in the list of permissions. In step 304, process 300 may determine if the permission is unused … process 300 may determine that a permission is unused if the permission has never been used before; and Paragraph [0060]: process 300 may determine the potential damage based on the target resources associated with the entity and/or the privilege … a target resource score may be calculated based upon one or more sub-scores associated with the permission, including the resource's service, target resources type, resource's sensitivity profile, and resource's size).
The motivation to combine the arts is the same as that of Claim 21.
Regarding Claim 24:
The combination of Hecht, Sites, and Kirti teaches the computing device of claim 21.
Hecht further teaches wherein the impact risk is further calculated based at least on a cybersecurity attack on the human user account (Hecht – Paragraph [0070]: process 500 may identify one or more custom risk factors … the customized risk factor may address whether the permission corresponds to a historical attack permission. A historical attack permission may be, for example, a permission that has been used in one or more previous malicious attacks waged on the corresponding entity or on other entities or environments).
The motivation to combine the arts is the same as that of Claim 21.
Regarding Claim 25:
The combination of Hecht, Sites, and Kirti teaches the computing device of claim 21.
Sites further teaches wherein the impact risk is further calculated based at least on a membership of the human user account in a security group associated with the managed computing system (Sites – Col. 20, Line 60-67 and Col. 21, Line 1-17: Examples of alternative or additional features that may be fed into one or more artificial intelligence models separately or in combination to determine a job score for a user or a risk score for a user include: … Group risk booster—A user's personal risk score can be impacted by a group risk booster when the user is added to a group).
The motivation to combine the arts is the same as that of Claim 21.
Regarding Claim 27:
Hecht teaches a computer-readable storage device storing instructions which, upon execution by a processor, cause the processor to perform acts comprising (Hecht – Paragraph [0004]: in an exemplary embodiment, there may be a non-transitory computer readable medium including instructions that, when executed by at least one processor, cause the at least one processor to perform operations for developing composite and permission-based risk assessments for network identities): automatically calculating an access pillar value associated with a human user account based on at least one access signal, the access pillar value representing an access authorization of the human user account which authorizes the human user account to access a computing system (Hecht – Paragraph [0030]: In accordance with disclosed techniques, a system may have multiple users, applications, or other types of identities attempting to access a secure resource, such as a cloud computing resource. As discussed further below, an identity may be a user account, machine account, application account, virtual computing resource instance, serverless code instance, or any other type of account that may be associated with a particular user, machine, or application in a computer network. An identity may also be used to gain access to resources of a local machine or computing device, such as a locally installed application or remote desktop. An identity may access the resource using a client computing device, virtual computing instance, or other type of computing resource. In order to grant access to the identity, the resource or another part of the computing system may require authorization and/or authentication of the identity; and Paragraph [0034]: In the disclosed embodiments, techniques of analyzing and addressing least-privilege security threats on a composite basis are described. In some embodiments, a least-privilege damage score may be calculated that quantifies the threat that an unused permission poses to a secure entity or environment. In other embodiments, scores for individual permissions may be aggregated to calculate a score for the entity), wherein the access pillar value is calculated based at least on permission of the human user account to access at least one computing system resource of the computing system that the human user account has not previously accessed (Hecht – Paragraph [0057]: process 300 may iterate through a plurality of sub-steps, 304-307, for each permission identified in the list of permissions. In step 304, process 300 may determine if the permission is unused … process 300 may determine that a permission is unused if the permission has never been used before; and Paragraph [0062]: process 300 may calculate a least-privilege damage score for each unused permission; and Paragraph [0063]: process 300 may aggregate all of the unused permissions' damage scores calculated in step 308. In step 310, process 300 may output the entity's least-privilege damage score, calculated from the aggregate of the of the unused permissions' damage scores for the entity. In some embodiments, the permission scores may be weighted when calculating the entity's least-privilege damage score); based on at least the access pillar value [and the influence pillar value], automatically computing an impact risk associated with the human user account (Hecht – Paragraph [0047]: A least-privilege damage score may be a normalized score that quantifies the extent of the security risk associated with specific permissions of an entity, for example a secure network resource, account, application, etc. The score may also correspond to the severity of the risk, the potential damage that could be caused by exploitation of the permission, the impact of a security breach using the permission, the urgency of making a change to address the potential risk of the permission, etc).
Hecht does not expressly teach automatically calculating an influence pillar value associated with the human user account, wherein the influence pillar value is calculated based on at least one influence signal that represents an extent of organizational influence associated with a human user of the human user account and is calculated based at least on organizational data representing a position of the human user in an organizational hierarchy with respect to other human users.
However, Sites teaches automatically calculating an influence pillar value associated with the human user account (Sites – Col. 2, Line 64-67 and Col. 3, Line 1-3: A system comprising one or more servers can be configured to derive a measure of potential risk with respect to cybersecurity attacks. In embodiments, a risk score (which may also be called a vulnerability score) is used to represent how vulnerable an organization's users are. A risk score may be calculated for an individual user, a group of users, or the organization as a whole.; and Col. 3, Line 29-31: The system may also determine a user job score that indicates the level of risk that a user presents to an organization based on their role in the organization), wherein the influence pillar value is calculated based on at least one influence signal that represents an extent of organizational influence associated with a human user of the human user account and is calculated based at least on organizational data representing a position of the human user in an organizational hierarchy with respect to other human users (Sites – Col. 20, Line 49-63 and Col. 21, Line 18-28: In some embodiments, an artificial intelligence model configured to determine a job score for a user may consider different features that relate to the user. For example in the context of the present disclosure, individual features or sets of features can be input into an artificial intelligence model … Examples of alternative or additional features that may be fed into one or more artificial intelligence models separately or in combination to determine a job score for a user or a risk score for a user include: … Depth of the user in the organization—The hierarchy above a user's position in an organization (for example a data entry user may be ten organizational levels below the CEO) or the number of people above the user in the organization (for example a user has ten managers above them). Height of the user in an organization—The hierarchy below a user's place (for example a user manages 5 levels down), or how many people are reporting to a user (for example a user manages (directly only, or directly and indirectly) 15 people on a team); based on at least [the access pillar value and] the influence pillar value, automatically computing an impact risk associated with the human user account (Sites – Col. 18, Line 10-25: The job scores of users, for example determined by one or more servers using artificial intelligence, are useful in a security awareness system when determining a user's risk score with respect to cybersecurity threats. A user risk score (which may also be called a vulnerability score) may take into consideration a job score of the user which in some examples is determined by at least the job, position or role that the user has in an organization. The job, position or role that a user has in an organization may be indicative of how frequently the user is presented with a malicious attack, how likely a user is to respond to a malicious attack, or how severe the consequence of the user responding to a malicious attack may be to the organization, which may for example be influenced by how much access the user has to critical systems and servers of their organization).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Hecht, further incorporating Sites to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Site’s teaching of a user risk factor based on that user’s hierarchical position in an organization/enterprise relative to other users into Hecht’s method for calculating user risk based on permissions. This additional consideration helps establish a more complete risk evaluation for determining insider threat potential for users within an organization.
The combination of Hecht and Sites does not expressly teach automatically computing an impact risk associated with the human user account; and in at least one instance: identifying the human user account as a source of insider security risk based at least on the impact risk; and automatically taking at least one cybersecurity action in the computing system, the at least one cybersecurity action protecting the computing system from potential harm by the human user account.
However, Kirti teaches automatically computing an impact risk associated with the human user account (Kirti – Paragraph [0003]: Customers of cloud service providers, which can be referred to as users or tenants, can subscribe to the service provider to obtain access to the particular services provided by the service provider. The service provider can maintain an account for a user or tenant, through which the user and/or tenant can access the provider's services. The service provider can further maintain user accounts that are associated with the tenant, for individual users; and Paragraph [0012]: In various aspects, risk scores indicate a degree of security risk to the tenant from actions performed by a user in using the cloud service. In various aspects, risk scores are computed as a weight sum of risk indicators); and in at least one instance: identifying the human user account as a source of insider security risk based at least on the impact risk (Kirti – Paragraph [0122]: Another example of a threat scenario is an insider threat. Insider threats can refer to security breaches perpetrated by a person from within a network. For example, an employee of an organization, who has been authorized, through the course of employment with the organization, may misuse the authorization and intentionally or unintentionally case a security breach. Detection of an insider threat can involve tracking a user's normal behavior and generating alerts when events or activities associated with the user's account or accounts deviate from the norm; and Paragraph [0199]: FIG. 6 includes a flowchart that illustrates an example of a process 600 for determining privileged users of a cloud service, and managing security risks that the activity of privileged users may cause; and Paragraph [0200]: In some examples, a tenant can be an organization that brings together people and resources to serve a common purpose. Examples of organizations include companies, universities, hospitals, government agencies, and other groups of people and resources; and Paragraph [0209]: At step 610, the process 600 includes determining, using the activity data, one or more risk scores for the one or more users. In various examples, risk scores indicate a degree of security risk to the tenant from actions performed by a user in using the cloud service. Risk scores can be computed for individual users … In some examples, risk scores are computed as a weight sum of risk indicators; and Paragraph [0211]: At step 612, the process 600 includes determining that a risk score for [a] user in the set of users is greater than a threshold. In various examples, the threshold can indicate activity that, when the threshold is exceeded, constitutes a security risk for the tenant. In various examples, the threshold can be associated with … a particular user); and automatically taking at least one cybersecurity action in the computing system, the at least one cybersecurity action protecting the computing system from potential harm by the human user account (Kirti – Paragraph [0212]: At step 614, the process 600 includes determining a security control for the service provider system, wherein the security control is used by the service provider system to configure access to the cloud service. The security control can depend on factors such as the action or actions performed that caused the risk score to exceed the threshold, the resource affected by the actions, threat intelligence, and/or configuration settings associated with the tenant, among other factors. Examples of security controls that can be determined include blocking a user or group of users from using the service, disabling a particular user account with the cloud service, causing the service to send alerts whenever certain users log in and/or perform certain actions, and blocking data from being uploaded to or downloaded from the service, among other controls; and Paragraph [0214]: At step 618, the process 600 includes sending the one or more instructions to the service provider system, wherein the one or more instructions cause the security control to be changed with respect to the user, wherein access to the cloud service by the user is modified due to the change to the security control. In various examples, sending the instructions can include using an authorization assigned to the tenant (e.g., a password, token, or other form of credential), which can enable the security management system to configure the cloud service on behalf of the tenant. In some examples, the instructions are sent to the service provider system for activation by the tenant or the service provider. Once executed, a security risk caused by the privileged user can be monitored, mitigated, and/or stopped).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Hecht and Sites, further incorporating Kirti to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Kirti’s teaching to calculate risk scores for individual users based on a weighted plurality of risk indicators and performing some protective responsive action into Hecht and Sites’s combined method for calculating user risk based on permissions and organizational role. Kirti’s broader risk score determination combines naturally with the more particular risk considerations of Hecht and Sites. One of ordinary skill in the art would find it obvious to factor in the teachings of Hecht and Sites with the methods of Kirti in determining reliable assessments for potential insider risks.
Regarding Claim 31:
The combination of Hecht, Sites, and Kirti teaches the computer-readable storage device of claim 27.
Sites further teaches wherein the at least one influence signal identifies a cumulative number of other human users that report to the human user associated with the human user account (Sites – Col. 20, Line 49-63 and Col. 21, Line 18-28: In some embodiments, an artificial intelligence model configured to determine a job score for a user may consider different features that relate to the user. For example in the context of the present disclosure, individual features or sets of features can be input into an artificial intelligence model … Examples of alternative or additional features that may be fed into one or more artificial intelligence models separately or in combination to determine a job score for a user or a risk score for a user include: … Depth of the user in the organization—The hierarchy above a user's position in an organization (for example a data entry user may be ten organizational levels below the CEO) or the number of people above the user in the organization (for example a user has ten managers above them). Height of the user in an organization—The hierarchy below a user's place (for example a user manages 5 levels down), or how many people are reporting to a user (for example a user manages (directly only, or directly and indirectly) 15 people on a team).
The motivation to combine the arts is the same as that of Claim 27.
Claim(s) 8 and 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hecht in view of Sites, Kirti, and Shtar et al. (US 20190028504 A1), hereinafter Shtar.
Regarding Claim 8:
The combination of Hecht, Sites, and Kirti teaches the computer-implemented method of claim 1.
Kirti further teaches wherein automatically computing the impact risk is also based on at least a cumulative potential exfiltration anomaly access signal (Kirti – Paragraph [0047]: In some examples, a cloud service can be authorized or unauthorized for use within the organization 130. An authorized service is one that the organization 130 has approved for use … An unauthorized service is one that the organization may not have specifically approved, and that a user is using at the user's own discretion. For example, a user may be using a file sharing service that the organization 130 has not specifically authorized, possibly without the organization 130 being aware that the file sharing service is being used; and Paragraph [0131]: the behavioral analytics engine 304 can include contextual data in the activity profile for a user … Examples of contextual data include … sensitive emails from email servers … contextual data can additionally or alternatively be obtained from client devices used by the user; and Paragraph [0209]: At step 610, the process 600 includes determining, using the activity data, one or more risk scores for the one or more users … risk scores are computed as a weight sum of risk indicators).
The combination of Hecht, Sites, and Kirti does not expressly teach which represents a detection of anomalous cumulative potential exfiltration of data in response to a request received from the authorized human user account.
However, Shtar teaches which represents a detection of anomalous cumulative potential exfiltration of data in response to a request received from the authorized human user account (Shtar – Paragraph [0062]: As indicated above, upon the generation of a model 170, the detection module 114 can detect suspicious accesses within data object access data 108B that may be indicative of an insider threat; and Paragraph [0063]: For example, it is possible that some of the client end stations 120 include one (or possibly multiple) malware modules that cause the client end stations 120 to participate in one (or more) botnets. In some cases, a client end station (e.g., 120A) could be infected with malware while its user (e.g., owner/operator) is unaware of the infection. Thus, the user may continue to operate their client end station in a non-malicious manner, and the client end station may act as part of a botnet (e.g., receive commands from a controller, begin transmitting malicious traffic, etc.) and perform malicious actions without the user's knowledge, perhaps even concurrently while the user is actively utilizing the client end station. Alternatively or additionally, a user may be using one or more client end stations 120 to “snoop” through the enterprise's data for malicious or non-malicious purposes. Additionally, some of these access requests 122B may be part of a large-scale data breach, where a user attempts to access a large number of data objects over time for improper purposes, such as providing information to a competitor of the organization, leaking sensitive information, exploiting sensitive organizational data, etc. Embodiments disclosed herein can identify these types of anomalous data objects accesses as being suspicious).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Hecht, Sites, and Kirti, further incorporating Shtar to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Shtar’s teaching to detect insider risk based on user requests indicating a potential or intention to leak organizational information into Hecht, Sites, and Kirti’s combined method for calculating user risk based on permissions and organizational role. This additional functionality provides a trigger for suspicious or potentially malicious activity resulting in further attention to a given user’s activity.
Regarding Claim 9:
The combination of Hecht, Sites, Kirti, and Shtar teaches the computer-implemented method of claim 8.
Shtar further teaches further comprising; detecting the anomalous cumulative potential exfiltration of data (Shtar – Paragraph [0062]: As indicated above, upon the generation of a model 170, the detection module 114 can detect suspicious accesses within data object access data 108B that may be indicative of an insider threat; and Paragraph [0063]: For example, it is possible that some of the client end stations 120 include one (or possibly multiple) malware modules that cause the client end stations 120 to participate in one (or more) botnets. In some cases, a client end station (e.g., 120A) could be infected with malware while its user (e.g., owner/operator) is unaware of the infection. Thus, the user may continue to operate their client end station in a non-malicious manner, and the client end station may act as part of a botnet (e.g., receive commands from a controller, begin transmitting malicious traffic, etc.) and perform malicious actions without the user's knowledge, perhaps even concurrently while the user is actively utilizing the client end station. Alternatively or additionally, a user may be using one or more client end stations 120 to “snoop” through the enterprise's data for malicious or non-malicious purposes. Additionally, some of these access requests 122B may be part of a large-scale data breach, where a user attempts to access a large number of data objects over time for improper purposes, such as providing information to a competitor of the organization, leaking sensitive information, exploiting sensitive organizational data, etc. Embodiments disclosed herein can identify these types of anomalous data objects accesses as being suspicious) at least in part by comparing potential exfiltration activity of the authorized human user account to first activities of a first peer group of the authorized human user account and to second activities of a second peer group of the authorized human user account (Shtar – Paragraph [0046]: Based on the analysis, a model can be generated that can identify suspicious accesses. The model can be used to identify that a request for a data object, issued on behalf of a user, is suspicious when the resource group of the data object is not within the set of resource groups of that user's user group, and is not within the set(s) of resource groups of any nearby user groups to that user's user group. Accordingly, embodiments can flexibly and dynamically detect suspicious accesses made by a user involving a resource group that is not commonly accessed by other users in that user's user group (i.e., “similar” users), and that is not commonly accessed by other users in nearby user groups).
The motivation to combine the arts is the same as that of Claim 8.
Claim(s) 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hecht in view of Sites, Kirti, and Saunders et al. (US 20120158454 A1), hereinafter Saunders.
Regarding Claim 12:
The combination of Hecht, Sites, and Kirti teaches The computer-implemented method of claim 1.
Kirti further teaches wherein further comprising marking the human user account with a potential high impact user designation based on the impact risk exceeding a specified threshold (Kirti – Paragraph [0211]: At step 612, the process 600 includes determining that a risk score for user in the set of users is greater than a threshold. In various examples, the threshold can indicate activity that, when the threshold is exceeded, constitutes a security risk for the tenant).
The combination of Hecht, Sites, and Kirti does not expressly teach and persisting the potential high impact user designation after the impact risk falls below the specified threshold.
However, Saunders teaches and persisting the potential high impact user designation after the impact risk falls below the specified threshold (Saunders – Paragraph [0036]: When correlation between the engaged activity of a HRU candidate and predetermined parameters for indicating high risk activity is made, the HRU candidate may be flagged as high risk by a HRU update module 207. In certain embodiments, the HRU update module 207 escalates the user from a candidate, where the specified HRU status on the watch list 217 is set to "FALSE," to an actual HRU, where the specified HRU status on a HRU monitor list 221 is set to "TRUE" in response to a determined correlation; and Paragraph [0051]: The risk management application 400 may also present "Establish HRU Settings" fields 415 for enabling a user to enter one or more monitoring start and end dates. The start and end data provide information for enabling the HRU event management platform 111 to determine if a candidate on the HRU monitor list 113 should be enabled or disabled. By way of example, if the current date 405 (e.g., insertion date or date of update) is determined by the HRU event management platform 111 to be set between the start date and end date, then a monitoring status 417 is enabled (e.g., set to TRUE). Alternatively, if the current date 405 (e.g., insertion date or date of update) is set outside the start date and end date, then the monitoring status 417 is disabled (e.g., set to FALSE). It is noted that the monitoring status field 417 presents the HRU status via the interface; Examiner’s Comment: the start and end dates of the monitoring status corresponding to a determination of a user as a high risk user indicates a persistence of the high risk user status despite the user’s behavior while being monitored, aligning with the description in Paragraph [0079] of the instant specification: “the method includes marking 1004 the authorized user with a potential high impact user designation 408 based on the impact risk 214 exceeding a specified threshold 430, and persisting 1016 the designation after the impact risk is below the specified threshold. In some embodiments, a user designation as an PHIU is not reversible within a timeframe defined by a policy. For instance, if the user is detected as a PHIU on day 1, and on day 3 they are no longer a PHIU, the designation is nonetheless not removed. The reason is that the user possessed the influence or access or both to cause increased harm in the time near the activity that corresponds to the designation”).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Hecht, Sites, and Kirti, further incorporating Saunders to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Saunders’s teaching to mark a user as high risk for a designated time period into Hecht, Sites, and Kirti’s method for managing insider risk in a computing system. This addition would enhance the security of the system by ensuring that inconsistent but high impact risks do not go unnoticed.
Claim(s) 26 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hecht in view of Sites, Kirti, and Fridakis (US 11651313 B1), hereinafter Fridakis.
Regarding Claim 26:
The combination of Hecht, Sites, and Kirti teaches the computing device of claim 21.
The combination of Hecht, Sites, and Kirti does not expressly teach wherein the impact risk is further calculated based at least on a response speed to access requests by the human user account when requesting to access other resources of the computing system.
However, Fridakis teaches wherein the impact risk is further calculated based at least on a response speed to access requests by the human user account when requesting to access other resources of the computing system (Fridakis – Col. 10, Line 10-52: FIG. 4 illustrates example elements of legitimate access path records which may be used to detect potential insider threats, according to at least some embodiments … In some embodiments, one or more types of access time statistics 224 may be included in the legitimate access path record—e.g., indicating the usual distribution of accesses to the artifact as a function of the time of day, or the amount of time it typically takes for an access request to be handled at various intermediaries. If the times indicated in activity log records (e.g., the time at which an access is initiated, or the time it takes to respond to a particular access request) varies substantially from the norm, this might indicate a possibility of a security attack in some embodiments).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Hecht, Sites, and Kirti, further incorporating Fridakis to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Fridakis’s consideration of unusual access request response times into Hecht, Sites, and Kirti’s combined method for calculating user risk based on permissions and organizational role. This combination enriches the dataset based on which risk can be determined.
Claim(s) 28 and 29 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hecht in view of Sites, Kirti, and Argoety et al. (US 20210120014 A1), hereinafter Argoety.
Regarding Claim 28:
The combination of Hecht, Sites, and Kirti teaches the computer-readable storage device of claim 27.
The combination of Hecht, Sites, and Kirti does not expressly teach wherein the at least one cybersecurity action comprises automatically boosting a risk score associated with a cybersecurity tool having alerting functionality.
However, Argoety teaches wherein the at least one cybersecurity action comprises automatically boosting a risk score associated with a cybersecurity tool having alerting functionality (Argoety – Paragraph [0018]: In certain embodiments, the alert management system can be configured to rank the incoming alert in relation to other alerts based on the impact scores or bias the importance scores using the impact score. For example, alerts with higher impact scores can be ranked higher than other alerts with lower impact scores. In another example, importance scores can be modified, e.g., using the impact scores as multipliers, additions, or in other suitable manners. As such, alerts associated with high impact scores can also have high modified importance scores; and Paragraph [0004]: Reviewing such large numbers of alerts for false positives or remedial actions can be labor intensive, costly, and prone to “alert fatigue.” Thus, the alerts are normally sorted, ranked, or classified according to some criteria for urgency of review by security analysts. In one example, an importance score may be calculated for each alert based on how much the detected operation deviates from a baseline value).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Hecht, Sites, and Kirti, further incorporating Argoety to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Argoety’s teaching to bias alert priority/risk scores based on scores indicating their potential system impact into Hecht, Sites, and Kirti’s combined method for calculating user risk based on permissions and organizational role. This additional functionality provides a logical weighting mechanism for prioritizing important issues configurable based on per-system or per-organization preferences.
Regarding Claim 29:
The combination of Hecht, Sites, and Kirti teaches the computer-readable storage device of claim 27.
The combination of Hecht, Sites, and Kirti does not expressly teach wherein the at least one cybersecurity action comprises prioritizing an alert directed to the human user account over another alert directed to another human user account that lacks a boosted risk score.
However, Argoety teaches wherein the at least one cybersecurity action comprises prioritizing an alert directed to the human user account over another alert directed to another human user account that lacks a boosted risk score (Argoety – Paragraph [0018]: In certain embodiments, the alert management system can be configured to rank the incoming alert in relation to other alerts based on the impact scores or bias the importance scores using the impact score. For example, alerts with higher impact scores can be ranked higher than other alerts with lower impact scores. In another example, importance scores can be modified, e.g., using the impact scores as multipliers, additions, or in other suitable manners. As such, alerts associated with high impact scores can also have high modified importance scores; and Paragraph [0048]: The determined impact score can then be used to sort, rank, or modify priority of the incoming alerts 109).
The motivation to combine the arts is the same as that of Claim 28.
Claim(s) 30 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hecht in view of Sites, Kirti, and Athavle (US 10841321 B1), hereinafter Athavle.
Regarding Claim 30:
The combination of Hecht, Sites, and Kirti teaches the computer-readable storage device of claim 27.
The combination of Hecht, Sites, and Kirti does not expressly teach wherein the at least one access signal identifies a total number of files that have been accessed by the human user account.
However, Athavle teaches wherein the at least one access signal identifies a total number of files that have been accessed by the human user account (Athavle – Col. 6, Line 45-58: The term “dynamic attributes,” as used herein, generally refers to any type or form of user characteristic that can change over time. In some examples, dynamic attributes may be based on user behavior. Examples of user behavior may include the number of files accessed by a user, the number of file permissions granted to a user, the number of file reads performed by a user, the number of file writes performed by a user, the number of files created by a user, the number of files deleted by a user, the number of file permission changes performed in connection with a user, the number of file rename operations performed by a user, the number of files to which the user has access, the number of internet protocol addresses that a user accesses, and/or the number of files that a user owns).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Hecht, Sites, and Kirti, further incorporating Athavle to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Athavle’s teaching to factor in at least a number of files accessed by a user in determining whether a user is behaving suspiciously into Hecht, Sites, and Kirti’s combined method for calculating user risk based on permissions and organizational role. This teaching adds another layer to the quantification of malicious insider risk.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Ramzan et al. (US 20200233955 A1) teaches methods for monitoring user behavior in a system and calculating a risk score that represents a predicted impact of user compromise
Gill et al. (US 10664785 B2) teaches generation of risk scores for enterprise users based on access, role, and interactive factors
McCarthy et al. (US 20220405401 A1) teaches threat management using impact scoring to prioritize attention for remediation and/or prevention
Stephens et al. (US 8707431 B2) teaches insider threat detection based on various elements of contextual information
Zimmermann et al. (US 20180027006 A1) teaches systems and methods for discovering potential insider threats based on behavioral and static user attributes
Ross et al. (US 20210168150 A1) teaches techniques for evaluating risks associated with applications that provide access/privileges/permissions
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NICHOLAS JOSEPH DILUZIO whose telephone number is (703)756-1229. The examiner can normally be reached Mon - Fri -- 7:30 AM - 5 PM.
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, Yin-Chen Shaw can be reached at 571-272-8878. 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.
/NICHOLAS JOSEPH DILUZIO/Examiner, Art Unit 2498
/YIN CHEN SHAW/Supervisory Patent Examiner, Art Unit 2498
Prosecution Insights