System and method for software service network security repair

Abstract

A system and method for initiating a repair measure for a software service in a computing environment is presented. The method includes detecting a software service in a computing environment, the service including code objects and resources; generating a representation of the software service in a secure database, the secure database further comprising a representation of the computing environment; traversing the secure database to detect a plurality of components, each component having a representation connected to the representation of the software service; initiating a check of the network security object for each component of the software service; and initiating a repair measure for each component of the software service that detected the network security object.

Description

Technical Field

[0001] This disclosure generally pertains to the field of cybersecurity, and in particular to cybersecurity remediation of software services. Background Technology

[0002] Software service discovery is a key aspect of distributed computing systems, enabling applications to dynamically locate and interact with services within a network. Essentially, it's about facilitating the seamless identification and connection of services within a network environment. This advancement is particularly important in distributed computing, supporting dynamic interactions between services across a network. This process becomes especially crucial in large-scale deployments, cloud computing environments, and microservice architectures, where services are continuously added, removed, or expanded based on demand. Service discovery mechanisms typically involve registration (services publish their availability in the registration) and lookup (clients query for specific services in the lookup).

[0003] Some current challenges in software discovery include ensuring scalability and resilience in large-scale environments, where the sheer number of services and their constantly changing states can strain traditional discovery mechanisms. Furthermore, maintaining consistency and synchronization among service registries distributed across multiple nodes is a challenge, often leading to potential inconsistencies or service disruptions. Security is another critical issue, as malicious actors could exploit vulnerabilities in the discovery process to gain unauthorized access or compromise service availability. Moreover, interoperability between different discovery protocols and frameworks remains an ongoing challenge, hindering seamless integration across heterogeneous environments. Therefore, providing a solution to overcome these challenges would be beneficial. Summary of the Invention

[0004] The following is an overview of several exemplary embodiments of this disclosure. This overview is provided to facilitate the reader in gaining a basic understanding of these embodiments and does not necessarily limit the scope of this disclosure. This overview is not a comprehensive summary of all contemplated embodiments and is neither intended to identify key or essential elements of all embodiments nor to depict the scope of any or all aspects. Its sole purpose is to present some concepts of one or more embodiments in a simplified form as a prelude to the more detailed description that follows. For convenience, the terms "some embodiments" or "certain embodiments" may be used herein to refer to a single embodiment or multiple embodiments of this disclosure.

[0005] A system comprising one or more computers can be configured to perform specific operations or measures by installing software, firmware, hardware, or combinations thereof on the system, which causes the system to perform measures during operation. One or more computer programs can be configured to perform specific operations or measures by including instructions that, when executed by a data processing device, cause that device to perform measures.

[0006] In a general aspect, a method for initiating remedial measures on a software service in a computing environment includes: detecting a software service in the computing environment, the service including code objects and resources; generating a representation of the software service in a security database, the security database also including a representation of the computing environment; traversing the security database to detect a plurality of components, each component having a representation connected to the representation of the software service; initiating an inspection for cybersecurity objects on each component of the software service; and initiating remedial measures on each component of the software service for which cybersecurity objects have been detected. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform measures of the method.

[0007] Implementations may include one or more of the following features. The method may include: detecting a representation of a code object connected to a representation of a software service; detecting a representation of a first resource deployed based on the code object; detecting a representation of a second resource deployed based on the code object; and initiating remediation of the first and second resources in response to detecting that both the representation of the first resource and the representation of the second resource are connected to the representation of a code object in a security database. The method may include: determining that the software service includes a cybersecurity issue in response to detecting a cybersecurity object on any component of the software service. The method may include: initiating remediation measures based on the cybersecurity issue. The method may include: determining a cybersecurity risk score based on the cybersecurity issue; and prioritizing the remediation measures based on the determined cybersecurity risk score. The method may include: initiating remediation measures for each component of the software service. The method may include: applying a policy to the representation of the software service; and further initiating remediation measures in response to determining that the applied policy causes a failure. The remedial measures of this method include any one of the following: revoking access to a resource, revoking access from a resource, revoking access from a subject, revoking access to a subject, sandboxing the resource, updating a software application, removing a software application, updating the operating system, installing a software patch, generating an alert, generating a support ticket, updating the severity indicator of the alert, and any combination thereof. The method may include: determining that the remedial measures are unsuccessful; and initiating a second remedial measure in response to determining that the remedial measures are unsuccessful. Implementations of the technology may include hardware, methods or processes, or tangible computer media.

[0008] In a general aspect, a non-transitory computer-readable medium stores a set of instructions for initiating remedial measures against a software service in a computing environment, wherein the set of instructions includes: one or more instructions, which, when executed by one or more processors of a device, cause the device to: detect a software service in the computing environment, the service including code objects and resources; generate a representation of the software service in a security database, the security database also including a representation of the computing environment; traverse the security database to detect a plurality of components, each component having a representation connected to the representation of the software service; initiate an inspection of network security objects on each component of the software service; and initiate remedial measures on each component of the software service where network security objects have been detected. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform measures of the method.

[0009] In a general aspect, a system for initiating remedial measures on a software service in a computing environment includes: one or more processors configured to: detect a software service in the computing environment, the service including code objects and resources; generate a representation of the software service in a security database, the security database also including a representation of the computing environment; traverse the security database to detect a plurality of components, each component having a representation connected to the representation of the software service; initiate an inspection of network security objects on each component of the software service; and initiate remedial measures on each component of the software service where network security objects are detected. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform measures of the method.

[0010] Implementations may include one or more of the following features. The system may include one or more processors further configured to: detect representations of code objects connected to a representation of a software service; detect representations of a first resource deployed based on the code objects; detect representations of a second resource deployed based on the code objects; and, in response to detecting that both representations of the first and second resources are connected to representations of code objects in a security database, initiate remediation for the first and second resources. The system's one or more processors are further configured to: determine that the software service includes a cybersecurity issue in response to detecting a cybersecurity object on any component of the software service. The system's one or more processors are further configured to: initiate remediation measures based on the cybersecurity issue. The system's one or more processors are further configured to: determine a cybersecurity risk score based on the cybersecurity issue; and prioritize remediation measures based on the determined cybersecurity risk score. The system's one or more processors are further configured to: initiate remediation measures for each component of the software service. The system's one or more processors are further configured to: apply policies to representations of the software service; and, in response to determining that the applied policies cause a failure, further initiate remediation measures. The system's remedial measures include any one of the following: revoking access to a resource, revoking access from a resource, revoking access from a subject, revoking access to a subject, sandboxing the resource, updating software applications, removing software applications, updating the operating system, installing software patches, generating alerts, generating support tickets, updating the severity indicators of alerts, and any combination thereof. One or more processors of the system are also configured to: determine that a remedial measure has failed; and, in response to determining that a remedial measure has failed, initiate a second remedial measure. Implementations of the technology may include hardware, methods or processes, or tangible computer media. Attached Figure Description

[0011] The subject matter disclosed herein is specifically pointed out and expressly claimed in the claims at the end of the specification. The foregoing and other objects, features, and advantages of embodiments of this disclosure will become apparent from the following detailed description taken in conjunction with the accompanying drawings.

[0012] Figure 1 This is a network diagram used to describe monitoring of cloud environments utilizing Infrastructure as Code (IaC) in various embodiments.

[0013] Figure 2 This is a flowchart of a method for inspecting configuration code based on a security graph, implemented according to an embodiment.

[0014] Figure 3 This is a schematic diagram of a portion of a security graph used for risk assessment of instances in a cloud-based computing environment, implemented according to an embodiment.

[0015] Figure 4 This is an example of a code object according to an embodiment.

[0016] Figure 5 This is a schematic diagram of a unified policy engine implemented across multiple cloud environments according to an embodiment.

[0017] Figure 6 This is a flowchart illustrating the generation of inspection instructions based on detected code objects, implemented according to an embodiment.

[0018] Figure 7 This is an example of a schematic diagram illustrating a software container cluster having an admission controller for policy implementation, used to describe an embodiment.

[0019] Figure 8 This is an example of a network graph with multiple computing environments utilizing a unified policy engine, implemented according to an embodiment.

[0020] Figure 9 This is an example flowchart of a method for implementing an admission controller for software container deployment policies, according to an embodiment.

[0021] Figure 10 This is a flowchart of a method for generating a context strategy in a computing environment, implemented according to an embodiment.

[0022] Figure 11 This is an example flowchart of a method for software service discovery in a computing environment, implemented according to an embodiment.

[0023] Figure 12 This is an example flowchart of a method for enforcing network security policies on services in a computing environment, implemented according to an embodiment.

[0024] Figure 13 This is an example flowchart of a method for managing network security policy anomalies on software services in a computing environment, implemented according to an embodiment.

