Methods, apparatus, and programs for synthesizing security policies

Abstract

A method, apparatus, and computer program are provided for automated security policy synthesis and use in a container environment. In this approach, a binary analysis of a program associated with a container image is performed within a binary analysis platform, and the program is micro-executed directly within the analysis platform to generate a graph summarizing expected interactions of the program within the container environment at runtime during the binary analysis. The expected interactions are identified by analysis of one or more system calls and their arguments found during the micro-execution of the program. Once the graph is created, a security policy is automatically synthesized from the graph and instantiated within the container environment. The policy is embedded with at least one system call argument. Actions are taken if, during runtime monitoring of an event sequence associated with the program executing in the container environment, the event sequence is determined to violate the security policy.

Description

Technical Field

[0001] This disclosure generally relates to intrusion detection in a microservices computing environment.

Background Art

[0002] Currently, application developers routinely break down large-scale distributed systems into communicating "microservices" that all operate in parallel within a container orchestration engine (COE) such as, for example, Kubernetes(R), Docker(R) Swarm, or OpenShift(R). Each orchestration engine takes an image that includes an application, its dependencies, and a small operating system (OS) distribution of a hierarchical file system and creates a process within its own namespace on a hardware node.

[0003] Reference monitoring continuously inspects program execution to check for any behavior that deviates from the reference policy. The reference policy is a set of program behaviors that an operator is expected to observe during normal execution. If an adversary hijacks a program in any way, malicious behavior should deviate from the reference policy, and this should generate an alert for the operator or terminate the compromised program. While numerous reference monitors exist for enforcing policies at the individual process level within the operating system, the recent adoption of microservices, where developers configure large-scale distributed applications across service meshes, necessitates new approaches to reference monitoring that go beyond the capabilities seen in existing operating system kernel or compiler-based approaches. Cloud operators and individual security vendors are beginning to offer anomaly detection services built on top of granular container telemetry, but these approaches often require considerable manual expertise to implement or focus only on detecting well-known, persistent problems across all workloads, such as developers gaining unauthorized access to production containers or exploits made against cloud architectures.

[0004] Furthermore, defining policies for reference monitors is a manual task requiring considerable expertise to perform effectively. While automated approaches exist, they often focus on detecting general security issues rather than deriving policies tailored to a single application. Recent advances in creating application-specific policies include the introduction of the Common Intermediate Language (CIL) for SELinux(R) reference monitors found within the Linux(R) kernel. This allows operators to define reference policies in a declarative language, but writing useful policies still requires deep expertise in the protected program. Moreover, because these policies are stateless, analysts cannot infer the complex sequences of operations a program might perform on system resources. Currently, state-of-the-art reference monitors lack a fully automated approach to defining stateful policies that accurately describe how a program interacts with system resources. [Overview of the project]

[0005] Methods, apparatus, and computer program products are provided for the automated synthesis and use of security policies in container environments. In this approach, binary analysis of the program associated with the container image is performed within a binary analysis platform. During binary analysis, the program is directly microexecuted within the analysis platform to generate a graph summarizing the expected interactions of the program within the container environment at runtime. Expected interactions are identified by analyzing one or more system calls and their arguments found while the program is microexecuted. Once the graph is created, security policies are automatically synthesized from the graph and instantiated within the container environment. The policies are embedded with at least one system call argument. During runtime monitoring of event sequences related to the program running in the container environment, actions are taken if an event sequence is determined to violate the security policy.

[0006] The above outlines some of the more relevant features of the disclosed subject matter. These features should be interpreted as illustrative only. Many other beneficial results can be achieved by applying the disclosed subject matter in different ways, or by modifying it as described below.

[0007] To fully understand this subject and its advantages, please refer to the following description in conjunction with the attached drawings. [Brief explanation of the drawing]

[0008] [Figure 1] This is an exemplary block diagram of a distributed data processing environment in which an exemplary embodiment of the exemplary embodiment is implemented. [Figure 2] This is an exemplary block diagram of a data processing system in which an exemplary embodiment of the exemplary embodiment is implemented. [Figure 3]This diagram shows a typical cloud computing environment in which the technologies disclosed herein are put into practice. [Figure 4] This figure shows several implementations of intrusion detection systems related to network operating environments. [Figure 5] This figure shows a host-based intrusion detection system (IDS) to which the technology disclosed herein is associated. [Figure 6] This figure illustrates a framework in which, preferably offline, binary analysis of container images is performed to build a library of behavioral models, and then container telemetry is analyzed in real time against these models for intrusion detection. [Figure 7] This diagram illustrates a typical binary analysis process. [Figure 8] This figure illustrates an example of how a call graph is constructed from a container image using binary analysis. [Figure 9] This figure shows an example of how a target system call is identified through binary analysis. [Figure 10] This figure shows a binary analysis platform (BAP) that implements micro-execution of entire programs to process individual binary programs into a reference policy, as disclosed in this disclosure. [Figure 11] Figure 10 shows an exemplary Application Binary Interface (ABI) implemented in the microexecution environment of the entire program. [Figure 12] This figure shows the microexecution technique of the whole program of this disclosure, in which a given program is executed directly within an analysis environment, preferably using an Application Binary Interface (ABI) that enables the program to execute and access resources given within its container image. [Figure 13]This diagram shows typical intermediate representation (IR) syntax used in policy synthesis. [Figure 14] This diagram illustrates the various operational semantics that define how effects are generated by programs microexecuted during policy synthesis. [Modes for carrying out the invention]

[0009] Referring here to the drawings, and in particular to Figures 1 and 2, illustrative diagrams of a data processing environment in which exemplary embodiments of the present disclosure are implemented are provided. It should be understood that Figures 1 and 2 are merely examples and are not intended to imply or make any limitation on any aspect of the disclosed subject matter or the environment in which the embodiments are implemented. Many modifications to the illustrated environment can be made without departing from the scope of the invention.

[0010] Referring here to the drawings, Figure 1 illustrates an exemplary distributed data processing system in which an aspect of the exemplary embodiment is implemented. The distributed data processing system 100 may include a network of computers in which an aspect of the exemplary embodiment is implemented. The distributed data processing system 100 includes at least one network 102, which is a medium used to provide communication links between various devices and computers that are interconnected within the distributed data processing system 100. The network 102 may include, for example, wired, wireless, or fiber optic cable connections.

[0011] In the illustrated example, servers 104 and 106 are connected to network 102 along with storage unit 108. Additionally, clients 110, 112, and 114 are also connected to network 102. These clients 110, 112, and 114 could be, for example, personal computers, network computers, etc. In the illustrated example, server 104 provides clients 110, 112, and 114 with data such as boot files, operating system images, and applications. Clients 110, 112, and 114 are clients of server 104 in the illustrated example. The distributed data processing system 100 may include additional servers, clients, and other devices not shown.

