AUTOMATED SYNTHESIS OF REFERENCE GUIDELINES FOR THE PROTECTION OF MICRO SERVICES DURING RUNTIME

Abstract

A method, a device, and a computer program product for the automatic synthesis of security policies and for use in a container environment. This approach involves performing binary analysis of a program associated with a container image within a binary analysis platform. During the binary analysis, the program is microexecuted directly within the analysis platform to generate a graph summarizing the program's expected interactions within the runtime container environment. These expected interactions are identified by analyzing one or more system calls and their arguments, which are discovered during the microexecution. Once the graph is generated, a security policy is automatically synthesized from the graph and instantiated into the container environment. The policy incorporates at least one argument of the system call.During runtime monitoring of an event sequence related to the program running in the container environment, action is taken if it is determined that the event sequence violates the security policy.

Description

BACKGROUND OF THE INVENTION Technical field

[0001] This disclosure generally concerns the detection of external attacks in a microservice data processing environment. Background of the state of the art

[0002] Today, application developers divide large distributed systems evenly into communicating "microservices" that all run in parallel, for example, within a container orchestration engine (COE) such as Kubernetes, Docker Swarm, or OpenShift. Each orchestration engine takes an image containing an application, its dependencies, and a distribution of a small operating system (OS) in a multi-tiered file system, and creates a process within its own namespace on a hardware node.

[0003] Reference monitoring continuously checks a program's execution for behaviors that deviate from a reference policy. A reference policy summarizes the behavior a program can be expected to follow when running normally. If an attacker hijacks the program in any way, malicious behavior should deviate from the reference policy, and either an alert should be generated for the operator or the compromised program should be terminated.Numerous reference monitoring mechanisms exist for enforcing policies on individual processes within an operating system, but the recent advent of microservices, where developers assemble large, distributed applications across a service mesh, necessitates new approaches to reference monitoring that go beyond the capabilities found in existing operating system kernels or compiler-based approaches. Cloud providers and individual security vendors have offered anomaly detection services based on detailed container telemetry for some time, but these approaches often require extensive manual expertise for enforcement or focus solely on detecting known issues that persist across all operational workloads, such as...Developers who access production containers without permission or detect exploits that target the cloud architecture.

[0004] Furthermore, defining policies for a reference monitoring device is a manual task that requires extensive expertise to be performed effectively. While automated approaches exist, they often focus on identifying general security issues rather than deriving policies tailored to a single application. Recent advances in writing application-specific policies include the introduction of a Common Intermediate Language (CIL) for the SELinux reference monitoring device in the Linux kernel. While this allows operators to define reference policies in a declarative language, a thorough understanding of the protected program is still necessary to write useful policies.Furthermore, these policies are stateless and do not allow an analyst to explain the complex sequences of processes that a program can perform on system resources. State-of-the-art reference monitoring systems currently lack fully automated approaches for defining stateful policies that accurately describe how a program interacts with system resources.

[0005] Publication US 2020 / 0285733A1 concerns a method for operating a system for generating a security profile of a security instance. The method includes: extracting executable code and a library file from a container, thereby identifying a target for analysis; performing binary static analysis on the executable code and library file to generate a system call list; and generating a security profile in Secure Computing Mode (SECCOMP) based on the system call list.

[0006] Publication US 2017 / 0004303A1 relates to a method that includes: initiating offline malware detection by a network node for an application that is downloaded and executed on one or more user devices, wherein the offline malware detection includes: executing at least a portion of the application's code in a virtual environment and capturing logs of the application's function calls; deriving, at least in part based on the application's function call logs, at least one function call map of the application in offline mode, wherein a function call map records relationships between calls to functions invoked by the application; extracting patterns of function calls of the application from the at least one function call map;and comparing the extracted pattern with at least one pattern from normal applications to identify anomalies in the application.

[0007] The publication "Micro Execution" concerns micro-execution, the ability to execute arbitrary code fragments without test drivers or input data. Micro-execution can start (and stop) execution at any point and enables local, fast, precise, and dynamic analysis of small code fragments and executions. The key to implementing micro-execution is a runtime environment that can intercept and redirect input / output memory operations before they occur and provide input values ​​according to general rules. The article further refers to such an implementation called MicroX. MicroX is a virtual machine specifically designed for testing purposes (isolation and generation) (GODEFROID, P.: Micro Execution. In: 36th International Conference on Software Engineering (ICSE 2014), Hyderabad, India, May 31 - June 7, 2014, pp. 539-549. DOI:10.1145 / 2568225.2568273). SUMMARY

[0008] A method, a device, and a computer program product for the automatic synthesis of security policies and for use in a container environment. This approach involves performing binary analysis of a program associated with a container image within a binary analysis platform. During the binary analysis, the program is microexecuted directly within the analysis platform to generate a graph summarizing the program's expected interactions within the runtime container environment. These expected interactions are identified by analyzing one or more system calls and their arguments, which are discovered during the microexecution. Once the graph is generated, a security policy is automatically synthesized from the graph and instantiated into the container environment. The policy incorporates at least one argument of the system call.During runtime monitoring of an event sequence related to the program running in the container environment, action is taken if it is determined that the event sequence violates the security policy.

[0009] The foregoing describes some of the key features of the subject matter. These features are to be understood as being for illustrative purposes only. Many other advantageous results can be achieved by applying the disclosed subject matter in a different way or by modifying it, as described below. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] For a more comprehensive understanding of the subject and its advantages, reference is now made to the following descriptions in conjunction with the accompanying drawings, in which: Fig. 1. An exemplary block diagram of a distributed data processing environment is presented graphically, in which exemplary aspects of the illustrative embodiments can be implemented; Fig. 2 is an exemplary block diagram of a data processing system in which exemplary aspects of the illustrative embodiments can be implemented; Fig. 3. A representative cloud data processing environment is depicted in which the techniques of this revelation can be put into practice; Fig. 4. Illustrates several implementation forms of a system for detecting attacks in connection with a network operating environment; Fig. 5. A graphic representation of a host-based intrusion detection system (IDS), which may include the techniques of this disclosure; Fig. 6. A framework is graphically represented in which a binary analysis of container images is performed, preferably offline, to build a library of behavioral models, which is then used to analyze container telemetry in real time for the detection of attacks; Fig. 7. illustrates a representative binary analysis process; Fig. Figure 8 illustrates an example of how binary analysis constructs a call graph from a container image; Fig. Figure 9 illustrates an example of how binary analysis identifies relevant system calls of interest; Fig. 10. A binary analysis platform (BAP) is figuratively represented that implements a micro-execution of the entire program to process a single binary program into a reference policy according to this disclosure; Fig. Figure 11 illustrates an exemplary application binary interface (ABI) implemented in the microexecution environment of the entire program, which is in Fig. 10 is illustrated; Fig. 12. The micro-execution technique of the entire program of this disclosure is graphically represented, wherein a specific program is executed directly within the analysis environment, preferably with a binary application interface (ABI) that enables the program to execute and access the resources specified in its container image; Fig. 13. A representative syntax of an intermediate representation (IR) is presented graphically, which is used for policy synthesis; and Fig. It presents 14 different operational semantics that define how effects are generated by a micro-executed program during policy synthesis. DETAILED DESCRIPTION

[0011] Now with reference to the drawings and in particular with reference to the Fig. Sections 1 and 2 provide exemplary block diagrams of data processing environments in which illustrative embodiments of the disclosure can be implemented. It should be clear that the Fig. Figures 1 and 2 are merely examples and do not constitute any statement regarding limitations or implied limitations concerning the environments in which aspects or embodiments of the disclosed subject matter may be realized. Many modifications can be made to the environments depicted without altering the scope of protection of the present invention.

