Emulation System

The emulation system uses a virtualization layer provided by Docker containers and virtual networks to emulate IT infrastructures. An emulated IT infrastructure is defined by an emulation configuration, which includes the properties listed in Table 2. The set of configurations supported by the emulation system are stored in the metastore and can be seen as a configuration space, which defines the class of infrastructures that can be emulated (see Fig. 5).

Figure 5: The configuration space of the emulation system, which defines the class of infrastructures that the emulation system can emulate.

Table 2: Properties of an emulation configuration.

Users of CSLE can create new emulation configurations and insert them into the metastore. CSLE also includes a set of pre-installed configurations (see Table 3). One of these pre-installed configurations is csle-level9-020 (as an example), whose topology is shown in Fig. 6 and whose configuration is listed in Table 4.

Table 3: Pre-installed emulation configurations.

Figure 6: Topology of the emulation configuration `csle-level9-020`

Table 4: Configuration of the emulation configuration `csle-level9-070`, whose topology is shown in Fig. 6.

An emulation execution consists of a set of running containers and virtual networks, which are defined by an associated emulation configuration.

Creating an execution involves two main tasks of the emulation system. The first task is to replicate relevant parts of the physical infrastructure that is emulated, such as physical resources, operating systems, network interfaces, and network conditions. The second task is to instrument the emulated infrastructure with monitoring and management capabilities. Since the emulation execution will be used to evaluate reinforcement learning agents, it must be possible to monitor system metrics in real-time and to perform control actions prescribed by reinforcement learning agents.

In the following seven sections, we describe how the emulation system emulates physical hosts, network links, switches, network conditions, client populations, attackers, and defenders, respectively. In the subsequent three sections, we describe the monitoring and management capabilities of the emulation system. Lastly, we describe the process of creating an emulation execution from an emulation configuration.

Emulating Physical Hosts

Physical hosts are emulated with Docker containers. A container is a lightweight executable package that includes everything needed to emulate the host: a runtime system, code, system tools, system libraries, and configurations. Multiple containers can run on the same physical host and share the same operating system kernel, in which case their resources and processes are isolated using cgroups (see Fig. 7).

Figure 7: Software and hardware stack of a physical server that runs CSLE; closest to the hardware is the operating system; on top of the operating system is the Docker engine, which provides the base for running CSLE and virtual containers.

The CSLE Docker images are listed in Table 5 and include images for emulating application servers, Software-Defined Networking (SDN) controllers, clients, attackers, Intrusion Detection and Prevention Systems (IDPSs), and storage systems. Detailed configuration of each image is available here.

Table 5: Docker images in CSLE.

Emulating Physical Network Links

Network connectivity is emulated by virtual links implemented by Linux bridges. Network isolation between emulated hosts and emulated switches on the same physical host is achieved through network namespaces, which create logical copies of the physical host’s network stack.

Each emulation execution has a dedicated virtual subnetwork with the subnet mask:

executionId.emulationId.0.0/16

where executionID identifies the execution and emulationID identifies the emulation configuration. This addressing scheme allows several executions of the same emulation configuration to execute concurrently on the same physical servers without overlapping address spaces.

In the case that an emulated network spans multiple physical servers of the management system, VXLAN connections are used. These connections tunnel the emulated network traffic over the physical network (see Fig. 8). In other words, the physical network that connects the servers of the management system provides a substrate network, on top of which the emulation system deploys virtual networks.

Figure 8: Architecture diagram of a distributed emulation execution; servers of the management system are connected through a physical IP network, over which virtual networks are overlayed using VXLAN tunnels.

Emulating Physical Switches

Physical switches are emulated with Docker containers that run Open vSwitch (OVS) version 2.16 (see Fig. 9). The emulated switches connect to an SDN controller using the OpenFlow protocol version 1.3 over a secure TLS tunnel. The SDN controller is emulated by a container that resides in the management network (the management network is described below). (Since the switches are programmed through flow tables, they can act either as classical L2 switches or as routers, depending on the flow table configurations.)

Figure 9: Physical switches in CSLE are emulated as Open vSwitch (OVS) switches; each emulated switch runs the OpenFlow protocol and can be configured via a Software-Defined Networking (SDN) controller.

Emulating Network Conditions

Network conditions of virtual links are configured using the NetEm module in the Linux kernel, which allows fine-gained configuration of bit rates, packet delays, packet loss probabilities, jitter, and packet reordering probabilities (see Fig. 10).

Figure 10: Method to emulate network conditions with the Netem module in the Linux kernel; Netem uses a dedicted queueing discipline in the Linux networking stack and emulates bit rates, latencies, packet loss probabilities, packet reordering probabilities, and jitter according to a predefined configuration.

Emulating Client Populations