[0025] Figure 14 This is an example flowchart of a method for initiating remedial measures on a software service in a computing environment, implemented according to an embodiment.

[0026] Figure 15 This is an example schematic diagram of the unified strategy engine according to an embodiment. Detailed Implementation

[0027] It is important to note that the embodiments disclosed herein are merely examples of the many advantageous uses of the inventive teachings herein. Generally, the statements made in the specification of this application do not necessarily limit any of the various claimed embodiments. Furthermore, some statements may apply to some inventive features but not to others. Generally, unless otherwise stated, a singular element may be plural, and vice versa, without loss of generality. In the accompanying drawings, the same numerals refer to the same parts in several views.

[0028] The disclosed embodiments include methods and systems for software service repair.

[0029] Figure 1 This is a network diagram 100 used to describe a cloud environment that utilizes Infrastructure as Code (IaC) for monitoring in various embodiments.

[0030] Client device 110 generates configuration code file 120 based on input from one or more users (e.g., software programmers). While client device 110 is shown here for simplicity and educational purposes, it is clear that configuration code can be generated by client devices, virtual workloads in a cloud environment, etc. Similarly, configuration code can be generated by multiple different client devices, a single client device can generate multiple configuration codes, or any combination of these scenarios.

[0031] Configuration code file 120 can be implemented using a declarative computer language. In a declarative computer language, users declare the resources they wish to have as code objects, and the orchestrator 130 deploys instances in the cloud environment based on these declarations. In some embodiments, multiple configuration code files 120 may be used. For example, a user may operate multiple cloud environments, each with its own configuration code. As another example, a user may declare a first resource type for a first cloud environment and a second cloud environment in a first configuration code file, and a second resource type for both the first and second cloud environments in a second configuration code file.

[0032] Coordinator 130 receives configuration code file 120. Based on the declarations in the configuration code file, coordinator 130 configures cloud environment 140 (production cloud environment) to deploy various instances. Instances are virtual workloads, which can be, for example, virtual machines 142, containers 144, or serverless functions 146. Coordinator 130 performs deployment by allocating (also called pre-allocating) cloud environment resources (such as processors, memory, storage devices, etc.) to the virtual instances. The deployed instances are also called the production environment. The configuration code can be implemented in a development (dev) environment, which can also be a cloud computing environment.

[0033] In some embodiments, multiple instances can be associated with a first object (not shown) in configuration code file 120. This provides an advantage when multiple instances need to be deployed that share similar configurations, such as web servers providing access to a website. Unlike manually configuring each instance individually (also known as a workload), the coordinator is able to deploy multiple identical instances based on configuration code file 120.

[0034] In some embodiments, coordinator 130 can configure a cloud-native coordinator (not shown) in cloud environment 140 to deploy instances. This can be advantageous, for example, when instances need to be deployed in different cloud environments. For instance, the same instance might be deployed simultaneously in... Cloud platform (GCP) AWS Web Services or This can be achieved by configuring coordinator 130 to generate native instructions for deploying such instances in each cloud-native coordinator environment. The native instructions can be generated by coordinator 130, which generates instructions based on objects declared in configuration code file 120. This method of deploying instances reduces errors by eliminating the need for users to manually deploy and individually configure each instance, and is therefore a faster deployment method. In the example above, a first load balancer can be deployed in a first cloud computing environment, and a second load balancer can be deployed in a second cloud computing environment, each with different infrastructure than the others, wherein the first and second load balancers are deployed based on the same code objects from the configuration code file.

[0035] The second cloud environment 150 can be used to inspect the first cloud environment 140 and generate a security risk assessment for instances in the first cloud environment 140. The second cloud environment 150 may include one or more inspectors, such as inspector 160. An inspector is a workload that examines objects (such as keys, files, folders, registry values, etc.) in another workload. Each inspector can be configured to examine one or more different object types.

[0036] For example, an inspector (or other workload, not shown herein) can generate a request to inspect virtual machine 142. The request can be received via an API (not shown) of a first cloud environment 140. A snapshot of a volume of virtual machine 142 can be generated and sent to a second cloud environment 150. Containers can be deployed in the second cloud environment and attached to volumes generated in the second cloud environment based on the received snapshot. Inspector 160 then accesses the attached volume to inspect specific object types within that volume. Inspector 160 can generate data for storage on a security graph 170.

[0037] Security graph 170 can be stored in a graph database. A security graph includes multiple nodes, at least some of which correspond to resources or subjects. Resources can be workloads, such as virtual machines, serverless functions, containers, etc. Subjects can be user groups, user accounts, service accounts, etc. Generally, subjects take actions on resources to achieve results. Security graphs can also include enriched nodes, which can indicate certain functions, network access, etc. For example, enriched nodes can be used to indicate public internet access. Therefore, nodes corresponding to workloads with public internet access or accessible via a public internet connection will be connected to internet access nodes.

[0038] Code inspector 180 is also deployed in a second cloud environment 150. In this embodiment, more than one code inspector may be deployed. Configuration code can be provided by various different types of platforms (such as...). (etc.) generated. For example, the first code inspector can check the use of The generated configuration code, and the second code inspector can check its usage. The generated configuration code. In an embodiment, the code inspector 180 is implemented as a workload configured to receive configuration code and inspect it to find one or more types of code objects. For example, the type of code object could be a key (such as a public key, private key), a resource type, a policy identifier, a role identifier, a flag status, etc. A flag status could indicate that an object is allowed to perform certain actions (such as network access) or assume a certain role (such as an administrator role (in the case of a user or service account)). The code inspector 180 can attempt to match the detected objects with one or more nodes in the security graph. This will be discussed below. Figure 2 The code checker is discussed in more detail in U.S. nonprovisional patent application No. 17 / 532,557, the entire contents of which are incorporated herein by reference.

[0039] The second cloud environment 150 also includes a policy engine 190. The policy engine 190 can be implemented as a workload, such as a virtual machine or a container. The policy engine 190 can include multiple rules, each rule including conditions and actions. For example, a rule can be implemented as an "if...then..." statement. In an embodiment, the policy engine 190 can periodically check whether a workload or account in the first cloud environment 140 has violated one or more rules. The policy engine 190 can also include policies that indicate permissions associated with a workload, account, or both. For example, a policy can state that a user account belonging to a first user group is authorized to access VM 142. In an embodiment, the policy engine 190 can be implemented in the first cloud environment 140 and can be accessed by the second cloud environment 150.

[0040] Configuration code 120 can be further accessed by the pre-release environment coordinator 130-S. While this embodiment uses coordinator 130 for the production cloud environment 140 and pre-release environment coordinator 130-S for the pre-release cloud environment 140-S, it is clear that a single coordinator can be used for both production and pre-release environments simultaneously. The pre-release cloud environment 140-S is a cloud computing environment almost identical to the production cloud environment 140, except for testing the existence of workloads or other changes tested for later deployment in the production environment. The pre-release environment is used for testing purposes, such as determining whether a workload can handle a large amount of expected traffic. Typically, a workload is deployed to the pre-release environment before being deployed to the production environment to detect any problems the workload might cause in the production environment.

[0041] For example, the second VM 143-S is a workload deployed in the pre-release cloud environment 140-S but not yet deployed in the production cloud environment 140. The first VM 142-S is the same workload as VM 142, container 144-S is the same workload as container 144 deployed in the production cloud environment 140, and serverless function 146-S is the same as serverless function 146.

[0042] For example, based on the policy of production cloud environment 140, workloads in production environment 140 frequently trigger errors. Policy engine 190 allows users to configure exceptions for errors. For example, if VM 142 triggers an error (i.e., violates the policy), an exception can be added to policy engine 190 so that the error is ignored when applied to VM 142. Exceptions can be implemented as rules in policy engine 190. However, because the exception is VM 142-specific, the same pre-release environment VM 142-S will trigger an error based on violating the same policy. This can be addressed by representing the configuration code object, the object of pre-release environment 140-S, and the object of production environment 140 in security diagram 170. See below for details. Figure 8 Examples of this approach will be discussed in more detail.

[0043] Figure 2 This is an example flowchart 200 of a method for inspecting configuration code based on a security graph, implemented according to an embodiment. This method provides the ability to inspect configuration code in a development (dev) environment based on a security graph generated at least in part from the production environment. The production environment is rarely (if any) the same as the environment originally deployed by the code. This is, for example, due to upgrades and patches being implemented in the production environment. Since production and development teams are often not the same, there exists a phenomenon called configuration drift, which describes how the production environment “drifts” away from the initial configuration code design over time.

