System and method for verifying network security issues using runtime data

Abstract

A system and method for verifying network security issues using runtime data is disclosed. In an embodiment, the method comprises: checking a workload deployed in a computing environment for a network security problem; deploying a sensor on the workload, the sensor configured to collect runtime data from the workload; in response to verifying the network security issue from the collected runtime data, initiating a first mitigation measure having a first priority in the computing environment; in response to failing to verify the network security issue from the collected runtime data, a second mitigation measure having a second priority lower than the first priority is initiated.

Description

Technical Field

[0001] The present disclosure generally relates to the detection of cybersecurity threats, and more particularly to complementary solutions for detecting cybersecurity threats using static analysis and runtime data. Background Art

[0002] Cybersecurity threats come in many forms, such as malware, worms, man-in-the-middle attacks, code injection, misconfigurations, etc. Different threats pose different risks and can generally be detected in different ways. Thus, there are many solutions for detecting different types of cybersecurity threats, but each solution has its advantages and disadvantages. Cloud computing platforms, such as Amazon Web Services (AWS), Google Cloud Platform (GCP), Azure, etc., are high-value targets for attackers, so their vulnerabilities are more likely to become cybersecurity threats. Therefore, it is very useful to detect such cybersecurity threats.

[0003] For example, agent-based solutions are able to detect runtime and stored data, thus forming a complete picture of the cybersecurity state of the machine on which the agent is installed. However, agent-based solutions require a large amount of computing resources (such as processor and memory resources). This is because the agent is deployed on the machine being scanned. For endpoints in a network, this type of solution is impractical because the use of these resources is reserved for performing the tasks of the endpoint machine. In addition, some agent solutions also need to communicate with a backend that provides definitions, rules, etc., so that the agent can scan for cybersecurity threats using the latest information. In addition, some agent-based solutions require root privileges or are deployed as privileged software containers. This itself is a security risk because passing such permissions is risky. Therefore, as an endpoint detection and response (EDR) solution for cloud computing production environments, agent-based solutions cannot achieve their goals. In fact, for the reasons mentioned above, these solutions are rarely used for network endpoints.

[0004] On the other hand, agentless solutions do not require an agent to be installed on the machine. These solutions include static analysis, such as analyzing the disks of the machine to determine what cybersecurity threats exist. However, these solutions also cannot provide a complete picture because static analysis solutions cannot access runtime data. Such agentless solutions also cannot provide real-time threat detection, which may cause cybersecurity threats to go undetected for a long time before being responded to.

[0005] It is impractical to utilize these two types of solutions because there is an overlap in the data of agent and agentless solutions, and the computational cost of deploying both solutions on a single network is high. In practice, this leads to a choice between the two solutions and also results in some threats inevitably going undetected.

[0006] Accordingly, it would be advantageous to provide a solution that overcomes the above challenges. SUMMARY OF THE INVENTION

[0007] The following is an overview of several example embodiments of the present disclosure. This overview is provided to facilitate a basic understanding of these embodiments by the reader and does not fully delimit the scope of the present disclosure. This overview is not an extensive overview of all contemplated embodiments, nor is it intended to identify the key or important elements of all embodiments or to describe 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 presented later. For convenience, the term "some embodiments" or "certain embodiments" may be used herein to refer to a single embodiment or multiple embodiments of the present disclosure.

[0008] A system of one or more computers can be configured to perform particular operations or actions by installing software, firmware, hardware, or a combination thereof on the system, such that the system performs the actions in operation. One or more computer programs can be configured to perform particular operations or actions by including instructions that, when executed by a data processing device, cause the device to perform those actions.

[0009] In a general aspect, the method can include checking for network security issues in a workload deployed in a computing environment. The method can also include deploying a sensor on the workload, the sensor being configured to collect runtime data from the workload. The method can also include, in response to verifying a network security issue from the collected runtime data, initiating a first mitigation measure having a first priority in the computing environment. The method can also include, in response to failing to verify a network security issue from the collected runtime data, initiating a second mitigation measure having a second priority lower than the first priority. Other embodiments of this aspect include corresponding computer systems, apparatuses, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the method.

[0010] Embodiments may include one or more of the following features. The method may include: generating an inspectable disk based on a workload; and inspecting a network security object in the inspectable disk, where the network security object indicates a network security issue. The method may include: determining a reachability attribute of a workload; generating a network path between an external network and the workload; and initiating an active inspection of the network path to determine whether the workload is a reachable workload. The method may include: in response to determining that the workload is a reachable workload, initiating a first mitigation measure with a third priority higher than a first priority. The method may include: configuring sensors to collect: products, events, data link layer communications, permissions, a list of applications loaded in a memory, a list of libraries loaded in the memory, and combinations thereof. The method may include: initiating a first mitigation measure including any of the following: generating an alert, revoking a permission, revoking access to the workload, revoking access from the workload, sandboxing the workload, generating an alert, installing a software patch, uninstalling a software application, updating the priority of an alert, and any combination thereof. Embodiments of the described techniques may include hardware, methods or processes, or computer tangible media.

[0011] In one general aspect, a non-transitory computer-readable medium may include one or more instructions that, when executed by one or more processors of a device, cause the device to: inspect for network security issues in a workload deployed in a computing environment. The medium may also deploy a sensor on the workload, the sensor being configured to collect runtime data from the workload. The medium may also initiate, in the computing environment, a first mitigation measure with a first priority in response to validating a network security issue from the collected runtime data. Additionally, the medium may initiate a second mitigation measure with a second priority lower than the first priority in response to failing to validate a network security issue from the collected runtime data. Other embodiments of this aspect include corresponding computer systems, apparatuses, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the method.

[0012] In one general aspect, a system may include processing circuitry. The system may also include a memory that contains instructions that, when executed by the processing circuitry, configure the system to: check for cybersecurity issues in a workload deployed in a computing environment. The system may also deploy a sensor on the workload, the sensor being configured to collect runtime data from the workload. Additionally, the system may initiate a first mitigation measure with a first priority in the computing environment in response to verifying a cybersecurity issue from the collected runtime data. The system may also initiate a second mitigation measure with a second priority lower than the first priority in response to failing to verify a cybersecurity issue from the collected runtime data. Other embodiments of this aspect include corresponding computer systems, apparatuses, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the method.