Client populations in CSLE are emulated by processes that run inside Docker containers and interact with emulated hosts through various network protocols, e.g., HTTP, SSH, and DNS. The clients select functions from the list in Table 6 according to some probability distribution.

Table 6: Network functions that emulated clients may invoke.

Client arrivals are emulated by a Poisson process with exponentially distributed service times (see Fig. 11). This process may be stationary or non-stationary, e.g., it may be sine-modulated to model periodic load patterns. The duration of a time-step in an emulation is defined by its configuration; a typical duration is 30 seconds.

Figure 11: Clients are emulated by processes that invoke network functions of emulated hosts; client arrivals and service times are emulated by a Poisson process with exponentially distributed service times.

Emulating Attackers

Attackers are emulated by automated programs that select actions from a pre-defined set. The actions are selected according to an attacker strategy, which may depend on system metrics of the emulation. (These metrics are collected in real-time by monitoring agents described below.) The attacker commands are listed in Table 7.

Table 7: Attacker commands.

Emulating Defenders

Defender actions are emulated by executing system commands on emulated hosts. These commands are invoked through a management API based on gRPC and SSH (the API is detailed below). Similar to the attacker actions, the defender actions are prescribed by a defender strategy, which may depend on system metrics collected by monitoring agents (described below). The defender actions are listed in Table 8.

Table 8: Defender commands.

The Management Network

Each emulation execution has a dedicated virtual subnetwork, called the management network, which spans the following address space:

executionID.emulationID.253.0/24

This network interfaces directly with the management system and also has an interface to each emulated component. The purpose of this network is to connect management systems to the emulated devices, e.g., storage systems, monitoring systems, and SDN controllers (see Fig. 12). The reason for using a dedicated management network instead of carrying management traffic on the network that carries device-to-device traffic is to avoid interference and to simplify control of the execution.

Figure 12: The management network; it is a dedicated network used for operation of the emulated infrastructure.

Monitoring Agents

Each emulated device runs a monitoring agent that reads local metrics of the device and pushes those metrics to a distributed Kafka queue, which is deployed inside the management network (see Fig. 13). The metrics collected at every time-step are listed in Tables 10-13.

The data in the Kafka queue is organized in a set of topics (see Table 9), each of which stores a sequence of records in a first-in first-out (FIFO) order for a pre-determined time window. These topics are distributed over a set of partitions, each of which is stored at a server in the Kafka cluster.

The topics are consumed by a set of data pipelines implemented with Spark, which process the data and write the results to Presto and Elasticsearch for persistent storage and search, respectively. These storage systems are then consumed by various downstream applications, e.g., dashboards applications and machine learning applications. The processed data is also input to reinforcement learning agents, which use it to decide on control actions.

Figure 13: The monitoring system of CSLE; monitoring agents running on emulated devices push metric data to a distributed Kafka queue; the data in this queue is consumed by data pipelines that process the data and write to Presto and Elasticsearch for persistent storage and search, respectively; the processed data is used by Reinforcement Learning (RL) agents to decide on control actions, and by downstream applications to create dashboards and statistical models.

Table 9: Kafka topics.

Table 10: Metrics collected per time-step by the monitoring system (1/4).

Table 11: Metrics collected per time-step by the monitoring system (2/4).

Table 12: Metrics collected per time-step by the monitoring system (3/4).

Table 13: Metrics collected per time-step by the monitoring system (4/4).

Management Agents

In addition to the monitoring agent, each emulated device runs a management agent, which is connected to the management network and exposes a gRPC API for management actions (see Fig. 14). This API is invoked by the management system to perform management operations on behalf of CSLE users and reinforcement learning agents, e.g., restarting services, rotating log files, or updating firewall configurations. The management functions available in the API are listed in Tables 14-16.

Figure 14: The management setup in CSLE; each emulated device runs a management agent which is connected to the management network and exposes a gRPC API for management actions, which is invoked by the management system on behalf of CSLE users and reinforcement learning agents.

Table 14: Remote procedure calls (RPCs) in the gRPC API exposed by management agents (1/3).

Table 15: Remote procedure calls (RPCs) in the gRPC API exposed by management agents (2/3).

Table 16: Remote procedure calls (RPCs) in the gRPC API exposed by management agents (3/3).

Starting an Emulation Execution

An emulation execution corresponds to a set of running Docker containers and virtual networks. Starting an execution takes around 10-15 minutes. To start an execution, the emulation system first reads the emulation configuration from the metastore and starts the containers that are described in the configuration. Once the containers have started, the emulation system applies the emulation configuration. This step involves executing a sequence of Remote Procedure Calls (RPCs) through the gRPC API described above, e.g., RPCs to create user accounts, to start services, and to configure services (see Fig. 15).

Figure 15: Sequence diagram of the emulation system's procedure to start an emulation execution.