[0044] Security graphs can be generated based on code and the production environment. By examining the configuration code based on the security graph generated from production data, insights can be gained and deployment issues can be identified early. For example, instances deployed based on the current version of the configuration code will include those where the production environment has been upgraded to a newer software version. This method can be performed by a configuration code inspector (such as Code Inspector 180).

[0045] In S210, the configuration code is received by, for example, a configuration code inspector. The configuration code comprises multiple code objects, at least a portion of which correspond to instances intended for deployment in a cloud computing environment. The configuration code can be scanned as a text object or otherwise inspected, meaning that regular expressions, strings, etc., can be searched.

[0046] At S220, a first code object is extracted from the received code. Extracting the code object may include, for example, searching for one or more predetermined strings in the text of a configuration code file. For example, the code object may be a text field that identifies the workload type, workload name, network address, name in a namespace, role, permissions, etc.

[0047] At S230, the security graph is traversed to detect whether a node in the graph corresponds to the extracted first object. Traversing the security graph may include, for example, sending a request via an API of a graph database hosting the security graph to search the graph for a string or value corresponding to the first object. For example, if the first object is a key (such as a private key), the security graph may be traversed to determine if there exists a node representing a matching public key. In some embodiments, a query against the security graph may include, for example, multiple clauses for searching for container nodes attached to nodes representing public keys. Notably, detecting nodes corresponding to the extracted first object may include nodes that are not nodes representing the workload corresponding to the first object.

[0048] For example, executing the code of the first object can result in the deployment of the first load balancer in a Virtual Private Cloud (VPC). Once the first load balancer is deployed, a node can be generated in the security graph to represent the first load balancer, and this node can be connected to the node representing the VPC. An advantage of the disclosed method is that the attributes of the first object can be detected in the graph, which allows for node detection before the actual workload is generated. In other words, security risks can be detected in the workload before deployment. In this example, because the code of the first object includes instructions for deployment in the VPC, the VPC node can be detected, thereby assessing the security risks associated with the VPC, or assessing the security risks associated with deploying the load balancer in the VPC.

[0049] At S240, a check is performed to determine if a node is detected. If "no", execution can continue at S270. In an embodiment, if no match exists, a new node can be generated in the security graph to represent the first object. If a match exists, execution continues to S250.

[0050] At S250, a check is performed to determine whether the matching node corresponds to a previously identified risk factor or vulnerability. For example, a risk factor or vulnerability could be access to / from a network resource (such as the Internet), obsolete software, privilege escalation, etc. In some embodiments, a risk factor score may be further determined. This score can indicate the severity of the risk, such as "low," "medium," "high," and "critical." In embodiments, different instructions can be executed based on the risk factor score. Risk factors can be represented by metadata associated with the matching node. For example, metadata could be a data field indicating the presence of a risk factor. For example, a flag could indicate whether the node has external network access. If the matching node corresponds to a previously identified risk factor, execution continues at S260; otherwise, execution continues at S270. In embodiments, vulnerabilities can be represented by nodes on a security graph. For example, a node corresponding to a workload can be connected to a vulnerable node. Therefore, if the workload node is a matching node, then a security vulnerability can be associated with a code object.

[0051] At an optional step S260, a notification can be generated to indicate that a security risk has been detected in the configuration code. In embodiments, the notification can be generated and sent to the client device that wrote the code, a user account, or both. In some embodiments, the notification may include an indicator specifying the reason for generating the notification and the measures to be taken to mitigate the risk. In the example above, if the workload includes an outdated software version, an alert (notification) is generated, and the alert includes the current version, which needs to be configured in the code to pass the check.

[0052] At S270, a check is performed to determine whether another code object should be checked. If "yes", execution continues at S220; otherwise, execution terminates.

[0053] Figure 3 This is a schematic diagram of a portion of a security graph 300 implemented according to an embodiment for risk assessment of instances in a cloud-based computing environment. Graph 300 may be stored in a graph database and includes multiple nodes. Nodes may represent resources, subjects, metadata, enriched data, etc.

[0054] In this example, the diagram includes a first cloud key node 310 and a second cloud key node 320 connected to user account node 340. A third cloud key node 330 is connected to service account node 360. User account node 340 and service account node 360 ​​are connected to Identity and Access Management (IAM) object node 350.

[0055] Cloud keys can provide temporary or permanent access between a first workload and a second workload. In some embodiments, one or more first workloads and one or more second workloads may reside on the same tenant, different tenants, or a combination thereof. Cloud keys can be embedded in text configuration files, structured configuration files (e.g., JSON, YAML, XML, etc.), scripts, source code, etc. Example implementations of cloud keys include AWS IAM access keys, OAuth refresh tokens, access tokens, etc.

[0056] By generating a graph that includes these nodes and populating that graph with data based on a cloud computing environment, security risks can be assessed. For example, if the first cloud key is compromised, it becomes apparent which other objects are vulnerable to attack. In this embodiment, each node can also store metadata and data associated with the object. For example, cloud key node 320 may include a unique account identifier.

[0057] Figure 4 Example 400 of the code object is shown according to an embodiment. Code object 400 includes object type 410. In this example, object type 410 indicates that the code object is a resource type, meaning that executing instructions associated with the object will deploy resources in a cloud computing environment. The object type also includes data fields, such as instance type data field 412 and network association data field 414. Instance type 412 specifies the type of resource to be deployed; in this example, the instance type is t2.micro, which is a processing instance used in an AWS cloud computing environment. Network association field 414 in this example indicates that the instance should be associated with a specific Virtual Private Cloud (VPC). In this example, the code object is a data structure with parameters (or data fields) that can be customized to generate resources, accounts, etc., in a cloud computing environment.

[0058] Figure 5 Example 500 is a schematic diagram of a unified policy engine implemented across multiple cloud environments according to an embodiment. The unified policy engine 510 is a policy engine that can be used across the entire technology stack. Production cycles typically begin in development environment 540. Development environments may include sandboxed applications, Infrastructure as Code (IaC) declarative code (such as...) Figure 1 Configuration code 120, etc. For example, It provides Azure DevOps services, which can be used as a cloud-based development environment.

[0059] After workloads, policies, or other changes to the infrastructure are approved in development environment 540, these changes will be implemented in pre-release environment 550. For example, workloads may be deployed in pre-release environment 550, policy changes may be updated to the policy engine of pre-release environment 550, etc. Pre-release environment 550 can be implemented as a cloud computing environment that is the same as or similar to the production environment where the workloads or changes are ultimately deployed. The purpose of pre-release environment 550 is to provide a test environment that highly simulates the production environment. This allows, for example, the final deployment of workloads with relatively high certainty that they perform as expected. If the workload does not perform as expected, it can be returned to development environment 540 to address any issues detected during deployment in pre-release environment 550.

[0060] The workloads tested in the pre-release environment 550 can be implemented in the production environment 560. The production environment is a cloud computing environment used in real time.

[0061] In the example embodiment, the code object can be written as code in a configuration code file stored in the development environment 540. Then, for example, it can be... Execute the configuration code file to deploy workloads (or user accounts, as another example) based on code objects in the pre-release environment 550. The deployed workloads can be tested in the pre-release environment 550, for example, by performing performance tests, load tests, etc. If the deployed workload passes the tests in the pre-release environment 550, the code objects can be added to the main configuration code file (or submitted according to industry terminology). The next time the main configuration code file is used, the code objects will be used to deploy instances in the production environment 560.

[0062] Inspectors can be used to inspect various objects across different computing environments. For example, code inspector 520 can inspect at least one object in each of development environment 540 and pre-release environment 550. As another example, graph inspector 530 can inspect graph objects (i.e., objects appearing in a security graph) in production environment 560. While this embodiment illustrates inspector workloads operating in different environments, this is merely for simplicity and educational purposes. In some embodiments, a first inspector that inspects a first object type can inspect the first object type in each cloud environment. In other embodiments, an inspector for the first object type can be implemented for each computing environment. In some embodiments, the inspector can inspect objects having data fields, attributes, or other values ​​configured with predetermined values.

[0063] Typically, in response to the detection of a real-world event (as opposed to theoretical test cases completed in pre-release), the system administrator will change the production environment policy. For example, in response to the detection of a vulnerability, the system administrator may update or create a policy to address the vulnerability. The policy is stored in the cloud environment of production environment 560, which is inaccessible to pre-release environment 550 and typically unreadable by development environment 540. Furthermore, operators of development environment 540 or pre-release environment 550 are unaware of policy changes. Therefore, operators of development environment 540 and pre-release environment 550 can continue to create workloads that violate the policies specified in production environment 560.

