DETAILED ACTION
Examiner acknowledges receipt of Applicant’s amendment filed on 09/12/2025
Claims 1, 2, 5, 8, 13, and 16 are currently amended
Claims 1-20 are pending
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
Examiner has fully considered Applicant’s amendments to the Claims in the arguments filed on 09/12/2025. Claims 1-20 remain pending in the application.
Response to Arguments
Applicant’s arguments filed 09/12/2025, with respect to the 101 rejections of claims 1-20 have been fully considered, but they are not persuasive. The amended limitation “identifying the authorized user as a source of insider security risk” is an additional judicial exception, per se. The further amended portion “and automatically adjusting a cybersecurity characteristic based on at least the identifying and the computed impact risk, thereby improving cybersecurity of the computing system” suggests an improvement, but does not clearly define the claimed improvement. Regarding evaluation of improvements to the functioning of a computer/technology, MPEP 2106.04(d)(1) recites: “… if the specification explicitly sets forth an improvement but in a conclusory manner (i.e., a bare assertion of an improvement without the detail necessary to be apparent to a person of ordinary skill in the art), the examiner should not determine the claim improves technology. Second, if the specification sets forth an improvement in technology, the claim must be evaluated to ensure that the claim itself reflects the disclosed improvement. That is, the claim includes the components or steps of the invention that provide the improvement described in the specification”. Therefore, the abstract idea listed in the claim(s) cannot be considered as being integrated into a practical application by the mere statement that the cybersecurity of the system is improved. As noted in Applicant’s Remarks, claim 7 provides details describing the step of “automatically adjusting a cybersecurity characteristic”, at least one of which may reflect an apparent improvement in the functioning of a computing system. However, claim 7 is rejected due to its dependence on claim 1.
Applicant’s remarks filed 09/12/2025, with respect to the rejections of claims 1, 3-7, 10, 11, and 16-20 under 35 USC 103 have been fully considered and they are persuasive. Therefore, the rejections have been withdrawn. However, upon further consideration, new ground(s) of rejection are made in view of the previously applied reference from Kirti, in addition to a newly applied reference from Semel et al. (US 20220103592 A1), hereinafter Semel. Specifically, Semel teaches the amended limitations, the rejections of which previously relied upon the teachings of Ahmad. That is, Semel teaches “the calculating comprising calculating a weighted combination in which at least two influence signals have different respective weights”, and “the additional pillar value representing at least one of the following: an access request response speed for a request received from the authorized user to access at least one access-requested computing system resource, a public visibility of the authorized user, a measure of influence of the authorized user on a social network, or a risk of damage to a brand of an organization”.
Regarding claims 13-15, the claims do not reflect the amendments discussed in Applicant’s Remarks, and were not otherwise substantially amended. Therefore, the rejections of record to claims 13-15 are maintained herein.
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.
Claim 1 is directed to a cybersecurity insider risk management method including steps of calculating an access pillar value, calculating an influence pillar value, computing an impact risk, identifying a user as a source of insider risk, and adjusting a cybersecurity characteristic – 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 authorized user 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 computing system, an additional pillar value, and the step for adjusting the cybersecurity characteristic. The computing system is recited at a high level of generality, and thus, does not serve to integrate the abstract ideas into a practical application by mere performance of the mental processes listed above. The additional pillar value represents one of various observable user characteristics, and implies mere data gathering by the generically stated computing system. The additional adjusting step is also recited at a high level of generality and serves as insignificant extra-solution activity, which may be performed by a generic computing system. Therefore, these additional elements do not serve to integrate the abstract ideas into a practical application because they do not serve to 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 additional elements, as stated above, are recited at a high level of generality—the claim language does not meaningfully connect the abstract calculating, computing, and identifying steps to the operation of the computing system as a whole, nor to the adjusting 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 corresponding system claim 13, which includes further additional elements of a managed computing system, a resource, a digital memory, a processor, a user device/account, a computational mechanism/artifact. The active steps performed by the process of the insider risk management computing system are the same computing and adjusting steps of Claim 1. The acquisition of the access and influence pillar values are listed as mere data gathering elements which contribute to the computation of the impact risk. 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 corresponding storage device claim 16, which includes further additional elements of a computer-readable storage device, a processor, and a cloud computing environment. 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.
Claims 2-12, 14-15, and 17-20 are also rejected due to their respective dependence on claims 1, 13, and 16.
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, 3-7, 10, 11, and 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over Kirti et al. (US 20180375886 A1), hereinafter Kirti, in view of Semel et al. (US 20220103592 A1), hereinafter Semel.
Regarding Claim 1:
Kirti teaches a cybersecurity insider risk management method performed by a computing system with respect to an authorized user (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), the method comprising: automatically calculating an access pillar value based on at least one access signal (Kirti – Paragraph [0104]: the data loader application 206 can retrieve activity data for the tenant 220 from the service provider 230. The activity data can come from logs generated by the service provider 230 as the tenant's users use the service providers services. In various examples, the data loader application 206 can obtain the activity data by requesting the data from the service provider 230. The data retrieved by the data loader application 206 can be entered into a landing repository 210 and/or analytics and threat intelligence repository 211. The data entered into a landing repository 210 may be in different formats and/or have different ranges of values, due, for example, from having been collected from different service providers. In some examples, the data from the data loader application 206 can be reformatted and/or structured before being moved to the analytics and threat intelligence repository 211 so that, for example, the data has a uniform format), the access pillar value representing an access authorization of the authorized user which authorizes access to an access-authorized computing system resource (Kirti – Paragraph [0134]: Table 3 below shows example calculated statistics for some user activities. The example user activities include an average login count for a four-week window profile (“avglogcntday4wk”), an average login IP address count for a four week window profile (“avglogipcntday42k”), a standard deviation of login count for a one week window profile (“stdlogcntday 1wk”), and a standard deviation of login IP address count for a one week window profile (“stdlogipcntday1wk”). Similar and other statistics can be calculated, depending on the available data and/or the threat being predicted); automatically calculating an influence pillar value (Kirti – Paragraph [0183]: In various implementations, a security management and control system can implement techniques for identifying the privileged users of a cloud service. The activities of the privileged users can then be tracked using methods such as those discussed above, including behavioral analysis, anomaly detection, and machine learning techniques, with a higher degree of scrutiny applied that is commensurate with the greater harm that can be done should a privileged account be misused), the influence pillar value representing an extent of influence of the authorized user (Kirti – Paragraph [0184]: In various implementations, identification of privileged users can be a component of a analytics engine of a security management and control system. FIG. 4 illustrates a block diagram of a behavioral analytics engine 404, which is an example of one component of an analytics engine that can implement identification of privileged users. In various examples, the behavioral analytics engine 404 can receive activity data 410 that can include records of user activity for one cloud service or multiple cloud services. The activity data 410 can include, for example, a listing of actions performed, users that performed the action, one or more objects impacted by the action(s), contextual data such as timestamp, and/or network location from where user performed the action, among other things; and Paragraph [0186]: In various examples, the behavioral analytics engine 404 can also include a privileged user identification engine 434, which can produce a list of the privileged users 444 of a cloud service. In various examples, the privileged user identification engine 434 can use different techniques, possibly in combination, to identify the privileged users of a cloud service; and Paragraph [0188]: As a second example, the privileged user identification engine 434 can learn the identities of privileged users from service provider data 418, which is obtained from a service provider. The service provider have an API that can include functions that enable the security management and control system to request a list of privileged users of the service); automatically computing an impact risk based on at least the access pillar value, the influence pillar value, and an additional pillar value (Kirti – Paragraph [0184]: In various implementations, identification of privileged users can be a component of a analytics engine of a security management and control system. FIG. 4 illustrates a block diagram of a behavioral analytics engine 404, which is an example of one component of an analytics engine that can implement identification of privileged users. In various examples, the behavioral analytics engine 404 can receive activity data 410 that can include records of user activity for one cloud service or multiple cloud services. The activity data 410 can include, for example, a listing of actions performed, users that performed the action, one or more objects impacted by the action(s), contextual data such as timestamp, and/or network location from where user performed the action, among other things; 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, groups of uses, individual services, multiple services, services from different service providers, and/or a combination of users and services. In some examples, risk scores are computed as a weight sum of risk indicators; and Paragraph [0210]: In various examples, risk scores for users categorized as privileged are computed with greater weights than are risk scores for non-privileged users. Thus, for example, when a privileged user performs an action, the risk score for the privileged user may be higher than when a non-privileged users performs the same action. Alternatively or additionally, more or different indicators can be used to determine the risk score for privileged users than for ordinary users. Alternatively or additionally, risk scores for privileged users may be computed more frequently, or otherwise be given a higher degree of scrutiny than the risk scores of non-privileged users); identifying the authorized user as a source of insider security 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 adjusting a cybersecurity characteristic based on at least the identifying and the computed impact risk, thereby improving cybersecurity of 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).
Kirti does not expressly teach the calculating comprising calculating a weighted combination in which at least two influence signals have different respective weights; and the additional pillar value representing at least one of the following: an access request response speed for a request received from the authorized user to access at least one access-requested computing system resource, a public visibility of the authorized user, a measure of influence of the authorized user on a social network, or a risk of damage to a brand of an organization.
However, Semel teaches the calculating comprising calculating a weighted combination in which at least two influence signals have different respective weights (Semel – Paragraph [0066]-[0072]: Paragraph [0066]: Using the weights for each factor and the factor score, the risk score or value for an entity can then be computed using the equation: (Equation 00001); and Paragraphs [0067]-[0072]: Description of calculations of the functional, configurational, and behavioral factor values which contribute to the overall risk score, each factor value being a weighted sum of signals); and the additional pillar value representing at least one of the following: an access request response speed for a request received from the authorized user to access at least one access-requested computing system resource, a public visibility of the authorized user, a measure of influence of the authorized user on a social network, or a risk of damage to a brand of an organization (Semel – Paragraph [0022]: In some embodiments, an entity risk score is based on several different indicators or factors to provide more useful and actionable risk scores. To detect the different risk indicators, embodiments may use three entity characteristics; and Paragraph [0025]: (3) Behavioral Factors refers to observations regarding ‘What the entity does’—entity activity (e.g., network related activities). This can include … Internet Exposure (e.g., public Internet facing)).
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 Kirti, further incorporating Semel to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Semel’s calculation of an individual risk indicator to contribute to an overall risk score by calculating a weighted combination of sub-indicators, one of the indicators being based on at least a user’s public visibility into Kirti’s method for managing insider risk in a computing system. This combined functionality would result in a more organized and thorough approach for analyzing different risk factors contributing to an overall risk posed by each system user.
Regarding Claim 3:
The combination of Kirti and Semel teaches the method of claim 1.
Kirti further teaches wherein the at least one influence signal represents at least one of the following: a position of the authorized user within a hierarchy of at least one organization; a title or a role of the authorized user within at least one organization; a count of people who report to the authorized user within at least one organization; or an administrative role of the authorized user within a computing environment (Kirti – Paragraph [0076]: In various implementations, the information handler system 138 of the security monitoring and control system 102 manages the data in the storage 122, including, for example, storing data, locating and retrieving data, organizing data, and updating data, among other operations. In some examples, the information handler system 138 received data from users of the organization 130, such as administrative users, who can provide information such as lists of the organization's users and data about the users. The data about the users can include, for example, roles or privileges for a user. In these and other examples, the information handler system 138 can manage storing of the user data in the appropriate data store in the storage 122; and Paragraph [0186]: In various examples, the behavioral analytics engine 404 can also include a privileged user identification engine 434, which can produce a list of the privileged users 444 of a cloud service. In various examples, the privileged user identification engine 434 can use different techniques, possibly in combination, to identify the privileged users of a cloud service).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 4:
The combination of Kirti and Semel teaches the method of claim 1.
Kirti further teaches further characterized in at least one of the following ways: automatically calculating the access pillar value includes calculating a weighted combination in which at least two access signals have different respective weights; automatically computing the impact risk includes computing a weighted combination in which the pillar values have different respective weights (Kirti – Paragraph [0159]: In various examples, scores such as those illustrated above, as well as other indicators, can be used to compute a risk score, which is also referred to herein as a measure of security. In various examples, the threat detection engine 302 can compute a risk score for a user, a group or category of users, a service, and/or a service provider. A risk score can indicate a degree of security risk. For example, a scale from one to five can be defined, where a higher value indicates that a user or a service poses a higher security risk for an organization; 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, groups of uses, individual services, multiple services, services from different service providers, and/or a combination of users and services. In some examples, risk scores are computed as a weight sum of risk indicators. Risk indicators can be associated with an action that was performed, a resource that was affected by the action, particular user, a group of users, a service, a service provider, a network location where the user is located, a network location where the service provider or service is located, a geolocation, a time of day or day of the week or month of the year, another factor, or a combination of factors. Alternatively or additionally, risk indicators can come from threat intelligence obtained from external aggregators and/or distributors of network threat intelligence. In some examples, more important risk indicators are given a higher weight value).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 5:
The combination of Kirti and Semel teaches the method of claim 1.
Kirti further teaches wherein the impact risk is also automatically computed based on an additional pillar value which represents at least one of the following: an access request response speed in response to a request received from the authorized user to access at least one computing system resource; a success rate of the authorized user in receiving access to the at least one computing system resource; a membership of the authorized user in a computing system security group; a cybersecurity attack on the authorized user; an exfiltration activity of the authorized user; a public visibility of the authorized user; a measure of influence of the authorized user on a social network; a risk of damage to a brand of an organization; or a mission criticality of the at least one computing system resource that is accessible to the authorized user (Kirti – Paragraph [0129]: In various examples, the activity data 310 can be ingested in the analytics engine 300 by a behavioral analytics engine 304. In various implementations, the behavioral analytics engine 304 can collect statistics from the activity data 310 and identify behavioral characteristics from the activity data 310. Statistics can include, for example, counts of actions, such as successful login attempts or failed login attempts. In some examples, statistics can be associated with a particular service provider, a particular service, a particular user, a particular action that can be performed in using a service, a particular time frame, other factors, and/or a combination of factors; and Paragraph [0159]: In various examples, scores such as those illustrated above, as well as other indicators, can be used to compute a risk score, which is also referred to herein as a measure of security. In various examples, the threat detection engine 302 can compute a risk score for a user, a group or category of users, a service, and/or a service provider. A risk score can indicate a degree of security risk. For example, a scale from one to five can be defined, where a higher value indicates that a user or a service poses a higher security risk for an organization).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 6:
The combination of Kirti and Semel teaches the 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 Kirti and Semel teaches the method of claim 1.
Kirti further teaches wherein automatically adjusting a cybersecurity characteristic based on at least the impact risk comprises at least one of the following: automatically boosting a risk score in a cybersecurity tool which has alerting functionality; automatically disabling, automatically suspending, or automatically deleting an account in a computing environment; automatically altering membership of the authorized user in a computing system security group; automatically turning on a particular security threat detection mechanism; automatically turning off a particular security threat detection mechanism; automatically changing a particular security alert threshold; or training a machine learning model with training data, wherein at least one quarter of the training data includes at least one of the influence signals, the access signal, the pillar values, or the impact risk, as measured by data size or training data examples count or both (Kirti – Paragraph [0051]: In some implementations, the security monitoring and control system 102 can further suggestion remediation actions, and/or can automatically perform remediation actions to isolate or stop the threat; and Paragraph [0179]: In various examples, the recommendation engine 308 can also determine actions 326, including remediation actions, which the security management and control system will automatically perform. In various examples, the organization can configure to automatically perform remediation actions when the analytics engine 300 detects certain security events. Examples of remediation actions include deactivating an account, resetting a password, or setting stronger security controls, among others).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 10:
The combination of Kirti and Semel teaches the method of claim 1.
Kirti further teaches further comprising calculating a weighted combination based on at least a mean risk score for a signal or a pillar, and a distance from the mean risk score (Kirti – Paragraph [0134]: Table 3 below shows example calculated statistics for some user activities. The example user activities include an average login count for a four week window profile (“avglogcntday4wk”), an average login IP address count for a four week window profile (“avglogipcntday42k”), a standard deviation of login count for a one week window profile (“stdlogcntday 1wk”), and a standard deviation of login IP address count for a one week window profile (“stdlogipcntday1wk”). Similar and other statistics can be calculated, depending on the available data and/or the threat being predicted; and Paragraph [0144]: Algorithm 2 is an example of an algorithm that can be used to detect failed login IP address variations. Z-Scores may be calculated for a login IP address feature vector over different time periods, here illustrated as one week, four weeks, and eight weeks, as an example; and Paragraph [0145]: The Z-scores for the failed login IP addresses may be combined with weights (w1 . . . w3) assigned to each score).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 11:
The combination of Kirti and Semel teaches the method of claim 1.
Kirti further teaches further comprising imposing role-based access control on a request to view the impact risk (Kirti – Paragraph [0085]: 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); and Paragraph [0159]: In various examples, scores such as those illustrated above, as well as other indicators, can be used to compute a risk score, which is also referred to herein as a measure of security. In various examples, the threat detection engine 302 can compute a risk score for a user, a group or category of users, a service, and/or a service provider. A risk score can indicate a degree of security risk. For example, a scale from one to five can be defined, where a higher value indicates that a user or a service poses a higher security risk for an organization).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 16:
Kirti teaches a computer-readable storage device configured with data and instructions which upon execution by a processor cause a computing system (Kirti – Paragraph [0026]: The processes depicted herein, such as those described with reference to the figures in this disclosure, may be implemented in software (e.g., code, instructions, program) executed by one or more processing units (e.g., processors cores), hardware, or combinations thereof. The software may be stored in a memory (e.g., on a memory device, on a non-transitory computer-readable storage medium)) to perform a method in a cloud computing environment (Kirti – Paragraph [0008]: Provided are systems, methods, and computer-readable medium that enable a security management system to identity the privileged users of a cloud service. In various implementations, the security management system can include techniques for identifying privileged users of a cloud service, where the techniques include performing various steps. The steps can include obtaining activity data from a service provider system. The activity data can describe actions performed during use of a cloud service. The actions can be performed by one or more users associated with a tenant, where the service provider system provides the tenant with a tenant account. The tenant account enables the one or more users to access the cloud service. The steps can further include identifying, in the activity data, one or more actions that are privileged with respect to the cloud service), the method comprising: automatically calculating an access pillar value based on at least one access signal (Kirti – Paragraph [0104]: the data loader application 206 can retrieve activity data for the tenant 220 from the service provider 230. The activity data can come from logs generated by the service provider 230 as the tenant's users use the service providers services. In various examples, the data loader application 206 can obtain the activity data by requesting the data from the service provider 230. The data retrieved by the data loader application 206 can be entered into a landing repository 210 and/or analytics and threat intelligence repository 211. The data entered into a landing repository 210 may be in different formats and/or have different ranges of values, due, for example, from having been collected from different service providers. In some examples, the data from the data loader application 206 can be reformatted and/or structured before being moved to the analytics and threat intelligence repository 211 so that, for example, the data has a uniform format), the access pillar value representing an access authorization of the authorized user which authorizes access to a computing system resource (Kirti – Paragraph [0134]: Table 3 below shows example calculated statistics for some user activities. The example user activities include an average login count for a four week window profile (“avglogcntday4wk”), an average login IP address count for a four week window profile (“avglogipcntday42k”), a standard deviation of login count for a one week window profile (“stdlogcntday 1wk”), and a standard deviation of login IP address count for a one week window profile (“stdlogipcntday1wk”). Similar and other statistics can be calculated, depending on the available data and/or the threat being predicted); automatically calculating an influence pillar value based on at least one influence signal (Kirti – Paragraph [0183]: In various implementations, a security management and control system can implement techniques for identifying the privileged users of a cloud service. The activities of the privileged users can then be tracked using methods such as those discussed above, including behavioral analysis, anomaly detection, and machine learning techniques, with a higher degree of scrutiny applied that is commensurate with the greater harm that can be done should a privileged account be misused), the influence pillar value representing an extent of influence of the authorized user (Kirti – Paragraph [0184]: In various implementations, identification of privileged users can be a component of a analytics engine of a security management and control system. FIG. 4 illustrates a block diagram of a behavioral analytics engine 404, which is an example of one component of an analytics engine that can implement identification of privileged users. In various examples, the behavioral analytics engine 404 can receive activity data 410 that can include records of user activity for one cloud service or multiple cloud services. The activity data 410 can include, for example, a listing of actions performed, users that performed the action, one or more objects impacted by the action(s), contextual data such as timestamp, and/or network location from where user performed the action, among other things; and Paragraph [0186]: In various examples, the behavioral analytics engine 404 can also include a privileged user identification engine 434, which can produce a list of the privileged users 444 of a cloud service. In various examples, the privileged user identification engine 434 can use different techniques, possibly in combination, to identify the privileged users of a cloud service; and Paragraph [0188]: As a second example, the privileged user identification engine 434 can learn the identities of privileged users from service provider data 418, which is obtained from a service provider. The service provider have an API that can include functions that enable the security management and control system to request a list of privileged users of the service); automatically computing an impact risk based on at least the pillar values (Kirti – Paragraph [0184]: In various implementations, identification of privileged users can be a component of a analytics engine of a security management and control system. FIG. 4 illustrates a block diagram of a behavioral analytics engine 404, which is an example of one component of an analytics engine that can implement identification of privileged users. In various examples, the behavioral analytics engine 404 can receive activity data 410 that can include records of user activity for one cloud service or multiple cloud services. The activity data 410 can include, for example, a listing of actions performed, users that performed the action, one or more objects impacted by the action(s), contextual data such as timestamp, and/or network location from where user performed the action, among other things; 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, groups of uses, individual services, multiple services, services from different service providers, and/or a combination of users and services. In some examples, risk scores are computed as a weight sum of risk indicators; and Paragraph [0210]: In various examples, risk scores for users categorized as privileged are computed with greater weights than are risk scores for non-privileged users. Thus, for example, when a privileged user performs an action, the risk score for the privileged user may be higher than when a non-privileged users performs the same action. Alternatively or additionally, more or different indicators can be used to determine the risk score for privileged users than for ordinary users. Alternatively or additionally, risk scores for privileged users may be computed more frequently, or otherwise be given a higher degree of scrutiny than the risk scores of non-privileged users); and automatically adjusting a cybersecurity characteristic based on at least the impact risk, thereby improving cybersecurity of the computing system (Kirti – Paragraph [0213]: At step 616, the process 600 includes determining one or more instructions to send to the service provider system. In various examples, the instructions can be determined by querying the service provider to request the appropriate instructions to accomplish a desired configuration. In these examples, a computing system can include automated programs for performing the queries. As another example, the instructions can be determined from an API of the cloud service, where the API can include operations that enable a computing system to modify the configuration of the cloud service; 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).
Kirti does not expressly teach and wherein the impact risk is also automatically computed based on an additional pillar value which represents at least one of the following: an access request response speed in response to the request by the authorized user to access the computing system resource; a public visibility of the authorized user; a measure of influence of the authorized user on a social network; or a risk of damage to a brand of an organization.
However, Semel teaches and wherein the impact risk is also automatically computed based on an additional pillar value which represents at least one of the following: an access request response speed in response to the request by the authorized user to access the computing system resource; a public visibility of the authorized user; a measure of influence of the authorized user on a social network; or a risk of damage to a brand of an organization (Semel – Paragraph [0022]: In some embodiments, an entity risk score is based on several different indicators or factors to provide more useful and actionable risk scores. To detect the different risk indicators, embodiments may use three entity characteristics; and Paragraph [0025]: (3) Behavioral Factors refers to observations regarding ‘What the entity does’—entity activity (e.g., network related activities). This can include … Internet Exposure (e.g., public Internet facing)).
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 Kirti, further incorporating Semel to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Semel’s calculation of an individual risk indicator to contribute to an overall risk score by calculating a weighted combination of sub-indicators, one of the indicators being based on at least a user’s public visibility into Kirti’s method for managing insider risk in a computing system. This combined functionality would result in a more organized and thorough approach for analyzing different risk factors contributing to an overall risk posed by each system user.
Regarding Claim 17:
The combination of Kirti and Semel teaches the computer-readable storage device of claim 16.
Kirti further teaches wherein automatically computing the impact risk comprises computing a weighted combination in which the pillar values have different respective weights (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. 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, groups of uses, individual services, multiple services, services from different service providers, and/or a combination of users and services. In some examples, risk scores are computed as a weight sum of risk indicators. Risk indicators can be associated with an action that was performed, a resource that was affected by the action, particular user, a group of users, a service, a service provider, a network location where the user is located, a network location where the service provider or service is located, a geolocation, a time of day or day of the week or month of the year, another factor, or a combination of factors. Alternatively or additionally, risk indicators can come from threat intelligence obtained from external aggregators and/or distributors of network threat intelligence. In some examples, more important risk indicators are given a higher weight value).
The motivation to combine the arts is the same as that of Claim 16.
Regarding Claim 18:
The combination of Kirti and Semel teaches the computer-readable storage device of claim 16.
Kirti further teaches wherein the impact risk is also automatically computed based on at least two additional pillar values which each respectively represents at least one of the following: an access request response speed in response to a request received from by the authorized user to access at least one computing system resource; a success rate of the authorized user in receiving access to at least one computing system resource; a membership of the authorized user in a computing system security group; a cybersecurity attack on the authorized user; a public visibility of the authorized user; a measure of influence of the authorized user on a social network; a risk of damage to a brand of an organization; or a mission criticality of at least one computing system resource that is accessible to the authorized user (Kirti – Paragraph [0129]: In various examples, the activity data 310 can be ingested in the analytics engine 300 by a behavioral analytics engine 304. In various implementations, the behavioral analytics engine 304 can collect statistics from the activity data 310 and identify behavioral characteristics from the activity data 310. Statistics can include, for example, counts of actions, such as successful login attempts or failed login attempts.; and Paragraph [0093]: In various implementations, the analytics visualization console 216 can display security indicators in a library format with risk factors that are color coded (such as red, green, yellow). Other statistics or metrics may be displayed such as, for example, user logins attempts, groups with the most newly added users, deleted files, users with the most deleted files, and/or users downloading the most files, among other metrics; and Paragraph [0159]: In various examples, scores such as those illustrated above, as well as other indicators, can be used to compute a risk score, which is also referred to herein as a measure of security. In various examples, the threat detection engine 302 can compute a risk score for a user, a group or category of users, a service, and/or a service provider. A risk score can indicate a degree of security risk. For example, a scale from one to five can be defined, where a higher value indicates that a user or a service poses a higher security risk for an organization).
The motivation to combine the arts is the same as that of Claim 16.
Regarding Claim 19:
The combination of Kirti and Semel teaches the computer-readable storage device of claim 16.
Kirti further teaches wherein the impact risk is also automatically computed based on at least an additional pillar value which represents an exfiltration activity of the authorized user (Kirti – Paragraph [0047]: For example, the service provider 110 can be categorized by the service provider 110 as a “trusted” service provider. In some examples, the organization 130 can categorize other service providers as “untrusted,” or categorize all service providers that are not on the trusted list as untrusted. 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 [0160]: Indicators used to compute a risk score can provide a particular risk factor, also in the form of a score. For example, an outcome of anomaly detection can include an indicator in the form of a score that indicates a degree of deviation from the norm and/or a degree of risk the anomaly poses to the organization. In some examples, each anomaly associated with the same user or the same service can be used as a separate indicator. In various examples, other indicators that can be used to compute a risk score can be associated with a user, a service, a service provider, a geolocation where the user appears to be located, a domain where the user appears to be located, a time of day or day of the week or time of the year, or another factor).
The motivation to combine the arts is the same as that of Claim 16.
Regarding Claim 20:
The combination of Kirti and Semel teaches the computer-readable storage device of claim 16.
Kirti further teaches wherein automatically adjusting the cybersecurity characteristic based on at least the impact risk comprises at least one of the following: automatically boosting a risk score in a cybersecurity tool which has alerting functionality; automatically altering membership of the authorized user in a computing system security group; or automatically changing a particular security alert threshold (Kirti – Paragraph [0051]: In some implementations, the security monitoring and control system 102 can further suggestion remediation actions, and/or can automatically perform remediation actions to isolate or stop the threat; and Paragraph [0176]: In some examples, when the network administrators of an organization receive alerts 322, the network administrators may take remediation actions from within the organization's network. In these examples, the security management and control system may maintain an alert in an “open” state until the network administrators repot that the alert can be closed; and Paragraph [0143]: An anomaly condition in the variation in login IP addresses may be defined as L_Combined>T where T is a threshold. The threshold can be determined from previous data and/or can be modified over time).
The motivation to combine the arts is the same as that of Claim 16.
Claim(s) 2 is rejected under 35 U.S.C. 103 as being unpatentable over Kirti, Semel, and Hildebrand et al. (US 20080288330 A1), hereinafter Hildebrand.
Regarding Claim 2:
The combination of Kirti and Semel teaches the method of claim 1.
The combination of Kirti and Semel does not expressly teach wherein the at least one access signal represents at least one of the following: a count of at least one computing system resource which is accessed in response to a request received from the authorized user; a count of the at least one computing system resource which the authorized user is authorized to access; a count of the at least one computing system resource of a specified sensitivity which have been accessed in response to a request received from the authorized user; or a count of the at least one computing system resource of a specified sensitivity which the authorized user is authorized to access.
However, Hildebrand teaches wherein the at least one access signal represents at least one of the following: a count of at least one computing system resource which is accessed in response to a request received from the authorized user; a count of the at least one computing system resource which the authorized user is authorized to access; a count of the at least one computing system resource of a specified sensitivity which have been accessed in response to a request received from the authorized user; or a count of the at least one computing system resource of a specified sensitivity which the authorized user is authorized to access (Hildebrand – Paragraph [0050]: Users 111 may have various roles, job functions, responsibilities, etc. to perform within various processes associated with enterprise 100. To accomplish their responsibilities, users 111 may have entitlements to access resources 102 which may give rise to risk of negligent or malicious use of resources 102; and Paragraph [0052]: To accomplish different functions, different users 111 may have differing access entitlements to differing resources 102. Some access entitlements may allow particular users 111 to obtain, enter, manipulate, etc. information in resources 102 which may be relatively innocuous. Some access entitlements may allow particular users 111 to manipulate information in resources 102 which might be relatively sensitive; and Paragraph [0080]: Some embodiments can use three types of scores to measure access risk: baseline access risk (BAR) scores, compensating access risk factor (CARF) scores, and composite access risk scores (CARS); and Paragraph [0082]: BAR subcomponent scores can be determined using data mined from the IT environment of enterprise 100. Job function access risk can be determined by roles 504 that user 111 plays within enterprise 100 based on access entitlements 506 associated with those roles 504. Entitlement access risk can be determined by the number and type of access entitlements 408 held by user 111 that do not map to roles 504 or to job functions held by user 111 (extra entitlements)).
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 Kirti and Semel, further incorporating Hildebrand to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Hildebrand’s teaching of an evaluation of user access risk including at least a count of resources that user has access to into Kirti and Semel’s method for managing insider risk in a computing system. This combined functionality would enhance the precision of the impact risk assessment taught by Kirti and Semel.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Kirti in view of Semel and Hurley et al. (US 20080195407 A1), hereinafter Hurley.
Regarding Claim 8:
The combination of Kirti and Semel teaches the method of claim 1.
Kirti further teaches impact risk (Kirti – Paragraph [0160]: Indicators used to compute a risk score can provide a particular risk factor, also in the form of a score. For example, an outcome of anomaly detection can include an indicator in the form of a score that indicates a degree of deviation from the norm and/or a degree of risk the anomaly poses to the organization. In some examples, each anomaly associated with the same user or the same service can be used as a separate indicator. In various examples, other indicators that can be used to compute a risk score can be associated with a user, a service, a service provider, a geolocation where the user appears to be located, a domain where the user appears to be located, a time of day or day of the week or time of the year, or another factor); exfiltration anomaly access signal which represents a detection of anomalous cumulative
potential exfiltration of data in response to the request received from the authorized user (Kirti – Paragraph [0047]: Approval can include, for example, vetting the service through a certification process to ensure the service is secure, establishing a service contract with the service provider 110, placing the service provider 110 on a list of approved service providers, identifying the service provider 110 as a well-known and trusted service provider, and/or controlling the generation of user accounts with the service for the users of the organization 130, among other activities. For example, the service provider 110 can be categorized by the service provider 110 as a “trusted” service provider. In some examples, the organization 130 can categorize other service providers as “untrusted,” or categorize all service providers that are not on the trusted list as untrusted. 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).
The combination of Kirti and Semel does not expressly teach wherein automatically computing the impact risk is also based on at least a cumulative potential exfiltration anomaly access signal which represents a detection of anomalous cumulative potential exfiltration of data in response to the request received from the authorized user.
However, Hurley teaches wherein automatically computing the impact risk is also based on at least a cumulative [potential exfiltration anomaly access] signal [which represents a detection of anomalous cumulative potential exfiltration of data in response to the request received from the authorized user] (Hurley – Paragraph [0024]: Preferably, said risk threshold is operable as an upper limit to be approached by a risk value accumulator operating additively using one or more said element risk values); and Paragraph [0057]: Thus, the method or operation of the logic arrangement commences at START step 300. At step 302, the system is queried to discover new or added elements. In the first instance, all elements of the system are discovered in step 302. At step 304, the elements are analyzed to determine their intrinsic and dependency risk values, and at step 306, each element is assigned an element risk value. At step 308, the or each domain is assigned a domain risk quantum. If it is determined at test step 310 that the incorporation of an element in the domain would cause the domain risk threshold to be exceeded, a new domain is created at step 314 and the element, with its risk value, is incorporated in that domain. If incorporation of the element in the existing domain would not cause the domain risk threshold to be exceeded, the element, with its risk value, is incorporated in the existing domain at step 312. The method or operation of the logic arrangement concludes at END step 316).
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 Kirti and Semel, further incorporating Hurley to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Hurley’s teaching to evaluate overall risk by considering cumulative values representing risk factors into Kirti and Semel’s combined method for managing insider risk in a computing system. This combination would enhance the method by establishing a capability to consider a combination of many risk factors in determining an ultimate risk level.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Kirti, in view of Semel, Hurley, and Thomas (US 20190318109 A1), hereinafter Thomas.
Regarding Claim 9:
The combination of Kirti, Semel, and Hurley teaches the method of claim 8.
Kirti further teaches further comprising detecting the anomalous cumulative potential exfiltration of data (Kirti – Paragraph [0047]: Approval can include, for example, vetting the service through a certification process to ensure the service is secure, establishing a service contract with the service provider 110, placing the service provider 110 on a list of approved service providers, identifying the service provider 110 as a well-known and trusted service provider, and/or controlling the generation of user accounts with the service for the users of the organization 130, among other activities. For example, the service provider 110 can be categorized by the service provider 110 as a “trusted” service provider. In some examples, the organization 130 can categorize other service providers as “untrusted,” or categorize all service providers that are not on the trusted list as untrusted. 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).
The combination of Kirti, Semel, and Hurley does not expressly teach at least in part by comparing potential exfiltration activity of the authorized user to first activities of a first peer group of the authorized user and to second activities of a second peer group of the authorized user.
However, Thomas teaches at least in part by comparing potential exfiltration activity of the authorized user to first activities of a first peer group of the authorized user and to second activities of a second peer group of the authorized user (Thomas – Paragraph [0036]: In an embodiment, the security management facility 122 may provide for email security and control, for example to target spam, viruses, spyware and phishing, to control email content, and the like. Email security and control may protect against inbound and outbound threats, protect email infrastructure, prevent data leakage, provide spam filtering, and more. Aspects of the email security and control may be provided, for example, in the security agent of an endpoint 12, in a wireless access point 11 or firewall 10, as part of application protection 150 provided by the cloud, and so on; and Paragraph [0077]: In embodiments, events are continuously analyzed against a baseline. The baseline may be adjusted to account for normal behavior. Comparison to baselines may include looking for outliers and anomalies as well as impossible events. For example, if a user logs on from Germany and then logs in from San Francisco, that may be considered impossible. Comparisons may be made at different levels. For example, the entity may be compared to itself e.g., does this user on Monday compare to past activity. For example, the entity may be compared to its peer group, e.g., is a finance department member behaving similar to others. For example, the entity may be compared to other entities within the enterprise. For example, the entity may be compared to other users at similar enterprises in the same industry, or in the same location, as well as to the universe of all users; and Paragraph [0078]: Real-time and retrospective threat intelligence may also be included, as well as vulnerability information and patch information; and Paragraph [0079]: With a sufficient level of confidence in the inferences, active, adaptive responses may be taken. For example, policies may be updated to better fit the security profile to the environment that has been discovered and observed).
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 Kirti, Semel, and Hurley, further incorporating Thomas to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Thomas’s teaching detect anomalies in user behavior based on expected behaviors based on group activity into Kirti, Semel, and Hurley’s combined method for managing insider risk in a computing system. This combination enhances the method by providing an additional approach to detecting abnormal user activity.
Claim(s) 12 is rejected under 35 U.S.C. 103 as being unpatentable over Kirti, Semel, and Saunders et al. (US 20120158454 A1), hereinafter Saunders.
Regarding Claim 12:
The combination of Kirti and Semel teaches the method of claim 1.
Kirti further teaches further comprising marking the authorized user 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 Kirti and Semel does not express teach and persisting the potential high impact user designation after the impact risk is below the specified threshold.
However, Saunders teaches and persisting the potential high impact user designation after the impact risk is 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 Kirti and Semel, 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 Kirti and Semel’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) 13-15 are rejected under 35 U.S.C. 103 as being unpatentable over Kirti in view of Hildebrand.
Regarding Claim 13:
Kirti teaches an insider risk management computing system which is configured to manage insider risks to a managed computing system that contains a managed resource (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. Metrics can include, for example, an usually high use of corporate resources such as a high number of downloads and/or an employee with a low rating downloading or sharing an unusually high number of files/folders, deleting code from a source code control system, or downloading, deleting, or modifying customer information, among other things), the insider risk management computing system comprising: a digital memory, at least a portion of the digital memory being external to the managed computing system (Kirti – Paragraph [0055]: In various implementations, the security monitoring and control system 102 may include at least one memory, one or more processing units (e.g., processor(s)), and/or storage. The processing unit(s) can be implemented as appropriate in hardware (e.g., integrated circuits), computer-executable instructions, firmware, or combinations of hardware and instructions. In some examples, the security monitoring and control system 102 can include several subsystems and/or modules. The subsystems and/or modules in the security monitoring and control system 102 may be implemented in hardware, software (e.g., program code or instructions executable by a processor) executing on hardware, or combinations thereof. In some examples, the software can be stored in a memory (e.g., a non-transitory computer-readable medium), on a memory device, or some other physical memory, and may be executed by one or more processing units (e.g., one or more processors, one or more processor cores, one or more Graphics Process Units (GPUs), etc.). Computer-executable instructions or firmware implementations of the processing unit(s) can include computer-executable or machine-executable instructions written in any suitable programming language, which can perform the various operations, functions, methods, and/or processes described herein. The memory may store program instructions that are loadable and executable on the processing unit(s), as well as data generated during the execution of these programs. The memory may be volatile (such as random access memory (RAM)) and/or non-volatile (such as read-only memory (ROM), flash memory, etc.); and Paragraph [0265]: Together and, optionally, in combination with the system memory 910, the computer-readable storage media 922 may comprehensively represent remote, local, fixed, and/or removable storage devices plus storage media for storing computer-readable information); a processor in operable communication with the digital memory, the processor configured to perform insider risk management operations including automatically (Kirti – Paragraph [0055]: In various implementations, the security monitoring and control system 102 may include at least one memory, one or more processing units (e.g., processor(s)), and/or storage. The processing unit(s) can be implemented as appropriate in hardware (e.g., integrated circuits), computer-executable instructions, firmware, or combinations of hardware and instructions. In some examples, the security monitoring and control system 102 can include several subsystems and/or modules. The subsystems and/or modules in the security monitoring and control system 102 may be implemented in hardware, software (e.g., program code or instructions executable by a processor) executing on hardware, or combinations thereof. In some examples, the software can be stored in a memory (e.g., a non-transitory computer-readable medium), on a memory device, or some other physical memory, and may be executed by one or more processing units (e.g., one or more processors, one or more processor cores, one or more Graphics Process Units (GPUs), etc.). Computer-executable instructions or firmware implementations of the processing unit(s) can include computer-executable or machine-executable instructions written in any suitable programming language, which can perform the various operations, functions, methods, and/or processes described herein. The memory may store program instructions that are loadable and executable on the processing unit(s), as well as data generated during the execution of these programs. The memory may be volatile (such as random access memory (RAM)) and/or non-volatile (such as read-only memory (ROM), flash memory, etc.): computing an impact risk of an authorized user of the managed computing system, and adjusting a cybersecurity characteristic of the managed computing system based on at least the impact risk (Kirti – Paragraph [0184]: In various implementations, identification of privileged users can be a component of a analytics engine of a security management and control system. FIG. 4 illustrates a block diagram of a behavioral analytics engine 404, which is an example of one component of an analytics engine that can implement identification of privileged users. In various examples, the behavioral analytics engine 404 can receive activity data 410 that can include records of user activity for one cloud service or multiple cloud services. The activity data 410 can include, for example, a listing of actions performed, users that performed the action, one or more objects impacted by the action(s), contextual data such as timestamp, and/or network location from where user performed the action, among other things; 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, groups of uses, individual services, multiple services, services from different service providers, and/or a combination of users and services. In some examples, risk scores are computed as a weight sum of risk indicators. Risk indicators can be associated with an action that was performed, a resource that was affected by the action, particular user, a group of users, a service, a service provider, a network location where the user is located, a network location where the service provider or service is located, a geolocation, a time of day or day of the week or month of the year, another factor, or a combination of factors; and Paragraph [0210]: In various examples, risk scores for users categorized as privileged are computed with greater weights than are risk scores for non-privileged users. Thus, for example, when a privileged user performs an action, the risk score for the privileged user may be higher than when a non-privileged users performs the same action. Alternatively or additionally, more or different indicators can be used to determine the risk score for privileged users than for ordinary users; and Paragraph [0213]: At step 616, the process 600 includes determining one or more instructions to send to the service provider system. In various examples, the instructions can be determined by querying the service provider to request the appropriate instructions to accomplish a desired configuration. In these examples, a computing system can include automated programs for performing the queries. As another example, the instructions can be determined from an API of the cloud service, where the API can include operations that enable a computing system to modify the configuration of the cloud service; 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); wherein the authorized user of the managed computing system includes at least one of: a user device within the managed computing system, a user account within the managed computing system, a computational mechanism within the managed computing system, or a computational artifact within the managed computing system (Kirti – Paragraph [0041]: For example, in the example of FIG. 1, the resources of the organization 130 include an enterprise network 104 and a number of client devices 106a-106c. The client devices 106a-106c can include, for example, desktop computers, laptop computers, smartphones, tablets, and other computing devices. In some examples, the client devices 106a-106c can be personally owned by employees of the organization 130, but while these devices are connected to the enterprise network 104, the devices are administered by the organization 130. The enterprise network 104 can also include other computing devices, such as servers, printers, routers, switches, and other network devices); wherein the impact risk includes a digital value which represents an impact of unauthorized activity of the authorized user or future unauthorized activity of the authorized user or both (Kirti – Paragraph [0047]: For example, the service provider 110 can be categorized by the service provider 110 as a “trusted” service provider. In some examples, the organization 130 can categorize other service providers as “untrusted,” or categorize all service providers that are not on the trusted list as untrusted. 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 [0160]: Indicators used to compute a risk score can provide a particular risk factor, also in the form of a score. For example, an outcome of anomaly detection can include an indicator in the form of a score that indicates a degree of deviation from the norm and/or a degree of risk the anomaly poses to the organization. In some examples, each anomaly associated with the same user or the same service can be used as a separate indicator. In various examples, other indicators that can be used to compute a risk score can be associated with a user, a service, a service provider, a geolocation where the user appears to be located, a domain where the user appears to be located, a time of day or day of the week or time of the year, or another factor), the impact risk is computed based on at least an authorized user access pillar value and an authorized user influence pillar value (Kirti – Paragraph [0184]: In various implementations, identification of privileged users can be a component of a analytics engine of a security management and control system. FIG. 4 illustrates a block diagram of a behavioral analytics engine 404, which is an example of one component of an analytics engine that can implement identification of privileged users. In various examples, the behavioral analytics engine 404 can receive activity data 410 that can include records of user activity for one cloud service or multiple cloud services. The activity data 410 can include, for example, a listing of actions performed, users that performed the action, one or more objects impacted by the action(s), contextual data such as timestamp, and/or network location from where user performed the action, among other things; 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, groups of uses, individual services, multiple services, services from different service providers, and/or a combination of users and services. In some examples, risk scores are computed as a weight sum of risk indicators; and Paragraph [0210]: In various examples, risk scores for users categorized as privileged are computed with greater weights than are risk scores for non-privileged users. Thus, for example, when a privileged user performs an action, the risk score for the privileged user may be higher than when a non-privileged users performs the same action. Alternatively or additionally, more or different indicators can be used to determine the risk score for privileged users than for ordinary users. Alternatively or additionally, risk scores for privileged users may be computed more frequently, or otherwise be given a higher degree of scrutiny than the risk scores of non-privileged users), the authorized user influence pillar value represents an extent of influence of the authorized user within the managed computing system or within an organization which utilizes the managed computing system, or both (Kirti – Paragraph [0183]: In various implementations, a security management and control system can implement techniques for identifying the privileged users of a cloud service. The activities of the privileged users can then be tracked using methods such as those discussed above, including behavioral analysis, anomaly detection, and machine learning techniques, with a higher degree of scrutiny applied that is commensurate with the greater harm that can be done should a privileged account be misused); and Paragraph [0184]: In various implementations, identification of privileged users can be a component of a analytics engine of a security management and control system. FIG. 4 illustrates a block diagram of a behavioral analytics engine 404, which is an example of one component of an analytics engine that can implement identification of privileged users. In various examples, the behavioral analytics engine 404 can receive activity data 410 that can include records of user activity for one cloud service or multiple cloud services. The activity data 410 can include, for example, a listing of actions performed, users that performed the action, one or more objects impacted by the action(s), contextual data such as timestamp, and/or network location from where user performed the action, among other things; and Paragraph [0186]: In various examples, the behavioral analytics engine 404 can also include a privileged user identification engine 434, which can produce a list of the privileged users 444 of a cloud service. In various examples, the privileged user identification engine 434 can use different techniques, possibly in combination, to identify the privileged users of a cloud service; and Paragraph [0188]: As a second example, the privileged user identification engine 434 can learn the identities of privileged users from service provider data 418, which is obtained from a service provider. The service provider have an API that can include functions that enable the security management and control system to request a list of privileged users of the service), and the authorized user access pillar value represents an extent of authorized access to the managed computing system resource in response to a request received from the authorized user (Kirti – Paragraph [0104]: the data loader application 206 can retrieve activity data for the tenant 220 from the service provider 230. The activity data can come from logs generated by the service provider 230 as the tenant's users use the service providers services. In various examples, the data loader application 206 can obtain the activity data by requesting the data from the service provider 230; and Paragraph [0134]: Table 3 below shows example calculated statistics for some user activities. The example user activities include an average login count for a four week window profile (“avglogcntday4wk”), an average login IP address count for a four week window profile (“avglogipcntday42k”), a standard deviation of login count for a one week window profile (“stdlogcntday 1wk”), and a standard deviation of login IP address count for a one week window profile (“stdlogipcntday1wk”). Similar and other statistics can be calculated, depending on the available data and/or the threat being predicted).
Kirti does not expressly teach and wherein the authorized user access pillar value is calculated from at least one of the following: a count of at least one computing system resource the authorized user is authorized to access; a count of the at least one computing system resource of a specified sensitivity which has been accessed in response to the request received from the authorized user; or a count of the at least one computing system resource of a specified sensitivity which the authorized user is authorized to access.
However, Hildebrand teaches and wherein the authorized user access pillar value is calculated from at least one of the following: a count of at least one computing system resource the authorized user is authorized to access; a count of the at least one computing system resource of a specified sensitivity which has been accessed in response to the request received from the authorized user; or a count of the at least one computing system resource of a specified sensitivity which the authorized user is authorized to access (Hildebrand – Paragraph [0050]: Users 111 may have various roles, job functions, responsibilities, etc. to perform within various processes associated with enterprise 100. To accomplish their responsibilities, users 111 may have entitlements to access resources 102 which may give rise to risk of negligent or malicious use of resources 102; and Paragraph [0052]: To accomplish different functions, different users 111 may have differing access entitlements to differing resources 102. Some access entitlements may allow particular users 111 to obtain, enter, manipulate, etc. information in resources 102 which may be relatively innocuous. Some access entitlements may allow particular users 111 to manipulate information in resources 102 which might be relatively sensitive; and Paragraph [0060]: an entitlement can designate that a particular user 111 has access to a particular resource 102; and Paragraph [0080]: Some embodiments can use three types of scores to measure access risk: baseline access risk (BAR) scores, compensating access risk factor (CARF) scores, and composite access risk scores (CARS); and Paragraph [0082]: BAR subcomponent scores can be determined using data mined from the IT environment of enterprise 100. Job function access risk can be determined by roles 504 that user 111 plays within enterprise 100 based on access entitlements 506 associated with those roles 504. Entitlement access risk can be determined by the number and type of access entitlements 408 held by user 111 that do not map to roles 504 or to job functions held by user 111 (extra entitlements)).
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 Kirti, further incorporating Hildebrand to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Hildebrand’s teaching of an evaluation of user access risk including at least a count of resources that user has access to into Kirti and Semel’s method for managing insider risk in a computing system. This combined functionality would enhance the precision of the impact risk assessment taught by Kirti.
Regarding Claim 14:
The combination of Kirti and Hildebrand teaches the insider risk management computing system of claim 13.
Kirti further teaches in combination with the managed computing system (Kirti – Paragraph [0088]: FIG. 2 illustrates a block diagram of an example cloud security system 200 that can be implemented by a security management and control system. In various implementations, the example cloud security system 200 can conduct network threat analysis for a tenant 220 of a service provider 230, and determine whether actions by users of the tenant 220 in using a service of the service provider 230 constitute a network threat. In various implementations, the cloud security system 200 can include user interface components 215 for interfacing with a tenant 220 and provider interface components 201 for interfacing with a service provider 230. On the back end, the cloud security system 200 can include various applications for conducting analytics and data stores for storing data used in the analytics; and Paragraph [0089]: In the context of the example of FIG. 2, the tenant 220 is a tenant of the service provider 230, meaning that the tenant 220 is using a service of the service provider 230. When the cloud security system 200 is provided as a cloud service, the tenant 220 can also be a tenant of the cloud security system 200, n that the tenant 220 is using the services of the cloud security system 200).
The motivation to combine the arts is the same as that of Claim 13.
Regarding Claim 15:
The combination of Kirti and Hildebrand teaches the insider risk management computing system of claim 13.
Kirti further teaches wherein the managed computing system contains a security control and a security group, the security control is applied differently to a user who is a member of the security group than to another user who is not a member of the security group, and the adjusting includes at least one of: altering user membership of the security group based on at least the impact risk, or modifying application of the security control to at least one user based on at least the impact risk (Kirti – Paragraph [0213]: At step 616, the process 600 includes determining one or more instructions to send to the service provider system. In various examples, the instructions can be determined by querying the service provider to request the appropriate instructions to accomplish a desired configuration. In these examples, a computing system can include automated programs for performing the queries. As another example, the instructions can be determined from an API of the cloud service, where the API can include operations that enable a computing system to modify the configuration of the cloud service; 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 13.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Scheidler et al. (US 20180167402 A1) teaches a method and system for determining cybersecurity threats including insider threats based on multiple factors
Voss (US 7552480 B1) teaches a quantitative model for assessing risk that considers impact, threat, and vulnerability factors
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 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