[0012] In the illustrated example, the distributed data processing system 100 is the Internet, and network 102 represents a global collection of networks and gateways that communicate with each other using the Transmission Control Protocol / Internet Protocol (TCP / IP) protocol suite. At the heart of the Internet is a backbone of high-speed data communication lines between major node or host computers consisting of thousands of commercial, governmental, educational, and other computer systems routing data and messages. Naturally, the distributed data processing system 100 can also be implemented to include several different types of networks, such as intranets, local area networks (LANs), and wide area networks (WANs). As stated above, Figure 1 is intended as an example and not as an architectural limitation to different embodiments of the disclosed subject matter, and therefore, the specific elements shown in Figure 1 should not be considered as limitations relating to the environment in which exemplary embodiments of the present invention are implemented.

[0013] Referring now to Figure 2, a block diagram of an exemplary data processing system in which an aspect of the exemplary embodiment is implemented is shown. The data processing system 200 is an example of a computer, such as client 110 in Figure 1, in which computer-readable code or instructions that implement the processes of the exemplary embodiment of the present disclosure are located.

[0014] Referring now to Figure 2, a block diagram of a data processing system in which an exemplary embodiment is implemented is shown. The data processing system 200 is an example of a computer, such as the server 104 or client 110 in Figure 1, in which computer-readable code or instructions that implement the processes of the exemplary embodiment are located. In this exemplary example, the data processing system 200 includes a processor unit 204, memory 206, persistent storage 208, a communication unit 210, an input / output (I / O) unit 212, and a communication fabric 202 that provides communication between the display 214.

[0015] The processor unit 204 is responsible for executing software instructions loaded into memory 206. Depending on the specific implementation, the processor unit 204 may be a set of one or more processors, or it may be a multiprocessor core. Furthermore, the processor unit 204 may be implemented using one or more heterogeneous processor systems in which the main processor and secondary processors reside on a single chip. As another exemplary example, the processor unit 204 may be a symmetric multiprocessor system containing multiple processors of the same type.

[0016] Memory 206 and persistent storage 208 are examples of storage devices. A storage device is any hardware capable of storing information either temporarily or persistently or both. Memory 206, in these examples, can be, for example, random access memory or any other suitable volatile or non-volatile storage device. Persistent storage 208 can take various forms depending on the particular implementation. For example, persistent storage 208 can include one or more components or devices. For example, persistent storage 208 can be a hard drive, flash memory, rewritable optical disk, rewritable magnetic tape, or any combination thereof. The medium used by persistent storage 208 can also be removable. For example, a removable hard drive can be used for persistent storage 208.

[0017] Communication unit 210, in these examples, provides communication with other data processing systems or devices. In these examples, communication unit 210 is a network interface card. Communication unit 210 can provide communication through the use of one or both of physical and wireless communication links.

[0018] Input / output unit 212 enables the input and output of data with other devices connected to data processing system 200. For example, input / output unit 212 can provide connections for user input via a keyboard and mouse. Further, input / output unit 212 can send output to a printer. Display 214 provides a mechanism for displaying information to the user.

[0019] Instructions relating to the operating system and applications or programs are placed in persistent storage 208. These instructions can be loaded into memory 206 for execution by the processor unit 204. Processes in different embodiments can be executed by the processor unit 204 using computer implementation instructions placed in memory, such as memory 206. These instructions are referred to as program code, computer-readable program code, or computer-accessible program code, which are read and executed by the processor within the processor unit 204. Program code in different embodiments can be embodied on different physical or tangible computer-readable media, such as memory 206 or persistent storage 208.

[0020] The program code 216 is arranged in a functional form on a selectively removable computer-readable medium 218 and can be loaded or transferred to the data processing system 200 for execution by the processor unit 204. The program code 216 and the computer-readable medium 218 together form a computer program product 220 in these examples. In one example, the computer-readable medium 218 may be in tangible form, such as an optical or magnetic disk, inserted into or placed in a drive or other device that is part of persistent storage 208 for transfer onto a storage device, such as a hard drive that is part of persistent storage 208. In tangible form, the computer-readable medium 218 may also take the form of persistent storage, such as a hard drive, thumb drive, or flash memory connected to the data processing system 200. The tangible form of the computer-readable medium 218 is also called a computer-recordable storage medium. In some cases, the computer-recordable medium 218 may not be removable.

[0021] Alternatively, program code 216 may be transferred from the computer-readable medium 218 to the data processing system 200 via a communication link to the communication unit 210, or via a connection to the input / output unit 212, or both. In exemplary examples, the communication link or connection, or both, may be physical or wireless. The computer-readable medium may also take the form of an intangible medium, such as a communication link or wireless transmission containing the program code. The various components shown with respect to the data processing system 200 are not intended to impose architectural limitations on how various embodiments may be implemented. Various exemplary embodiments may be implemented in a data processing system that includes components added to or replacing those components shown for the data processing system 200. Other components shown in Figure 2 may be modified from the illustrated exemplary examples. As an example, a storage device in the data processing system 200 is any hardware device capable of storing data. Memory 206, persistent storage 208, and computer-readable medium 218 are examples of tangible storage devices.

[0022] In other examples, a bus system may be used to implement the communication fabric 202 and may consist of one or more buses, such as a system bus or input / output buses. Naturally, the bus system may be implemented using any suitable type of architecture that enables the transfer of data between various components or devices connected to the bus system. Furthermore, the communication unit may include one or more devices used for transmitting and receiving data, such as a modem or network adapter. In addition, memory may be, for example, memory 206, or a cache, such as one found in an interface and memory controller hub that may reside within the communication fabric 202.

[0023] The computer program code for performing the operation of the present invention may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java(R), Smalltalk(R), and C++, and conventional procedural programming languages ​​such as the C programming language or similar programming languages. The program code may run 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 a remote computer or server. In the last scenario, the remote computer may 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 it may be connected to an external computer (for example, via the Internet using an Internet service provider).

[0024] Those skilled in the art will understand that the hardware in Figures 1 and 2 may vary depending on the implementation. Other internal hardware or peripheral devices, such as flash memory, equivalent non-volatile memory, or optical disk drives, may be used in addition to or instead of the hardware shown in Figures 1 and 2. Furthermore, the processing of the exemplary embodiments may be applied to multiprocessor data processing systems other than the aforementioned SMP systems without departing from the scope of the disclosed subject matter.