[0064] By leveraging the inspector workload across all computing environments and representing detected objects in security graph 505, a unified policy engine 510 can be used to implement policies across all computing environments. In this example, code objects can be detected in development environment 540. The code objects are inspected, and their contents (e.g., identifiers, types, etc.) can match nodes in security graph 505. These nodes can be associated with policies accessible by the unified policy engine 510. Inspections can be performed to determine whether instances generated based on the detected code objects conform to the relevant policies. Therefore, based on policies in production environment 560, code objects can fail in development environment 540, for example, without wasting resources and time entering pre-release.

[0065] Figure 6 This is an example of a flowchart 600 for generating inspection instructions based on detected code objects, implemented according to an embodiment.

[0066] At S610, code objects are extracted from the configuration code file. The configuration code file includes multiple code objects, at least some of which contain instructions that, when executed by the coordinator, cause the generation of subjects or resources in the cloud computing environment.

[0067] At S620, the security graph is traversed to detect nodes associated with code objects. For example, if a node's data field matches a data field of a code object, then the node is associated with the code object. Above... Figure 5 In the example shown, a code object can be matched with a node representing a VPC. For example, if a workload generated based on a code object is represented by a node, the code object can also match the node.

[0068] At S630, a check is performed to determine whether the detected node should be checked. If "yes," execution continues at S640. If "no," execution can terminate, or in another embodiment, execution can continue at another node at S620. In another embodiment, if the check returns "no," execution can continue at S610 for another code object.

[0069] At S640, a command is generated to initiate an inspection of the workload corresponding to the node. Inspecting the workload may include generating a disk snapshot of the workload and sending a notification to the inspector (such as...) via the inspection service account. Figure 1 The inspector 160 provides access to the snapshot. In an embodiment, a volume may be mounted based on the snapshot, and the inspector 160 may access the snapshot to inspect at least one data object.

[0070] Generating inspection instructions based on code objects is advantageous because it reduces the need to inspect virtual workloads in a network environment. Conversely, new workloads can be discovered by inspecting the code that generates them, and security issues in production workloads can, in turn, be traced back to the code objects that generated them.

[0071] Figure 7 This is an example of a schematic diagram illustrating a software container cluster having an admission controller for policy implementation in an embodiment. In the embodiment, the container cluster 710 is deployed on a computer system, such as the one described below. Figure 10 It is described in more detail in the text.

[0072] In some embodiments, utilizing platform, An engine, etc., implements a software container cluster 710. In some embodiments, the software container cluster 710 is configured to deploy multiple software containers. In these embodiments, the software containers are containerized software applications.

[0073] In some embodiments, the container cluster 710 includes a control plane 720 configured to communicate with an inspection application programming interface (API) 740 and multiple nodes 730-1 to 730-N (each individually referred to as node 730, and collectively as node 730), where “N” is an integer having a value of “2” or greater.

[0074] In some embodiments, control plane 720 is implemented on a single machine in a cluster. In some embodiments, the machine on which control plane 720 is implemented executes only components of control plane 720. For example, in some embodiments, the machine does not include containers based on user-generated images, base images, etc.

[0075] For example, in some embodiments, the Kubernetes container cluster control plane 720 includes components such as an API server, a key-value store, a scheduler, and a controller. In some embodiments, the API server is implemented as kube-apisserver, which is configured to expose the Kubernetes API to external resources. In some embodiments, the key-value store is configured to store keys, cluster data, etc.

[0076] In some embodiments, the controller includes a node controller, a job controller, a service account controller, etc. In some embodiments, the control plane 720 includes a webhook 724. In embodiments, the webhook 724 is a verification webhook, a modification webhook, etc. In embodiments, the webhook 724 is configured to detect requests to an API, to another node in the cluster, etc. In some embodiments, the webhook 724 is also configured to send the request to an admission controller 722.

[0077] In some embodiments, cluster 710 includes multiple nodes 730-1 to 730-N. In some embodiments, each node 730 includes a container 732. In some embodiments, container 732 includes a containerized software application. In some embodiments, node 730 includes multiple containers, agents, network agents, combinations thereof, etc. In some embodiments, containerized software applications include software, dependencies of the software, combinations thereof, etc.

[0078] In some embodiments, API 740 is configured to expose resources, communications, etc., through a cloud computing environment. For example, in one embodiment, the cloud computing environment is a Virtual Private Cloud (VPC), Virtual Network (VNet), etc., deployed on cloud computing infrastructure. In another embodiment, the cloud computing infrastructure is... AWS Web Services Cloud platform (GCP) In some embodiments, the control plane 720 of cluster 710 is configured to communicate via API 740.

[0079] In some embodiments, admission controller 722 is deployed on node 730-1. In an embodiment, admission controller 722 is configured to receive interception requests to the API server of control plane 720. For example, in an embodiment, software container 732-N is configured to communicate with the API server of control plane 720 via node 730-N, and the API server of control plane 720 is configured to communicate with inspection API 740.

[0080] In some embodiments, the admission controller 722 is implemented as computer software deployed on nodes of cluster 710. In some embodiments, the admission controller 722 is configured to communicate with the unified policy engine 810, for example, by inspecting API 740.

[0081] In some embodiments, the admission controller 722 is configured to request a policy from the unified policy engine 710. In one embodiment, the admission controller 722 is configured to apply the received policy to a request intercepted by container 732-1 of slave node 730-1.

[0082] In some embodiments, the policy includes conditional rules. For example, in one embodiment, the policy includes conditional rules for checking whether network communication is directed to an IP address on a list of blocked IP addresses. In one embodiment, a request to send a network message is generated by software container 732-N, the request including a target address (e.g., an IP address). In one embodiment, the request is passed from node 730-N to control plane 720, where the request is intercepted by network hook 724. The request is sent to admission controller 722, which is configured to apply a policy to the request.

[0083] In some embodiments, the admission controller 722 is configured to apply policies to requests. For example, in one embodiment, the admission controller 722 is configured to apply conditional rules such that if communication points to an IP address stored in a list of blocked IP addresses, communication is rejected and the request is not passed to the inspection API 740. In some embodiments, the admission controller 722 is configured to apply conditional rules such that if communication does not point to an IP address stored in a list of blocked IP addresses, communication is allowed to pass and, for example, the communication is forwarded to the inspection API 740.

[0084] In one embodiment, the admission controller 722 is configured to apply conditional rules such that if communication points to an IP address stored in a list of allowed IP addresses, communication is allowed, and the request is passed to the inspection API 740. In another embodiment, the admission controller 722 is configured to apply conditional rules such that if communication does not point to an IP address stored in a list of allowed IP addresses, communication is rejected, and the request is not passed to the inspection API 740.

[0085] Figure 8 This is an example of a network graph with multiple computing environments utilizing a unified policy engine, implemented according to an embodiment. In the embodiment, the unified policy engine 810 includes rules, policies, and combinations thereof. In some embodiments, rules include conditions, such as executing an action when a condition is met, not executing an action when a condition is met, executing an action when a condition is not met, not executing an action when a condition is not met, and combinations thereof.

[0086] In some embodiments, the unified policy engine 810 provides rules, policies, etc., to various computing environments. For example, in an embodiment, the unified policy engine provides rules to a first cloud computing environment 820, a second cloud computing environment 830, and an Infrastructure as Code (IaC) environment 840.

[0087] In this embodiment, the cloud computing environment is a Virtual Private Cloud (VPC), Virtual Network (VNET), etc., implemented on cloud computing infrastructure. According to this embodiment, the cloud computing infrastructure is, for example... AWS Web Services Cloud platforms (GCP), etc. In this embodiment, the second cloud computing environment 830 includes virtual machines 834, serverless functions 836, clusters 832, and combinations thereof.

[0088] In some embodiments, for example, the IaC environment 840 is connected with Use them together.

[0089] In some embodiments, security policies are maintained for different computing environments, such as to protect certain digital assets or prevent unwanted or accidental access. In some embodiments, such as in the implementation of continuous integration and continuous deployment (CI / CD), multiple computing environments are related. For example, according to an embodiment, declarative code in IaC environment 840 is used to deploy software container cluster 822 in pre-release environment 820.

[0090] In this embodiment, the pre-release environment is a cloud computing environment in which resources, entities, etc., are deployed before being deployed in a production environment (such as production environment 830). This is advantageous because it allows resources (such as container cluster 822) to be tested and benchmarked before the counterpart of container cluster 822 is deployed to production environment 830. For example, in this embodiment, the counterpart of container cluster 822 deployed in pre-release environment 820 is software container cluster 832 deployed in production environment 830.

[0091] According to an embodiment, once a resource (such as container cluster 822) passes benchmarking, testing, etc., code used to deploy container cluster 822 in pre-release environment 820 can be used to deploy container cluster 832 in production environment 830. In some embodiments, it is beneficial to take measures based on the code object, the resources deployed in the pre-release environment based on the code object, and the corresponding resources deployed in the production environment, wherein the measures are applied to each of the code object and the two resources.

