DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on May 13, 2026 has been entered.
Response to Amendment
The amendment filed on May 13, 2026 has been entered.
Claims 1 and 13-14 have been amended.
Claim 26 has been added.
Response to Arguments
Applicant's arguments filed on May 13, 2026, have been fully considered, but they are moot in view of the new grounds of rejection.
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-26 are rejected under 35 U.S.C. 103 as being unpatentable over Kaapoor et al. (Patent No. US 11,677,772), hereinafter Kaapoor; in view of Stephen et al. (Pub. No. US 2022/0335151), hereinafter Stephen.
Claim 1. Kaapoor discloses a method for detecting an exploited vulnerable cloud entity (See Col. 3 lines 66-67 and Col. 4 lines 1-12; FIG. 1 illustrates an example of an environment in which activities that occur within datacenters are modeled. Using techniques, a baseline of datacenter activity can be modeled, and deviations from that baseline can be identified as anomalous… A datacenter can also comprise cloud-based resources), comprising:
detecting in at least one cloud log of a cloud computing environment a plurality of events, each event corresponding to a failed action, each event further corresponding to a cloud entity deployed in the cloud computing environment (See Col. 4 lines 19-30; Both datacenter 104 and datacenter 106 include a plurality of nodes ... Installed on each of the nodes are in-server/in-virtual machine (VM)/embedded in IoT device agents, which are configured to collect data and report it to platform 102 for analysis… Agents monitor the nodes on which they execute for a variety of different activities, including: connection, process, user, machine, and file activities. See Col. 9 lines 33-37; examples of data that an agent, such as agent 112, can collect and provide to platform 102. 18. User Data: Core User Data: user name, UID (user ID), primary group, other groups, home directory. Failed Login Data: IP address, hostname, username, count. See Col. 36 lines 60-67 and Col. 37 lines 1-23; software agents (such as agent 112) run on machines (such as machine 116) and detect new connections, processes, and logins. As also previously explained, such agents send associated records to platform 102 which includes one or more datastores (e.g., database 142) for persistently storing such data. Such data can be modeled using logical tables, also persisted in datastores (e.g., in a relational database that provides an SQL interface), allowing for querying of the data. Other datastores such as graph oriented databases and/or hybrid schemes can also be used See Col. 45 lines 57-67, Col. 45 lines 1-4 and Fig. 26; log data associated with a user session (and thus an original user) is received … See also Col. 5 lines 15-37, See Col. 13 lines 13-48, Col. 24 lines 44-53);
traversing a security graph to detect a node representing the cloud entity, based on the extracted identifier, wherein the security graph includes a representation of the cloud computing environment (See Col. 13 lines 13-48; platform 102 can model activities that occur within datacenters, such as datacenters 104 and 106 ... Using techniques described, platform 102 can automatically discover entities deployed in a given datacenter. Examples of entities include workloads, applications, processes, machines, virtual machines, containers, files, IP addresses, domain names, and users... In particular, using techniques described, periodic graphs can be constructed, in which the nodes are applicable logical entities, and the edges represent behavioral relationships between the logical entities in the graph. Baselines can be created for every node and edge… Deviations from the expected normal behavior can then be detected and automatically reported (e.g., as anomalies or threats detected). Such deviations may be due to a desired change, a misconfiguration, or malicious activity. As applicable, platform 102 can score the detected deviations (e.g., based on severity and threat posed). Additional examples of analysis groups include models of machine communications, models of privilege changes, and models of insider behaviors. See Col. 36 lines 60-67 and Col. 37 lines 1-23; An ssh login session can be identified uniquely by an (MID, PID_hash) tuple. The MID is a machine identifier that is unique to each machine, whether physical or virtual, across time and space … See Col. 38 lines 9-20; Login Table: The logins table maintains records of logins to the machines … MID Identifier of the machine that the login was observed on … See also Col. 3 lines 66-67, Col. 4 lines 1-5, Col. 18 lines 28-41, Col. 20 lines 56-67, Col. 21 lines 1-21, Col. 24 lines 44-53, and Fig. 16);
detecting a node representing a cybersecurity vulnerability connected to the node representing the cloud entity, wherein the connection indicates that the cloud entity includes the cybersecurity vulnerability (See Col. 13 lines 41-50; Deviations from the expected normal behavior can then be detected and automatically reported (e.g., as anomalies or threats detected). Such deviations may be due to a desired change, a misconfiguration, or malicious activity. As applicable, platform 102 can score the detected deviations (e.g., based on severity and threat posed). Additional examples of analysis groups include models of machine communications, models of privilege changes, and models of insider behaviors (monitoring the interactive behavior of human users as they operate within the datacenter). See Col. 18 lines 16-27; ntpd's privilege change actions, and the legitimate actions of various administrators (e.g., using sudo) will be incorporated into a baseline model by platform 102. When deviations occur, such as where a new application that is not ntpd escalates privilege, or where an individual that has not previously/does not routinely use sudo does so, such behaviors can be identified as anomalous. See also Col. 48 lines 22-35); and
initiating a mitigation action for a workload based on the cybersecurity vulnerability (See Col. 24 lines 51-53; Detected anomalies can be recorded and surfaced (e.g., to administrators, auditors, etc.), such as through alerts which are generated at 1808 based on anomaly detection).
Kaapoor discloses an identifier of the cloud entity (see Col. 12 lines 28-29; each node having a globally unique identifier within platform 102), but Kaapoor doesn’t explicitly discloses extracting the identifier of the cloud entity from the cloud log.
However, Stephen discloses:
extracting from the cloud log an identifier of the cloud entity (See Parag. [0067]; Infrastructure logs component 343 parses infrastructure logs for the cloud-based computing environment to identify one or more applications deployed in the cloud-based environment and one or more users authenticating to the one or more applications. See Parag. [0074]; graph 503 is constructed based on parsing of infrastructure logs and captured application queries. In the depicted example, graph 503 includes a vertex for APP 1, which connects with BLUDB and reads ID2, and a vertex for APP 2, which connects with BLUDB and reads USERID. Finally, graph 504 is constructed in response to USER X connecting with APP 1 and APP 2. See also Parag. [0124]).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the identifier of the cloud entity (unique identifier), taught by Kaapoor, to be extracted from the cloud log, as taught by Stephen. This would be convenient for identifying sensitive data risks in cloud-based enterprise deployments based on graph analytics (Stephen, Parag. [0001]).
Claim 2. Kaapoor in view of Stephen discloses the method of claim 1,
Kaapoor further discloses the method further comprising:
detecting a principal identifier in an event corresponding to a failed action (See Col. 9 lines 33-42; Below are additional examples of data that an agent, such as agent 112, can collect and provide to platform 102. 1. User Data. Core User Data: user name, UID (user ID), primary group, other groups, home directory. Failed Login Data: IP address, hostname, username, count. User Login Data: user name, hostname, IP address, start time, TTY (terminal), UID (user ID), GID (group ID), process, end time); and
detecting an event corresponding to a successful action associated with the principal identifier (See Col. 43 lines 62-67 and Col. 44 lines 1-30; Administrators and other users of network environments (e.g., ACME's datacenter 104) often change roles to perform tasks. As one example, suppose that at the start of a workday, an administrator (hereinafter “Joe Smith”) logs in to a console, using an individualized account (e.g., username=joe.smith). Joe performs various tasks as himself (e.g., answering emails, generating status reports, writing code, etc.)).
Claim 3. Kaapoor in view of Stephen discloses the method of claim 2,
Kaapoor further discloses the method further comprising:
determining that the successful action is an action which corresponds to a predetermined action; and initiating a mitigation action based on the successful action (See Col. 43 lines 62-67 and Col. 44 lines 1-30; Administrators and other users of network environments (e.g., ACME's datacenter 104) often change roles to perform tasks. As one example, suppose that at the start of a workday, an administrator (hereinafter “Joe Smith”) logs in to a console, using an individualized account (e.g., username=joe.smith). Joe performs various tasks as himself (e.g., answering emails, generating status reports, writing code, etc.). For other tasks (e.g., performing updates), Joe may require different/additional permission than his individual account has (e.g., root privileges). One way Joe can gain access to such permissions is by using sudo, which will allow Joe to run a single command with root privileges. Another way Joe can gain access to such permissions is by su or otherwise logging into a shell as root. After gaining root privileges, another thing that Joe can do is switch identities. As one example, to perform administrative tasks, Joe may use “su help” or “su database-admin” to become (respectively) the help user or the database-admin user on a system. He may also connect from one machine to another, potentially changing identities along the way (e.g., logging in as joe.smith at a first console, and connecting to a database server as database-admin). When he's completed various administrative tasks, Joe can relinquish his root privileges by closing out of any additional shells created, reverting back to a shell created for user joe.smith. While there are many legitimate reasons for Joe to change his identity throughout the day, such changes may also correspond to nefarious activity. Joe himself may be nefarious, or Joe's account (joe.smith) may have been compromised by a third party (whether an “outsider” outside of ACME's network, or an “insider”). Using techniques described herein, the behavior of users of the environment can be tracked (including across multiple accounts and/or multiple machines) and modeled (e.g., using various graphs described herein). Such models can be used to generate alerts (e.g., to anomalous user behavior).
Claim 4. Kaapoor in view of Stephen discloses the method of claim 3,
Kaapoor further discloses wherein initiating the mitigation action includes any one of: revoking a permission associated with the cloud entity, changing a configuration of a resource, reducing a network exposure of the cloud entity, isolating the cloud entity, blocking network traffic to the cloud entity, blocking network traffic from the cloud entity, and a combination thereof (See Col. 5 lines 2-6; platform 102 can provide updates, configuration information, etc., to data aggregator 114 (which in turn distributes them to nodes 108), rather than requiring nodes 108 to allow incoming connections from platform 102 directly).
Claim 5. Kaapoor in view of Stephen discloses the method of claim 2,
Kaapoor further discloses wherein the principal identifier corresponds to any one of: a user account, a service account, and a role (See Col. 43 lines 62-67 and Col. 44 lines 1-30; Administrators and other users of network environments (e.g., ACME's datacenter 104) often change roles to perform tasks. As one example, suppose that at the start of a workday, an administrator (hereinafter “Joe Smith”) logs in to a console, using an individualized account (e.g., username=joe.smith). Joe performs various tasks as himself (e.g., answering emails, generating status reports, writing code, etc.)).
Claim 6. Kaapoor in view of Stephen discloses the method of claim 2,
Kaapoor further discloses the method further comprising:
detecting a series of events and principal identifier, each event in the series of events corresponding to a unique failed action (See Col. 43 lines 62-67 and Col. 44 lines 1-30; Administrators and other users of network environments (e.g., ACME's datacenter 104) often change roles to perform tasks. As one example, suppose that at the start of a workday, an administrator (hereinafter “Joe Smith”) logs in to a console, using an individualized account (e.g., username=joe.smith). Joe performs various tasks as himself (e.g., answering emails, generating status reports, writing code, etc.). For other tasks (e.g., performing updates), Joe may require different/additional permission than his individual account has (e.g., root privileges). One way Joe can gain access to such permissions is by using sudo, which will allow Joe to run a single command with root privileges. Another way Joe can gain access to such permissions is by su or otherwise logging into a shell as root. After gaining root privileges, another thing that Joe can do is switch identities. As one example, to perform administrative tasks, Joe may use “su help” or “su database-admin” to become (respectively) the help user or the database-admin user on a system. He may also connect from one machine to another, potentially changing identities along the way (e.g., logging in as joe.smith at a first console, and connecting to a database server as database-admin). When he's completed various administrative tasks, Joe can relinquish his root privileges by closing out of any additional shells created, reverting back to a shell created for user joe.smith. While there are many legitimate reasons for Joe to change his identity throughout the day, such changes may also correspond to nefarious activity. Joe himself may be nefarious, or Joe's account (joe.smith) may have been compromised by a third party (whether an “outsider” outside of ACME's network, or an “insider”). Using techniques described herein, the behavior of users of the environment can be tracked (including across multiple accounts and/or multiple machines) and modeled (e.g., using various graphs described herein). Such models can be used to generate alerts (e.g., to anomalous user behavior).
Claim 7. Kaapoor in view of Stephen discloses the method of claim 1,
Kaapoor further discloses wherein the failed action is failed based on insufficient permission to initiate the action (See Col. 4 lines 19-30; Agents monitor the nodes on which they execute for a variety of different activities, including: connection, process, user, machine, and file activities. See Col. 9 lines 33-37; examples of data that an agent, such as agent 112, can collect and provide to platform 102. 18. User Data: Core User Data: user name, UID (user ID), primary group, other groups, home directory. Failed Login Data: IP address, hostname, username, count.).
Claim 8. Kaapoor in view of Stephen discloses the method of claim 1,
Kaapoor further discloses wherein the cybersecurity vulnerability is any one of: a weak password, an exposed password, a misconfiguration, an exposure, and a combination thereof (See Col. 13 lines 36-51; Communication (e.g., between applications/nodes) is one example of a behavior. A model of communications between processes is an example of a behavioral model. As another example, the launching of applications is another example of a behavior that can be modeled. Deviations from the expected normal behavior can then be detected and automatically reported (e.g., as anomalies or threats detected). Such deviations may be due to a desired change, a misconfiguration, or malicious activity. As applicable, platform 102 can score the detected deviations (e.g., based on severity and threat posed). Additional examples of analysis groups include models of machine communications, models of privilege changes, and models of insider behaviors (monitoring the interactive behavior of human users as they operate within the datacenter)).
Claim 9. Kaapoor in view of Stephen discloses the method of claim 1,
Kaapoor further discloses the method further comprising: generating a notification to
indicate that the workload is compromised, as part of the mitigation action (See Col. 24 lines 51-53; Detected anomalies can be recorded and surfaced (e.g., to administrators, auditors, etc.), such as through alerts which are generated at 1808 based on anomaly detection. See also Col. 48 lines 57-60).
Claim 10. Kaapoor in view of Stephen discloses the method of claim 1,
Kaapoor further discloses the method further comprising: updating a severity of an alert associated with the cybersecurity vulnerability as part of the mitigation action (See Col. 21 lines 33-39; EventGen (158) is a microservice that is responsible for generating alerts. It examines observations (e.g., produced by GBM 154) in aggregate, deduplicates them, and scores them. Alerts are generated for observations with a score exceeding a threshold. EventGen 158 also computes (or retrieves, as applicable) data that a customer (e.g., Alice or Bob) might need when reviewing the alert. See Col. 24 lines 36-43; the detection of a new PType can be used to generate an alert. If the new PType has a new CmdType, a severity of the alert can be increased. If any surviving nodes (i.e., present in both the cumulative graph and the snapshot graph) change PTypes, such change is noted as a transition, and an alert can be generated. Further, if a surviving node changes PType and also changes CmdType, a severity of the alert can be increased).
Claim 11. Kaapoor in view of Stephen discloses the method of claim 1,
Kaapoor further discloses the method further comprising: detecting a node representing a principal connected to the node representing the workload; and initiating a mitigation action based on the principal (See Col. 43 lines 62-67 and Col. 44 lines 1-30; Administrators and other users of network environments (e.g., ACME's datacenter 104) often change roles to perform tasks. As one example, suppose that at the start of a workday, an administrator (hereinafter “Joe Smith”) logs in to a console, using an individualized account (e.g., username=joe.smith). Joe performs various tasks as himself (e.g., answering emails, generating status reports, writing code, etc.). For other tasks (e.g., performing updates), Joe may require different/additional permission than his individual account has (e.g., root privileges). One way Joe can gain access to such permissions is by using sudo, which will allow Joe to run a single command with root privileges. Another way Joe can gain access to such permissions is by su or otherwise logging into a shell as root. After gaining root privileges, another thing that Joe can do is switch identities. As one example, to perform administrative tasks, Joe may use “su help” or “su database-admin” to become (respectively) the help user or the database-admin user on a system. He may also connect from one machine to another, potentially changing identities along the way (e.g., logging in as joe.smith at a first console, and connecting to a database server as database-admin). When he's completed various administrative tasks, Joe can relinquish his root privileges by closing out of any additional shells created, reverting back to a shell created for user joe.smith. While there are many legitimate reasons for Joe to change his identity throughout the day, such changes may also correspond to nefarious activity. Joe himself may be nefarious, or Joe's account (joe.smith) may have been compromised by a third party (whether an “outsider” outside of ACME's network, or an “insider”). Using techniques described herein, the behavior of users of the environment can be tracked (including across multiple accounts and/or multiple machines) and modeled (e.g., using various graphs described herein). Such models can be used to generate alerts (e.g., to anomalous user behavior).
Claim 12. Kaapoor in view of Stephen discloses the method of claim 1,
Kaapoor further discloses wherein the failed action corresponds to any one of: deletion of a record, changing a permission of a principal account, changing a configuration of a resource, encrypting a database, deploying multiple workloads, deactivating multiple workloads, generating a secret, generating a certificate, generating a key, deleting a secret, deleting a certificate, deleting a key, exposing a resource to a public network, exfiltrating data, planting a malicious entity, initiating a privilege escalation, encrypting a record, assuming a role, and a combination thereof (See Col. 50 lines 11-23; An example of an anomalous privilege change and an example of an anomalous privilege escalation are each depicted in graph 3200 of FIG. 32. In particular, as indicated in region 3202, two alerts for the time period 2 pm-3 pm on June 8 were generated (corresponding to the detection of the two anomalous events). In region 3204, root has changed privilege to the user “daemon,” which root has not previously done. This anomaly is indicated to the user by highlighting the daemon node (e.g., outlining it in the color red). As indicated by edge 3206, Bill has escalated his privilege to the user root (which can similarly be highlighted in region 3208). This action by Bill represents a privilege escalation).
Claim 13. Kaapoor discloses a non-transitory computer readable medium having stored thereon instructions for causing a processing circuitry to execute a process (See Col. 3 lines 32-49), the process comprising:
detecting in at least one cloud log of a cloud computing environment a plurality of events, each event corresponding to a failed action, each event further corresponding to a cloud entity deployed in the cloud computing environment (See Col. 4 lines 19-30; Both datacenter 104 and datacenter 106 include a plurality of nodes ... Installed on each of the nodes are in-server/in-virtual machine (VM)/embedded in IoT device agents, which are configured to collect data and report it to platform 102 for analysis… Agents monitor the nodes on which they execute for a variety of different activities, including: connection, process, user, machine, and file activities. See Col. 9 lines 33-37; examples of data that an agent, such as agent 112, can collect and provide to platform 102. 18. User Data: Core User Data: user name, UID (user ID), primary group, other groups, home directory. Failed Login Data: IP address, hostname, username, count. See Col. 36 lines 60-67 and Col. 37 lines 1-23; software agents (such as agent 112) run on machines (such as machine 116) and detect new connections, processes, and logins. As also previously explained, such agents send associated records to platform 102 which includes one or more datastores (e.g., database 142) for persistently storing such data. Such data can be modeled using logical tables, also persisted in datastores (e.g., in a relational database that provides an SQL interface), allowing for querying of the data. Other datastores such as graph oriented databases and/or hybrid schemes can also be used See Col. 45 lines 57-67, Col. 45 lines 1-4 and Fig. 26; log data associated with a user session (and thus an original user) is received … See also Col. 5 lines 15-37, See Col. 13 lines 13-48, Col. 24 lines 44-53);
traversing a security graph to detect a node representing the cloud entity, based on the extracted identifier, wherein the security graph includes a representation of the cloud computing environment (See Col. 13 lines 13-48; platform 102 can model activities that occur within datacenters, such as datacenters 104 and 106 ... Using techniques described, platform 102 can automatically discover entities deployed in a given datacenter. Examples of entities include workloads, applications, processes, machines, virtual machines, containers, files, IP addresses, domain names, and users... In particular, using techniques described, periodic graphs can be constructed, in which the nodes are applicable logical entities, and the edges represent behavioral relationships between the logical entities in the graph. Baselines can be created for every node and edge… Deviations from the expected normal behavior can then be detected and automatically reported (e.g., as anomalies or threats detected). Such deviations may be due to a desired change, a misconfiguration, or malicious activity. As applicable, platform 102 can score the detected deviations (e.g., based on severity and threat posed). Additional examples of analysis groups include models of machine communications, models of privilege changes, and models of insider behaviors. See Col. 36 lines 60-67 and Col. 37 lines 1-23; An ssh login session can be identified uniquely by an (MID, PID_hash) tuple. The MID is a machine identifier that is unique to each machine, whether physical or virtual, across time and space … See Col. 38 lines 9-20; Login Table: The logins table maintains records of logins to the machines … MID Identifier of the machine that the login was observed on … See also Col. 3 lines 66-67, Col. 4 lines 1-5, Col. 18 lines 28-41, Col. 20 lines 56-67, Col. 21 lines 1-21, Col. 24 lines 44-53, and Fig. 16);
detecting a node representing a cybersecurity vulnerability connected to the node representing the cloud entity, wherein the connection indicates that the cloud entity includes the cybersecurity vulnerability (See Col. 13 lines 41-50; Deviations from the expected normal behavior can then be detected and automatically reported (e.g., as anomalies or threats detected). Such deviations may be due to a desired change, a misconfiguration, or malicious activity. As applicable, platform 102 can score the detected deviations (e.g., based on severity and threat posed). Additional examples of analysis groups include models of machine communications, models of privilege changes, and models of insider behaviors (monitoring the interactive behavior of human users as they operate within the datacenter). See Col. 18 lines 16-27; ntpd's privilege change actions, and the legitimate actions of various administrators (e.g., using sudo) will be incorporated into a baseline model by platform 102. When deviations occur, such as where a new application that is not ntpd escalates privilege, or where an individual that has not previously/does not routinely use sudo does so, such behaviors can be identified as anomalous. See also Col. 48 lines 22-35); and
initiating a mitigation action for a workload based on the cybersecurity vulnerability (See Col. 24 lines 51-53; Detected anomalies can be recorded and surfaced (e.g., to administrators, auditors, etc.), such as through alerts which are generated at 1808 based on anomaly detection).
Kaapoor discloses an identifier of the cloud entity (see Col. 12 lines 28-29; each node having a globally unique identifier within platform 102), but Kaapoor doesn’t explicitly disclose extracting the identifier of the cloud entity from the cloud log.
However, Stephen discloses:
extracting from the cloud log an identifier of the cloud entity (See Parag. [0067]; Infrastructure logs component 343 parses infrastructure logs for the cloud-based computing environment to identify one or more applications deployed in the cloud-based environment and one or more users authenticating to the one or more applications. See Parag. [0074]; graph 503 is constructed based on parsing of infrastructure logs and captured application queries. In the depicted example, graph 503 includes a vertex for APP 1, which connects with BLUDB and reads ID2, and a vertex for APP 2, which connects with BLUDB and reads USERID. Finally, graph 504 is constructed in response to USER X connecting with APP 1 and APP 2. See also Parag. [0124]).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the identifier of the cloud entity (unique identifier), taught by Kaapoor, to be extracted from the cloud log, as taught by Stephen. This would be convenient for identifying sensitive data risks in cloud-based enterprise deployments based on graph analytics (Stephen, Parag. [0001]).
Claim 14. Kaapoor discloses a system for detecting an exploited vulnerable cloud entity (See Col. 3 lines 66-67 and Col. 4 lines 1-12; FIG. 1 illustrates an example of an environment in which activities that occur within datacenters are modeled. Using techniques, a baseline of datacenter activity can be modeled, and deviations from that baseline can be identified as anomalous… A datacenter can also comprise cloud-based resources), comprising: a processing circuitry; and a memory, the memory containing instructions that, when executed by the processing circuitry (See Col. 3 lines 32-49), configure the system to:
detect in at least one cloud log of a cloud computing environment a plurality of events, each event corresponding to a failed action, each event further corresponding to a cloud entity deployed in the cloud computing environment (See Col. 4 lines 19-30; Both datacenter 104 and datacenter 106 include a plurality of nodes ... Installed on each of the nodes are in-server/in-virtual machine (VM)/embedded in IoT device agents, which are configured to collect data and report it to platform 102 for analysis… Agents monitor the nodes on which they execute for a variety of different activities, including: connection, process, user, machine, and file activities. See Col. 9 lines 33-37; examples of data that an agent, such as agent 112, can collect and provide to platform 102. 18. User Data: Core User Data: user name, UID (user ID), primary group, other groups, home directory. Failed Login Data: IP address, hostname, username, count. See Col. 36 lines 60-67 and Col. 37 lines 1-23; software agents (such as agent 112) run on machines (such as machine 116) and detect new connections, processes, and logins. As also previously explained, such agents send associated records to platform 102 which includes one or more datastores (e.g., database 142) for persistently storing such data. Such data can be modeled using logical tables, also persisted in datastores (e.g., in a relational database that provides an SQL interface), allowing for querying of the data. Other datastores such as graph oriented databases and/or hybrid schemes can also be used See Col. 45 lines 57-67, Col. 45 lines 1-4 and Fig. 26; log data associated with a user session (and thus an original user) is received … See also Col. 5 lines 15-37, See Col. 13 lines 13-48, Col. 24 lines 44-53);
traverse a security graph to detect a node representing the cloud entity, based on the extracted identifier, wherein the security graph includes a representation of the cloud computing environment (See Col. 13 lines 13-48; platform 102 can model activities that occur within datacenters, such as datacenters 104 and 106 ... Using techniques described, platform 102 can automatically discover entities deployed in a given datacenter. Examples of entities include workloads, applications, processes, machines, virtual machines, containers, files, IP addresses, domain names, and users... In particular, using techniques described, periodic graphs can be constructed, in which the nodes are applicable logical entities, and the edges represent behavioral relationships between the logical entities in the graph. Baselines can be created for every node and edge… Deviations from the expected normal behavior can then be detected and automatically reported (e.g., as anomalies or threats detected). Such deviations may be due to a desired change, a misconfiguration, or malicious activity. As applicable, platform 102 can score the detected deviations (e.g., based on severity and threat posed). Additional examples of analysis groups include models of machine communications, models of privilege changes, and models of insider behaviors. See Col. 36 lines 60-67 and Col. 37 lines 1-23; An ssh login session can be identified uniquely by an (MID, PID_hash) tuple. The MID is a machine identifier that is unique to each machine, whether physical or virtual, across time and space … See Col. 38 lines 9-20; Login Table: The logins table maintains records of logins to the machines … MID Identifier of the machine that the login was observed on … See also Col. 3 lines 66-67, Col. 4 lines 1-5, Col. 18 lines 28-41, Col. 20 lines 56-67, Col. 21 lines 1-21, Col. 24 lines 44-53, and Fig. 16);
detect a node representing a cybersecurity vulnerability connected to the node representing the cloud entity, wherein the connection indicates that the cloud entity includes the cybersecurity vulnerability (See Col. 13 lines 41-50; Deviations from the expected normal behavior can then be detected and automatically reported (e.g., as anomalies or threats detected). Such deviations may be due to a desired change, a misconfiguration, or malicious activity. As applicable, platform 102 can score the detected deviations (e.g., based on severity and threat posed). Additional examples of analysis groups include models of machine communications, models of privilege changes, and models of insider behaviors (monitoring the interactive behavior of human users as they operate within the datacenter). See Col. 18 lines 16-27; ntpd's privilege change actions, and the legitimate actions of various administrators (e.g., using sudo) will be incorporated into a baseline model by platform 102. When deviations occur, such as where a new application that is not ntpd escalates privilege, or where an individual that has not previously/does not routinely use sudo does so, such behaviors can be identified as anomalous. See also Col. 48 lines 22-35); and
initiate a mitigation action for a workload based on the cybersecurity vulnerability (See Col. 24 lines 51-53; Detected anomalies can be recorded and surfaced (e.g., to administrators, auditors, etc.), such as through alerts which are generated at 1808 based on anomaly detection).
Kaapoor discloses an identifier of the cloud entity (see Col. 12 lines 28-29; each node having a globally unique identifier within platform 102), but Kaapoor doesn’t explicitly discloses extract the identifier of the cloud entity from the cloud log.
However, Stephen discloses:
extract from the cloud log an identifier of the cloud entity (See Parag. [0067]; Infrastructure logs component 343 parses infrastructure logs for the cloud-based computing environment to identify one or more applications deployed in the cloud-based environment and one or more users authenticating to the one or more applications. See Parag. [0074]; graph 503 is constructed based on parsing of infrastructure logs and captured application queries. In the depicted example, graph 503 includes a vertex for APP 1, which connects with BLUDB and reads ID2, and a vertex for APP 2, which connects with BLUDB and reads USERID. Finally, graph 504 is constructed in response to USER X connecting with APP 1 and APP 2. See also Parag. [0124]).
It would be obvious to one of ordinary skill in the art at the time before the effective filling date of the claimed invention to modify the identifier of the cloud entity (unique identifier), taught by Kaapoor, to be extracted from the cloud log, as taught by Stephen. This would be convenient for identifying sensitive data risks in cloud-based enterprise deployments based on graph analytics (Stephen, Parag. [0001]).
Claim 15. The applicant is directed to the rejections to claim 2 set forth above, as they are rejected based on the same rationale.
Claim 16. The applicant is directed to the rejections to claim 3 set forth above, as they are rejected based on the same rationale.
Claim 17. The applicant is directed to the rejections to claim 4 set forth above, as they are rejected based on the same rationale.
Claim 18. The applicant is directed to the rejections to claim 5 set forth above, as they are rejected based on the same rationale.
Claim 19. The applicant is directed to the rejections to claim 6 set forth above, as they are rejected based on the same rationale.
Claim 20. The applicant is directed to the rejections to claim 7 set forth above, as they are rejected based on the same rationale.
Claim 21. The applicant is directed to the rejections to claim 8 set forth above, as they are rejected based on the same rationale.
Claim 22. The applicant is directed to the rejections to claim 9 set forth above, as they are rejected based on the same rationale.
Claim 23. The applicant is directed to the rejections to claim 10 set forth above, as they are rejected based on the same rationale.
Claim 24. The applicant is directed to the rejections to claim 11 set forth above, as they are rejected based on the same rationale.
Claim 25. The applicant is directed to the rejections to claim 12 set forth above, as they are rejected based on the same rationale.
Claim 26. Kaapoor in view of Stephen discloses the system of claim 14,
Kaapoor further discloses wherein the memory contains further instructions which when executed by the processing circuitry further configure the system to: store data associated with the cybersecurity vulnerability only in the node representing the cybersecurity vulnerability (See Col. 13 lines 41-50; Deviations from the expected normal behavior can then be detected and automatically reported (e.g., as anomalies or threats detected). Such deviations may be due to a desired change, a misconfiguration, or malicious activity. As applicable, platform 102 can score the detected deviations (e.g., based on severity and threat posed). Additional examples of analysis groups include models of machine communications, models of privilege changes, and models of insider behaviors (monitoring the interactive behavior of human users as they operate within the datacenter). See Col. 18 lines 16-27; ntpd's privilege change actions, and the legitimate actions of various administrators (e.g., using sudo) will be incorporated into a baseline model by platform 102. When deviations occur, such as where a new application that is not ntpd escalates privilege, or where an individual that has not previously/does not routinely use sudo does so, such behaviors can be identified as anomalous. See also Col. 48 lines 22-35).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure (see PTO-form 892).
Crabtree et al. (Pub. No. US 2022/0232040) - discloses a method for analyzing the cybersecurity threat of software applications from the software supply chain is disclosed, comprising the steps of: receiving a software application for analysis; identifying one or more software components comprising the software application; searching one or more databases to identify a source of each software component; searching one or more databases to identify a vulnerability of each software component; constructing a cyber-physical graph of a software supply chain for the software application, the cyber-physical graph comprising nodes representing the source and vulnerability of each software component of the software application and edges representing the relationships between the nodes; running one or more graph-processing algorithms on the cyber-physical graph to determine one or more paths of vulnerability in the software supply chain and a probability of occurrence for each path; and generating a cybersecurity score for the software application based on the vulnerabilities in the software supply chain (See Abstract).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GHIZLANE MAAZOUZ whose telephone number is (571)272-8118. The examiner can normally be reached Telework M-F 7:30-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, Philip J Chea can be reached on 571-272-3951. 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.
/GHIZLANE MAAZOUZ/Examiner, Art Unit 2499 /PHILIP J CHEA/Supervisory Patent Examiner, Art Unit 2499
Prosecution Insights