[0025] As is evident, the technologies described herein can operate in conjunction with a standard client-server paradigm, such as that shown in Figure 1, in which a client machine communicates with an Internet-accessible web-based portal running on one or more sets of machines. End users operate Internet-connected devices (e.g., desktop computers, notebook computers, Internet-enabled mobile devices, etc.) capable of accessing and interacting with the portal. Typically, each client or server machine is a data processing system, such as that shown in Figure 2, including hardware and software, and these entities communicate with each other over a network, such as the Internet, an intranet, an extranet, a private network, or any other communication medium or link. A data processing system typically includes one or more processors, an operating system, one or more applications, and one or more utilities. Applications on the data processing system provide native support for web services, including, among other things, support for HTTP, SOAP, XML, WSDL, UDDI, and WSFL, without limitation. Information on SOAP, WSDL, UDDI, and WSFL is available from the World Wide Web Consortium (W3C), which is responsible for developing and maintaining these standards, and further information on HTTP and XML is available from the Internet Engineering Task Force (IETF). It is assumed that you are familiar with these standards.

[0026] Cloud computing model Cloud computing is a service delivery model that enables convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal administrative effort or interaction with service providers. This cloud model may include at least five features, at least three service models, and at least four deployment models, all of which are described and defined in the “Draft NIST Working Definition of Cloud Computing” by Peter Mell and Tim Grance dated October 7, 2009.

[0027] Specifically, the following are typical characteristics:

[0028] On-demand self-service: Cloud consumers can unilaterally provision computing power, such as server time and network storage, automatically as needed, without requiring human interaction with service providers.

[0029] Broad network access: Capabilities are available over a network and accessed through standard mechanisms that facilitate use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0030] Resource pooling: A provider pools its computing resources to serve multiple consumers using a multi-tenant model where various physical and virtual resources are dynamically allocated and reallocated as needed. Generally, consumers have a sense of location independence in that they have no control over or knowledge of the exact location of the resources provided, although the location may be identifiable at a higher level of abstraction (e.g., country, state, or data center).

[0031] Rapid resilience: Capabilities can be provisioned quickly and resiliently, sometimes automatically, to scale out rapidly and release quickly to scale in rapidly. To consumers, provisionable capacity often appears unlimited and can be purchased in any quantity at any time.

[0032] Measured Services: Cloud systems automatically control and optimize resource usage by utilizing metric capabilities at a level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported to provide transparency to both service providers and consumers.

[0033] A typical service model is as follows:

[0034] Software as a Service (SaaS): The capability offered to consumers is the use of a provider's applications running on cloud infrastructure. These applications are accessible from various client devices via thin-client interfaces such as web browsers (e.g., web-based email). Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, storage, or even individual application functionalities, with the possible exception of limited, user-specific application configuration settings.

[0035] Platform as a Service (PaaS): The capability offered to consumers is the ability to deploy applications they have created or acquired, written using programming languages ​​and tools supported by the provider, onto cloud infrastructure. Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but they control the deployed applications and, in some cases, the configuration of the application hosting environment.

[0036] Infrastructure as a Service (IaaS): The capability offered to consumers is the provisioning of processing, storage, networking, and other fundamental computing resources that enable consumers to deploy and run any software, including operating systems and applications. Consumers do not manage or control the underlying cloud infrastructure, but they do control the operating system, storage, deployed applications, and, in some cases, select networking components (e.g., host firewalls).

[0037] The deployment model is typically as follows:

[0038] Private Cloud: Cloud infrastructure is operated exclusively for an organization. It is managed by the organization or a third party and may reside on-premises or off-premises.

[0039] Community Cloud: Cloud infrastructure is shared by several organizations to support a specific community with common concerns (e.g., mission, security requirements, policies, and compliance considerations). It can be managed by the organization or a third party and may reside on-premises or off-premises.

[0040] Public Cloud: Cloud infrastructure is made available to the general public or large industry groups and is owned by organizations that sell cloud services.

[0041] Hybrid Cloud: A cloud infrastructure is a combination of two or more clouds (private, community, or public) that remain separate entities but are joined together by standardized or proprietary technologies (e.g., cloud bursting for load balancing between clouds) that enable data and application portability.

[0042] Cloud computing environments are service-oriented, emphasizing statelessness, low coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure that includes a network of interconnected nodes. A typical cloud computing node is shown in Figure 2 above. Specifically, a cloud computing node is a computer system / server that can operate in many other general-purpose or dedicated computing system environments or configurations. Examples of well-known computing systems, environments, or configurations, or combinations thereof, that may be suitable for use in a computer system / server include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above systems or devices. A computer system / server can be described in the general context of computer system executable instructions, such as program modules, that are executed by the computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, etc., that perform a specific task or implement a specific abstract data type. A computer system / server can be practiced in a distributed cloud computing environment where tasks are executed by remote processing devices linked over a communication network. In a distributed cloud computing environment, program modules may reside on both local and remote computer system storage media, including memory storage devices.

[0043] Referring here to Figure 3, a set of functional abstraction layers provided by the cloud computing environment is shown as further background. It should be understood in advance that the components, layers, and functions shown in Figure 3 are illustrative only, and embodiments of the present invention are not limited thereto. As illustrated, the following layers and corresponding functions are provided:

[0044] Hardware and software layers 300 include hardware and software components. Examples of hardware components include mainframes, such as IBM® zSeries® systems; RISC (Reduced Instruction Set Computer) architecture-based servers, such as IBM® pSeries® systems, IBM® xSeries® systems, and IBM® BladeCenter® systems; storage devices; and network and networking components. Examples of software components include network application server software, such as IBM® WebSphere® application server software; and database software, such as IBM® DB2® database software. (IBM®, zSeries®, pSeries®, xSeries®, BladeCenter®, WebSphere®, and DB2® are trademarks of International Business Machines Corporation, registered in numerous jurisdictions worldwide.)

[0045] Virtualization layer 302 provides an abstraction layer, from which the following examples of virtual entities may be provided: virtual servers, virtual storage, virtual networks including virtual private networks, virtual applications and virtual operating systems, and virtual clients.

[0046] For example, management layer 304 may provide the following functions: Resource provisioning provides dynamic procurement of computing and other resources used to perform tasks within the cloud computing environment. Metering and pricing provides cost tracking when resources are used within the cloud computing environment and accounting or billing for the consumption of these resources. For example, these resources may include application software licenses. Security provides identity verification of cloud consumers and tasks, as well as protection for data and other resources. The user portal provides consumers and system administrators with access to the cloud computing environment. Service level management provides allocation and management of cloud computing resources so that the required service levels are met. Service Level Agreement (SLA) planning and execution provides pre-arrangement and procurement of cloud computing resources that are expected to be required in the future according to the SLA.

[0047] Workload Layer 306 provides examples of the functionalities in which cloud computing environments are used. Examples of workloads and functionalities provided by this layer include mapping and navigation, software development and lifecycle management, virtual classroom education delivery, data analytics processing, transaction processing, microservices, and others (for example, enterprise-specific functionalities in a private cloud).