[0092] For example, in some embodiments, it is useful to employ strategies for code objects, resources deployed in the pre-release environment 820, and corresponding resources deployed in the production environment 830, since all of these correspond to each other. In some embodiments, strategies are formulated based on observations of resources in the pre-release environment, such as container cluster 822.

[0093] The unified policy engine 810 allows for the storage of a single policy utilized by each relevant computing environment. This is preferable to storing a corresponding policy in each computing environment, especially when these computing environments are related to each other. In this embodiment, utilizing a single unified policy engine 810 also reduces the storage space required to store redundant similar policies, as it eliminates the need to store corresponding policies in each different (but related) computing environment.

[0094] Furthermore, configuring a software container cluster to deploy an admission controller provides a level of guarantee for policy formulation on each container in that cluster, and across multiple clusters in any computing environment, with the admission controller configured to utilize policies from the unified policy engine 810. Thus, a single policy is applied equally, objectively, and consistently. While recognizing that, for example, humans can apply conditions to resources, it is also recognized that humans cannot apply conditions (e.g., policies) consistently, equally, and objectively across multiple computing environments, and certainly cannot do so within the timeframe that makes such policy application useful.

[0095] Figure 9 This is an example flowchart of an admission controller method for enforcing deployment policies for software containers, implemented according to an embodiment.

[0096] At S910, an admission controller is deployed. In some embodiments, multiple admission controllers are deployed. In an embodiment, the admission controller is deployed in the control plane of the software container cluster. In some embodiments, the software container cluster is... Implemented on the platform.

[0097] In some embodiments, the admission controller is configured to intercept API requests between nodes in the container cluster and the container cluster's inspection API. In embodiments, the admission controller is configured to modify admission controllers, validate admission controllers, combinations thereof, etc. In some embodiments, multiple admission controllers are deployed, including modifying admission controllers and validating admission controllers.

[0098] In some embodiments, the admission controller is configured to modify requests received by the admission controller. For example, in one embodiment, the admission controller is configured to modify a policy modification request received from a unified policy engine.

[0099] In some embodiments, the admission controller is configured to verify the request without altering the request itself. In other embodiments, the admission controller is configured to verify requests modified by changing the admission controller.

[0100] At S920, a policy check is performed. In some embodiments, the admission controller is configured to periodically check, for example, by sending a request to the unified policy engine, to receive new policies. In some embodiments, the admission controller is configured to send a policy version number to the unified policy engine. In some embodiments, the unified policy engine is configured to compare the received policy version with a stored policy version, and in response to determining that the received version is older than the stored version, send the stored policy version to the admission controller.

[0101] At S930, the policy is applied. In an embodiment, the admission controller is configured to apply the policy, for example, on containers deployed on nodes of the cluster in which the admission controller is deployed. In some embodiments, multiple policies are applied.

[0102] In some embodiments, the admission controller is configured to merge multiple policies (such as a first policy and a second policy) into a single policy and apply that single policy to every container, pod, etc., in the cluster. In some embodiments, policies are merged by extracting conditional rules from the first policy, extracting conditional rules from the second policy, and generating new conditional rules, for example by adding a Boolean "AND" operator between the conditional rules of the first policy and the conditional rules of the second policy.

[0103] In some embodiments, the policy is applied to each occurrence of nodes, cabins, containers, etc., accessing the cluster's control plane. For example, in one embodiment, the policy is applied in response to detecting instructions to deploy nodes, cabins, containers, combinations thereof, etc., in the cluster. In some embodiments, the policy is applied to requests originating from nodes, cabins, containers, combinations thereof, etc., such as requests communicating via API and IP addresses.

[0104] Figure 10 This is a flowchart illustrating a method for generating context policies in a computing environment, implemented according to an embodiment. In some embodiments, context policies are generated based on existing policies, anomalies based on existing policies, network security objects detected in the computing environment, and combinations thereof.

[0105] In some embodiments, the context policy is a policy generated based on the context detected in the computing environment. For example, in some embodiments, the policy includes a condition that first-type network security objects (such as plaintext passwords) should not be stored on the deployed resources.

[0106] In some embodiments, a context is generated for the detected network security object. For example, in some embodiments, a first plaintext password provides a limited set of permissions in a cloud computing environment, while a second plaintext password provides administrator permissions in the cloud computing environment. In some embodiments, the context is generated based on a security graph in which a representation of the computing environment is stored. For example, according to an embodiment, nodes in the security graph represent resources, subjects, contexts, enrichments, endpoints, combinations thereof, etc.

[0107] According to an embodiment, by determining the context of each plaintext password, it is possible to allow the deployment of some workloads (e.g., workloads containing plaintext passwords with limited privileges) while denying the deployment of other workloads (e.g., workloads containing plaintext passwords with administrator privileges).

[0108] In some embodiments, a security graph is generated by performing network discovery on the computing environment and inspecting and scanning each discovered resource in the computing environment for network security objects. In some embodiments, each discovered resource, network security object, etc., is represented as a node in the security graph. In some embodiments, subjects, such as user accounts, service accounts, roles, etc., are detected in the computing environment. In some embodiments, access identity and access management services are used to determine the permissions associated with the subject.

[0109] In some embodiments, the subject is a cloud entity, which includes permissions, authorizations, etc., for taking measures on resources, initiating measures in the computing environment, and combinations thereof.

[0110] In some embodiments, resources are virtual machines, software containers, serverless functions, applications, software as a service, infrastructure as code platforms, pre-allocated hardware resources, storage devices, buckets in a cloud computing environment, and combinations thereof.

[0111] At step S1010, network security objects are detected. In this embodiment, network security objects are detected on the deployed virtualization. According to this embodiment, the deployed virtualization is a virtual machine, a software container, a serverless function, or a combination thereof.

[0112] In some embodiments, network security objects include operating systems, software applications, plaintext cryptography, encryption keys, certificates, misconfigurations, vulnerabilities, exposures, and combinations thereof.

[0113] In some embodiments, network security objects are detected using scanners, inspectors, etc. In other embodiments, the representation of the network security objects is stored on a security graph. In some embodiments, the security graph includes a representation of the computing environment, for example, by generating nodes representing resources, subjects, enrichments, etc., detected in the computing environment.

[0114] In some embodiments, detection of resources, entities, etc., is performed by leveraging network discovery. In one embodiment, a node representing a network security object is connected to a node representing a cloud entity (e.g., a resource, entity, etc.). In some embodiments, a security graph is traversed based on the network security object to detect nodes representing resources. For example, a query for the security graph is generated using the identifier of the network security object.

[0115] At S1020, a detection policy is implemented. In this embodiment, the policy is applied to the computing environment for detecting network security objects. In some embodiments, the policy is detected by extracting the identifier of the network security object and matching that identifier against the policy. In this embodiment, the identifier is matched against the policy by querying an identity and access management service.

[0116] In some embodiments, a detection policy is based on the identifier of the resource on which the network security object is detected. For example, in one embodiment, data related to the resource, metadata of the resource, etc., are used for the detection policy. For example, in one embodiment, the identifier of the resource is used for the detection policy. In some embodiments, an identifier query policy engine is used to detect the policy.

[0117] At S1030, a context policy is generated. In some embodiments, the context policy is generated based on the application's policy and a network security object. In other embodiments, the context policy is generated based on the application's policy and an exception generated based on the network security object. In some embodiments, the application's policy includes rules such that the context policy includes rules applied beyond the case where an exception is true (e.g., the exception condition is true).

[0118] In some embodiments, exceptions are exclusive, while in others, exceptions are inclusive. According to an embodiment, exceptions are exclusive when the applied policy is applied to all instances except those where the exception condition is true.

[0119] In some embodiments, the exception is inclusive, meaning that the exception applies to some instances and to another instance, but if no exception condition exists, the applied policy will not apply to that other instance.

[0120] For example, in one embodiment, the rule includes a condition that containers cannot be deployed using plaintext passwords (network security objects). In this embodiment, a first plaintext password provides administrator privileges, while a second plaintext password provides limited privileges. Therefore, a contextual policy is generated based on the rule (e.g., no containers deployed using plaintext passwords) and the exception (e.g., plaintext passwords with limited privileges).

[0121] In one embodiment, a second plaintext password is detected on the deployed workload. In some embodiments, security graphs, identity and access management services, etc., are queried to determine the permissions associated with the second plaintext password. In another embodiment, the second plaintext password is associated with limited permissions (i.e., not administrator permissions), generating an exception for a policy rule that states that containers cannot be deployed with plaintext passwords.