[0013] Implementations may include one or more of the following features. A system in which the memory contains further instructions that, when executed by the processing circuitry, further configure the system to: generate an inspectable disk based on a disk of the workload; and check for cybersecurity objects in the inspectable disk, where the cybersecurity objects indicate cybersecurity issues. A system in which the memory contains further instructions that, when executed by the processing circuitry, further configure the system to: determine a reachability attribute of the workload; generate a network path between an external network and the workload; and initiate an active check of the network path to determine whether the workload is a reachable workload. A system in which the memory contains further instructions that, when executed by the processing circuitry, configure the system to: in response to determining that the workload is a reachable workload, initiate a first mitigation measure with a third priority higher than the first priority. A system in which the memory contains further instructions that, when executed by the processing circuitry, further configure the system to: configure the sensor to collect: artifacts, events, data link layer communications, permissions, a list of applications loaded in the memory, a list of libraries loaded in the memory, and combinations thereof. A system in which the memory contains further instructions that, when executed by the processing circuitry, further configure the system to: initiate a first mitigation measure including any of the following: generate an alert, revoke permissions, revoke access to the workload, revoke access from the workload, sandbox the workload, generate an alert, install a software patch, uninstall a software application, update the priority of an alert, and any combination thereof. Implementations of the described techniques may include hardware, a method or process, or a computer tangible medium. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The subject matter disclosed herein is particularly pointed out and distinctly claimed at the end of the specification in the claims. The above and other objects, features, and advantages of the disclosed embodiments will become apparent from the following detailed description when taken in conjunction with the accompanying drawings.

[0015] Figure 1 It is an exemplary schematic diagram of a cloud computing environment monitored for cybersecurity threats by an inspection environment implemented according to an embodiment.

[0016] Figure 2 It is an exemplary schematic diagram of a sensor backend server communicating with multiple sensors deployed on various workloads implemented according to an embodiment.

[0017] Figure 3 It is an exemplary flowchart of a method for performing cybersecurity threat detection on resources in a cloud computing environment implemented according to an embodiment.

[0018] Figure 4 It is an exemplary schematic diagram of a sensor backend server according to an embodiment.

[0019] Figure 5 It is an exemplary flowchart of a method for mitigating cybersecurity threats implemented according to an embodiment.

[0020] Figure 6 It is an exemplary flowchart of a method for leveraging a security graph in detecting cybersecurity threats based on threat metrics implemented according to an embodiment.

[0021] Figure 7 It is an exemplary flowchart of a method for performing vulnerability verification through multiple data sources implemented according to an embodiment.

[0022] Figure 8 It is an exemplary flowchart of a method for performing proactive inspection of a cloud computing environment implemented according to an embodiment. Detailed implementation manners

[0023] It is important to note that the embodiments disclosed herein are merely examples of many useful applications of the innovative teachings herein. In general, the statements in this application specification do not necessarily limit any of the various claimed embodiments. Additionally, some statements may apply to some inventive features but not to others. In general, unless otherwise stated, a singular element may be plural and vice versa without loss of generality. In the drawings, the same numbers represent the same components through several views.

[0024] The various disclosed embodiments include methods and systems for providing sensors on workloads deployed in a cloud computing environment to supplement the detection of cybersecurity threats using static analysis techniques. The sensors are software packages that can be executed on a machine, such as an endpoint machine. The endpoint machine (or simply "endpoint") can be, for example, an agent, a gateway, a reverse proxy, a web server, etc. The sensors can be deployed on the endpoints using fewer resources than agents because the sensors are configured to retrieve and analyze less data than the agent software. This is because the sensor functionality is supplemented by a static analysis solution, such as a cybersecurity threat checker.

[0025] In an embodiment, the sensor is configured to listen on the data link layer. For example, in an embodiment, the sensor is configured to listen for packets using the extended Berkeley packet filter (eBPF) interface. In some embodiments, the sensor is configured to request rules, definitions, etc. from a sensor backend server. For example, the sensor is configured to apply the rules in the requested rules, definitions, etc. to events detected by listening on the eBPF interface of the machine on which the sensor is deployed. In some embodiments, the sensor is configured to send an event to the sensor backend server, for example, in response to determining that the event matches a predefined definition.

[0026] In some embodiments, the sensor is configured to send an event to the sensor backend server, for example, based on a predefined definition. The sensor backend server is configured to store the event on a security graph. The security graph includes a representation of the cloud computing environment in which the endpoints are deployed. For example, the sensor can detect that an endpoint is sending network packets to an IP address associated with a known cybersecurity risk. The sensor is configured to generate a notification to the sensor backend server. In an embodiment, the sensor backend server is configured to generate instructions for an inspection controller. The inspection controller is in turn configured to provide an inspector to check for the presence of malware in the endpoint.

[0027] By performing runtime and static analysis in this way, the detection overlap between the sensor and the inspector is reduced. In addition, the sensor is able to initiate the inspection of the inspector, which allows for effective prioritization of inspection resources, thereby reducing the time to detect cybersecurity threats and also reducing the time required to respond to cybersecurity threats.

[0028] Figure 1 is an example schematic diagram of a cloud computing environment being monitored for cybersecurity risks by an inspection environment according to an embodiment. In an embodiment, the cloud computing environment 110 is implemented as a virtual private cloud (VPC), a virtual network (VNet), etc. on a cloud computing platform. The cloud computing platform can be provided by, for example Amazon Web Services (AWS), Google Cloud Platform (GCP), Provided by Azure, etc. The cloud computing environment 110 includes cloud entities deployed therein. Cloud entities can be, for example, principals, resources, and their combinations, etc. In an embodiment, a resource is a cloud entity that provides access to computing resources (such as processors, memories, storage devices, etc.). In some embodiments, a resource is a virtual machine, a software container, a serverless function, etc. A resource can be or can include a software application deployed thereon, such as a web server, a gateway, a load balancer, a web application firewall (WAF), a device, etc.

[0029] In certain embodiments, a principal is a cloud entity authorized to initiate measures in the cloud computing environment. For example, a cloud entity can be, for example, a user account, a service account, a role, etc. In some embodiments, a cloud entity is a principal relative to another cloud entity and also a resource relative to other cloud entities. For example, a load balancer is a resource for a user account that requests a web page from a web server behind the load balancer, and the load balancer is a principal for the web server.

[0030] The cloud computing environment 110 includes multiple resources, such as virtual machines 112, a software container orchestrator 114, and serverless functions 116. For example, a virtual machine 112 can be deployed by using, for example, A virtual machine 112 can be deployed by using, for example, An engine, An engine, etc. to deploy the software container orchestrator 114. In an embodiment, the software container orchestrator 114 is configured to deploy software clusters, and each cluster includes multiple nodes. In an embodiment, a node includes multiple Pods. The serverless function 116 can be used, for example, with Lambda. In an embodiment, the serverless function 116 is a serverless function container image.

