Method and system for control plane containment of cyber-security threats and media

Abstract

A method and system for controlling a flat containment network security threat and a medium are presented. The method includes: generating at least one detection rule for a sensor configured to detect an event; configuring the sensor to be deployed on a resource in a cloud computing environment, and deploying the sensor on the resource, wherein the sensor is configured to: apply the at least one detection rule to a detected event; detect an event that triggers the at least one detection rule, the event corresponding to a process running on the resource; and stop execution of the process.

Description

Technical Field

[0001] This disclosure generally relates to the detection of cybersecurity threats, and specifically to a method for using software sensors to control planes to contain cybersecurity threats. Background Technology

[0002] Cybersecurity threats manifest in various forms, such as malware, worms, man-in-the-middle attacks, code injection, and misconfigurations. Different threats pose different risks and can typically be detected in different ways. Therefore, numerous solutions exist for detecting different types of cybersecurity threats, each with its own advantages and disadvantages. Cloud computing platforms such as Amazon® Web Services (AWS), Google® Cloud Platform (GCP), and Microsoft® Azure are high-value targets for attackers, making their vulnerabilities more likely to pose cybersecurity threats. Therefore, detecting such cybersecurity threats is highly valuable.

[0003] In the field of cybersecurity threat detection, sensors play a crucial role in monitoring and identifying malicious activity within networks and systems. However, the current state of sensor technology faces several challenges and problems. One significant issue is the ability of sensors to accurately detect and classify emerging threats in real time. As cyber threats become increasingly complex and diverse, traditional sensors may struggle to keep pace with the rapidly evolving nature of cyberattacks. Furthermore, the massive amounts of data generated by modern networks pose a challenge to sensors, as they must sift through vast amounts of information to identify potential threats while avoiding false positives.

[0004] Therefore, it would be beneficial to provide a solution that can overcome the above challenges. Summary of the Invention

[0005] The following is an overview of several exemplary embodiments of this disclosure. This overview is provided to facilitate a reader's 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.

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

[0007] In one general aspect, a method may include: generating at least one detection rule for a sensor application configured to detect events. The method may further include: configuring a sensor for deployment on a resource in a cloud computing environment. The method may further include: deploying the sensor on the resource, wherein the sensor is configured to: apply at least one detection rule to detected events; detect an event that triggers at least one detection rule, the event corresponding to a process running on the resource; and stop the execution of the process. 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 the actions of the method.

[0008] Implementations may include one or more of the following features. The method may include: generating at least one detection rule based on static analysis of code objects used in the deployed resource. The method may include: generating at least one detection rule based on a determined resource state. The method may include: configuring a sensor to detect runtime data, wherein the runtime data includes any of the following: resource state, cloud entity, component, application, and any combination thereof. The method may include: applying at least one detection rule to an event based on comparing data of a detected event with predefined conditions of at least one detection rule. The method may include: configuring a sensor to be deployed on any of the following: virtual machine, software container, serverless function, and any combination thereof. The method may include: configuring a sensor to perform any of the following: real-time tracking of system calls, monitoring resource usage, and any combination thereof. The method may include: in response to detecting a potential threat based on an event that triggers at least one detection rule, configuring a sensor to perform mitigation actions. The mitigation actions include any of the following: stopping the execution of a process running on the resource, isolating the system, modifying permissions, disabling the threatened account, blocking unauthorized users, and any combination thereof. Implementations of the described techniques may include hardware, methods or processes, or tangible computer media.

[0009] In one general aspect, a non-transitory computer-readable medium may include one or more instructions, which, when executed by one or more processors of a device, cause the device to: generate at least one detection rule for a sensor application configured to detect an event; configure the sensor to be deployed on a resource in a cloud computing environment. The non-transitory computer-readable medium may also include a sensor and deploy it on the resource, wherein the sensor is configured to: apply at least one detection rule to a detected event; detect an event that triggers at least one detection rule, the event corresponding to a process running on the resource; and stop the execution of the process. 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 the actions of the method.