[0122] At S1040, the admission controller is configured to apply context policies. In some embodiments, the admission controller is configured to periodically request policies, rules, exceptions, etc. In some embodiments, the admission controller applies context rules before deploying software containers in the software container cluster. In some embodiments, the admission controller is configured to apply context rules to each request sent to a software container in the software container cluster. In some embodiments, the admission controller is configured to apply context rules to each communication directed to a software container in the software container cluster.

[0123] In some embodiments, the context policy is generated by a unified policy engine and sent from the unified policy engine to each of a plurality of admission controllers, each admission controller being deployed in a software container cluster of a plurality of software container clusters. In some embodiments, each of the plurality of software container clusters is deployed in a different cloud computing environment. In some embodiments, each cloud computing environment is deployed on a different cloud computing infrastructure.

[0124] For example, according to an embodiment, the first software container cluster is deployed in a first cloud computing environment (e.g., a Virtual Private Cloud, VPC), and the first cloud computing environment is deployed in... The second cloud computing environment (e.g., Virtual Network, VNet) is deployed on AWS web services and a second software container cluster. superior.

[0125] Figure 11 This is an example flowchart 1100 of a method for service discovery in a computing environment implemented according to an embodiment.

[0126] At S1110, a code object is detected. In this embodiment, the code object is detected in a computing environment. In some embodiments, the code object includes a key (such as a public key, private key, etc.), a resource type, a policy identifier, a role identifier, a flag state, a combination thereof, etc.

[0127] In some embodiments, the computing environment is a cloud computing environment. In other embodiments, the cloud computing environment is a Virtual Private Cloud (VPC), Virtual Network (VNET), etc., implemented on cloud computing infrastructure.

[0128] According to an embodiment, the cloud computing infrastructure is, for example, AWS Web Services Cloud platforms (GCP), etc. In this embodiment, the code object is part of the declarative code.

[0129] In some embodiments, declarative code uses a declarative computer language, wherein the coordinator (e.g., such as...) Figure 1 (As shown) is configured to deploy instances in a cloud environment based on declarations in declarative code.

[0130] According to an embodiment, static analysis techniques are used to detect code objects by accessing code repositories, accessing files containing computer code, accessing command-line interfaces (CLI), and combinations thereof.

[0131] At S1120, resources are detected. In some embodiments, resources are deployed based on code objects. In an embodiment, resources are deployed in the computing environment based on the detected code objects. In an example embodiment, the code object includes an object type ( Figure 4 ,410), the object type indicates that the code object is a resource type, that is, executing instructions associated with the code object will result in the deployment of resources in a cloud computing environment.

[0132] In this example embodiment, the code object is a data structure with parameters (e.g., data fields) that are customized with data values ​​to generate entities such as resources and accounts in a cloud computing environment.

[0133] In some embodiments, network discovery techniques are used to detect resources. For example, in some embodiments, discovering resources in a network (e.g., a computing environment) includes determining the IP range used by the resources in the network and sending commands such as PING and SYN, which are used to determine the presence of the resources based on the responses.

[0134] In some embodiments, resources are detected in a computing environment (such as a cloud computing environment) by querying the API of the computing environment to discover the resources deployed therein.

[0135] At S1130, a representation of the code object is generated. In this embodiment, the representation of the code object is generated in a security database. In this embodiment, the security database also includes a representation of the computing environment.

[0136] In embodiments, representations are generated based on a unified data schema, which includes predefined templates, data structures, etc., for representing code objects. For example, in some embodiments, the security database is implemented as a graph database (such as...). It is stored based on a graph pattern, including different nodes, edges, etc.

[0137] In S1140, a representation of the resource is generated. In some embodiments, the representation of the resource is generated in a security database. In some embodiments, the representation of the resource is linked to the representation of the code object.

[0138] In some embodiments, the code object is represented by multiple nodes, each node representing a resource deployed based on the same code object.

[0139] For example, in one embodiment, multiple nodes of a software container are deployed based on a single image, such that the single image is a code object and the multiple nodes are resources among multiple resources. In such an embodiment, the single image is represented by a node in a security graph, and this node is connected to multiple nodes, each of which represents a node of the software container.

[0140] At S1150, a representation of the service is generated. In an embodiment, the representation of the service is generated in a security library. In some embodiments, the representation of the service is linked to the representation of the code object and the representation of the resource.

[0141] In embodiments, the representation of a service includes representations of dependent components (e.g., resources such as databases, messaging queues, etc.) connected to a secure database, representations of software artifacts, representations of repositories, representations of deployed instances, representations of code objects, and various combinations thereof.

[0142] In some embodiments, the representation of a service is connected to the representation of a service instance. In some embodiments, the service is utilized across multiple computing environments, such as Kubernetes clusters deployed in pre-release and production environments. In such embodiments, the service is represented in a security database that is connected to a first representation of the service instance (e.g., a cluster deployed in a pre-release environment) and a second representation of the service instance (e.g., a cluster deployed in a production environment).

[0143] At S1160, the code object is examined. In the example, a first network security object is examined within the code object. In some embodiments, the network security object is an identity object, a file, a folder, a file system, a software application, a software library, a software binary, an encryption key, a certificate, a password, a code object, a software call, a malware object, a combination thereof, etc.

[0144] In some embodiments, such as those described above Figure 1 The inspector, discussed in more detail, is configured to inspect code objects, for example, by reading a code file and parsing the code into data fields, extracting the values ​​of the data fields, and comparing the extracted values ​​with pre-existing values, value types, etc.

[0145] At S1170, resources are examined. For example, a second network security object is examined within the resources. In embodiments, examining resources includes utilizing static analysis techniques. According to some embodiments, examining resources includes detecting disks associated with the resources, such as disks provided or allocated to the resources.

[0146] In some embodiments, a checkable disk is generated based on a resource-based inspection disk. In some embodiments, a checkable disk is generated based on a clone, snapshot, copy, etc., of the original disk. In some embodiments, it is advantageous to generate a clone disk as a checkable disk because the clone disk is readily available, whereas, for example, snapshots require the entire snapshot data to be written before the snapshot becomes accessible for inspection.

[0147] At S1180, a context is generated. In an embodiment, a context is generated for the representation of the service. In some embodiments, the context of the service representation is generated based on a first result of inspecting the code object and a second result of inspecting the resource. In an embodiment, the context includes build time, code commit, security test results, executed policies, policy exceptions, a list of service instance identifiers, the identifier version of each service instance, combinations thereof, etc.

[0148] In an embodiment, the context includes the service owner, the risk level associated with the software service, the risk level associated with a component of the service, additional features (e.g., SLAs regarding bug fixes), the service's security contact, the service's source code, etc.

[0149] In some embodiments, the context also includes subject information, such as the subject accessing the service, the subject taking action on the service, the subject utilizing the service, the subject utilizing the components of the service, and combinations thereof.

[0150] Figure 12 This is an example flowchart 1200 of a method for enforcing network security policies on services in a computing environment, according to an embodiment. In the embodiment, policies are enforced on services, service instances, multiple service instances, combinations thereof, etc.

[0151] At S1210, software services are detected. In some embodiments, software services in a computing environment are detected. In certain embodiments, software services include code objects and resources. In some embodiments, software services are detected based on methods described in more detail herein.

[0152] In embodiments, the computing environment includes cloud computing environments, registry, repositories, CI / CD environments, CLI environments, and various combinations thereof. In some embodiments, each component of the computing environment is examined, for example, using static analysis, runtime data (e.g., using sensors deployed on the workload), and combinations thereof to detect network security objects.

[0153] In some embodiments, the detection service is based on the detection of code objects used to deploy multiple resources, software artifacts, forensic artifacts, events in cloud logs, and combinations thereof.

[0154] At S1220, a representation of the software service is generated. In some embodiments, the representation of the software service is generated in a security database. In some embodiments, the security database also includes a representation of the computing environment.

[0155] In some embodiments, the representation of the software service is connected to the representation of an instance of the software service. For example, according to some embodiments, multiple instances of the software service are deployed on different computing environments, such as production environments, pre-release environments, testing environments, etc.

[0156] At S1230, the policy is applied to the representation of the software service. In some embodiments, the policy includes conditional rules. In an embodiment, applying the policy to the representation of the software service includes providing the policy, conditional rules, representation of the software service, etc., to the policy engine. In an embodiment, the policy engine is configured to apply rules, for example, by determining whether a conditional rule is satisfied (e.g., whether it is "true").

[0157] For example, according to an embodiment, a conditional rule checks whether a database application is password protected. In this embodiment, the database representation (a component of the software service) is connected to the service representation. In some embodiments, the policy is applied to a database representation that does not include a password. Therefore, when a conditional rule is applied to the database representation, the conditional rule will result in a faulty (or "error") outcome.