[0031] Each such resource is vulnerable to various cybersecurity threats. For example, such threats may become apparent due to software versions of applications in the software container 114, operating system (OS) versions of the virtual machine 112, code configuration errors of the serverless function 116, etc. The cloud computing environment 110 is monitored for cybersecurity threats by the inspection environment 120. In an embodiment, the inspection environment is implemented as a cloud computing environment (such as a VPC, a VNet, etc.).

[0032] In an embodiment, each of the virtual machine 112, the software container 114, and the serverless function 116 includes sensors configured for specific resources, resource types, and their combinations, etc. Examples of sensor deployments are discussed in more detail below. Figure 2 Examples of sensor deployments are discussed in more detail below.

[0033] In an embodiment, the sensor ( Figure 1(not shown in the figure) is configured to listen for events, data packets, etc. at the data link layer. For example, the sensor is configured to utilize an eBPF interface, which allows non-intrusive monitoring of data link layer communications. In some embodiments, the sensor is also configured to send data to and receive data from the sensor backend server 128. The sensor backend server 128 is a workload (such as a virtual machine, software container, serverless function, and combinations thereof, etc.) deployed in the inspection environment 120.

[0034] In an embodiment, the sensor backend server 128 is configured to receive data generated by the sensor. For example, in an embodiment, the sensor backend server 128 is configured to receive events from the sensor. In some embodiments, the sensor is configured to request rules, definitions, etc. from the sensor backend server 128, and the sensor is configured to apply them to events (such as events detected on the eBPF interface). For example, a predefined event (such as indicating access to an IP address, IP address range, etc.) can be checked according to a definition. A definition is a logical expression that, when applied to an event, produces a "true" or "false" result. In an embodiment, a rule is a logical expression that includes a measure. For example, a rule can be that if a certain definition is true when applied to an event, the data related to that event should be sent to the sensor backend server 128.

[0035] In some embodiments, the sensor backend server 128 is configured to initiate an inspection of resources deployed in the cloud computing environment 110. For example, the sensor backend server 128 can be configured to initiate such an inspection in response to receiving events, data, and combinations thereof, etc. from sensors deployed on the resources. In an embodiment, the initiation of the inspection of the resources is performed by generating instructions for the inspection controller 122, which, when executed, configure the inspector 124 to inspect the resources.

[0036] For example, the sensor is configured to send event data to the sensor backend server 128 in response to detecting that a definition applied by the sensor to a detected event produces a "true" value. For example, the definition can be "IP addresses in the range from 127.0.0.1 to 127.0.0.99", which in this example corresponds to the IP address range used by malware. When the definition is applied to, for example, a detected network packet and the result is "true", the sensor is configured to send the data related to the event to the sensor backend server 128. The data related to the event can be, for example, an IP address, an event type, and combinations thereof, etc.

[0037] In an embodiment, the sensor backend server 128 is configured to receive data. In some embodiments, the sensor backend server 128 is further configured to apply rules to the received data to determine whether an inspection of the workload where the sensor is deployed should check for cybersecurity risks. For example, the sensor backend server 128 is configured to generate instructions to inspect the virtual machine 112 in response to an indication received from a sensor deployed as a service on a virtual machine, i.e., detecting communication between the virtual machine 112 and a server with a prohibited IP address (such as an IP address associated with malware).

[0038] For example, the sensor backend server 128 may generate instructions for the inspection controller 122, which, when executed by the inspection controller (such as by using a snapshot, copy, clone, etc. of a disk (not shown) associated with the virtual machine 112), generates an inspectable disk and provides access to the inspectable disk to the inspector 124. In an embodiment, the inspector 124 is configured to detect cybersecurity threats. For example, in an embodiment, the inspector 124 is configured to receive the hash of an application stored on the inspectable disk and determine whether the hash matches the hash of a known malware application. In certain embodiments, a persistent volume claim (PVC) for the inspectable disk is provided to the inspector 124.

[0039] In some embodiments, the sensor is configured to generate a hash of an application on the resource (such as the virtual machine 112) where it is deployed and send the hash to the sensor backend server 128. Then, for example, by providing the received hash to the inspector 124, it is compared with known hash values corresponding to malware applications.

[0040] Although the above examples discuss malware, it is clear that the sensors and the inspector 124 can be used to detect other types of cybersecurity threats (such as exposures, vulnerabilities, weak passwords, exposed passwords, misconfigurations, etc.).

[0041] In some embodiments, the inspection environment 120 further includes an active inspector 125. In an embodiment, the active inspector is configured to detect the reachability properties of the workloads deployed in the cloud computing environment 110 and determine whether the network path is a viable network path by performing an active inspection. According to some embodiments, an active inspection is initiated in response to verifying a vulnerability, misconfiguration, exposure, etc. through a sensor.

[0042] In certain embodiments, the inspection environment 120 further includes a security database 126, which includes a representation of the computing environment 110. In some embodiments, the security database 126 stores a security graph, for example, as a graph database.

[0043] In an embodiment, the security graph is configured to store a representation of a cloud computing environment (e.g., cloud computing environment 110). For example, the representation can be based on a predefined unified data schema, such that each different cloud platform can be represented using the unified data schema, thereby allowing for a unified representation. For example, a principal can be represented by a predefined data structure, and each principal is represented by a node in the security graph. Similarly, a resource can be represented by another predefined data structure, and each resource is represented by a node in the security graph.

[0044] In some embodiments, data received from sensors on resources deployed in a cloud computing environment can be stored in a graph database as part of the security graph. In the above example, in an embodiment, in response to receiving data from a sensor indicating a potential malware infection of virtual machine 112, the sensor backend server 128 is configured to: generate a node representing the malware in the security graph, generate a node representing virtual machine 112 in the security graph, and connect the node representing the malware to the node representing virtual machine 112.

[0045] Figure 2 FIG. is an exemplary schematic diagram of a sensor backend server communicating with multiple sensors deployed on various workloads according to an embodiment. In some embodiments, the sensor backend server 128 is configured to communicate with a machine (not shown) on which a sensor is installed and communicatively coupled to the sensor backend server 28. In an embodiment, the machine is a computing device such as a bare metal machine, a computer device, a networked computer device, a laptop, a tablet, etc.

[0046] In an embodiment, the sensor backend server 128 is implemented as a virtual machine, a software container, a serverless function, and combinations thereof, etc. In some embodiments, multiple sensor backend servers 128 can be implemented. In some embodiments that utilize multiple sensor backend servers 128, a first group of the multiple sensor backend servers is configured to communicate with sensors on resources deployed on a first type of resource (e.g., virtual machines), and a second group of sensor backend servers is configured to communicate with a second type of resource, and so on. In an embodiment, the first group of sensor backend servers is configured to communicate with sensors on resources in a first cloud computing environment deployed on a first cloud platform (e.g., AWS), and the second group of sensor backend services is configured to communicate with sensors deployed on resources in a second cloud computing environment on a second cloud platform (e.g., GCP).

[0047] The virtual machine 112 includes a sensor 210. In an embodiment, the sensor 210 is deployed as a service executed on the virtual machine 112. In some embodiments, the virtual machine 112 is configured to request binary code, software packages, etc. from, for example, the sensor backend server 128, which, when executed by the virtual machine 112, causes the sensor 210 to run as a service on the virtual machine 112. The sensor 210 is configured to listen for data link layer communications through, for example, the eBPF interface.

[0048] The container cluster 114 runs a daemon set and includes multiple nodes (such as node 220). The daemon set ensures that each node 220 runs a daemon set pod 222 configured as a sensor. For example, The cluster may execute a daemon set configured to deploy a daemon set pod on each deployed node, where the daemon set pod is configured to (e.g., through the eBPF interface) listen for data link layer communications, listen for communications of multiple pods (such as pod-1224 to pod-N 226), where 'N' is an integer with a value of '1' or greater. In an embodiment, the daemon set pod 222 is configured to communicate with the sensor backend server 128.

[0049] In an embodiment, the serverless function 116 includes function code 232 and multiple code layers 1 to M (labeled 234 to 236 respectively), where "M" is an integer with a value of '1' or greater. For example, in AWS Lambda in an embodiment, the layer contains code, content, and their combinations, etc. In some embodiments, a layer such as layer 234 includes runtime data, configuration data, software libraries, etc.

[0050] In certain embodiments, the serverless function 116 includes a sensor layer 238. In an embodiment, the sensor layer 238 is configured to listen for data link layer communications of the serverless function 116 through, for example, the eBPF interface.

[0051] According to an embodiment, each of the sensor service 210, the daemon set pod 222, and the sensor layer 238 is an implementation of a sensor. In an embodiment, the sensor is configured to communicate with the sensor backend server 128 through a transport layer protocol such as TCP. For example, in an embodiment, the sensor backend server 128 is configured to listen on a predetermined port using the TCP protocol, and the sensors (such as the sensor 210, the daemon set pod 222, and the sensor layer 238) are all configured to communicate with the sensor backend server 128 (e.g., by initiating communication using TCP on the predetermined port).

[0052] Figure 3FIG. 300 is an example flowchart of a method for performing network security threat detection on resources in a cloud computing environment implemented according to an embodiment.

[0053] At S310, sensor software is provided for the resource. In an embodiment, the resource is any one of a virtual machine, a software container, a serverless function, etc. In some embodiments, the sensor software is provided based on the resource type. For example, a virtual machine is equipped with a software package (such as executable code (e.g., binary code)). A software container engine is equipped with a set of daemons such that in an embodiment where a node is deployed in a software container engine cluster, the node is configured as a set of daemon pods that provide the function of a sensor as described above. In an embodiment, a sensor layer is provided for a serverless function, for example, by providing code in a.ZIP file.

[0054] In an embodiment, providing the sensor includes configuring the resource (such as a virtual machine, a software container, a serverless function, etc.) to receive software that, when executed, configures the resource to deploy the sensor thereon.

[0055] At S320, events are detected from data link layer communications. In an embodiment, the data link layer is monitored for events through an eBPF interface. In some embodiments, a software bill of materials (SBOM) is generated. The SBOM can be implemented as a text file that is based on, for example, events detected through the eBPF interface. In an embodiment, the SBOM includes identifiers of libraries accessed at runtime, identifiers of binaries accessed at runtime, images whose instances are deployed at runtime, ports accessed by a runtime program, cryptographic hash function values (such as SHA1, SHA2, etc.). For example, the SBOM can include:

[0056]

[0057]

[0058]

[0059] This portion of the SBOM represents the execution of a remote procedure call (RPC) that is configured to receive a client request to mount a file system.

[0060] At S330, the event matches the definition. In some embodiments, the definition includes a logical expression that, when applied to the event, produces a "true" or "false" value. For example, when applied to an event, the definition might state "software library xyz has been accessed", resulting in true or false. In some embodiments, a rule is applied to the event. In an embodiment, the rule is a logical expression that further includes a measure. For example, in an embodiment, the rule states "if unknown software accesses software library xyz, then generate an alert". In this example, when an event is detected where software with an unknown identifier (e.g., not matching a list of pre-approved identifiers) attempts to access software library xyz, an alert is generated to indicate that such access has occurred.

[0061] At S340, a check is performed to determine whether data should be transferred to the inspection environment. In some embodiments, the check is performed by applying a rule to the event and determining the transfer based on the output of the applied rule. If 'yes', then execution continues at S350; if 'no', then execution continues at S360.

[0062] At S350, the corresponding data of the event is transferred to the inspection environment. In an embodiment, the data is based on an SBOM file. In some embodiments, the data includes event data such as identifiers of resources (such as virtual machines, software containers, serverless functions, etc.), identifiers of applications, hash values, uniform resource locator (URL) requests, software library identifiers, software binary file identifiers, timestamps, etc.

[0063] At S360, a check is performed to determine whether resource monitoring should continue. For example, a daemon set of a container can be configured to periodically deploy daemon set pods to monitor pods in a node. As another example, a virtual machine can be configured to periodically deploy a sensor service that runs as a process on the virtual machine, terminate the process after a predetermined period of time, terminate the process after detecting a predetermined number of events, etc. In some embodiments, the check is performed based on a predetermined amount of elapsed time (e.g., every four hours, daily, twice a day, etc.). If 'yes', then execution continues at S320. If 'no', then in an embodiment, termination is performed. In some embodiments, if 'no', then another check is performed at S360 (e.g., after a predetermined period of time has elapsed).

[0064] Figure 4 It is an example schematic diagram of a sensor backend server 128 according to an embodiment. The sensor backend server 128 includes a processing circuit 410 coupled to a memory 420, a storage device 430, and a network interface 440. In an embodiment, the components of the sensor backend server 128 can be communicatively connected via a bus 450.

[0065] The processing circuit 410 can be implemented as one or more hardware logic components and circuits. For example, but not limited to, exemplary 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), Systems on Chip (SOCs), Graphics Processing Units (GPUs), Tensor Processing Units (TPUs), general microprocessors, microcontrollers, Digital Signal Processors (DSPs), etc., or any other hardware logic components that can perform computations and other information operations.