[0010] In one general aspect, the system may include processing circuitry. The system may also include memory containing instructions that, when executed by the processing circuitry, configure the system to generate at least one detection rule for use by a sensor configured to detect an event. The system may also configure the sensor to be deployed on a resource in a cloud computing environment. The system may also deploy the sensor on the resource, wherein the sensor is configured to apply at least one detection rule to detected events. The system may also detect events that trigger at least one detection rule, the events corresponding to a process running on the resource. The system may also stop the execution of the process. 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 the actions of the method.

[0011] The implementation may include one or more of the following features. In this system, the memory contains additional instructions that, when executed by the processing circuitry, further configure the system to: generate at least one detection rule based on static analysis of code objects used in the deployed resources. In this system, the memory contains additional instructions that, when executed by the processing circuitry, further configure the system to: generate at least one detection rule based on a determined resource state. In this system, the memory contains additional instructions that, when executed by the processing circuitry, further configure the system to: configure sensors to detect runtime data, wherein the runtime data includes any of the following: resource state, cloud entity, component, application, and any combination thereof. In this system, the memory contains additional instructions that, when executed by the processing circuitry, further configure the system to: apply at least one detection rule to an event based on comparing data of a detected event with predefined conditions of at least one detection rule. In this system, the memory contains additional instructions that, when executed by the processing circuitry, further configure the system to: configure sensors to be deployed on any of the following: virtual machines, software containers, serverless functions, and any combination thereof. In this system, the memory contains additional instructions that, when executed by the processing circuitry, further configure the system to: configure the sensors to perform any of the following: real-time tracking of system calls, monitoring resource usage, and any combination thereof. In this system, the memory contains additional instructions that, when executed by the processing circuitry, further configure the system to: in response to detecting a potential threat based on an event triggering at least one detection rule, configure the sensors to perform mitigation actions. Mitigation actions in this system include any of the following: stopping the execution of processes running on resources, isolating the system, modifying permissions, disabling threatened accounts, blocking unauthorized users, and any combination thereof. Implementations of the described techniques may include hardware, methods, processes, or tangible computer media. Attached Figure Description

[0012] The claims in the specification specifically point out and expressly claim protection for the subject matter disclosed herein. The above and other objects, features, and advantages of the disclosed embodiments will become apparent from the following detailed description taken in conjunction with the accompanying drawings.

[0013] Figure 1 This is an example illustration of a cloud computing environment being monitored by an inspection environment for cybersecurity threats, implemented according to an embodiment.

[0014] Figure 2 This is an example schematic diagram illustrating communication between a sensor backend server and multiple sensors deployed on various workloads, according to an embodiment.

[0015] Figure 3 This is an example flowchart of a method for controlling cybersecurity threats in a control plane, implemented according to an embodiment.

[0016] Figure 4 This is a schematic diagram of a sensor backend server according to an embodiment.

[0017] Figure 5 This is a schematic diagram of a multi-architecture sensor deployment implemented according to an embodiment. Detailed Implementation

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

[0019] Various disclosed embodiments include a method for controlling the cybersecurity threat profile based on the use of sensors configured with detection rules that allow for the accurate detection of potential cybersecurity threats and vulnerabilities.

[0020] Figure 1 This is an example schematic diagram 100 illustrating the monitoring of a cloud computing environment for cybersecurity threats by an inspection environment, implemented according to an embodiment. In this embodiment, the cloud computing environment 110 includes virtual private clouds (VPCs) and virtual networks (VNets) deployed on a cloud computing platform. The cloud computing platform may be provided by, for example, Amazon® Web Services (AWS), Google® Cloud Platform (GCP), Microsoft® Azure, etc.

[0021] The cloud computing environment 110 includes cloud entities deployed therein. Cloud entities can be, for example, entities, resources, and combinations thereof. In embodiments, resources are cloud entities that provide access to computing resources such as processors, memory, and storage devices. In some embodiments, resources are virtual machines, software containers, and serverless functions, etc. Resources can be software applications deployed thereon or can include such software applications, such as web servers, gateways, load balancers, web application firewalls (WAFs), and devices, etc.

[0022] In some embodiments, a principal is a cloud entity authorized to initiate operations in a cloud computing environment. A principal can be, for example, a user account, a service account, and a role. In some embodiments, a cloud entity is a principal relative to another cloud entity and a resource relative to that other cloud entity. For example, a load balancer is a resource of a user account requesting web pages from a web server behind the load balancer, and the load balancer is a principal of the web server.