[0012] Referring to the drawings, Fig. Figure 1 is a pictorial representation of a distributed data processing system in which exemplary aspects of the illustrative embodiments can be implemented. The distributed data processing system 100 can comprise a network of computers in which aspects of the illustrative embodiments can be implemented. The distributed data processing system 100 includes at least one network 102, which is the medium that provides data exchange connections between different units and computers that are interconnected within the distributed data processing system 100. The network 102 can have connections such as wired or wireless data exchange links or optical fibers.

[0013] In the illustrated example, servers 104 and 106, as well as storage unit 108, are connected to network 102. Clients 110, 112, and 114 are also connected to network 102. Clients 110, 112, and 114 could be, for example, personal computers, network computers, or similar devices. In this illustrated example, server 104 provides clients 110, 112, and 114 with data such as boot files, operating system images, and applications. In this illustrated example, clients 110, 112, and 114 are clients of server 104. The distributed data processing system 100 can contain additional servers, clients, display units, and other units not shown.

[0014] In the illustrated example, the distributed data processing system 100 is the Internet, where the network 102 represents a globally distributed collection of networks and gateways that use the Transmission Control Protocol / Internet Protocol (TCP / IP) protocol suite for data exchange. The core of the Internet is a main line (backbone) of high-speed data transmission lines between main nodes or host computers, which consist of thousands of computer systems for businesses, government agencies, and educational institutions, as well as other computer systems that forward data and messages. Of course, the distributed data processing environment 100 can also be implemented in the form of a number of different types of networks, for example, an intranet, a local area network (LAN), a wide area network (WAN), or the like. As mentioned above, Fig. 1 is intended as an example and not as a limitation of the architecture of different embodiments of the disclosed subject matter, and therefore the ones in Fig. The individual elements shown in Figure 1 are not to be regarded as a limitation with regard to the environments in which the illustrative embodiments of the present invention can be realized.

[0015] With reference to Fig. Figure 2 shows a block diagram of an exemplary data processing system in which aspects of the illustrative embodiments can be implemented. Data processing system 200 is an example of a computer such as client 110 in Fig. 1, which may contain computer-usable program code or computer-usable instructions that implement the processes illustrating embodiments of the disclosure of the invention.

[0016] With reference to Fig. Figure 2 shows a block diagram of a data processing system, in which illustrative embodiments can be implemented. Data processing system 200 is an example of a computer such as server 104 or client 110 in Fig. 1, on which computer-usable program code or computer-usable instructions of the illustrative embodiments may be located, which implement the processes of the illustrative embodiments. In this illustrative example, the data processing system 200 includes the data exchange structure 202, which enables data exchange between a processor unit 204, a main memory 206, a permanent memory 208, a data exchange unit 210, an input / output unit (I / O unit) 212, and a display unit 214.

[0017] The processor unit 204 is used to execute instructions from software that can be loaded into main memory 206. Depending on the specific implementation, the processor unit 204 can be a group of one or more processors or a single multi-core processor. Furthermore, the processor unit 204 can be implemented using one or more heterogeneous processor systems, in which a main processor and secondary processors are located on a single chip. As another illustrative example, the processor unit 204 can be a symmetric multiprocessor system containing several processors of the same type.

[0018] Main memory 206 and permanent storage 208 are examples of storage units. A storage unit is any hardware component that can store data either temporarily and / or permanently. In these examples, main memory 206 could be, for instance, random-access memory or any other volatile or non-volatile storage unit. Depending on the specific implementation, permanent storage 208 can take various forms. For example, permanent storage 208 can contain one or more components or units. It could be, for instance, a hard disk drive, flash memory, a rewritable optical disk, a rewritable magnetic tape, or a combination thereof. The medium used by permanent storage 208 can also be replaceable.For example, a removable hard disk drive can be used as permanent storage.

[0019] In this example, the Data Transmission Unit 210 provides data transmission to other data processing systems or units. In these examples, the Data Transmission Unit 210 is a network interface card. The Data Transmission Unit 210 can provide data transmission using either physical data transmission links, wireless data transmission links, or both.

[0020] The input / output unit 212 enables the input and output of data using other units that can be connected to the data processing system 200. For example, the input / output unit 212 can provide a connection for user input via a keyboard and mouse. Furthermore, the input / output unit 212 can send output to a printer. The display 214 can provide a mechanism for displaying information to a user.

[0021] Instructions for the operating system and applications or programs are located in the permanent storage 208. These instructions can be loaded into the main memory 206 for execution by the processor unit 204. The processes of the different embodiments can be implemented by the processor unit 204 using computer-implemented instructions located in a main memory such as the main memory 206. These instructions are referred to as "program code," "computer-usable program code," or "computer-readable program code" and can be read and executed by a processor in the processor unit 204. The program code in the different embodiments can be embodied on various physical or material computer-readable media, such as the main memory 206 or the permanent storage 208.

[0022] The program code 216 is stored in a functional form on the selectively removable, computer-readable medium 218 and can be loaded into or transferred to the data processing system 200 by the processor unit 204. In these examples, the program code 216 and the computer-readable medium 218 constitute the computer program product 220. In one example, the computer-readable medium 218 can be in physical form, e.g., as an optical or magnetic disk, which can be inserted into or placed in a drive or other unit that forms part of the permanent storage 208 for the purpose of transferring the data to a storage unit such as a hard drive. Alternatively, the computer-readable medium 218 can also be in the form of a permanent storage device such as...a hard drive, a USB stick, or a flash memory connected to the data processing system 200. The physical form of the computer-readable medium 218 is also referred to as a "computer-writable storage medium." In some cases, the computer-writable medium 218 may be non-removable.

[0023] Alternatively, the program code 216 can be transferred from the computer-readable medium 218 to the data processing system 200 via a data exchange connection to the data exchange unit 210 and / or a connection to the input / output unit 212. In the illustrative examples, the data exchange connection and / or the connection can be in physical or wireless form. The computer-readable medium can also take the form of non-material media, such as communication links or wireless transmissions, that contain the program code. The different illustrated components of the data processing system 200 are not intended to restrict the architecture with respect to the ways in which different embodiments can be implemented.The various illustrative embodiments can be implemented in a data processing system that includes components in addition to or instead of the components illustrated in connection with data processing system 200. Others in . Fig. The components shown may differ from the illustrative examples. For example, in the data processing system 200, the storage unit is any hardware device capable of storing data. Main memory 206, permanent storage 208, and computer-readable medium 218 are examples of storage units in physical form.

[0024] In another example, a bus system can be used to implement the data exchange structure 202, and can have one or more buses, such as a system bus or an input / output bus. Naturally, the bus system can be implemented using any suitable type of architecture that provides data transfer between different components or units connected to the bus system. Furthermore, a data exchange unit can contain one or more units used for sending and receiving data, such as a modem or a network adapter. Additionally, main memory can be, for example, main memory 206 or a cache, such as those found in an interface and a memory controller hub, which can be present in a data exchange structure 202.

[0025] Computer program code for executing operations of the present invention can be written in any combination of one or more programming languages, including, but not limited to, an object-oriented programming language such as Java, Smalltalk, C++, or similar languages, and conventional procedural programming languages ​​such as "C" or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server.In the latter scenario, the remotely located computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (e.g., via the internet using an internet service provider).

[0026] Experts will be aware that the hardware in the Fig. 1 to 2 may vary depending on the implementation. Other internal hardware or peripheral units, such as flash memory, equivalent non-volatile memory, optical disk drives, and the like, may be used in addition to or instead of those specified in the Fig. The hardware shown in Figures 1 and 2 can be used. Furthermore, unlike the previously mentioned symmetrical multiprocessor system, the processes of the illustrative embodiments can be applied to a multiprocessor data processing system without deviating from the scope of protection of the disclosed subject matter.