[0066] The memory 420 can be volatile (e.g., random access memory, etc.), non-volatile (e.g., read-only memory, flash memory, etc.), and combinations thereof.

[0067] In one configuration, the software for implementing one or more embodiments disclosed herein can be stored in the storage device 430. In another configuration, the memory 420 is configured to store such software. Software should be interpreted broadly as any type of instruction, whether it is called software, firmware, middleware, microcode, hardware description language, or others. The instructions can include code (e.g., source code format, binary code format, executable code format, or any other suitable code format). When the instructions are executed by the processing circuit 410, the processing circuit 410 is caused to perform the various processes described herein.

[0068] The memory 430 can be a magnetic memory, an optical memory, etc., and can be implemented as, for example, flash memory and other memory technologies, Compact Disc Read-Only Memory (CD-ROM), Digital Versatile Disc (DVD), or any other medium that can be used to store the required information.

[0069] The network interface 440 allows the sensor backend server 128 to communicate with, for example, the sensor 210, the daemon set pod 222, the sensor layer 238, etc.

[0070] It should be understood that the embodiments described herein are not limited to Figure 4 the specific architecture shown, and other architectures can be equally used without departing from the scope of the disclosed embodiments.

[0071] In addition, in certain embodiments, the inspection controller 122, the inspector 124, etc. can be implemented with Figure 4 the architecture shown. In other embodiments, other architectures can be equally used without departing from the scope of the disclosed embodiments.