[0023] The cloud computing environment 110 includes various resources such as virtual machines 112, software container orchestrators 114, serverless functions 116, and cloud logs 118. For example, virtual machines 112 can be deployed using Oracle® VirtualBox®. Software container orchestrators 114 can be deployed using Docker® engines and Kubernetes® engines. In an embodiment, software container orchestrator 114 is configured to deploy software clusters, each cluster comprising multiple nodes. In an embodiment, nodes comprise multiple pods. Serverless functions 116 can be used, for example, with Amazon® Lambda. In an embodiment, serverless functions 116 are serverless function container images.

[0024] In one embodiment, cloud log 118 is configured to store events in cloud computing environment 110. In some embodiments, the cloud log is configured to store runtime events from runtime sensors. According to one embodiment, an event is a data record of events that occur or are performed within a network. In one embodiment, an event indicates unauthorized access, damage, misuse, or combinations thereof to computer networks, computer resources, and identities.

[0025] For example, in one embodiment, events include unsuccessful user login attempts, file deletion, abnormal network communication, system modifications, security alert notifications, and combinations thereof. In some embodiments, cloud log 118 is implemented as a database deployed to run in a public or hybrid cloud environment and managed by a database-as-a-service (DBaaS) deployed on cloud-based virtual machines (VMs) or similar platforms.

[0026] Each such resource is vulnerable to various cybersecurity threats. For example, such threats can become apparent due to the software version of the application in the software container orchestrator 114, the operating system (OS) version of the virtual machine 112, misconfigurations in the code of the serverless function 116, etc. In this embodiment, a monitoring environment 120 monitors for cybersecurity threats to the cloud computing environment 110. In this embodiment, the monitoring environment 120 utilizes a cloud computing environment (such as VPC and VNet).

[0027] In this embodiment, each of the virtual machine 112, the software container orchestrator 114, and the serverless function 116 includes sensors configured to specific resources, resource types, and combinations thereof. (See below...) Figure 2 The example deployment of the sensor is discussed in more detail.