[0027] As will become clear, the techniques described herein can be combined within, for example, the Fig. Figure 1 illustrates the client-server standard model, in which client computers exchange data with a web-based portal accessible via the internet, running on a group of one or more computers. End users operate internet-connected devices (e.g., desktop computers, notebook computers, internet-enabled mobile devices, or similar) that can access and interact with the portal. Typically, a client or server computer is a data processing system, such as in Fig. Figure 2 illustrates a data processing system that consists of hardware and software, and these units exchange data with each other over a network such as the Internet, an intranet, an extranet, a private network, or any other data exchange medium or connection. A data processing system typically includes one or more processors, an operating system, one or more applications, and one or more utilities. The applications on the data processing system provide native support for web services, which includes, but is not limited to, support for HTTP, SOAP, XML, WSDL, UDDI, and WSFL. Information about SOAP, WSDL, UDDI, and WSFL can be found at the World Wide Web Consortium (W3C), which is responsible for developing and maintaining these standards; further information about HTTP and XML can be found at the Internet Engineering Task Force (IETF).It is assumed that the reader is familiar with these standards. Cloud computing model

[0028] Cloud computing is a service delivery model that provides convenient and on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, main memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management overhead or interaction with a service provider. This cloud model can have at least five characteristics, at least three service models, and at least four deployment models, all of which are described and defined in more detail in the "Draft NIST Working Definition of Cloud Computing" by Peter Mell and Tim Grance, dated October 7, 2009.

[0029] The following properties are particularly typical: On-demand Self Service: A cloud customer can unilaterally and automatically provision data processing functions such as server time and network storage as needed, without requiring any human interaction with the service provider.

[0030] Broad Network Access: Functions are available over a network, accessible via standard mechanisms that support use by heterogeneous platforms, thin or thick client platforms (e.g., mobile phones, notebook computers, and PDAs).

[0031] Resource pooling: The provider's data processing resources are pooled to serve multiple customers using a multi-user model with diverse physical and virtual resources that are dynamically allocated and reassigned according to demand. There is a perceived location independence in that the customer generally has no control over or knowledge of the exact location of the provided resources, but may be able to specify the location at a higher level of abstraction (e.g., country, state, or data center).

[0032] Rapid elasticity: Features can be deployed quickly and elastically, in some cases automatically, to rapidly scale up functionality, and released quickly to rapidly scale down functionality. This often gives customers the impression that the available features are unlimited and can be purchased in any quantity at any time.

[0033] Measured Service: Cloud systems automatically control and optimize resource usage by employing a measurement function at a specific level of abstraction appropriate for the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency for both the service provider and the customer.

[0034] The service models are generally the following: Software as a Service (SaaS): The functionality provided to the customer consists of using the provider's applications running on a cloud infrastructure. These applications can be accessed from various client devices via a thin-client interface, such as a web browser (e.g., web-based email). The customer does not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, storage space, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

[0035] Platform as a Service (PaaS): The functionality provided to the customer is to deploy customer-created or purchased applications on the cloud infrastructure, using programming languages ​​and tools supported by the provider. The customer does not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage space, but has control over the deployed applications and potentially over configurations of the applications' hosting environment.

[0036] Infrastructure as a Service (IaaS): The functionality provided to the customer consists of supplying processing, storage, networking, and other basic data processing resources, allowing the customer to deploy and run any software, including operating systems and applications. The customer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, and deployed applications, and potentially limited control over selected networking components (e.g., host firewalls).

[0037] The deployment models are generally the following: Private Cloud: The cloud infrastructure is operated exclusively for one organization. It can be managed by the organization or a third party and can be located on or off-site.

[0038] Community Cloud: This cloud infrastructure is used by multiple organizations and supports a specific user community with shared interests (e.g., aspects related to a task, security requirements, policies, and compliance with laws and regulations). It can be managed by the organizations or a third party and may be located on or off-site.

[0039] Public Cloud: The cloud infrastructure is made available to the general public or a large group within an industry and is owned by an organization that sells cloud services.

[0040] Hybrid cloud: The cloud infrastructure is a mixture of two or more clouds (private cloud, community cloud or public cloud) that remain independent entities but are connected via a standardized or proprietary technology that enables the portability of data and applications (e.g. cloud bursting for load balancing between clouds).

[0041] A cloud computing environment is service-oriented, emphasizing statelessness, low coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure comprised of a network of interconnected nodes. A representative cloud computing node is shown above. Fig. Figure 2 illustrates this. In particular, a cloud computing node contains a computer system / server that is capable of operating in conjunction with numerous other general-purpose or specialized data processing system environments or configurations. Examples of commonly known data processing systems, environments, and / or configurations suitable for use in conjunction with the computer system / server include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, handheld or notebook units, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics units, network PCs, minicomputer systems, mainframe systems, and distributed cloud computing environments, which may include any of the aforementioned systems or units, and the like.The computer system / server can be described in the general context of instructions executable on a computer system, such as program modules that are executed by a computer system. Program modules can generally contain routines, programs, objects, components, logic, and data structures, etc., that perform specific tasks or implement certain abstract data types. The computer system / server can be practically implemented in distributed cloud computing environments, where tasks are performed by remotely located processing units connected via a data transmission network. In a distributed cloud computing environment, program modules can reside on both local and remotely located computer system storage media, including storage units.

[0042] Now with reference to Fig. Figure 3 shows, as an example of additional background, a set of functional abstraction layers provided by a cloud computing environment. It should be clear from the outset that the Fig. The components, layers, and functions shown in the three diagrams are for illustrative purposes only, and embodiments of the invention are not limited to them. As illustrated, the following layers and corresponding functions are provided: A hardware and software layer 300 comprises hardware and software components. Examples of hardware components include mainframe computers, such as IBM. ® zSeries ® -systems; servers based on the RISC architecture (RISC = Reduced Instruction Set Computer), for example the IBM pSeries ® -systems; IBM xSeries ® -systems; IBM BladeCenter ®Systems; storage units; networks and networking components. Examples of software components include network application server software, such as the IBM WebSphere application server software. ® ; and database software, for example the database software IBM DB2 ® (IBM, zSeries, pSeries, xSeries, BladeCenter, WebSphere and DB2 are trademarks of International Business Machines Corporation registered worldwide in many jurisdictions.)

[0043] A virtualization layer 302 provides an abstraction layer from which the following examples of virtual entities can be deployed: virtual servers; virtual storage; virtual networks, including virtual private networks; virtual applications and operating systems; and virtual clients.

[0044] In one example, a 304 administration layer can provide the functions described below. Resource provisioning provides the dynamic procurement of compute resources and other resources used to perform tasks within the cloud computing environment. Charge tracking and pricing provide cost monitoring while resources are used within the cloud computing environment, as well as billing and invoicing for the use of these resources. In one example, these resources might include application software licenses. Security provides identity verification for cloud customers and tasks, as well as protection for data and other resources. A user portal provides customers and system administrators with access to the cloud computing environment.Service level management (SLM) provides the allocation and management of cloud computing resources to ensure the required level of service is achieved. Service level agreement (SLA) planning and fulfillment involves the advance planning and procurement of cloud computing resources for which future requirements are anticipated based on the SLA.

[0045] An operational load layer 306 provides examples of functionalities for which the cloud computing environment can be used. Examples of operational loads and functions that can be provided from this layer include: mapping and navigation; software development and lifecycle management; delivery of training in virtual classrooms; processing of data analytics; transaction processing; microservices and others (e.g., enterprise-specific functions in a private cloud).

[0046] It is understood from the outset that while this disclosure contains a detailed description of cloud computing, the implementation of the teachings presented herein is not limited to a cloud computing environment. Rather, embodiments of the disclosed subject matter can be implemented in conjunction with any other type of data processing environment currently known or developed in the future.