[0072] Figure 5 is an example flowchart 500 of a method for mitigating cybersecurity threats implemented according to an embodiment.

[0073] In S510, an instruction for performing an inspection is generated. In an embodiment, a resource is inspected, and the resource can be, for example, a virtual machine, a software container, a serverless function, etc. In an embodiment, when the instruction is executed, an inspectable disk is generated based on the disk of the resource. For example, in an embodiment, the inspectable disk is generated by performing a snapshot, clone, copy, duplicate, etc. of the disk connected to the virtual machine. The inspector can access the inspectable disk. In an embodiment, the inspector utilizes static analysis techniques (such as detecting network security objects (such as passwords, certificates, application binaries, software libraries, hashes, etc.)).

[0074] In an embodiment, the detected network security objects, network security threats, etc. are represented in a security graph. For example, in an embodiment, a node is generated to represent a malware object. The node representing the malware object is connected to the node representing the resource on which the inspector detected the malware object to indicate that the malware object exists on the resource.

[0075] In S520, a network security threat is detected. In an embodiment, in response to detecting a network security object on the disk, a network security threat is detected. In some embodiments, network security threats refer to exposures, vulnerabilities, misconfigurations, malware code objects, hashes, and combinations thereof, etc. In some embodiments, the detected or generated hash is compared with another hash in a list of hashes indicating known network security threats. For example, malware code objects are typically detected by generating a hash value of the code object and comparing it with the hash value stored in a database of known hash values related to malware. In some embodiments, the network security threat is a potential network security threat. In an embodiment, runtime data is utilized to determine whether the potential network security threat is an actual network security threat.

[0076] In S530, runtime data is received. In an embodiment, the runtime data is received from the resource being inspected. In some embodiments, the runtime data is received based on the network security objects detected by a static analysis method performed on the resource. For example, when the inspector accesses an inspectable disk generated based on the disk of a virtual machine deployed in a cloud computing environment, an application library is detected as a network security object. In an embodiment, a definition is generated based on the detected network security object. For example, the network security object may be the binary file of application "xyz". A definition is generated according to the detected network security object, such as "application xyz is deployed at runtime". In an embodiment, for example, a rule is generated based on the definition, further stating that "if application xyz is deployed at runtime, then mitigation measures are executed".

[0077] At S540, an instruction to execute a mitigation measure is generated. In an embodiment, when the instruction is executed, the mitigation measure is initiated in a cloud computing environment where resources are deployed. In some embodiments, the mitigation measure is generated based on a detected cybersecurity threat and received runtime data. In certain embodiments, the mitigation measure includes generating an alert, assigning a severity score to the alert (e.g., low, medium, severe, critical), modifying the severity score of the alert, and the like.

[0078] Although static analysis techniques can detect such cybersecurity objects and threats, runtime data is needed to determine whether the cybersecurity objects and threats actually exist at runtime. For example, a database with a configuration error (such as no password protection) is considered a cybersecurity threat. Generally, an alert is generated when such a cybersecurity threat is detected, and a mitigation measure is initiated. However, in a cloud computing production environment, many such alerts are generated, so it is desirable to prioritize the alerts based on, for example, the severity of the event. In this example, if there is no process managing the database at runtime, then the severity of the cybersecurity threat is actually lower than when the database software is running, so it constitutes an actual cybersecurity threat. Therefore, it is beneficial to combine static analysis data with runtime data in an effective manner to prioritize responses (such as mitigation measures) to detected cybersecurity threats. This allows for better utilization of the computing resources of the cloud computing environment and shortens the response time to cybersecurity threats based on the actual severity.

[0079] Figure 6 FIG. 600 is an example flowchart of a method for leveraging a security graph in detecting a cybersecurity threat based on threat indicators, implemented according to an embodiment.

[0080] At S610, threat indicators (IOCs) are received. In an embodiment, the IOCs are received from a sensor configured to detect the IOCs. In certain embodiments, the IOCs are data (e.g., network traffic data, login data, access data, data requests, etc.). For example, in an embodiment, the IOC data indicates abnormal network traffic, abnormal login times, abnormal login user session times, a large number of data requests, network traffic to a restricted domain, network communication to a suspicious geographical region, network traffic with a mismatched port application (i.e., sending command and control communication as a DNS request through port 80), and the like.

[0081] In certain embodiments, the IOC data is generated based on the aggregation of events detected on a resource (e.g., a virtual machine). In an embodiment, the sensor is configured to store multiple events and generate aggregated data based on the stored multiple events. For example, in an embodiment, the network traffic destinations are stored to perform anomaly detection (i.e., detect abnormal network traffic destinations).

[0082] At S620, traverse the security graph to detect network security threats. In an embodiment, instructions are generated which, when executed by a graph database, configure a database management system to execute a query to detect nodes in a security graph stored on the graph database. In certain embodiments, the detected nodes represent resources where sensors are deployed, and the sensors generate the IOC data received at S610.

[0083] In certain embodiments, traverse the security graph to detect nodes representing network security threats corresponding to the IOCs and connected to nodes representing resources that generate the IOCs. For example, a query is generated based on the IOC data and executed on the security graph. In an embodiment, the execution of the query returns results.

[0084] At S630, perform a check to determine whether a network security threat has been detected. In an embodiment, the check includes receiving the results of a query executed on the security graph and determining whether nodes representing resources are connected to nodes representing network security threats. If 'yes', proceed to execute S660. If 'no', continue to execute at S640.

[0085] At S640, generate a node to represent the IOC in the security graph. In an embodiment, the IOC data is stored with the node. In certain embodiments, an identifier of the IOC can be assigned to the IOC data, and the identifier of the IOC is stored with the node in the graph database.