[0158] At S1240, a remedial measure is initiated in response to the detection of a policy failure. In some embodiments, the remedial measure is initiated. In an embodiment, the remedial measure is initiated in response to the detection of a policy failure when a policy is applied to a representation of a software service.

[0159] According to an embodiment, the remedial measures include initiating remedial measures for each component of the software service, for a portion of the software service, or for a single component of the software service.

[0160] In this embodiment, remedial measures are initiated only for the components that cause the software service to fail due to policy malfunction. In some embodiments, remedial measures include updating the software, installing software patches, revoking access to resources, revoking access from resources, revoking access to subjects, revoking access from subjects, generating alerts, updating the severity of alerts, generating supporting tickets, updating the severity of supporting tickets, or combinations thereof.

[0161] In some embodiments, remedial measures are initiated for each instance of the software service. According to some embodiments, remedial measures are initiated on each instance of the software service corresponding to a specific version number. In some embodiments, a first remedial measure is initiated in a first computing environment, and a second remedial measure is initiated in a second computing environment.

[0162] Figure 13 This is an example flowchart 1300 of a method for managing network security policy anomalies on software services in a computing environment, according to an embodiment.

[0163] At S1310, a software service is detected. In some embodiments, a software service in a computing environment is detected. In some embodiments, a software service includes code objects and resources. In embodiments, a software service in a computing environment is detected. In some embodiments, a software service includes code objects and resources. In some embodiments, a software service is detected based on a method described in more detail herein.

[0164] In embodiments, the computing environment includes cloud computing environments, registry, repositories, CI / CD environments, CLI environments, and various combinations thereof. In some embodiments, each component of the computing environment is examined, for example, using static analysis, runtime data (e.g., using sensors deployed on the workload), and combinations thereof to detect network security objects.

[0165] In some embodiments, the detection service is based on the detection of code objects used to deploy multiple resources, software artifacts, forensic artifacts, events in cloud logs, and combinations thereof.

[0166] At S1320, a representation of the software service is generated. In some embodiments, the representation of the software service is generated in a security database. In this embodiment, the security database includes a representation of the computing environment.

[0167] In some embodiments, the representation of a software service is connected to the representation of a software service instance. For example, according to some embodiments, multiple instances of the software service are deployed on different computing environments, such as production environments, pre-release environments, and testing environments.

[0168] At S1330, the policy is applied to the representation of the software service. In some embodiments, the policy includes conditional rules. In an embodiment, applying the policy to the representation of the software service includes providing the policy, conditional rules, representation of the software service, etc., to the policy engine. In an embodiment, the policy engine is configured to apply rules, for example, by determining whether a conditional rule is satisfied (e.g., whether it is "true").

[0169] For example, according to an embodiment, a conditional rule checks whether a database application is password protected. In this embodiment, the database representation (a component of the software service) is connected to the service representation. In some embodiments, the policy is applied to a database representation that does not include a password. Therefore, when a conditional rule is applied to the database representation, the conditional rule will result in a faulty (or "error") outcome.

[0170] At S1340, a policy anomaly is detected. In some embodiments, a policy anomaly is detected in response to the application of a policy that causes a policy failure in a condition rule.

[0171] In the embodiments, policy exceptions are based on resource identifiers, software service identifiers, software service instance identifiers, computing environment identifiers (for deploying resources, software services, etc.), and various combinations thereof.

[0172] At S1350, it is determined that the software service passes the policy. In some embodiments, it is determined that the software service passes the policy in response to an application that causes a policy exception. In embodiments, the application of the policy exception is applied to all instances of the software service and to each of its components.

[0173] According to an embodiment, applying policy exceptions in this manner allows the generation of a single exception that applies to each software service instance, each of its components, and each computing environment in which the software service is deployed. This is advantageous in the embodiment because it reduces the number of policies used for computing environments and further eliminates the possibility of exception mismatches, ensuring that an exception is applied to one policy rather than another corresponding policy that would otherwise utilize multiple policies.

[0174] At S1360, remedial measures are initiated. In some embodiments, remedial measures are generated in response to determining that an application policy anomaly would cause a policy failure.

[0175] According to an embodiment, the remedial measures include initiating remedial measures for each component of the software service, for a portion of the software service, or for a single component of the software service.

[0176] In this embodiment, remedial measures are initiated only for the components that cause the software service to fail due to policy malfunction. In some embodiments, remedial measures include updating the software, installing software patches, revoking access to resources, revoking access from resources, revoking access to subjects, revoking access from subjects, generating alerts, updating the severity of alerts, generating supporting tickets, updating the severity of supporting tickets, or combinations thereof.

[0177] In some embodiments, remedial measures are initiated for each instance of the software service. According to some embodiments, remedial measures are initiated on each instance of the software service corresponding to a specific version number. In some embodiments, a first remedial measure is initiated in a first computing environment, and a second remedial measure is initiated in a second computing environment.

[0178] Figure 14 This is an example flowchart 1400 of a method for initiating remedial measures on a software service in a computing environment according to an embodiment.

[0179] At S1410, a software service is detected. In some embodiments, a software service in a computing environment is detected. In some embodiments, the software service includes code objects and resources. In some embodiments, a software service in a computing environment is detected. In some embodiments, the software service includes code objects and resources. In some embodiments, the software service is detected based on a method described in more detail herein.

[0180] In embodiments, the computing environment includes cloud computing environments, registry, repositories, CI / CD environments, CLI environments, and various combinations thereof. In some embodiments, each component of the computing environment is examined, for example, using static analysis, runtime data (e.g., using sensors deployed on the workload), and combinations thereof to detect network security objects.

[0181] In some embodiments, the detection service is based on the detection of code objects used to deploy multiple resources, software artifacts, forensic artifacts, events in cloud logs, and combinations thereof.

[0182] At S1420, a representation of the software service is generated. In some embodiments, the representation of the software service is generated in a security database. In some embodiments, the security database also includes a representation of the computing environment.

[0183] In some embodiments, the representation of a software service is connected to the representation of a software service instance. For example, according to some embodiments, multiple instances of the software service are deployed on different computing environments, such as production environments, pre-release environments, and testing environments.

[0184] At S1430, multiple components are detected. In an embodiment, a security database is traversed, queried, etc., to detect the multiple components. In some embodiments, each of the multiple components has a representation that is connected to a software service.

[0185] In one embodiment, a first group of components of the plurality of components is associated with a first instance of the software service, and a second group of components of the plurality of components is associated with a second instance of the software service.

[0186] At S1440, an inspection is initiated for network security objects on each component. In some embodiments, an inspection is initiated for each component of the software service to detect network security objects.

[0187] In some embodiments, components for inspecting the software service include generating clones, copies, snapshots, etc. In some embodiments, an inspectable disk is generated for inspection, which is inspected instead of the original disk, thereby allowing the original disk to remain undisturbed. This is particularly advantageous in production environments.

[0188] In some embodiments, examining resources includes utilizing static analysis techniques. According to certain embodiments, examining resources includes detecting disks associated with the resources, such as disks provided or allocated to the resources.

[0189] In some embodiments, a checkable disk is generated based on resource detection. In some embodiments, a checkable disk is generated based on a clone, snapshot, copy, etc., of the original disk. In some embodiments, it is advantageous to generate a cloned disk as a checkable disk because the cloned disk is readily available, whereas, for example, a snapshot requires the entire snapshot data to be written before it becomes accessible for inspection.

[0190] At S1450, remedial measures are initiated. In this embodiment, remedial measures are initiated for each component of the software service. In some embodiments, remedial measures are initiated for each component of the software service that detects a network security object.

[0191] In this embodiment, remedial measures are initiated only for the components that cause the software service to fail due to policy malfunction. In some embodiments, remedial measures include updating the software, installing software patches, revoking access to resources, revoking access from resources, revoking access to subjects, revoking access from subjects, generating alerts, updating the severity of alerts, generating supporting tickets, updating the severity of supporting tickets, or combinations thereof.

[0192] In some embodiments, remedial measures are initiated for each instance of the software service. According to some embodiments, remedial measures are initiated on each instance of the software service corresponding to a specific version number. In some embodiments, a first remedial measure is initiated in a first computing environment, and a second remedial measure is initiated in a second computing environment.

[0193] Figure 15 This is an example schematic diagram 1500 of a policy engine 190 according to an embodiment. The policy engine 190 includes processing circuitry 1510 coupled to a memory 1520, a storage device 1530, and a network interface 1540. In this embodiment, components of the policy engine 190 may be communicatively connected via a bus 1550.