[0047] A representative cloud computing environment therefore has a set of higher-level functional components, including a front-end identity manager, a business support services (BSS) component, an operational support services (OSS) component, and the data processing cloud component. The identity manager is responsible for establishing connections with requesting clients to provide identity management, and this component can be implemented using one or more well-known systems, such as the Tivoli Federated Identity Manager (TFIM), available from IBM Corporation in Armonk, New York. Under appropriate circumstances, TFIM can be used to provide federated single sign-on (F-SSO) for other cloud components.The Enterprise Support Services component provides certain administrative functions, such as billing support. The Operations Support Services component is used to provide the deployment and management of other cloud components, such as virtual machine (VM) instances. A virtual machine is an operating system or application environment installed on software that emulates a physical computer. The cloud component represents the primary computing resources, typically a multitude of virtual machine instances used to run a target application made available for access through the cloud. One or more databases are used to store directory, log, and other operational data.All these components (including the front-end identity manager) reside "within" the cloud, but this is not a requirement. In an alternative implementation, the identity manager can be operated externally in the cloud. The service provider can also be operated outside the cloud.

[0048] Some clouds rely on non-traditional IP networks. For example, a cloud might be based on two-tier CLOS networks, where a dedicated single layer performs IP routing using MAC address hash values. The techniques described here can be used in such non-traditional clouds.

[0049] Most currently available cloud-based services are delivered either via bare-metal computers (computers without their own operating system) or virtual machines (VMs), although container technologies can also be used. Bare-metal environments are those in which applications are installed, run, and delivered from a base consisting of purpose-built cloud infrastructure and OS platforms. These environments utilize dedicated and specialized hardware and operating system configurations. A virtual machine, on the other hand, is a complete guest host running within a host system. When virtual machines are used, applications are installed, aggregated, and run under the control of a hypervisor, which virtualizes the hardware environment.Containers, on the other hand, provide an operating environment containing only the essential parts of the application (sometimes referred to as cloud services) and their dependencies, and multiple containers can run within a single instance of an operating system such as Linux. Docker is a virtualization platform that shares a single Linux kernel with all running instances (called containers). Other container-based technologies include Kubernetes and OpenShift. These container implementations share many common characteristics.

[0050] In general terms, a container is typically a single software unit, bundled with all its dependencies into a single image designed to run reliably on diverse systems. Container resources are managed via process control groups and separated by core namespaces. A container orchestration control routine determines where containers run within a managed cluster and establishes a private network for data transfer.

[0051] For example, a single Docker container is simple software because it runs on a shared core, thus making efficient use of available resources. Containers are widely used by many cloud PaaS developers for next-generation applications. For example, and not limited to, IBM ®Bluemix™ is a PaaS cloud platform that uses IBM containers to run Docker containers. Because a Docker container runs on the existing operating system and shared binaries, it is more compact than a virtual machine; therefore, a container solution is often faster and requires less storage.

[0052] A typical Docker architecture consists of a set of components: a Docker client, a Docker host, and a Docker registry. A Docker client exchanges data with a Docker host by sending it a command (such as a CLI command) that Docker can understand. A Docker host is a computer or a cloud-based platform that executes the request from the CLI Docker client. The Docker registry stores Docker images that have been published and registered. A Docker host retrieves images from the registry as needed. In a typical operation, a Docker client queries a Docker host for an image / container. If the image is available on the host, the host starts running the image; if the image is not available, the host can use the registry to try to find and download it.Runnable images are containers. Images are frozen copies of an application. When an image that has main memory and coordinates with the kernel is started to run, it becomes a container. Microservices

[0053] Microservices (sometimes also called micro-services) is an application architecture style in which an application consists of many discrete, network-connected components called microservices. This approach to designing and managing applications breaks down large, monolithic applications into small services. A single, network-accessible service is the smallest operational unit for a microservice application. Typically, each microservice is optimized for a single function and runs in its own process. Data transfers between microservices usually occur via RESTful application modules and message switching services. Preferably, a microservice is configured to be continuously integrated (CI) and continuously delivered (CD).Companies that use microservices benefit from numerous advantages, including efficiency, simplified deployment and maintenance, improved application quality, and scalability.

[0054] Since a microservice is typically a single task that is language-independent and requires no significant dependencies, it is well-suited for implementing a container-based operating environment. As noted above, application developers today divide large distributed systems evenly into communicating microservices, all running in parallel, for example, within a container orchestration control engine (COE) such as Kubernetes, Docker Swarm, or OpenShift. Each COE takes an image containing an application, its dependencies, and a distribution of a small operating system (OS) in a multi-tiered file system and creates a process within its own namespace on a hardware node.

[0055] Typically, a cloud provider receives a container image from a continuous integration / continuous delivery (CI / CD) pipeline. After deployment, the container orchestration control routine of a cloud provider is distributed to physical data processing nodes (see Fig. 3) The following assumptions (a threat model) can be made about the containers that an attacker can successfully compromise. Specifically, the entry points of the container images are binary programs implemented in system languages ​​such as C / C++, Go, or Rust. An attacker can interact with a container process running on a physical node via a network socket. Furthermore, the program contained in the image or any of its library dependencies may contain a vulnerability that allows the attacker to issue arbitrary system calls to the kernel of the operating system running the container process. However, it is assumed that the attacker is unable to break out of the container abstraction. Micro version

[0056] As further background information, micro-execution is a software testing technique for automatically executing binary code fragments without the need to manually define test harnesses. This capability can save significant time when testing arbitrary sections of binary programs that are difficult to execute using conventional tools or without stopping a production environment. To execute arbitrary code fragments, a micro-execution control routine must accurately model a program's environment, including main memory areas, environment variables, the file system, and library dependencies. For example, a micro-execution control routine can execute a sequence of machine instructions that dereferencing pointers by catching segmentation violations and returning random data with each dereferencing operation. Attack detection

[0057] As further background, Intrusion Detection Systems (IDS) are an established technology for protecting entire networks and individual hosts from attackers. Fig. Figure 4 illustrates these typical use cases. On the left, an IDS 400 is operated in the network 402, which contains several hosts 404, to detect and mitigate network-based attacks 405. On the right, an IDS 406 is executed in conjunction with a specific host 408 in an attempt to detect and mitigate a host-based attack 407.

[0058] Fig. Figure 5 illustrates a typical host-based Intrusion Detection System (IDS) 500, implemented in conjunction with a host operating system that has a core space 502 and a user space 504. A system call table 506 is accessible in the core space 502. A program P 508 runs in the user space 504 and makes system calls 510 to the host core via the table 506. The IDS 500, implemented in this operational context, tracks system calls made by the program to the host core to detect activity that deviates from normal behavior. Normal behavior can be defined as a model extracted from an application, as rules manually specified by an administrator, or as models derived from harmless program traces. For example, the IDS 500 implements a model M for the program P, and the IDS checks whether M ⊨ T.IDS approaches based on automata result in the definition of automata A ← P and a check to see if A is accepted by T. IDS approaches using machine learning (ML) / data mining define a classification F and training data D, and then check F. D = safe. However, generating a safe model can be difficult because it may not be possible to see all sections of the application being executed; furthermore, it can be difficult to determine whether the traces used to build the safe model are truly safe. Detection of attacks on microservices via binary analysis and container telemetry