[0086] At S650, generate an edge that connects the node representing the IOC to the node representing the resource. In an embodiment, the resource is the resource from which the IOC originated. For example, an edge can be generated that connects the node representing the IOC to the node representing the resource.

[0087] At S660, generate mitigation measures. In an embodiment, generating mitigation measures includes generating instructions which, when executed, configure a computing device to initiate the mitigation measures. In an embodiment, the mitigation is to initiate an inspection of the resource, generate an alert, an alarm, and combinations thereof, etc. In certain embodiments, the alert is generated based on any one of the following: IOC data, resource identifier, pre-determined rules, and combinations thereof, etc. In an embodiment, initiating an inspection of the resource includes generating instructions which, when executed in a cloud computing environment, configure the cloud computing environment to generate an inspectable disk and provide access to an inspector workload for the inspectable disk to check whether there is a network security threat corresponding to the IOC data.

[0088] Figure 7 It is an example flowchart of a method for performing vulnerability verification through multiple data sources implemented according to an embodiment. Although vulnerability verification is discussed in this example embodiment, it is obvious that other network security issues (such as exposure, misconfiguration, etc.) are verified by leveraging multiple data sources.

[0089] At S710, check the network security issues of the disk. In an embodiment, checking the network security issues of the disk includes detecting network security objects on the disk. In some embodiments, the network security objects are encryption keys, certificates, applications, binary files, libraries, hashes, code objects, nested workloads, malware objects, misconfigurations, vulnerabilities, permissions, valid permissions, and combinations thereof, etc.

[0090] In certain embodiments, checking the network security objects in the disk includes generating an inspectable disk based on the original disk. For example, the original disk is a disk allocated to a virtual machine, a software container, a serverless function, etc.

[0091] In some embodiments, generating an inspectable disk includes generating a copy, a clone, a snapshot, etc., and using the generated copy, clone, snapshot, etc. as the basis for the inspectable disk.

[0092] In an embodiment, provide access to the inspectable disk to an inspector configured to check network security objects (e.g., provide access to the detectable disk through a supposed service account).

[0093] In certain embodiments, the inspector is configured on demand (e.g., configured by an inspection controller according to the demand for the inspector workload). In an embodiment, cancel the inspector workload in response to detecting a competition for network security inspection.

[0094] At S720, deploy sensors on the workload. In an embodiment, the sensors are deployed on the workload associated with the disk. In some embodiments, deploy the sensors using the method described in more detail above.

[0095] In certain embodiments, the sensors are configured by a sensor backend server, for example, to detect events, permissions, runtime artifacts, objects, running code, running applications, loaded applications, and combinations thereof, etc.

[0096] In an embodiment, the sensors are configured to detect events, artifacts, etc. based on the detection of network security objects during inspection. For example, according to an embodiment, the sensor backend server is configured to configure the sensors to detect specific artifacts, events, etc. based on detecting, for example, a misconfiguration on an inspectable disk associated with the workload where the sensors are deployed.

[0097] At S730, perform an inspection to determine whether the network security issues are verified. In an embodiment, verifying the network security issues includes receiving inspection results (e.g., static analysis), receiving signals from sensors (e.g., detecting events, artifacts, etc.), receiving results from proactive inspections, and combinations thereof. Proactive inspections will be discussed in more detail below with reference to Figure 8 Proactive inspections will be discussed in more detail below.

[0098] In some embodiments, when a cybersecurity issue is verified, execution continues at S740. In certain embodiments, when a cybersecurity issue is not verified, execution continues at S750. In an embodiment, when a cybersecurity issue is not verified, execution continues at S750.

[0099] At S740, mitigation measures are initiated. In some embodiments, initiating mitigation measures includes storing metrics in a security database to indicate that a cybersecurity issue has been verified. In some embodiments, the mitigation measures include storing metrics in a security database to indicate that a cybersecurity issue has been verified by runtime data, proactive checks, inspections, and combinations thereof.

[0100] In certain embodiments, the mitigation measures include initiating a remediation measure. For example, in an embodiment, software data packets are detected by static analysis. In some embodiments, the software includes vulnerabilities that can be exploited via a network path. In an embodiment, a proactive checker is configured to check the network path to determine whether a software data packet vulnerability can be exploited.

[0101] In some embodiments, a sensor is configured to determine whether a software data packet is deployed at runtime. For example, in an embodiment, a software package is deployed at runtime, where the software package is loaded into the memory of a workload (e.g., virtual memory).

[0102] In certain embodiments, proactive checks are initiated only in response to verifying a runtime vulnerability. This is advantageous because proactive checks require the allocation of computing resources, which is wasted if the software data packet is not actually running during workload deployment. According to an embodiment, a software data packet can be installed on a workload without running during deployment.

[0103] In some embodiments, the mitigation measures include priorities. For example, in an embodiment, a cybersecurity issue verified at runtime is stored with a higher priority value (e.g., a qualitative priority value, a quantitative priority value, and combinations thereof) than a cybersecurity issue not verified at runtime.

[0104] According to an embodiment, the mitigation measures include generating an alert, revoking permissions, revoking access to a workload, revoking access from a workload, sandboxing a workload, generating an alert, installing a software patch, uninstalling a software application, updating the priority of an alert, and combinations thereof.

[0105] In S750, mitigation measures are preferentially considered. In an embodiment, when a cybersecurity issue is invalid or is found not to be a valid cybersecurity issue, the cybersecurity issue still exists on the workload. For example, an inspection of the workload shows that the workload includes 100 software data packets, among which 20 are deployed at runtime. Among the remaining 80 undeployed software data packets, 2 have vulnerabilities, and among the 20 deployed software data packets, 5 contain vulnerabilities.

[0106] According to the embodiment, compared with the 2 software data packets not deployed at runtime, it is more effective to preferentially initiate mitigation measures for the 5 software data packets deployed and detected at runtime. This is because in order to exploit a vulnerability in an application, the application usually has to be executed. Therefore, according to the embodiment, the priority of mitigation measures for cybersecurity issues not verified at runtime is lower than that for cybersecurity issues verified at runtime.

[0107] Figure 8 It is an example flowchart of a method for performing proactive inspection of a cloud computing environment implemented according to an embodiment.

[0108] In S810, the network path of the first resource in the cloud computing environment is received. The network path, also known as object reachability, includes data (such as reachability parameters) for accessing the first resource from a public network, which is not the cloud computing environment of the first resource (such as the Internet). In an embodiment, the proactive checker can receive at least one network path from, for example, a security graph. In an embodiment, S820 includes generating an instruction (or instructions) that, when executed by a database system storing the security graph, returns the results of one or more resources and the corresponding network paths of each resource. In some embodiments, the network path can be received periodically.