[0028] In the embodiment, the sensor ( Figure 1 (Not shown in the image) is configured to listen for events and packets at the data link layer. For example, the sensor is configured to utilize the Extended Berkeley Packet Filter (eBPF) interface, which allows for non-intrusive monitoring of data link layer communications.

[0029] In some embodiments, the sensor is implemented as a runtime sensor, configured to be deployed alongside an operating system, open-source platform container cluster, etc. In some embodiments, the runtime sensor is configured to monitor system behavior in real time to detect cybersecurity threats. In embodiments, the runtime sensor is configured to track and log system and entity behavior in real time. For example, in embodiments, the runtime sensor is configured to monitor network activity and track any of the following: user actions, file changes, system configurations, memory usage, and combinations thereof.

[0030] In some embodiments, the sensor is further configured to send data to and receive data from the sensor backend server 128. The sensor backend server 128 is a workload deployed in the inspection environment 120, such as a virtual machine, software container, serverless function, or a combination thereof.

[0031] In some embodiments, sensor backend server 128 is configured to receive sensor data generated by sensors (e.g., runtime sensors). For example, in some embodiments, sensor backend server 128 is configured to receive events from sensors. In some embodiments, sensors are configured to request rules and definitions from sensor backend server 128, and the sensors are configured to apply these rules and definitions to events detected, for example, on an eBPF interface. For example, in some embodiments, predetermined events are checked against definitions, such as indications of access to Internet Protocol (IP) addresses and IP address ranges. In some embodiments, a definition is a logical expression that produces a "true" or "false" result when applied to an event. In some embodiments, a rule is a logical expression that includes an action. For example, in some embodiments, a rule is: in response to a definition being true when applied to an event, data about that event should be sent to sensor backend server 128.

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

[0033] For example, in one embodiment, the sensor is configured to send log data to a sensor backend server 128 in response to the detection that a definition applied by the sensor to a detected event produces a "true" value upon application. As an example, in one embodiment, the definition could be "Is the IP address in the range of 127.0.0.1 to 127.0.0.99?", which in this example corresponds to the range of IP addresses used by malware. In another embodiment, when the definition is applied to, for example, a detected network packet, and the result is "true," the sensor is configured to send event-related data to the sensor backend server 128. In various embodiments, event-related data may include, for example, IP addresses, event types, and combinations thereof.

[0034] In one embodiment, sensor backend server 128 is configured to receive data. In some embodiments, sensor backend server 128 is further configured to apply rules to the received data to determine whether the workload on which the sensor is deployed should be inspected for cybersecurity threats. For example, in one embodiment, sensor backend server 128 is configured to generate instructions to inspect virtual machine 112 in response to receiving an indication from a sensor deployed as a service on a virtual machine that communication between virtual machine 112 and a server with a banned IP address (such as an IP address associated with malware).

[0035] In some embodiments, the inspection environment 120 further includes a security database 126 on which a representation of the computing environment 110 is stored. In embodiments, the security database is configured to store representations of cloud computing environments, such as cloud computing environment 110. For example, in one embodiment, the representation is based on a predefined unified data schema, allowing each different cloud platform to be represented using the unified data schema, thereby enabling a unified representation. For example, in one embodiment, subjects are represented by a predefined data structure, with each subject represented by a node in a security graph. Similarly, in one embodiment, resources may be represented by another predefined data structure, with each resource represented by a node in a security graph.

[0036] In some embodiments, sensor data received from sensors deployed on resources in a cloud computing environment is stored in a secure database 126.

[0037] In various embodiments, the inspection environment 120 further includes a detection engine 129. In embodiments, the detection engine 129 is configured to detect cybersecurity threats and attacks based on detected events stored in cloud logs 118 and the state of entities (e.g., cloud entities) deployed in the cloud computing environment 110, and combinations thereof. Furthermore, in embodiments, the detection engine 129 is configured to access data from the cloud logs 118. Additionally, in some embodiments, the detection engine 129 is configured to receive sensor data from runtime sensors. In various embodiments, the detection engine 129 is configured to determine the state of each entity in the cloud computing environment 110, for example, based on data extracted from events received from sensors deployed on resources in the computing environment 110.

[0038] In some embodiments, the detection engine 129 is configured to detect anomalies based on the detection of events and states, and combinations thereof, of entities deployed in a cloud computing environment. In most embodiments, the detection engine 129 is configured to initiate remedial actions based on detected anomalies.

[0039] Figure 2 This is an example schematic diagram 200 illustrating communication between a sensor back-end server and multiple sensors deployed on various workloads, implemented according to an embodiment. In some embodiments, the sensor back-end server 128 is configured to communicate with a machine (not shown) on which sensors are mounted and communicatively coupled. In embodiments, the machine is a computing device such as a bare metal, a computer device, a networked computer device, a laptop, or a tablet computer.

[0040] In some embodiments, the sensor backend server 128 is implemented as a virtual machine, a software container, a serverless function, or a combination thereof. In some embodiments, multiple sensor backend servers 128 may be implemented. In some embodiments, when using multiple sensor backend servers 128, a first group of sensor backend servers is configured to communicate with sensors deployed on a first type of resource (e.g., a virtual machine), a second group of sensor backend servers is configured to communicate with a second type of resource, and so on.

[0041] In one embodiment, a first set of sensor backend servers is configured to communicate with sensors deployed on resources in a first cloud computing environment deployed on a first cloud platform (e.g., AWS), and a second set of sensor backend servers is configured to communicate with sensors deployed on resources in a second cloud computing environment deployed on a second cloud platform (e.g., GCP).

[0042] According to an embodiment, virtual machine 112 includes sensor 210. In this embodiment, sensor 210 is deployed as a service executed on virtual machine 112. In some embodiments, virtual machine 112 is configured to, for example, request binary code and software packages from sensor backend server 128, such that when the binary code and software packages are executed by virtual machine 112, sensor 210 runs as a service on virtual machine 112. Sensor 210 is configured to, for example, listen for data link layer communication via an eBPF interface.

[0043] Software container orchestrator 114 runs a daemonset and includes multiple nodes (such as node 220). The daemonset ensures that each node 220 runs a daemonset pod 222, which is configured as a sensor. For example, a Kubernetes® cluster can execute a daemonset configured to deploy daemonset pods on each deployed node, wherein the daemonset pods are configured to, for example, listen for data link layer communication via an eBPF interface, listen for communication from multiple pods (such as pod-1 224 to pod-N 226), where "N" is an integer with a value of "1" or greater. In this embodiment, daemonset pod 222 is configured to communicate with a sensor backend server 128.

[0044] In an embodiment, 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 an embodiment, in AWS Lambda, layers contain code, content, and combinations thereof. In some embodiments, layers (such as layer 234, etc.) include runtime data, configuration data, and software libraries, etc.

[0045] In some embodiments, serverless function 116 includes a sensor layer 238. In some embodiments, sensor layer 238 is configured to, for example, listen for data link layer communications of serverless function 116 via an eBPF interface.

[0046] According to the embodiment, sensor 210, daemon pod 222, and sensor layer 238 are all sensor implementations. In the embodiment, the sensor is configured to communicate with sensor backend server 128 via a transport layer protocol (such as Transmission Control Protocol, TCP, etc.). For example, in the embodiment, sensor backend server 128 is configured to listen on a predetermined port using the TCP protocol, and the sensors (such as sensor 210, daemon pod 222, and sensor layer 238, etc.) are each configured to communicate with sensor backend server 128, for example, by initiating communication using TCP on the predetermined port.

[0047] Figure 3 This is an example flowchart 300 of a method for controlling a cybersecurity threat to be contained in a control plane, implemented according to an embodiment. Utilizing a sensor configured with detection rules for detecting cybersecurity threats and the ability to perform mitigation actions in response to such threats is advantageous. In this embodiment, this provides accurate detection of actual threats rather than potential false threats and provides rapid action in response to such threats.

[0048] In S310, detection rules for deployment on the sensor are generated. In this embodiment, the sensor is implemented as a runtime sensor. In some embodiments, the sensor is configured to be deployed on resources in a cloud computing environment. In some embodiments, resources are virtual machines, software containers, and serverless functions, etc. In this embodiment, resources are software applications, files, gateways, web servers, load balancers, and web application firewalls (WAFs), etc.

[0049] In this embodiment, the detection engine is configured to generate detection rules, strategies, and conditional rules, etc. In this embodiment, the detection rules are logical expressions, such as conditional rules that receive input and output a true or false response.

[0050] In some embodiments, detection rules are generated based on static analysis of code objects used in the deployment resources. In some embodiments, static analysis is performed on code objects (e.g., computer-executable code) used to deploy resources in a computing environment, such as files and software applications. In various embodiments, static analysis includes examining code objects without fully executing the code to generate detection rules, policies, and conditional rules, etc.

[0051] For example, in one embodiment, the response indicates that an application deployed on the system is configured to receive input (e.g., data packets) from a specific range of Internet Protocol (IP) addresses (e.g., 192.24.0.100 to 192.24.0.900), and the sensor implements a detection rule that "only accepts data packets from IP addresses in the range of 192.24.0.100 to 192.24.0.900". In various embodiments, the code objects are subjected to static analysis to identify potential cybersecurity threats and security vulnerabilities in the computing system.

[0052] In some embodiments, the detection engine is configured to generate detection rules based on the deterministic state of resources. In various embodiments, the detection engine receives runtime data generated from sensors (e.g., runtime sensors). In some embodiments, the runtime data is used to determine the state of resources, cloud entities, components, and applications deployed in a cloud computing environment.

[0053] For example, in one embodiment, detection rules are generated based on the normal baseline status of resources, entities, and cloud entities. For example, in one embodiment, if accessing the server using two failed login attempts is normal behavior for a specific user, a detection rule is generated to trigger an alert in response to four failed login attempts by that specific user within a one-hour timeframe. In another embodiment, for example, if the baseline behavior of a specific user account indicates low-level privileges, a detection rule is generated to trigger an alert in response to the elevation of privileges for that specific user account.

[0054] In S320, the sensor is deployed on a resource. In some embodiments, the sensor (e.g., a runtime sensor) is configured to be deployed on a virtual machine, software container, serverless function, or a combination thereof. In some embodiments, the sensor is configured to monitor network traffic in real time.

[0055] In some embodiments, the sensor is configured to detect events originating from processes running on resources, hosts, software containers, physical machines, and hardware devices. In other embodiments, the sensor is configured to detect events in a cloud computing environment, runtime events, and cloud events. In some embodiments, the sensor is configured to perform real-time tracking of system calls, monitor resource usage (e.g., processor, memory, storage devices, network bandwidth, etc.) and combinations thereof.

[0056] In some embodiments, an event is a specific event occurring within an operating system and related to a software application deployed on a virtual environment, an event related to a cloud computing environment, an event related to a software container, or a combination thereof. In some embodiments, an event log is a digital record of events.

[0057] In some embodiments, an event is a specific occurrence in network traffic. In other embodiments, an event is a data record indicating a change in the state of a system, network, environment, operating system, or a combination thereof. In some embodiments, an event record includes an event identifier, a subject associated with the event, an identifier of the resource on which the event occurred, a timestamp of the event, or a combination thereof.

[0058] In S330, the sensor is configured to detect events that trigger detection rules. In various embodiments, the sensor, detection engine, and combinations thereof are configured to apply at least one detection rule to detected events, runtime events, event logs, and cloud events, etc. In various embodiments, the detection rule is applied to the event based on a comparison of data from the detected events, event logs, cloud events, and runtime events, etc., with predefined conditions of the detection rule.

[0059] For example, in one embodiment, a detection rule such as "generating an alert in response to a user attempting to access a file more than three times in a day" would be triggered by an event where an unknown user attempts to access a software file three times within an hour. Similarly, in another embodiment, a detection rule such as "generating an alert in response to an unauthorized user attempting to access resources outside their role" would be triggered by an event where a user account attempts to access a confidential file (e.g., a file marked as containing sensitive data) five times within an hour.

[0060] In S340, the sensor is configured to stop the execution of a process running on the resource. In various embodiments, in response to a process triggering a detection rule (e.g., an event indicating that the process has triggered a detection rule), the sensor is configured to stop the execution of a process running on the resource (e.g., the execution of a software application). In some embodiments, in response to detecting an event indicating a potential threat or vulnerability, as indicated by an event that triggers a detection rule, the sensor is configured to initiate mitigation actions and automated actions, etc.

[0061] In various embodiments, mitigation actions include: stopping the execution of processes running on resources, isolating processes, modifying application licenses, modifying user account licenses, disabling compromised accounts, blocking unauthorized users, blocking network traffic, resetting network connections, and combinations thereof.

[0062] For example, in one embodiment, the sensor is configured to stop an unknown software application from running on a resource in response to an event that triggers a detection rule that performs mitigation actions in response to an unknown software application installed by an unauthorized user. In another embodiment, the sensor is configured, for example, to stop the upload of an unidentified file to a virtual machine in response to an event that triggers a detection rule that performs mitigation actions in response to a file upload from an unauthorized user outside their role.

[0063] Figure 4 This is an example schematic diagram of a sensor backend server 128 according to an embodiment. In the embodiment, Figure 1 The sensor back-end server 128 is implemented as a sensor back-end server 128. The sensor back-end server 128 includes processing circuitry 410 coupled to memory 420, storage device 430, and network interface 440. In an embodiment, the components of the sensor back-end server 128 can be communicatively connected via bus 450.

[0064] The processing circuit 410 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 systems (SOCs), graphics processing units (GPUs), tensor processing units (TPUs), general-purpose microprocessors, microcontrollers, and digital signal processors (DSPs), or any other hardware logic component that can perform computation or other information operations.

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

[0066] In one configuration, software for implementing one or more embodiments disclosed herein may be stored in storage device 430. In another configuration, memory 420 is configured to store such software. Software should be interpreted broadly as any type of instruction, whether referred to as software, firmware, middleware, microcode, hardware description language, or others. 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 410, the instructions cause processing circuitry 410 to perform the various processes described herein.

[0067] Storage device 430 can be a magnetic storage device or an optical storage device, and can be implemented as, for example, flash memory or other storage technologies, a compact disk-read-only memory (CD-ROM), a digital versatile disk (DVD), or any other medium that can be used to store the desired information.

[0068] Network interface 440 allows sensor backend server 128 to communicate with, for example, sensor 210, daemon pod 222 and sensor layer 238.

[0069] It should be understood that the embodiments described herein are not limited to those described herein. Figure 4The specific architecture shown can be used equivalently with other architectures without departing from the scope of the disclosed embodiments.

[0070] Furthermore, in some embodiments, the controller 122 and the inspector 124, etc., may be employed. Figure 4 The architecture shown is an implementation of the present invention. In other embodiments, other architectures may be used equivalently without departing from the scope of the disclosed embodiments.

[0071] Figure 5 This is an example schematic diagram of a multi-architecture sensor deployment implemented according to an embodiment. In this embodiment, a sensor application 510 is deployed from a software abstraction layer (SAL) 520. In some embodiments, the SAL 520 includes a monitoring debugger on which the sensor application 510 is deployed. In some embodiments, the SAL 520, the monitoring debugger, etc., are persistent software that is continuously executed during machine runtime, while the sensor application 510 is semi-persistent.

[0072] According to embodiments, the semi-persistent software application is in a running state except during semi-persistent software updates, restarts, changes, etc. In some embodiments, it is advantageous for a sensor to have a separate architecture between the persistent part (i.e., SAL 520) and the semi-persistent part (i.e., sensor application 510) because it allows the persistent engine to retain the ability to update itself without losing the ability to monitor events.

[0073] For example, in one embodiment, SAL 520 is configured to receive, detect, and listen for events from multiple different computing architectures. This allows the same sensor application 510 to be deployed and updated across multiple different types of computing and virtualization, without having to write specific interfaces for each such virtualization.

[0074] For example, in one embodiment, SAL 520 is configured to receive events via eBPF interface 532, process tracing (pTrace) interface 534, Linux® kernel driver 536, and Microsoft® Windows® event-based interface 538. Therefore, the same sensor application 510 can detect events regardless of the type of computation from which they originate. When sensor application 510 needs updating, this can be done without updating the SAL 520 components. Thus, a single update to sensor application 510 can be applied to every computation instance, such as virtual machines, software containers, and serverless functions, without having to uniquely address each instance.

[0075] According to embodiments, the decoupled architecture of sensors is advantageous for use in runtime environments such as serverless functions and software containers. For example, in embodiments, such environments are implemented using AWS Elastic Compute Service (ECS) Fargate, AWS Elastic Kubernetes Service (EKS) Fargate, Azure Container App (ACA), etc. In such embodiments, for example, access to eBPF is restricted or unavailable because the software container is controlled by the client, while the machine is controlled by the provider, such as a cloud infrastructure provider.

[0076] In one embodiment, the sensor application is deployed in a client container, and an entry point overlay is added to run the sensor application. In some embodiments, the sensor application is added to the container image during the build process.

[0077] In some embodiments, the sensor is deployed on a shared volume. The shared volume is then mounted into a software container. The entry point of the software container is then overlaid onto the sensor application. According to embodiments, this deployment allows for periodic updates to the sensor application.

[0078] 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 on a program storage unit or computer-readable medium, which comprises some or some devices and / or combinations of devices. The application can be uploaded to a machine including any suitable architecture and executed by that machine. 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 an application, or any combination thereof, which 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 propagation signals.

[0079] All examples and conditional language described herein are intended for educational purposes to aid the reader in understanding the principles of the disclosed embodiments and the concepts contributed by the inventors to further advance the art, and should be understood as not being limited to such specifically enumerated examples and conditions. Furthermore, all statements regarding the principles, aspects, and embodiments of the disclosed embodiments, as well as specific examples thereof, are intended to cover their structural and functional equivalents. Moreover, such equivalents are intended to include both currently known equivalents and those developed in the future; that is, any element developed that performs the same function, regardless of its structure.

[0080] It should be understood that any reference to elements in this document using names such as "first," "second," etc., does not generally limit the number or order of these elements. Rather, these names are generally used herein as a convenient way to distinguish two or more elements or instances of elements. Therefore, a reference to a first element and a second element does 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.

[0081] As used herein, the phrase “at least one” followed by a list of items means that any of the listed items may be used alone, or any combination of two or more of the listed items may be used. For example, if a system is described as including “at least one of A, B, and C”, then the system may 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, etc.

Claims

1. A method for controlling cybersecurity threats in a control plane, comprising: Generate at least one detection rule for sensor applications configured to detect events; Configure the sensor to be deployed on resources in a cloud computing environment; The at least one detection rule is generated based on static analysis of the code objects used in deploying the resources. The sensor is deployed on the resource, wherein the sensor is configured to: Apply at least one of the detection rules to the detected events; Detect an event that triggers at least one detection rule, the event corresponding to a process running on the resource; and Stop the execution of the process.

2. The method according to claim 1, further comprising: The at least one detection rule is generated based on the determined resource status.

3. The method according to claim 1, further comprising: The sensor is configured to detect runtime data, wherein the runtime data includes any of the following: the status of resources, cloud entities, components, applications, and any combination thereof.

4. The method according to claim 1, further comprising: The at least one detection rule is applied to the event by comparing the data of the detected event with the predefined conditions of the at least one detection rule.

5. The method of claim 1, further comprising: The sensor can be configured to be deployed on any of the following: a virtual machine, a software container, a serverless function, or any combination thereof.

6. The method of claim 1, further comprising: Configure the sensor to perform any of the following: real-time tracking of system calls, monitoring of resource usage, and any combination thereof.

7. The method of claim 6, further comprising: In response to the detection of a potential threat based on an event that triggers at least one of the detection rules, the sensor is configured to perform mitigation actions.

8. The method according to claim 7, wherein, The mitigation actions include any of the following: stopping the execution of processes running on the resource, isolating the system, modifying permissions, disabling the compromised account, blocking unauthorized users, and any combination thereof.

9. A non-transitory computer-readable medium storing a set of instructions for controlling a network security threat containment plane, the set of instructions comprising: One or more instructions, when executed by one or more processors of the device, cause the device to perform: Generate at least one detection rule for sensor applications configured to detect events; Configure the sensor to be deployed on resources in a cloud computing environment; The at least one detection rule is generated based on static analysis of the code objects used in deploying the resources. The sensor is deployed on the resource, wherein the sensor is configured to: Apply at least one of the detection rules to the detected events; Detect an event that triggers at least one detection rule, the event corresponding to a process running on the resource; and Stop the execution of the process.

10. A system for controlling cybersecurity threats in the control plane, comprising: Processing circuitry; A memory containing instructions that, when executed by the processing circuitry, configure the system to: Generate at least one detection rule for sensor applications configured to detect events; Configure the sensor to be deployed on resources in a cloud computing environment; The at least one detection rule is generated based on static analysis of the code objects used in the deployment resources; The sensor is deployed on the resource, wherein the sensor is configured to: Apply at least one of the detection rules to the detected events; Detect an event that triggers at least one detection rule, the event corresponding to a process running on the resource; and Stop the execution of the process.

11. The system according to claim 10, wherein, The memory contains additional instructions that, when executed by the processing circuitry, further configure the system to: The at least one detection rule is generated based on the determined resource status.

12. The system according to claim 10, wherein, The memory contains additional instructions that, when executed by the processing circuitry, further configure the system to: The sensor is configured to detect runtime data, wherein the runtime data includes any of the following: the status of resources, cloud entities, components, applications, and any combination thereof.

13. The system according to claim 10, wherein, The memory contains additional instructions that, when executed by the processing circuitry, further configure the system to: The at least one detection rule is applied to the event by comparing the data of the detected event with the predefined conditions of the at least one detection rule.

14. The system according to claim 10, wherein, The memory contains additional instructions that, when executed by the processing circuitry, further configure the system to: The sensor can be configured to be deployed on any of the following: a virtual machine, a software container, a serverless function, or any combination thereof.

15. The system according to claim 10, wherein, The memory contains additional instructions that, when executed by the processing circuitry, further configure the system to: Configure the sensor to perform any of the following: real-time tracking of system calls, monitoring of resource usage, and any combination thereof.

16. The system according to claim 15, wherein, The memory contains additional instructions that, when executed by the processing circuitry, further configure the system to: In response to the detection of a potential threat based on an event that triggers at least one of the detection rules, the sensor is configured to perform mitigation actions.

17. The system according to claim 16, wherein, Relief actions include any of the following: Stop the execution of processes running on resources, isolate systems, modify permissions, disable compromised accounts, block unauthorized users, and any combination thereof.

Images