[0048] While this disclosure includes a detailed description of cloud computing, it should be understood in advance that the implementation of the teachings enumerated herein is not limited to cloud computing environments. Rather, embodiments of the disclosed subject matter can be implemented with any other type of computing environment that is currently known or may be developed in the future.

[0049] Therefore, a typical cloud computing environment has a set of high-level functional components, including a front-end identity manager, business support services (BSS) functional components, operations support services (OSS) functional components, and compute cloud components. The identity manager is responsible for interfaceing with the requesting client to provide identity management, and this component can be implemented using one or more known systems, such as Tivoli Federated Identity Manager (TFIM), available from IBM Corporation in Armonk, New York. In appropriate situations, TFIM can be used to provide federated single sign-on (F-SSO) to other cloud components. The business support services component provides specific administrative functions, such as billing support. The operations support services component is used to provide provisioning and management of other cloud components, such as virtual machine (VM) instances. A virtual machine is an operating system or application environment that is installed on top of software but mimics a hardware machine. Cloud components represent the primary computing resources, which are typically multiple virtual machine instances used to run target applications made accessible via the cloud. One or more databases are used to store directories, logs, and other working data. While all of these components (including the front-end identity manager) reside "within" the cloud, this is not a requirement. In alternative embodiments, the identity manager may operate outside the cloud. The service provider may also operate outside the cloud.

[0050] Some clouds are based on unconventional IP networks. For example, a cloud may be based on a two-layer CLOS-based network with special single-layer IP routing using MAC address hashes. The technologies described herein can be used in such unconventional clouds.

[0051] Most cloud-based services currently available are delivered via bare metal or virtual machines (VMs), although "container" technology can also be used. A bare-metal environment is one in which applications are installed, run, and delivered from a dedicated cloud infrastructure and OS platform base. Such environments utilize dedicated and specific hardware and operating system configurations. In contrast, a virtual machine is a complete guest host running within a host system. When a virtual machine is used, applications are installed, packaged, and run under the control of a hypervisor that virtualizes the hardware environment. Containers, on the other hand, provide an operating environment that contains only essential parts of an application (sometimes called a cloud service) and its dependencies, and multiple containers can exist running within a single instance of an operating system such as Linux(R). Docker(R) is a virtualization platform that shares a single Linux(R) kernel with all running instances (called containers). Other container-based technologies include, among others, Kubernetes(R) and OpenShift(R). These container implementations share many features.

[0052] Generally, a container is a single software unit packaged into an image, typically with all its dependencies, designed to run reliably on a variety of systems. Container resources are managed via process control groups and isolated via kernel namespaces. The container orchestration engine determines where containers run within a managed cluster and creates a private network for communication.

[0053] For example, a single Docker(R) container is lightweight because it runs on a shared kernel, and it efficiently uses available resources. Containers are widely used by many next-generation cloud platform-as-a-service (PaaS) developers. For example, IBM(R) Bluemix(TM) is a PaaS cloud platform that runs Docker(R) containers using IBM(R) containers. Because Docker(R) containers run on existing operating systems and shared binaries, they are more compact than VMs, and therefore, in many cases, container solutions are faster and have lower memory requirements.

[0054] A typical Docker(R) architecture consists of a set of components: a Docker(R) client, a Docker(R) host, and a Docker(R) registry. The Docker(R) client communicates with the Docker(R) host by sending commands that Docker(R) understands (e.g., CLI commands) to the Docker(R) host. The Docker(R) host is a computer-based or cloud-based platform that executes requests from the Docker(R) client via the CLI. The Docker(R) registry stores published and registered Docker(R) images. The Docker(R) host retrieves images from its associated registry as needed. In typical operation, the Docker(R) client requests an image / container from the Docker(R) host. If the image is available on the host, the host starts and runs the image; if the image does not exist, the host can use the registry to try to find and download the image. A running image is a container. An image is a frozen copy of an application. An image becomes a container when it is started, has memory, and interacts with a kernel.

[0055] Microservices Microservices (also known as micro-services) is an application architecture style in which an application is composed of a large number of separate, network-connected components called microservices. This approach to application design and management breaks down large, monolithic applications into smaller services. A single network-accessible service is the smallest deployable unit of a microservices application. Typically, each microservice is optimized for a single function and operates in its own process. Communication between microservices is typically done via RESTful APIs and message broker services. Preferably, microservices are configured to be continuously integrated (CI) and continuously delivered (CD). Enterprises using microservices enjoy many benefits, including increased efficiency, simplified deployment and maintenance, improved application quality, and scalability.

[0056] Microservices are typically single tasks, language-independent, and require few dependencies, making them well-suited for implementation in container-based environments. As mentioned above, application developers routinely break down large distributed systems into communicating microservices, all running in parallel within a container orchestration engine (COE), such as Kubernetes(R), Docker(R) Swarm, or OpenShift(R). Each orchestration engine takes an image containing the application, its dependencies, and a small operating system (OS) distribution with a hierarchical file system, and creates a process within its own namespace on a hardware node.

[0057] Typically, a cloud operator receives container images from its continuous integration / continuous delivery (CI / CD) pipeline. Once deployed to the cloud operator's container orchestration engine on a physical computing node (see Figure 3), the following assumptions (threat model) can be made regarding a container that an adversary could attempt to compromise: Specifically, the entry point of the container image is a binary program implemented in a system language such as C / C++, Go, or Rust. The adversary can interact with the container process running on the physical node via a network socket. Furthermore, one of the programs or library dependencies contained in the image contains a vulnerability that, if exploited, would allow the adversary to issue arbitrary system calls to the operating system kernel running the container process. However, it is assumed that the adversary cannot escape the container abstraction.

[0058] Microexecution Further context reveals that microexecution is a software testing technique for automatically executing binary code fragments without the need to manually define test harnesses. This capability significantly reduces the time required to test arbitrary areas of a binary program that might be difficult to execute using conventional tools or without setting up a production environment. To execute any code fragment, the microexecution engine must accurately model the program's environment, including memory regions, environment variables, file systems, and library dependencies. For example, a microexecution engine can execute a sequence of machine instructions that dereference pointers by detecting segmentation faults and returning random data with each dereference.

[0059] Intrusion detection Further background, intrusion detection systems (IDS) are established technologies for protecting entire networks and individual hosts from attackers. Figure 4 illustrates typical use cases. On the left, IDS 400 operates within network 402, which includes multiple hosts 404, to attempt to detect and mitigate a network-based attack 405. On the right, IDS 406 is run in relation to a specific host 408 to attempt to detect and mitigate a host-based attack 407.