[0109] In some embodiments, the first resource can be one of a plurality of first resources, and each first resource is substantially the same. For example, a group of virtual machines generated based on the same code or image are substantially the same because their initial deployment will be the same except for the unique identifier assigned to each machine. In such an embodiment, in order to reduce the required computing and network resources, it may be beneficial to check a subset of the plurality of first resources in at least one network path. This may be acceptable in such an embodiment because it is expected that multiple VMs will be accessible in similar network paths. In some embodiments, the subset includes one or more first resources.

[0110] In an embodiment, each received network path includes a set of reachability parameters to reach a specific cloud object in a cloud environment. The reachability parameters, as well as the network paths, are generated by statically analyzing the cloud environment. An example method of such static analysis is discussed in more detail in U.S. Patent Application No. 17 / 659,164, titled "Techniques for Active Inspection of Vulnerability Exploitation Using Exposure Analysis", the entire content of which is incorporated herein by reference.

[0111] In S820, an access instruction for accessing a first resource based on a network path is generated. In an embodiment, the access instruction is generated by an active inspector deployed outside the cloud environment where the first resource is located. In some embodiments, the instruction includes one or more access parameters. These parameters can include, but are not limited to, host name, IP address, communication protocol, port, user name, password, etc. and combinations thereof. The communication protocol can be, for example, HTTP or UDP (User Datagram Protocol). For example, the instruction can be a ping, GET, CONNECT, or TRACE request over HTTP.

[0112] In some embodiments, multiple access instructions can be generated. For example, the multiple generated access instructions can include a first access instruction having a first request and a second access instruction having a second request different from the first request. For example, the first access instruction can include a CONNECT request, while the second access instruction can include a GET request. In some embodiments, multiple first access instructions can be generated. In such embodiments, each first access instruction can include the same type of request (e.g., CONNECT) with different values (e.g., different URLs, different ports, etc.). For example, a resource is reachable at IP address 10.0.0.127 and at ports 800 to 805. The IP address and the ports will be reachability parameters based on which the active inspector can generate multiple first access instructions based on an HTTP GET request, such as:

[0113] GET / bin HTTP / 1.1

[0114] Host: 10.0.0.127:800

[0115] and further generate another HTTP GET request:

[0116] GET / bin HTTP / 1.1

[0117] Host: 10.0.0.127:801

[0118] and so on, which attempts to access the / bin folder in the resource with the IP address 10.0.0.127 during execution. In some embodiments, the active checker (e.g., Figure 1 the active checker 125) can connect to a proxy server (not shown) through the public network 130, send a first access instruction to the resource in the cloud environment 110 through the first proxy server, and send a second access instruction (which may be the same as or different from the first access instruction) through the second proxy server. In such an embodiment, each proxy server may appear to be from a different country of origin, so the source will receive access requests from seemingly different sources. For example, this is beneficial for determining whether the resource is configured to block certain network traffic based on geographical location.

[0119] In S830, the execution of the generated access instruction is caused. When the access instruction is executed, it causes an attempt to actually access the resource. In an embodiment, this attempt may result in the generation of network traffic, including requests sent to the resource and responses received (i.e., data packets). Although static analysis provides possible paths to access the resource, executing the access instruction provides the real result of attempting to utilize the possible paths to determine which paths are truly feasible and which are not. For example, based on static analysis, a path may be feasible, but in practice, it may not be, for example, an application deployed on the resource blocks such access from occurring. In an embodiment, if the access instruction does not return an error message when executed, the network path is determined to be feasible (or accessible). The error message may be, for example, a timeout (e.g., in response to a "ping" request), a 403 Forbidden (e.g., in response to an HTTP GET request), etc. In some embodiments, the access instruction may be executed by the active checker 125.

[0120] In S840, based on the execution of the generated access instruction, a determination is made to determine whether the network path is accessible. Performing an active check on the cloud environment can determine which reachability paths (i.e., network paths) are actually vulnerable, which means paths that can be used to access the cloud environment, and which reachability paths (network paths) are not vulnerabilities because the active checker cannot access the resource, so the reachability path is impossible in practice. The reachability paths confirmed by static analysis (i.e., using the analysis of the security graph) and active checking are more vulnerable paths. In an embodiment, if the network path results in successfully reaching the resource, the network path is determined to be accessible (or feasible). If the network path cannot access the resource, the network path is determined to be inaccessible (or infeasible).

[0121] At S850, the security map is updated based on network path determination. In some embodiments, an active checker may update the security map, which includes a representation of the cloud environment in which a first resource is deployed, to indicate whether the reachability path is confirmed (i.e., feasible) through active checking, where the confirmed path is the path by which the active checker successfully accesses the resource. In turn, the security map may update an alert generated based on determining that the resource has a reachability path through a public network.

[0122] At S860, a report is generated based on the execution of the generated instructions. In an embodiment, the report may be generated by the active checker that executes the method. In some embodiments, generating the report may include updating a log with network traffic between the active checker and the resource. For example, the active checker may record (e.g., write to a log) the generated instructions, resource identifiers, and responses received from the resource. For example, the response may include a response code. The response code may indicate success, redirect, client error, server error, etc., where the client is the active checker and the server is the resource. In some embodiments, the security map stored in the security DB 126 may be updated based on the feasibility of the determined network path. For example, if the resource is successfully accessed or not accessed (i.e., an attempt to access the resource is made but not successfully), this result may be stored as an attribute of the node representing the resource in the security map. For example, according to an embodiment, a node representing a workload includes an attribute indicating a reachability state, which may have values corresponding to the following: successfully reached (i.e., the active checker successfully accesses the resource), successfully not reached (i.e., the active checker does not successfully access the resource), and undetermined (the active checker has not yet attempted to access the resource via the network path). In some embodiments, certain network paths (i.e., feasible or infeasible) may be determined, while other paths may be undetermined. A node may be associated with multiple network paths, each network path having its own active checking metric.

[0123] In some embodiments, the active checker may communicate with a virtual private network (VPN) or a proxy to mask the IP address that the active checker attempts to access. For example, this may assist in testing, such as if a firewall (as shown by the firewall node 220) will allow communication to pass based on blocking or allowing certain IP addresses. In such an embodiment, multiple similar instructions may be generated, each instruction originating from a different IP address of the active checker. Figure 2 as shown by the firewall node 220) will allow communication to pass based on blocking or allowing certain IP addresses. In such an embodiment, multiple similar instructions may be generated, each instruction originating from a different IP address of the active checker.

[0124] In some embodiments, the network path may include multiple resources. The above method may be performed for each of the multiple resources to determine the reachability of each resource.