[0194] The processing circuit 1510 can be implemented as one or more hardware logic components and circuits. For example, but not limited to, illustrative types of hardware logic components that can be used include field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), graphics processing units (GPUs), tensor processing units (TPUs), general-purpose microprocessors, microcontrollers, digital signal processors (DSPs), and any other hardware logic component that can perform computation or other information operations.

[0195] Memory 1520 may be volatile (e.g., random access memory, etc.), non-volatile (e.g., read-only memory, flash memory, etc.), or a combination thereof. In embodiments, memory 1520 is on-chip memory, off-chip memory, a combination thereof, etc. In some embodiments, memory 1520 is a note-taking memory for processing circuitry 1510.

[0196] In one configuration, software for implementing one or more embodiments disclosed herein may be stored in storage device 1530, memory 1520, or a combination thereof. Software should be interpreted broadly as any type of instruction, whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise. Instructions may include code (e.g., source code format, binary code format, executable code format, or any other suitable code format). When executed by processing circuitry 1510, the instructions cause processing circuitry 1510 to perform the various processes described herein.

[0197] Storage device 1530 is a magnetic storage device, an optical storage device, a solid-state storage device, a combination thereof, etc., and is implemented according to embodiments as flash memory, hard disk drive or other memory technology, or any other medium that can be used to store desired information.

[0198] Network interface 1540 is configured to provide policy engine 190 with communication with, for example, inspection API 740, software container cluster 710, etc.

[0199] It should be understood that the embodiments described herein are not limited to those described herein. Figure 15 The specific architecture shown herein may be used equivalently without departing from the scope of the disclosed embodiments.

[0200] Furthermore, in some embodiments, the software container cluster 710 can be used Figure 15 The architecture shown is used for implementation. In other embodiments, other architectures may be used equivalently without departing from the scope of the disclosed embodiments.

[0201] The various embodiments disclosed herein can be implemented as hardware, firmware, software, or any combination thereof. Furthermore, the software is preferably implemented as an application tangibly contained in a program storage unit or computer-readable medium, which comprises some or more devices and / or combinations of devices. The application can be uploaded to and executed by a machine including any suitable architecture. Preferably, the machine is implemented on a computer platform having hardware such as one or more central processing units (“CPUs”), memory, and input / output interfaces. The computer platform may also include an operating system and microinstruction code. The various processes and functions described herein may be part of the microinstruction code or part of the application, or any combination thereof, and can be executed by the CPU, whether or not such a computer or processor is explicitly shown. Furthermore, various other peripheral units may be connected to the computer platform, such as additional data storage units and printing units. Additionally, a non-transitory computer-readable medium is any computer-readable medium other than transient propagating signals.

[0202] All examples and conditional language cited herein are intended for educational purposes to aid the reader in understanding the principles of embodiments of this disclosure and the concepts contributed by the inventors to advance the art, and should be construed as not being limited to these specifically cited examples and conditions. Furthermore, all statements and specific examples of the principles, aspects, and embodiments of embodiments of this disclosure herein are intended to cover their structural and functional equivalents. Moreover, it is intended that such equivalents include both currently known equivalents and those developed in the future, i.e., any elements developed that perform the same function, regardless of their structure.

[0203] It should be understood that any reference to elements in this document using names such as "first," "second," etc., generally does not restrict the number or order of these elements. Rather, these names are generally used here as a convenient way to distinguish two or more elements or instances of elements. Therefore, references to the first and second elements do not imply that only two elements can be used there, or that the first element must somehow precede the second element. Furthermore, unless otherwise stated, a group of elements includes one or more elements.

[0204] As used herein, the phrase “at least one of…” followed by a series of items means that any of the listed items can be used alone, or any combination of two or more of the listed items can be used. For example, if a system is described as including “at least one of A, B, and C”, then the system can include only A; only B; only C; 2 A; 2 B; 2 C; 3 A; a combination of A and B; a combination of B and C; a combination of A and C; a combination of A, B, and C; a combination of 2 A and C; a combination of A, 3 B, and 2 C, and so on.

Claims

1. A method for initiating remedial measures for software services in a computing environment, comprising: Detect software services in a computing environment, the services including code objects and resources; A representation of the software service is generated in a security database, which also includes a representation of the computing environment; The security database is traversed to detect multiple components, each of which has a representation of a connection to the software service; Initiate a network security check on each component of the software service; Detect the representation of the code object connected to the software service; Detect the representation of the first resource deployed based on the code object; Detect the representation of the second resource deployed based on the code object; as well as In response to the detection that the representation of the first resource and the representation of the second resource are both connected to the representation of the code object in the security database, remedial measures are initiated for the first resource and the second resource.

2. The method according to claim 1, further comprising: In response to the detection of the cybersecurity object on any component of the software service, it is determined that the software service includes a cybersecurity issue.

3. The method according to claim 2, further comprising: The remedial measures were initiated based on the aforementioned cybersecurity issues.

4. The method according to claim 2, further comprising: A cybersecurity risk score is determined based on the aforementioned cybersecurity issues; as well as The remediation measures are prioritized based on the determined cybersecurity risk score.

5. The method according to claim 1, further comprising: The remedial measures are initiated for each component of the software service.

6. The method according to claim 1, further comprising: Apply the strategy to the representation of the software service; as well as In response to the determination that the applied strategy results in a predetermined binary outcome, the remedial measures are further initiated.

7. The method according to claim 1, wherein, The remediation measures include any of the following: revoking access to a resource, revoking access from a resource, revoking access from a subject, revoking access to a subject, sandboxing a resource, updating a software application, removing a software application, updating an operating system, installing software patches, generating an alert, generating a support ticket, updating the severity indicator of an alert, or a combination thereof.

8. The method according to claim 1, further comprising: The repair measures were determined to be unsuccessful; as well as A second remedial measure is initiated in response to the determination that the remedial measure is unsuccessful.

9. A non-transitory computer-readable medium storing a set of instructions for initiating remedial measures for software services in a computing environment, the set of instructions comprising: One or more instructions, when executed by one or more processing circuits of the device, cause the device to: Detect software services in a computing environment, the services including code objects and resources; A representation of the software service is generated in a security database, which also includes a representation of the computing environment; The security database is traversed to detect multiple components, each of which has a representation of a connection to the software service; Initiate a network security check on each component of the software service; Detect the representation of the code object connected to the software service; Detect the representation of the first resource deployed based on the code object; Detect the representation of the second resource deployed based on the code object; as well as In response to the detection that the representation of the first resource and the representation of the second resource are both connected to the representation of the code object in the security database, remedial measures are initiated for the first resource and the second resource.

10. A system for initiating remedial measures for software services in a computing environment, comprising: One or more processing circuits, said one or more processing circuits being configured to: Detect software services in a computing environment, the services including code objects and resources; A representation of the software service is generated in a security database, which also includes a representation of the computing environment; The security database is traversed to detect multiple components, each of which has a representation of a connection to the software service; Initiate a network security check on each component of the software service; Detect the representation of the code object connected to the software service; Detect the representation of the first resource deployed based on the code object; Detect the representation of the second resource deployed based on the code object; as well as In response to the detection that the representation of the first resource and the representation of the second resource are both connected to the representation of the code object in the security database, remedial measures are initiated for the first resource and the second resource.

11. The system according to claim 10, wherein, The one or more processing circuits are further configured to: In response to the detection of the cybersecurity object on any component of the software service, it is determined that the software service includes a cybersecurity issue.

12. The system according to claim 11, wherein, The one or more processing circuits are further configured to: The remedial measures were initiated based on the aforementioned cybersecurity issues.

13. The system according to claim 11, wherein, The one or more processing circuits are further configured to: A cybersecurity risk score is determined based on the aforementioned cybersecurity issues; and The remediation measures are prioritized based on the determined cybersecurity risk score.

14. The system according to claim 10, wherein, The one or more processing circuits are further configured to: The remedial measures are initiated for each component of the software service.

15. The system according to claim 10, wherein, The one or more processing circuits are further configured to: Applying the strategy to the representation of the software service; and In response to the determination that the applied strategy results in a predetermined binary outcome, the remedial measures are further initiated.

16. The system according to claim 10, wherein, The remedial measures include any one of the following: Revoke access to a resource, revoke access from a resource, revoke access from a subject, revoke access to a subject, sandbox a resource, update a software application, remove a software application, update an operating system, install a software patch, generate an alert, generate a support ticket, and update the severity indicator and combinations thereof for alerts.

17. The system according to claim 10, wherein, The one or more processing circuits are further configured to: It was determined that the remedial measures were unsuccessful; and A second remedial measure is initiated in response to the determination that the remedial measure is unsuccessful.

Images