[0059] Fig. Figure 6 is a higher-level, automated attack detection system. As illustrated, the approach incorporates two components: an automated binary analyzer 600 for generating behavioral models for container images, and the node-based detector 602, which verifies whether the telemetry generated by a given container matches its behavioral model. The node-based detector 602 is generally operated to capture system call tracking telemetry in the manner described above. Fig. Figure 6 thus illustrates the complete end-to-end execution of the IDS for a container image 604 provided as input. In this example, the container image 604 was previously processed by automated binary analysis 600, preferably offline, to generate an associated behavioral model M. An IDS for this image is then defined by checking 606 (e.g., M ⊨ T, whether the system call tracing telemetry generated by the image's execution container (which in this example is executed in a hardware node 608 within a container orchestration control routine (COE) 610 (which here runs Kubernetes)) whether the associated behavioral model is satisfied. If the behavioral model is satisfied, no attack is detected; if the behavioral model is not satisfied, an attack (or more generally, an anomaly) is indicated, and an automated action (e.g.,Mitigation, notification, placement in a sandbox, logging, etc.) can then be taken.

[0060] As illustrated, the automated binary analysis 600 generates the behavioral model for the container image (e.g., a Docker image) 604 with binary entry points (e.g., C / C++ programs). As shown in Fig. Figure 6 shows that the automated binary analysis takes an ELF 610 as input. ELF (Executable and Linking Format) is a standard binary format in operating systems such as Linux. ®The ELF representation of control data in an object file is platform-independent, and this type of representation allows object files to be recognized, syntactically parsed, and interpreted in a similar way, making ELF object files compatible across multiple platforms and architectures of varying sizes. The three main types of ELF files are: executable, relocatable, and shared object. These file types contain the code, data, and information about the program that the operating system and linkage editor need to perform the appropriate actions on these files. As illustrated, the ELF 610 for the container image is received, and a call graph 612 is generated.

[0061] In particular, and taking the container image as input, the modeling analysis generates the behavioral model 614, which summarizes how containers executed from this image interact with other processes, the file system, or the network. Preferably, the behavioral model M generated by this process is a graph data structure 614, wherein nodes in the graph represent resources, including processes, files, or network sockets, and edges in the graph represent system calls made by a process in the graph. A specific sequence of system calls is valid if the behavioral model M contains a path that matches the sequence starting from the node that generated the sequence of system calls.

[0062] Fig. Figure 7 illustrates an embodiment for the automated processing of binary analyses with further details. As shown, the container image 700 contains a data set and the ELF. The ELF is the executable file that represents the process or application running in the container. The image 700 is fed into a binary analysis platform (BAP) 702, which generates a static behavioral model for the image. Typically, the BAP 702 operates as an automated process or set of processes that runs as software on one or more hardware processors. Fig. BAP 702 graphically represents a single container image (700), but the process is repeated for multiple container images to build a library of behavioral models. During operation, BAP 702 takes an entry point of a container image (e.g., nginx in this case) and finds all library dependencies located on the image. From this information (and especially from the entry point), BAP 702 constructs a call graph (704) and outputs the leaves of the call graph (706) that refer to functions in other libraries. This procedure is repeated for each library dependency to identify a set of functions that the entry point and its dependencies require from the standard C library (liibc). For each function f required from libc, this function is then microexecuted.Preferably, the binary analysis approach optimizes this step by defining an ABI (binary application interface) for the standard C library that wraps previously microexecuted behaviors or allows analyses to be customized, e.g., by manually defining ABI function wrappers. Furthermore, and for efficiency reasons, a similar approach is preferably used for other shared libraries (i.e., dynamically linked libraries) to accelerate the analysis.

[0063] With renewed reference to Fig. 7. The BAP 702 then examines every possible execution path in the function f and observes the value of the RAX register (familiarity with the semantics of the Linux kernel is assumed) when it encounters a syscall instruction. The BAP 702 then outputs a set of observed values ​​for RAX as a set of system calls executed by the function f. Preferably, and for efficiency, the BAP limits the output to only those system calls (e.g., execve) that affect the process lifecycle or interact with the file system or network. The BAP 702 then creates the behavioral model 708, preferably with a single node representing the execution container for this image. The BAP then re-inspects the original call graph 704 with respect to the entry point and preferably performs a depth-first search (DFS) traverse on the graph.Each time the search encounters a function from libc, a check is performed to determine if the discovered function makes relevant system calls. If so, these system calls are added to the edge that connects the calling process to the resource that the libc function modifies. If no such edge exists, a node is created for the resource, and an edge to it is added from the calling process. The resulting behavioral model M is illustrated at page 708.

[0064] To optimize the process described above, valid sequences of system calls are encoded into the behavioral model, for example, using static stain analysis. In particular, and for certain functions that create processes or open files and sockets, stain analysis enriches the behavioral model by identifying the sequence of functions that receive a specific resource as input.

[0065] For each function, the call graph is queried to determine the system calls it might make. The identified sequence of system calls is then embedded in the behavioral model, for example, as a path originating from the resource node. For each system call in the sequence, a new edge to a new node is created, if one does not already exist.

[0066] Fig. Figure 8 illustrates how a call graph is constructed from a binary representation. This example shows section 800 of the container image (which contains the main program). As described above, the Binary Analysis Platform (BAP) creates an intermediate representation (IR) 802, which is then processed to generate the call graph 804. Fig. Figure 9 illustrates how BAP recognizes system calls within a micro-execution of a program. The assembly code instructions 900 are shown on the left, and the value of the RAX register 902 is shown on the right. In this example, the recognized system calls 904 are clone and execve. Automated synthesis of reference guidelines for the protection of microservices during runtime

[0067] As described above, security policies are generated by annotating a program's call flow graph (CFG) with system call information obtained from microexecuted program dependencies. While the approach described above offers advantages, this disclosure describes an improved technique for the automated synthesis of reference policies. In particular, instead of the previous ad hoc approach to annotating a CFG, the technique presented here replaces this with the microexecution of entire programs, where a specific program is executed directly within the analysis environment, preferably with a binary application interface (ABI) that allows the program to execute and access the resources specified in its container image.As described, the ABI allows analysis to scale large and complex binaries because it provides a means of specifying the behavior of external libraries without requiring their microexecution. Microexecuting entire programs allows the analysis environment to maintain a behavior graph (BG), whose semantics are described below, and which is a compact representation of all system call sequences observed during analysis. This approach has several advantages over the one described above in conjunction with [missing information]. Fig. The technique described in section 7 includes embedding specific system call arguments in the final security policy, which prevents attackers from causing side effects by executing unused program functions, and enables the generation of policies from specific executions that utilize both the file system of a container image and process environments and test inputs.

[0068] Fig. Figure 10 provides a simplified illustration of how the micro-execution of entire programs functions in a preferred embodiment using the Binary Analysis Platform (BAP). Specifically, the Binary Analysis Platform 1000 is a framework environment for performing analyses on binary files that have been converted into a BAP Intermediate Language (BIL) 1002, which preserves the semantics of the instruction set architecture (ISA) of the binary file. Simultaneously, the BAP 1000 manages an intermediate representation (BIR) 1004 of the program in the form of static single assignments. According to this disclosure, the BIL micro-execution is then performed using the framework environment 1006 for BAP micro-execution.In a representative implementation, micro-execution is performed via a BAP plug-in called Primus. This plug-in allows user-defined plugins to execute BIL 1002 from any address and to perform script analysis in OCaml. OCaml is a general-purpose, multi-paradigm programming language that extends the Caml dialect of the machine learning programming language with object-oriented functionality. Micro-execution is activated in Primus by an integrated execution plug-in that emulates instructions in the BIL within a machine type. This Primus machine 1008 contains a process address range 1010, which mimics a real operating system process. This framework enables many interesting program analyses because user-defined plugins can comprehensively configure the Primus machine 1008. By default, this machine simply executes code in the form of micro-execution.To automatically track the effects of a particular program, a custom plug-in, as described below, explicitly tracks the effects produced by the BIR 1004, preferably as specified by an IR semantics and formal semantics, which are described in more detail below.

[0069] The following provides further details regarding the BAP microexecution framework, which provides a binary application interface (ABI). It is well known that binary programs often use routines located in external libraries. During microexecution, Primus replaces calls to external functions found in a binary's global offset table (GOT) with random values. For example, calling `sqrt` in the math package of the standard C library returns a random value in RAX instead of transferring and microexecuting `sqrt` from `libc.so`. This heuristic works well for modeling programs that can run without exact library dependencies, but it is insufficient to support programs that interact with input / output data streams, process strings, or send / receive network data.To overcome this limitation, the preferred approach here uses the Primus LISP interpreter 1012 to model the binary application interface (ABI) of an executable file and to implement LISP wrappers for abstractly interpreting the effects of shared library functions, or explicitly microexecuting them. This significantly speeds up the analysis because symbol state is constrained and microexecution steps are reduced. ABIs typically do not change frequently and can be further developed with library updates.

[0070] If Primus encounters an undefined symbol during microexecution according to the approach described herein, it consults the ABI provided to the BAP. If the undefined function exists in the ABI, Primus searches a corpus of LISP programs for a function that implements the desired interface and calls the LISP function with the arguments provided by the binary. By default, the BAP contains a subset of the standard C library implemented in the Primus LISP, including a dynamic main memory allocation unit. Additional functions with extended functionality can easily be implemented if required.

[0071] Fig. Figure 11 shows a representative ABI example. In this example, list 1100 provides a LISP wrapper that implements the function `strtok_r` in the ABI. Preferably, the abstraction level in the Primus LISP is intentionally kept close to the machine level, providing a convenient way to change machine state. When implementing more complex functions such as `printf`, the Primus LISP can be cumbersome, but the BAP makes it easy for a plug-in to extend the LISP language with user-defined functions that call back to the OCaml runtime when extended functionality is needed. As an example, a rough approximation of `sprintf` is implemented by using a combination of functions found within the string OCaml module and Primus's ability to enumerate the inputs -00 of a function during microexecution.By default, Primus is provided with a dynamic main memory allocation unit implemented in LISP to support the family of malloc functions found in stdlib.h, and may also include other functions (or modifications of provided functions). When microexecuting a program, Primus may encounter a system call instruction in the binary, where the system call is detected by checking the value of the RAX register. Preferably, the functions that wrap system calls are executed separately to determine if they have any effects.

[0072] The BAP plug-in builds a graph data structure called the effect graph, which encodes all system call sequences observed during microexecution, along with the arguments passed to each system call. Each node v in the graph represents a specific expression ID in the BIR (Bind-In-Record) that produces effects in the form of system calls. An expression ID in the BAP uniquely identifies a specific location in the IR. This can be either a system call directly output by the binary or an external library function, such as `printf`, that outputs system calls. Along with the expression ID that outputs a system call, each node v0 also contains the concrete arguments passed to the system call, obtained by examining the contents of registers.Each edge v1, v2 in the effect graph is labeled by the system call output by node v2. At the start of the analysis, the effect graph begins with a single root node representing the process before the binary's ... start routine is executed when the process starts. At the end of the symbol analysis, the final graph represents an instance of the valid system call flows that the program can output during its execution, taking into account the constraints imposed by the program entry point and its environment.

[0073] If a library function called at node v2 is observed in the binary and results in an effect of interest, it creates an edge in the effect graph between the last inspected node v1 and v2.

[0074] System calls observed against the function are assigned as edge labels. The new label is recorded as the last inspected node, and microexecution continues. The concrete function arguments are also stored in v2 to generate the post-microexecution safety policy. Storing the unique expression ID in each node allows the system to prevent duplicate nodes from being created in the effect graph and instead create edges that reference previously inspected nodes. This design decision has been found to result in more compact and general models and prevents programs that repeatedly call the same function within loops from having overly complex and large safety policies.

[0075] To build the effect graph, the BAP preferably defines a user-defined machine module that subscribes to relevant callbacks in the Primus interpreter. Each time Primus enters or exits a subroutine in the intermediate code, the analysis pushes the subroutine's name into or retrieves it from a call stack managed in plug-in state. This allows the framework environment to embed context within the effect graph and pass this context when policy violations are detected. In addition to managing a call stack, the system also subscribes to each JMP statement executed in the intermediate language. In the BIL, a JMP statement can represent a call to a subroutine contained in the analyzed binary, an external library function, or an address stored in a register.In the first case, the BAP pushes the function onto the call stack before microexecuting it. In the second case, the effect graph is extended to include the expression ID of the JMP if the external function has effects. In the third case, where the BAP only has the target address of the JMP, a search for the function is performed in the BAP's GOT. This third case is useful for programs that call functions by directly using function pointers stored in registers.

[0076] Once micro-execution is complete, the BAP receives an effect graph that encodes the permissible flows of valid, safety-related system calls that can output a binary file when executed. To export the effect graph into a suitable security policy for attack detection, the expression ID, which defines the label for each node, is replaced with the arguments passed to the system call observed during micro-execution. This results in a finite automaton that encodes a security policy.

[0077] Fig. Figure 12 illustrates an example of the automated processing described above. In comparison to the approach in Fig. 7 (commenting a call graph with system call information obtained by microexecuting program dependencies), in this preferred embodiment, the BAP replaces it with microexecuting the entire program, where a specific program is executed directly within the analysis environment. In this example, container image 1200 has a data record and the ELF.As before, the image 1200 is input into the binary analysis platform (BAP) 1202, but in this case, the BAP 1202 includes the BAP microexecution framework environment, preferably the Primus BAP plug-in, which includes its integrated machine 1204 that emulates instructions into the BIL 1206, and the LISP interpreter 1208, which models the binary application interface (ABI) of an executable file and implements one or more LISP wrapping units (some of which are shown at 1210) for abstractly interpreting the effects of shared library functions without explicitly microexecuting them. The BAP 1202 operates as an automated process or set of processes that is / are executed as software in one or more hardware processors. In contrast to the one in . Fig. In contrast to the earlier approach, illustrated in Figure 7, which involved microexecuting the entire program, concrete system call arguments 1214 are included in the final security policy 1216, thus preventing attackers from causing side effects by executing unused program functions. In this approach, the security policy 1216 is generated from concrete executions that utilize the file system of a container image, process environments, and arbitrary test inputs.

[0078] Although in Fig. Not shown in Figure 12, the security policy 1216 is instantiated in a microservice-aware intrusion detection system (MIDS) that instantiates the policy, preferably as a security automaton, and efficiently tracks the effects generated by containers to detect policy violations.

[0079] In summary, policy synthesis according to this disclosure begins by taking an unmodified container image containing an application and all its dependencies, and by microexecuting the container's entry point, represented as a binary executable. Microexecution allows the analysis framework to automatically invoke arbitrary machine code without requiring manual error simulations around individual code fragments. Microexecuting the binary enables the synthesis process to automatically execute individual code paths within the executable to observe the system calls that the binary can issue during its execution. Microexecution manages the effect graph data structure to represent a behavioral model that embeds all sequences of system calls that a binary can issue during a given execution.When microexecution executes new code fragments in the binary, it may detect a new system call S. In this approach, an edge E is added to the last inspected node of the graph to denote S, and a new node N is added to the graph to document the resources allocated to S as input. For example, if S is an "open" system call, the directed edge E is labeled "OPEN," and the node it points to contains the path of the file that was opened at that point in the program. If multiple paths are possible, a union of all possibilities is stored in N. If the file cannot be determined, a symbolic entry is provided in its place. The microexecution framework that performs this analysis translates the arguments for system calls by observing the concrete values ​​of relevant registers when it observes a syscall instruction.

[0080] After microexecution has either enumerated all the basic blocks specified in a program or exceeded a configured timeout, it outputs a behavior graph representing all possible sequences of system calls that a program can make during its execution. Naturally, the effect graph thus represents the most accurate safety policy P for a reference monitoring facility. Since many commercial reference monitoring facilities do not accept fully directed graphs as safety policies, P is typically transformed into a suitable safety policy. This transformation varies depending on the target reference monitoring facility, but usually, the information needed to define a useful and accurate policy for a program is obtained by traversing the graph structure specified in P.For example, restricting a program's access to the file system can be achieved by taking all nodes of the effect graph that are referred to as "OPEN" edges and deriving a policy that restricts access to these files.

[0081] As described above, automated policy synthesis is typically implemented in conjunction with a microservices architecture that divides application components into separate, self-contained file system images (the containers), which a container orchestration control routine manages across a set of physical data processing nodes. As noted above, a container image is a multi-layered file system containing an entry point program and all the files and dependencies required to execute the entry point within a sandbox environment. To secure the microservices architecture, container workloads are monitored for security policy violations, typically using a reference monitoring facility, such as a microservices-enabled attack detection system (IDS), as described previously.The preferred approach synthesizes security policies for container images via microexecution, and the resulting policies are then used to detect policy violations via container telemetry. Specifically, and as described in... Fig. As illustrated in Figure 5, the attack detector receives a system telemetry data stream that encodes process origin information and associates process events with network and file system activities associated with individual microservices, thereby enabling the microservice-enabled IDS to efficiently execute the security automation that complies with each microservice's security policy and flags unacceptable behaviors. Synthesis of safety guidelines

[0082] The following provides additional details regarding a preferred approach for synthesizing safety policies. Preferably, this synthesis is defined in terms of a simplified intermediate representation (IR) obtained by decomposing binary programs. This representation abstracts binary programs across different instruction set architectures and models the effects explicitly observed through the semantics of microexecution. Fig. Section 13 presents a representative language syntax. Programs P are represented by lists of instructions, denoted by c. Instructions consist of variable assignments, pointer dereferencing assignments (memory), conditional branches, function calls, function returns, system call calls (abstracted as special calls), and program termination statements. Expressions are evaluated to typical value representations n, which include variables, numeric values, binary operations, and loads from memory locations. Variable names range from register identifiers to function names to system call identifiers. The syntax assumes that programs are written correctly. Execution contexts consist of a memory σ, which links memory locations to values ​​and variables to memory locations, and an environment Δ, which maps variables to values. To represent the semantics of effects for external function calls (e.g.,In addition to expressing API calls of the runtime library, the syntax includes a function table φ. This table assigns the names of external functions to their entry points, creating an interpreter context. A, which dictates whether and how each external function produces observable effects, and the call stack O. The by A The returned effects are expressed as mappings of function parameters r (represented as register values) that can be fitted to the sequence of effects ε generated by f. Effects ε are defined as pairs 〈id, r〉, where id denotes system call identifiers and r denotes the system call parameters.

[0083] Fig. Figure 13 presents a visual representation of an operational semantics that defines how effects are generated by a microexecuted program. Expression evaluations occur in large steps (⇓), while instruction evaluations occur in small steps (→1). Abstract machine configurations consist of tuples 〈σ, Δ, Ξ, pc, l〉, where pc is the program pointer and l is the current instruction. The representation Δ [v ↦ n] denotes a function Δ, where v has been newly mapped to n, and the representation P[pc] refers to a program instruction at address pc. P is omitted from the machine configurations because it is static.

[0084] Expressions in the language are pure, and programs are unaware of their own structure. The semantics of `load e` read the value stored at memory location `e`. Conversely, `store e1, e2` stores the value `e2` at memory location `e1`. In C programs, this models pointer dereferencing and dereferencing assignments, respectively. Variable assignment is a sequential instruction `v := e` that evaluates `e`, updates the environment with the new assignments of `v`, and proceeds to the next instruction, `pc + 1`.

[0085] External function calls `call f` create a new stack frame `fr` with function arguments Δ[r1] ... Δ[r n ] and jump to the entry point of the called function. Return values ​​`ret e` then inherit the interpreter context. A one, to capture the sequence of effects ε accordingly, which were produced by the function based on its input arguments. The context A can be adapted and reused across microexecutions to specify how effects are generated by external libraries without requiring microexecution of the analysis. This design choice allows the symbol space to be kept small during microexecution, significantly speeding up policy synthesis. Special instructions are instructions that invoke system calls. The semantics of `spec id` produce the effect `ε = 〈id, Δ[r1] ... Δ[r`. n ]〉, where id indexes the system call type and Δ[r1] ... Δ[r n The system call parameters are defined according to the calling convention. The termination command `halt n` stops the program immediately and updates the environment with the return value `n`.

[0086] The approach used in the micro-execution of the micro-service-enabled IDS utilizes this operational semantics to create a directed graph. G to generate a list that summarizes the permissible sequences of observable effects that a program can produce during execution. More precisely, G=〈V,E,E→{(v1,v2)|(v1,v2)∈V2}〉, where the pair 〈pc, r〉 ∈ V is a node encoding a program state (including register values ​​used as parameters for system calls), and id ∈ E is a labeled edge representing an observed system call. This effect graph therefore describes a finite automaton used as a reference safety policy for detecting unintended program behavior, as described. Advantages and variations

[0087] The techniques described herein are advantageous because they provide the automatic synthesis of reference policies from programs using static analysis across binaries. As described, static binary analysis is used to automatically synthesize stateful policies that accurately describe a program's behavior. The behavior contained in these policies can be any behavior that an operating system can observe, and the techniques can be used to restrict behavior to system calls that a program can issue during its execution. Existing reference monitoring tools (e.g., SELinux, AppArmor, and Audit) accept declarative security policies as input, which only allow operators to restrict the program's access to specific system calls and resources.In contrast, the stateful policies generated by the policy synthesis procedure described herein enable operators to create policies that contain the valid sequences of system calls a program can produce. Instead of restricting to a finite set of system calls and resources, the described procedure generates policies that restrict programs to the valid sequences of system calls that any execution of a program can produce. These more informative policies can then be compiled into simpler representations that are accepted by widely used existing reference monitoring systems. This automatic policy generation for existing reference monitoring systems saves valuable time for the operator, as manually defining useful policies often requires extensive technical expertise.

[0088] This approach synthesizes security policies that summarize how a program interacts with the operating system via system calls. This approach can be generalized to any observable program behavior. For example, it can be used to synthesize policies that estimate the worst-case execution time of specific program fragments, that limit the main memory areas a program can access, or that prescribe the memory locations in an address space where sensitive information may reside.

[0089] In summary, this disclosure provides a framework and a method for generating behavioral models from container images, preferably using binary analysis. These models are preferably generated by microexecuting the entire program, preferably using a BAP framework configured with a plug-in such as Primus. An Intrusion Detection System (IDS) is then defined that checks whether the telemetry generated by an executed container of the image corresponds to the associated behavioral model. Behavioral models are built from container images that can be accessed from a registry database. These models are preferably sufficiently compact to be housed together with the executed containers and to detect irregularities in real time (or essentially in real time) if and when they occur on the associated hardware node.An attack detection system according to this disclosure generates the behavioral models through automated analysis and immediately detects attacks when they occur on the hardware node on which a particular container is running.

[0090] According to one variant of the embodiment, the IDS agent (or an IDS containing such agent processes) accesses a library of behavioral models for the container images that have been previously built and are available for retrieval. In other words, according to this variant, there is no requirement that the IDS (containing the agents) must be the same process that performs the offline binary analysis.

[0091] Typically, a behavioral model is associated with a specific container image, and this container image corresponds to a specific microservice that generates telemetry when executed in a runtime (COE) environment. While the technique requires the container image to correspond to a microservice, this is not a limitation, as the approach described herein can be used with any program that has an associated behavioral model.

[0092] The technique described herein is not specific to any particular application model and can be implemented in client-side or server-side configurations. In fact, even applications that are entirely server-side or have a significant server-side component can be built on a microservices model (or a SOA model) and benefit from it.

[0093] One or more aspects of the technology can be implemented in a cloud computing environment ( Fig. 3) or otherwise use cloud computing resources.

[0094] The functionality described above can be implemented as a standalone approach, e.g., as a software-based function executed by a processor, or it can be provided as a managed service (including, among other things, as a web service via a SOAP / XML interface). The specific details of the hardware and software implementation described herein serve only for illustrative purposes and are not intended to limit the scope of protection afforded to the described subject matter.

[0095] The techniques described herein are not limited to use with microservices-based applications, although this type of application implementation benefits significantly from this approach. In fact, the approach can also be used in execution environments based on monolithic models, object-oriented models, and others.

[0096] The scheme described herein can be implemented in or in conjunction with various server-side architectures that are not cloud-based infrastructures. These include, but are not limited to, simple n-level architectures, web portals, federated systems, and the like.

[0097] More generally, the subject matter disclosed herein may take the form of an embodiment implemented entirely in hardware, an embodiment implemented entirely in software, or an embodiment that includes both hardware and software elements.

[0098] Furthermore, the behavioral modeling and IDS functionality described herein can take the form of a computer program product accessible from a computer-usable or computer-readable medium that provides program code for use by or in conjunction with a computer or any system to execute instructions. For the purposes of this description, a computer-usable or computer-readable medium can be any device capable of containing or storing the program used by or in conjunction with the system, device, or unit to execute instructions. The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or a corresponding device or unit).Examples of computer-readable media include semiconductor or solid-state memory, magnetic tape, removable floppy disks, random access memory (RAM), read-only memory (ROM), magnetic hard disks, and optical discs. Current examples of optical discs include read-only storage in the form of a compact disc (CD-ROM), a rewritable compact disc (CR-R / W), and a DVD. A computer-readable medium is a physical object.

[0099] The computer program product may be a program that contains program instructions (or program code) to implement one or more of the described functions. These program instructions may be stored in a computer-readable storage medium within a data processing system after being downloaded over a network from a remote data processing system. Alternatively, these instructions may be stored in a computer-readable storage medium within a server data processing system and designed to be downloaded over a network to a remote data processing system for use on the remote system in a computer-readable storage medium.

[0100] In a representative embodiment, the components as described are implemented in a specialized computer, preferably in software executed by one or more processors. The software is also managed in one or more data storage devices or main memories belonging to the one or more processors, and the software can be implemented as one or more computer programs.

[0101] This function can be implemented as an addition to or extension of an existing security service or access management solution. The technology can also be implemented in an automated manner, as described.

[0102] Although the foregoing describes a specific sequence of operations performed by certain embodiments of the invention, it should be understood that this sequence serves as an example, since alternative embodiments may perform the operations in a different sequence, combine certain operations, overlap certain operations, and the like. References in the description to a particular embodiment indicate that the described embodiment may include a certain feature, structure, or property, but not all embodiments necessarily include that feature, structure, or property.

[0103] Although certain components of the system have been described separately, it will be clear to the person skilled in the art that some of the functions can be combined or divided into certain instructions, program sequences, code sections, and the like.

[0104] The techniques listed herein provide improvements to other technologies or technical fields, such as container-based operating environments and microservices.

[0105] While real-time container telemetry is preferably used for comparison with the behavioral models, an alternative embodiment may include the use of recorded system call traces.

[0106] While in a preferred embodiment the telemetry analyzed for the detection of irregularities is a set of captured system call traces, other diagnostic information can be used, such as that obtained by monitoring incoming or outgoing data packets, examining files, memory usage, and the like.

Claims

[1] Methods for the automated synthesis of security policies and their use in a container environment, comprising: during the binary analysis (600) of a program associated with a container image (604;700;1200), wherein the binary analysis is performed within a binary analysis platform (702;1000;1202), micro-executing the program directly within the binary analysis platform to generate a graph (612;704;804) that summarizes expected interactions of the program within the container environment; Automatic synthesis of a security policy (1216) from the graph; Instantiating the security policies into the container environment; and During runtime monitoring of an event sequence related to the program running in the container environment, take action if it is determined that the event sequence violates the security policy. [2] Method according to claim 1, wherein the expected interactions are detected by analyzing one or more system calls and their arguments found during micro-execution of the program. [3] Method according to claim 2, wherein the security policy embeds at least one system call argument. [4] The method of claim 1, further comprising modeling a binary application interface that specifies the behavior of an external library function, and generating an effect of executing the external library function during the micro-execution of the program without requiring its micro-execution. [5] Method according to claim 1, wherein during micro-execution of the program, one or more resources detected in the container image are accessed. [6] Method according to claim 1, wherein the program is converted into an intermediate representation prior to binary analysis, which retains the semantics of an underlying instruction set architecture. [7] Method according to claim 6, wherein the micro-execution of the program performs the intermediate representation. [8] Device (200) comprising: at least one hardware processor (204); Computer main memory (208) containing computer program instructions that are executed by at least one hardware processor to perform automated synthesis and use of security policies in a container environment, wherein the computer program instructions comprise program code configured to: during the binary analysis (600) of a program associated with a container image (604;700;1200), wherein the binary analysis is performed within a binary analysis platform (702;1000;1202), to micro-execute the program directly within the binary analysis platform to generate a graph (612;704;804) that summarizes expected interactions of the program within the container environment; to automatically synthesize a security policy (1216) from the graph; to instantiate the security policy into the container environment; and During runtime monitoring of an event sequence related to the program running in the container environment, action should be taken if it is determined that the event sequence violates the security policy. [9] Device according to claim 8, wherein the expected interactions of the program are detected by program code configured to analyze one or more system calls and their arguments found during micro-execution of the program. [10] Device according to claim 9, wherein the safety policy embeds at least one system call argument. [11] Device according to claim 8, further comprising program code for modeling a binary application interface (ABI) that specifies the behavior of an external library function, and wherein, during micro-execution of the program, the program code is further configured to produce an effect of executing the external library function without requiring its micro-execution. [12] Device according to claim 8, wherein during micro-execution of the program, one or more resources detected in the container image are accessed. [13] Device according to claim 8, further comprising program code that converts the program into an intermediate representation that retains the semantics of an underlying instruction set architecture. [14] Device according to claim 13, wherein the micro-execution of the program performs the intermediate representation. [15] Computer program product (220) on a non-volatile, computer-readable medium (218) for use in a data processing system (200), wherein the computer program product contains computer program instructions that are executed by the data processing system to perform an automated synthesis and use of security policies in a container environment; wherein the computer program instructions contain program code configured to: during the binary analysis (600) of a program associated with a container image (604;700;1200), wherein the binary analysis is performed within a binary analysis platform (702;1000;1202), the program is microexecuted directly within the binary analysis platform to generate a graph (612;704;804) that summarizes expected interactions of the program within the container environment; automatically synthesizes a security policy (1216) from the graph; the security policy instantiated into the container environment; and During runtime monitoring of an event sequence related to the program running in the container environment, action is taken if it is determined that the event sequence violates the security policy. [16] Computer program product according to claim 15, wherein the expected interactions of the program are detected by program code configured to analyze one or more system calls and their arguments found during micro-execution of the program. [17] Computer program product according to claim 16, wherein the security policy embeds at least one system call argument. [18] Computer program product according to claim 15, further comprising program code for modeling a binary application interface (ABI) that specifies a behavior of an external library function, and wherein the program code is further configured to produce an effect of executing the external library function during microexecution of the program without requiring its microexecution. [19] Computer program product according to claim 15, wherein during micro-execution of the program, one or more resources detected in the container image are accessed. [20] Computer program product according to claim 15, further comprising program code that transforms the program into an intermediate representation that retains the semantics of an underlying instruction set architecture. [21] Computer program product according to claim 20, wherein the micro-execution of the program performs the intermediate representation.

Images