[0125] It is advantageous to utilize an active checker that uses network paths generated from a security graph because attempting to access resources in this way to determine the feasibility (i.e., reachability) of a network path requires fewer resources than, for example, randomly guessing network paths to attempt to access resources.

[0126] Furthermore, using the active checker to verify network paths and update the security graph with the results allows for the detection of workloads that contain both vulnerabilities and verified network paths. This allows for alerts to be generated to users of the cloud environment to address these issues by accurately characterizing network security threats. This, in turn, can lead to a more efficient use of resources as the most vulnerable vulnerabilities in the cloud environment will be addressed first.

[0127] In an embodiment, using the active checker allows for further verification of network security issues verified at runtime. In some embodiments, network security issues verified at runtime and further exploited by the active checker pose a higher risk than other network security issues. Therefore, in situations where mitigation resources need to be prioritized and allocated, it is recommended to mitigate such network security issues first before other issues.

[0128] The various embodiments disclosed herein may be implemented as hardware, firmware, software, and any combination thereof. Additionally, the software is preferably implemented as an application program tangibly embodied on a program storage unit or computer-readable medium consisting of components or certain devices and / or combinations of devices. The application program may 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 an input / output interface. 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 program, and any combination thereof, and may be executed by the CPU, whether or not such a computer or processor is explicitly shown. Additionally, various other peripheral units may be connected to the computer platform, such as additional data storage units and printing units. Furthermore, a non-transitory computer-readable medium is any computer-readable medium other than a transitory propagated signal.

[0129] All of the examples and conditional language recited herein are intended for pedagogical purposes to aid the reader in understanding the principles of the disclosed embodiments and the concepts contributed by the inventor to further the art, and should not be construed as being limited to these specifically recited examples and conditions. Additionally, all statements herein reciting principles, aspects, and embodiments of the disclosed embodiments, as well as specific examples thereof, are intended to cover their structural and functional equivalents. Furthermore, such equivalents include both currently known equivalents and equivalents developed in the future, i.e., any elements developed that perform the same function regardless of structure.

[0130] It should be understood that any reference to an element using terms such as "first", "second", etc. in this document generally does not limit the number or order of these elements. On the contrary, these terms are generally used in this document as a convenient way to distinguish between two or more elements or instances of elements. Thus, referring to a first and a second element does not mean that only two elements can be used there, nor does it mean that the first element must precede the second element in some way. In addition, unless otherwise specified, a group of elements includes one or more elements.

[0131] As used herein, the phrase "at least one" followed by a list of items means that any one 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", the system can include only A; only B; only C; 2A; 2B; 2C; 3A; 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 2A and C; a combination of A, 3B, and 2C, and so on.

Claims

1. A method for verifying network security issues using runtime data, comprising: Use at least static analysis techniques to examine network security issues in workloads deployed in computing environments; deploying a sensor on the workload, the sensor being configured to collect runtime data from the workload; determining a reachability attribute of the workload; generating a network path between an external network and the workload; Initiating an active check of the network path to determine whether the workload is a reachable workload; In response to verifying the network security issue from the collected runtime data, initiating a first mitigation measure having a first priority in the computing environment; as well as In response to failing to verify the network security issue from the collected runtime data and determining that the workload is not a reachable workload, initiating a second mitigation measure having a second priority level lower than the first priority level.

2. The method according to claim 1, further comprising: generating a checkable disk based on the disk of the workload; as well as The inspectable disk is inspected for a network security object, wherein the network security object indicates the network security issue.

3. The method according to claim 1, further comprising: In response to determining that the workload is a reachable workload, a first mitigation measure having a third priority level higher than the first priority level is initiated.

4. The method according to claim 1, further comprising: The sensor is configured to collect: artifacts, events, data link layer communications, permissions, a list of applications loaded in memory, a list of libraries loaded in memory, and combinations thereof.

5. The method according to claim 1, further comprising: Initiate the first mitigation action including any of the following: generate an alert, revoke permissions, revoke access to the workload, revoke access from the workload, sandbox the workload, generate an alert, install a software patch, uninstall a software application, update the priority of an alert, and any combination thereof.

6. A non-transitory computer-readable medium storing an instruction set for verifying a network security issue using runtime data, the instruction set comprising: One or more instructions that, when executed by one or more processors of a device, cause the device to: Use at least static analysis techniques to examine network security issues in workloads deployed in computing environments; deploying a sensor on the workload, the sensor being configured to collect runtime data from the workload; determining a reachability attribute of the workload; generating a network path between an external network and the workload; Initiating an active check of the network path to determine whether the workload is a reachable workload; In response to verifying the network security issue from the collected runtime data, initiating a first mitigation measure having a first priority in the computing environment; as well as In response to failing to verify the network security issue from the collected runtime data and determining that the workload is not a reachable workload, initiating a second mitigation measure having a second priority level lower than the first priority level.

7. A system for verifying network security issues using runtime data, comprising: Processing circuit; a memory comprising instructions that, when executed by the processing circuit, configure the system to: Use at least static analysis techniques to examine network security issues in workloads deployed in computing environments; deploying a sensor on the workload, the sensor being configured to collect runtime data from the workload; determining a reachability attribute of the workload; generating a network path between an external network and the workload; Initiating an active check of the network path to determine whether the workload is a reachable workload; In response to verifying the network security issue from the collected runtime data, initiating a first mitigation measure having a first priority in the computing environment; as well as In response to failing to verify the network security issue from the collected runtime data and determining that the workload is not a reachable workload, initiating a second mitigation measure having a second priority level lower than the first priority level.

8. The system according to claim 7, wherein: The memory includes further instructions that, when executed by the processing circuitry, further configure the system to: generating a checkable disk based on the disk of the workload; and The inspectable disk is inspected for a network security object, wherein the network security object indicates the network security issue.

9. The system according to claim 7, wherein: The memory includes further instructions that, when executed by the processing circuitry, further configure the system to: In response to determining that the workload is a reachable workload, the first mitigation measure having a third priority level higher than the first priority level is initiated.

10. The system according to claim 7, wherein: The memory includes further instructions that, when executed by the processing circuitry, further configure the system to: The sensor is configured to collect: Artifacts, events, data link layer communications, permissions, a list of applications loaded in memory, a list of libraries loaded in memory, and combinations thereof.

11. The system according to claim 7, wherein: The memory includes further instructions that, when executed by the processing circuitry, further configure the system to: Initiate first mitigation actions including any of the following: Generate alert, revoke privileges, revoke access to a workload, revoke access from a workload, sandbox a workload, generate alert, install software patch, uninstall software application, update the priority of an alert, and any combination thereof.

Images