[0060] Figure 5 shows a typical host-based intrusion detection system (IDS) 500 implemented in relation to a host operating system having kernel space 504 and user space 502. The system call table 506 is accessible in kernel space 504. Program P 508 runs in user space 502 and makes system calls 510 to the host kernel via table 506. The IDS 500 implemented in this operating context traces the system calls the program makes to the host kernel to detect activity that deviates from normal behavior. Normal behavior can be defined as a model extracted from an application, rules manually defined by an administrator, or a model inferred from tracing benign programs. Thus, for example, the IDS 500 implements model M for program P, and the IDS is

number

[0061] Intrusion detection in microservices using binary analysis and container telemetry. Figure 6 is a high-level diagram of an automaton-based intrusion detection system. As shown, this approach includes two components: an automated binary analysis 600 for generating a behavioral model of a container image, and an on-node detector 602 for checking whether the telemetry generated by a given container satisfies that behavioral model. The on-node detector 602 generally operates to capture system call trace telemetry, as described above. Thus, Figure 6 shows a complete end-to-end execution of the IDS when a container image 604 is given as input. In this example, the container image 604 is pre-processed by the automated binary analysis 600, preferably offline, to generate an associated behavioral model M. The system call trace telemetry generated by the running container of the image (in this example, running on a hardware node 608 within a container orchestration engine (COE) 620 (here, a running Kubernetes(R))) is then checked to see whether it satisfies the associated behavioral model 606 (for example,

number

[0062] As shown in the figure, the automated binary analysis 600 generates a behavioral model of a container image (e.g., a Docker(R) image) 604 that has a binary entry point (e.g., a C / C++ program). As shown in Figure 6, the automated binary analysis receives an ELF 610 as input. ELF (Executable and Linking Format) is the standard binary format for operating systems such as Linux(R). The ELF representation of control data in an object file is platform-independent, and this type of representation allows object files to be identified, parsed, and interpreted similarly, so ELF object files are compatible across multiple platforms and architectures of different sizes. The three main types of ELF files are executable files, relocatable files, and shared objects. These file types hold information about the code, data, and programs that the operating system and linkage editor need to take appropriate actions on these files. As shown in the figure, the ELF 610 of the container image is received and a call graph 612 is generated.

[0063] Specifically, given a container image as input, modeling analysis generates a behavioral model 614 that summarizes how a container running from that image interacts with other processes, file systems, or networks. Preferably, the behavioral model M generated by this process is a graph data structure 614, where nodes in the graph represent resources including processes, files, or network sockets, and edges in the graph represent system calls made by processes in the graph. A given sequence of system calls is valid if there is a path in the behavioral model M that matches that sequence, starting from the node that generated the sequence of system calls.

[0064] Figure 7 illustrates in more detail one embodiment of the automated binary analysis process. As shown, the container image 700 contains a data set and an ELF. The ELF is an executable file representing a process or application running within the container. Image 700 is input to a Binary Analysis Platform (BAP) 702, which generates a static behavioral model of the image. Typically, BAP 702 operates as an automated process or set of processes, running as software on one or more hardware processors. Although Figure 7 shows a single container image 700, this process is repeated for multiple container images to build a library of behavioral models. In operation, BAP 702 obtains the entry point of the container image (for example, nginx in this case) and finds all of its library dependencies on the image. From this information (particularly the entry point), BAP 702 constructs a call graph 704, and in 706 outputs a leaf of the call graph that references functions in other libraries. This procedure is repeated for each library dependency to identify the set of functions that the entry point and its dependencies require from the standard C library (libc). Then, for each function f required from libc, that function is microexecuted. Preferably, the binary analysis approach optimizes this step by defining an ABI (Application Binary Interface) for the standard C library, which allows the analysis to be customized by wrapping pre-microexecuted behavior or by manually defining ABI function wrappers. Furthermore, for efficiency, it is preferable to use a similar approach for other shared libraries (i.e., dynamically linked libraries) to expedite the analysis.

[0065] Referring again to Figure 7, BAP702 then explores each possible execution path within function f, observing the value of the RAX register when encountering a syscall instruction (assuming familiarity with Linux(R) OS kernel semantics). BAP702 then outputs the observed set of RAX values ​​as a set of system calls made by function f. Preferably, for efficiency, BAP then restricts the output to only those system calls (e.g., execve) that affect the process lifecycle or interact with the file system or network. BAP702 then preferably creates a behavioral model 708 with a single node representing the running container of this image. BAP then revisits the entry point of the original call graph 704 and preferably performs a Depth First Search (DFS) traversal on the graph. Whenever a libc function is encountered in this search, it is checked to determine whether the identified function makes the target system call. If so, these system calls are added to an edge connecting the calling process to the resource that the libc function modifies. If such an edge does not exist, a node for the resource is created, and an edge is added from the calling process to that node. The resulting behavioral model M is shown in 708.

[0066] As an optimization of the process described above, static taint analysis is used, for example, to encode a sequence of valid system calls into a behavioral model. Specifically, given functions to create a process or open files and sockets, taint analysis enhances the behavioral model by finding a sequence of functions that take the given resources as input. For each function, the call graph is queried to determine the system calls it can execute. The identified sequence of system calls is then embedded into the behavioral model, for example, as a path originating from a resource node. For each system call in the sequence, a new edge to a new node is created if one does not already exist.

[0067] Figure 8 shows an example of how a call graph is constructed from a binary representation. In this example, a portion of the container image (containing the main program) 800 is shown. Using the method described above, the binary analysis platform BAP creates an intermediate representation (IR) 802, which is processed to generate a call graph 804. Figure 9 shows an example of how BAP detects system calls within the microexecution of a program. The assembly code instruction 900 is shown on the left, and the RAX register value 902 is shown on the right. In this example, the identified system calls 904 are clone and execve.

[0068] Automatic synthesis of reference policies for protecting microservices at runtime As described above, security policies are generated by annotating the program's call flow graph (CFG) with system call information obtained by microexecuting program dependencies. While the above approach has merits, this disclosure describes an improved technique for the automated synthesis of reference policies. Specifically, instead of the aforementioned ad-hoc approach of annotating the CFG, the technique herein replaces this with microexecution of the entire program, in which case the given program is executed directly within the analysis environment, preferably using an application binary interface (ABI) that allows the program to execute and access resources given within its container image. As will be discussed later, the ABI provides functionality for defining the behavior of external libraries without requiring microexecution of the external libraries, thus enabling the analysis to be extended to large and complex binaries. By microexecuting the entire program, the analysis environment can maintain a behavior graph (BG), the semantics of which are described below, and the BG is a compact representation of all system call sequences observed during the analysis. This approach has several advantages over the techniques described above in relation to Figure 7. For example, by embedding specific system call arguments into the final security policy, it prevents adversaries from executing unused program functions and causing side effects, and it makes it possible to generate policies from concrete execution that utilizes the entire container image file system, process environment, and test inputs.

[0069] Figure 10 shows a simplified diagram of how microexecution of an entire program works using a Binary Analysis Platform (BAP) in a preferred embodiment. Specifically, the Binary Analysis Platform 1000 is a framework for performing analysis on a binary that has been lifted into a BAP Intermediate Language (BIL) 1002 that preserves the semantics of the binary's instruction set architecture. Simultaneously, the BAP 1000 holds an Intermediate Representation (BIR) 1004 of the program in static single assignment form. Microexecution of the BIL is then performed using the BAP microexecution framework 1006, according to this disclosure. In a typical implementation, microexecution is performed through a BAP plugin called Primus, which allows custom plugins to execute the BIL 1002 from an arbitrary address and analyze an OCaml script, OCaml being a general-purpose multi-paradigm programming language that extends the Caml dialect of the ML programming language with object-oriented features. Microexecution in Primus is enabled by a built-in run plugin that emulates the instructions of the BIL within a Machine type. This Primus Machine 1008 includes a process address space 1010 that mimics an actual operating system process. This framework allows for extensive configuration of the Primus Machine 1008 with custom plugins, enabling many interesting program analyses. By default, this machine simply microexecutes code. To automatically track the effects caused by a given program, the custom plugins described below explicitly track the effects generated by BIR 1004, preferably defined through IR and formal semantics, which are described in more detail below.

[0070] The following provides further details about the BAP microexecution framework, which provides an Application Binary Interface (ABI). It is well known that binary programs often utilize routines located in external libraries. During microexecution, Primus replaces calls to external functions in the binary's Global Offset Table (GOT) with random values. For example, calling sqrt in the standard C library's Math package does not result in sqrt being lifted from libc.so and microexecuted; instead, a random value is generated in RAX. While this heuristic works well for modeling programs that can run without strict library dependencies, it is insufficient to support programs that interact with input / output streams, process strings, or send / receive network data. To overcome this limitation, the preferred approach herein leverages the Primus LISP interpreter 1012, which models the Application Binary Interface (ABI) of an executable file and implements a LISP wrapper for abstractly interpreting the effects of common shared library functions without explicit microexecution. This reduces symbolic state and the number of micro-execution steps, significantly speeding up analysis. Typically, ABIs do not change frequently and can evolve with library updates.

[0071] During micro-execution using the approach described herein, when Primus encounters an undefined symbol, it refers to the ABI provided to the BAP. If the undefined function exists in the ABI, Primus searches the 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 comes with a subset of the standard C library implemented in Primus LISP, including a dynamic memory allocator. Additional functions with extended functionality can be easily implemented as needed.

[0072] Figure 11 shows a typical ABI example. In this example, Listing 1100 provides a LISP wrapper that implements the strtok_r function in the ABI. The level of abstraction in Primus LISP is preferably kept intentionally close to the machine, which allows for convenient ways to change the state of the machine. When implementing more complex functions such as printf, Primus LISP can be cumbersome, but BAP makes it easy for plugins to extend the LISP language with custom functions that call back the OCaml runtime when more advanced functionality is needed. As an example, a rough approximation of sprintf is implemented using a combination of a function found in the String OCaml module and Primus's ability to enumerate the function's inputs during microexecution. By default, Primus provides a dynamic memory allocator implemented in LISP to support the malloc function family found in stdlib.h, and may include other functions (or modifications of the provided functions). When a program is microexecuted, Primus may encounter system call instructions in the binary and identify the system call by examining the value of the RAX register at that point. Preferably, the function wrapping the system call is microexecuted separately to ensure it does not contain any effects.

[0073] The BAP plugin constructs a graph data structure called an 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 term ID in the BIR that generates an effect in the form of a system call. The term ID in BAP uniquely identifies a specific location in the IR. This can be a system call issued directly by the binary, or a system call issued by calling an external library function that issues system calls, such as printf. Along with the term ID that issues the system call, each node v0 also includes the specific arguments passed to the system call, which can be obtained by examining the contents of the registers. Each edge v1,v2 in the Effect Graph is labeled with the system call issued by node v2. At the start of the analysis, the Effect Graph begins with a single root node representing the process before it executes the binary's _start routine at process startup. At the end of the symbolic search, the final graph represents a sample sequence of valid system calls that a program could issue during its execution, taking into account the constraints imposed by the program's entry point and its environment.

[0074] If a library function called at node v2 observed within the binary triggers the target effect, an edge is created between the last visited nodes v1 and v2 in the effect graph. The system calls observed for that function are assigned as edge labels, the new label is recorded as the last visited node, and the micro-execution resumes. The arguments of the specific function are also stored in v2 to generate a security policy after the micro-execution. Storing a unique term ID for each node allows the system to prevent the creation of duplicate nodes in the effect graph and instead create edges pointing to previously visited nodes. This design decision has been found to result in a more compact and generalized model, preventing programs that repeatedly call the same function in a loop from having overly complex and large security policies.

[0075] To construct the effect graph, BAP preferably defines a custom Machine module that subscribes to relevant callbacks within the Primus interpreter. Each time Primus enters or exits a subroutine in the intermediate code, the analysis pushes or pops the name of the subroutine from the call stack, which is held in a plugged-in state. This allows the framework to embed context into the effect graph and communicate that context when a policy violation is detected. In addition to holding the call stack, the system also subscribes to all Jmp instructions executed in the intermediate language. In the BIL, a Jmp instruction can represent a call to a subroutine, an external library function, or an address stored in a register within the analyzed binary. In the first case, BAP pushes the function onto the call stack before microexecuting it. In the second case, if the external function causes any effect, the effect graph is extended with the Jmp's term ID. In the third case, if BAP only has the destination address of the Jmp, a lookup of that function in BAP's GOT is performed. This third case helps the program calling the function to directly utilize the function pointer stored in a register.

[0076] Once the micro-execution is complete, the BAP obtains an effects graph that encodes an acceptable sequence of valid security-related system calls that the binary may issue at runtime. To export the effects graph into an appropriate security policy for intrusion detection, the term IDs defining the labels of each node are replaced with the arguments passed to the system calls observed during the micro-execution. This generates a finite automaton that encodes the security policy.

[0077] Figure 12 shows an example of the automated processing described above. Compared to the approach in Figure 7 (which annotates the program's call graph with system call information obtained by microexecuting program dependencies), the BAP in this preferred embodiment replaces it with a microexecution of the entire program, where a given program is executed directly within the analysis environment. In this example, the container image 1200 contains a data set and an ELF. As before, the image 1200 is input to the Binary Analysis Platform (BAP) 1202, but in this case, the BAP 1202 includes the BAP microexecution framework, preferably the Primus BAP plugin, which includes an embedded Machine 1204 that emulates instructions in BIL 1206, and a LISP interpreter 1208 that models the application binary interface (ABI) of an executable file and implements one or more LISP wrappers (one of which is shown in 1210) for abstractly interpreting the effects of common shared library functions without explicit microexecution. BAP1202 operates as an automated process or set of processes and runs as software on one or more hardware processors. In contrast to the aforementioned approach shown in Figure 7, in micro-execution of the entire program, the specific system call arguments 1214 are contained within the final security policy 1216, preventing adversaries from executing unused program functions and causing side effects. In this approach, security policy 1216 is generated from concrete executions that utilize the container image's file system, process environment, and test inputs.

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

[0079] In summary, the policy synthesis described in this disclosure begins by obtaining an unmodified container image containing the application and all its dependencies, and micro-executing the container's entry point, which is represented as a binary executable file. Micro-execution allows the analysis framework to automatically invoke arbitrary machine code without having to manually define test harnesses around individual code fragments. By micro-executing the binary, the synthesis method can automatically execute individual code paths within the executable file to observe the system calls that the binary may issue during execution. Micro-execution maintains an effects graph data structure representing a behavioral model embedded with all possible sequences of system calls that the binary may issue during a given execution. When micro-execution executes a new code fragment in the binary, it may discover a new system call S. In this approach, an edge E is added to the last visited node in the graph to represent S, and a new node N is added to the graph describing the resources given as input to S. For example, if S is a system call "open", the directed edge E is labeled OPEN, and the node pointed to by E contains the path to the file that is being opened at that moment in the program. If multiple paths are possible, the union of all possibilities is stored in N. If the file cannot be identified, a symbolic entry is given instead. The microexecution framework performing this analysis lifts the arguments to the system call by observing the specific values ​​of the relevant registers when observing the syscall instruction.

[0080] Microexecution enumerates all basic blocks given in the program, or, after a set timeout is exceeded, emits a behavior graph as output representing the sequence of all possible system calls the program could make during execution. Therefore, the effect graph inevitably represents the most accurate security policy P for the reference monitor. Since most commercial reference monitors do not accept fully directed graphs as security policies, P is typically translated into an appropriate security policy. This translation varies depending on the target reference monitor, but typically, traversing the graph structure given by P provides the information necessary to define a useful and accurate policy for the program. For example, restricting a program's access to the file system can be achieved by obtaining all nodes in the effect graph pointed to by "OPEN" edges and deriving a policy that restricts access to those files.

[0081] As described above, automated policy synthesis is typically implemented in the context of microservices architectures, which divide application components into independent, self-contained filesystem images (containers) managed by a container orchestration engine across a set of physical computing nodes. As described above, a container image is a hierarchical filesystem containing an entry point program and all the files and dependencies necessary to run the entry point in a sandboxed environment. To protect the microservices architecture, a reference monitor is typically used, for example, in conjunction with the aforementioned microservices-aware intrusion detection system (IDS), to monitor container workloads for security policy violations. A preferred approach is to synthesize security policies for the container image through microexecution, and then use the resulting policies to detect policy violations across container telemetry. Specifically, as shown in Figure 5, the intrusion detector receives a system telemetry stream that encodes process probability information and correlates process events with network and file system activity associated with individual microservices. This allows the microservice-aware IDS to efficiently execute security automata corresponding to the security policies of each microservice to flag unacceptable behavior.

[0082] Synthesizing security policies The following provides further details regarding a preferred security policy synthesis procedure. Preferably, this synthesis is defined with respect to a simplified intermediate representation (IR) obtained through the disassembly of a binary program. This representation abstracts the binary program across various instruction set architectures and explicitly models the effects observed by microexecution semantics. Figure 13 presents a typical language syntax. Program P is represented by a list of commands denoted as c. Commands consist of variable assignments, pointer dereference assignments (stores), conditional branches, function calls, function returns, system calls (abstracted as special calls), and program termination statements. Expressions evaluate to a typical value representation n, consisting of variables, numbers, binary operations, and loads from memory locations. Variable names include register identifiers, function names, and system call identifiers. This syntax assumes that the program is well-typed. The execution context consists of a store σ that associates locations with values ​​and variables with locations, and an environment Δ that maps variables to values. Furthermore, to express the semantics of the effect of external function calls (for example, runtime library API calls), its syntax is a function table that maps external function names to their entry points.

number

number

number

number

number

number

number

number

[0083] Figure 14 shows the operational semantics that define how the effects are produced by the microexecuted program. The expression is determined by a large step.

number

number

number

[0084] The expressions in this language are pure, and the programs are non-reflective. The semantics of `load e` read the value stored at memory location e. Conversely, `store e1,e2` stores e2 at location e1. In C programs, these model pointer dereferencing and dereference assignment, respectively. Variable assignment is done using sequential instructions.

number

[0085] An external function call, call f, takes the function arguments Δ[r1]...Δ[r n Creates a new stack frame fr with ] and jumps to the entry point of the call. The return ret e returns the interpreter context.

number

number

[0086] Microservices-enabled IDS microexecution procedures leverage these operational semantics to create a directed graph that summarizes an acceptable sequence of observable effects that a program may generate during execution.

number

number

number

[0087] Benefits and Torture The techniques described herein are advantageous because they enable the automatic synthesis of reference policies from a program using static analysis of the binary program. As described above, static binary analysis is used to automatically synthesize stateful policies that accurately describe the program's behavior. The behavior included in these policies can be any behavior observable by the operating system, and the techniques can be used to restrict the behavior to system calls that the program may issue during execution. Existing reference monitors (e.g., SELinux(R), AppArmor, and Audit) accept declarative security policies as input, which only allow operators to restrict a program's access to specific system calls and resources. In contrast, the stateful policies generated by the policy synthesis methods described herein enable more granular policies, allowing operators to create policies that include sequences of valid system calls that a program may issue. Instead of restricting a program's access to a finite set of system calls and resources, the methods described generate policies that restrict the program to sequences of valid system calls that are generated by the program's execution. These more expressive policies can then be summarized into simpler expressions that are accepted by widely used existing reference monitors. Manually defining useful policies often requires considerable expertise in the field, so this automated policy generation for existing reference monitors saves operators valuable time.

[0088] This approach synthesizes a security policy that outlines how a program interacts with the operating system through 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 a particular program fragment, outline the memory regions a program can access, or determine the location in address space where sensitive information may reside.

[0089] In summary, this disclosure provides a framework and procedures for generating behavioral models from container images, preferably using binary analysis. These models are preferably generated by micro-execution of the entire program, preferably using a BAP framework configured with plugins such as Primus. An IDS is defined that checks whether the telemetry generated by the running container of the image satisfies the associated behavioral model. The behavioral models are constructed from container images accessible from a registry. These models are preferably located in the same location as the running container and are compact enough to detect anomalies in real time (or substantially real time) when an anomaly occurs on the associated hardware node. The intrusion detection system according to this disclosure generates behavioral models through automated analysis and immediately detects an intrusion when one occurs on the hardware node running a given container.

[0090] According to the modified embodiment, the IDS agent (or an IDS incorporating such an agent process) accesses a pre-built, extractable library of container image behavior models. In other words, according to this modification, the IDS (including the agent) does not need to be the same process that performs offline binary analysis.

[0091] Typically, a behavioral model exists associated with a particular container image, and that container image corresponds to a specific micro-service that generates telemetry when run in a runtime (COE) environment. While this technique assumes that the container image corresponds to a micro-service, this is not limiting, as the approach described herein can be used with any program that has an associated behavioral model.

[0092] The techniques described herein are 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 implemented, or that have significant server-side components, can benefit from being built on a microservices (or SOA) model.

[0093] One or more embodiments of this technology may be executed in a cloud computing environment (Figure 3) or may utilize cloud computing resources in other ways.

[0094] The functions described above may be implemented as standalone approaches, such as software-based functions executed by the processor, or they may be available as managed services (including web services via SOAP / XML interfaces). Details of specific hardware and software implementations described herein are for illustrative purposes only and are not intended to limit the scope of the subject matter described.

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

[0096] The methods described herein may be implemented in or in combination with various server-side architectures other than cloud-based infrastructure. These include, but are not limited to, simple n-tier architectures, web portals, and federated systems.

[0097] More generally, the subject matter described herein may take the form of entirely hardware embodiments, entirely software embodiments, or embodiments that include both hardware and software elements.

[0098] Furthermore, the behavioral modeling and IDS functions described herein may take the form of computer program products accessible from computer-usable or computer-readable media that provide program code used by or in connection with a computer or any instruction execution system. For the purposes of this description, computer-usable or computer-readable media may be any device that contains or can store programs used by or in connection with an instruction execution system, apparatus, or device. The media may be electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems (or apparatus or devices). Examples of computer-readable media include semiconductor or solid memory, magnetic tape, removable computer diskettes, random-access memory (RAM), read-only memory (ROM), rigid magnetic disks, and optical disks. Current examples of optical disks include compact disc read-only memory (CD-ROM), compact disc read / write (CD-R / W), and DVD. Computer-readable media are tangible articles.

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

[0100] In typical embodiments, these components are implemented in a dedicated computer, preferably by software run by one or more processors. This software is also held in one or more data stores or memories associated with one or more processors, and this software may be implemented as one or more computer programs.

[0101] This functionality can be implemented as an add-on or extension to existing security services or access manager solutions. As previously described, this technology can also be implemented in an automated manner.

[0102] While the above describes a specific sequence of operations performed by a particular embodiment of the present invention, alternative embodiments may perform operations in a different order, combine certain operations, or superimpose certain operations; therefore, such order is illustrative. References to given embodiments in this specification indicate that the described embodiments may include certain features, structures, or characteristics, but not all embodiments necessarily include those specific features, structures, or characteristics.

[0103] Finally, although the given components of this system have been described individually, those skilled in the art will understand that some of the functions may be combined or shared in given instructions, program sequences, code sections, etc.

[0104] The technologies described 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 a behavioral model, alternative embodiments may include the use of recorded system call traces.

[0106] Furthermore, in a preferred embodiment, the telemetry analyzed for anomaly detection is a set of captured system call traces, but other diagnostic information obtained by monitoring incoming or outgoing data packets, for example, by examining files, memory usage, etc., may be utilized.

Claims

1. A computer information processing method comprising at least one hardware processor for the synthesis and use of automated security policies in a container environment, wherein the method comprises: A binary analysis of a program associated with a container image, which is performed within a binary analysis platform, and involves directly micro-executing the program within the binary analysis platform in order to generate a graph summarizing the expected interactions of the program within the container environment during the binary analysis. Automatically synthesizing security policies from the aforementioned graph, The security policy mentioned above is instantiated within the container environment, During runtime monitoring of event sequences related to the program running in the container environment, if it is determined that the event sequence violates the security policy, an action is taken. Methods that include...

2. The method according to claim 1, wherein the expected interactions of the program are identified by analyzing one or more system calls and the arguments of the one or more system calls found while the program is microexecuted.

3. The method according to claim 2, wherein the security policy has at least one system call argument embedded within it.

4. The method according to claim 1, further comprising: modeling an application binary interface (ABI) that defines the behavior of an external library function; and generating the effect of executing the external library function during the micro-execution of the program without requiring the micro-execution of the external library function.

5. The method according to claim 1, wherein when the program is microexecuted, one or more resources identified within the container image are accessed.

6. The method according to claim 1, wherein, prior to binary analysis, the program is lifted to an intermediate representation that preserves the semantics of the underlying instruction set architecture (ISA).

7. The method according to claim 6, wherein the intermediate representation is executed by micro-executing the program.

8. At least one hardware processor, Computer memory holding computer program instructions to be executed by at least one hardware processor for performing the synthesis and use of automated security policies in a container environment, The computer program instructions are provided, A binary analysis of a program associated with a container image, which is performed within a binary analysis platform, and involves directly micro-executing the program within the binary analysis platform in order to generate a graph summarizing the expected interactions of the program within the container environment during the binary analysis. Automatically synthesizing security policies from the aforementioned graph, The security policy mentioned above is instantiated within the container environment, During runtime monitoring of event sequences related to the program running in the container environment, if it is determined that the event sequence violates the security policy, an action is taken. A device containing program code configured to execute [something].

9. The apparatus according to claim 8, wherein the expected interactions of the program are identified by program code configured to analyze one or more system calls and the arguments of the one or more system calls found while the program is microexecuting.

10. The apparatus according to claim 9, wherein the security policy has at least one system call argument embedded within it.

11. The apparatus according to claim 8, further comprising program code for modeling an application binary interface (ABI) that defines the behavior of an external library function, wherein during micro-execution of the program, the program code is further configured to produce the effect of executing the external library function without requiring micro-execution of the external library function.

12. The apparatus according to claim 8, wherein when the program is microexecuted, one or more resources identified within the container image are accessed.

13. The apparatus according to claim 8, further comprising program code that lifts the program to an intermediate representation that preserves the semantics of the underlying instruction set architecture (ISA).

14. The apparatus according to claim 13, wherein the intermediate representation is executed by micro-executing the program.

15. A computer program that causes a computer to perform the method described in any one of Claims 1 to 7.

16. A computer-readable medium on which the computer program described in claim 15 is recorded.

Images