Review of NIST Publication SP 800-190, ‘Application Container Security Guide’

Ruslan Rakhmetov, Security Vision

Friends, in our previous publication we discussed the protection of virtualisation technologies in accordance with the recommendations of NIST Special Publication SP 800-125. At the same time we noted that the use of virtualisation technologies is widespread in modern OSes, which allows providing a secure, flexible, automated way to deploy and run new applications that work independently and in isolation from each other due to application containerisation technology. The topic of today's article is NIST Special Publication SP 800-190, ‘Application Container Security Guide,’ which describes the information security threats posed by application containerisation technologies and provides recommendations on how to mitigate them.

Unlike full virtualisation, in which a hypervisor manages a set of virtualised operating systems, containerisation technology involves creating a virtual environment for applications in which only dedicated operating system resources and application data are available, while data from other applications running on the same operating system is inaccessible. Application containerisation technologies also use a microservice approach, where a set of containers containing several components (services) for the operation of a single application is created. This fragmentation provides flexibility and scalability in application development and deployment, as it allows services to be distributed and replicated between different applications if necessary, and the independence of services makes it possible to use different programming languages and frameworks when creating them. Unlike virtualisation, where each virtual machine has its own lifecycle (i.e. can be changed or reconfigured), containers exist in an unchanged state, and if modification is required, the container is removed and a new one with the required characteristics is created; in this case, all the necessary files to run containerised applications are stored in container images. A similar approach is used when containers work with data: containers do not contain the necessary data within themselves, instead they access independent data stores that do not change when the container is replaced. When working with containers, some requirements are imposed on the host OS to ensure that containerisation works, such as namespace isolation (inaccessibility of the file system, network interfaces, processes of one container to be accessed from another container), resource allocation (the ability to specify certain hardware characteristics for each container), file system virtualisation (deduplication of files executed by containers, saving changes with access to new data only for the initiating container).

The architecture of containerisation technologies consists of five layers:

1. Development systems used to create container images and send them for testing and accreditation;

2. Testing and accreditation systems that verify and sign the contents of container images, with further submission to the image registry;

3. Container image registries, storing and transmitting these images upon request by the orchestrator;

4. orchestrators that convert images into containers and deploy the containers to hosts;

5. Hosts starting and stopping containers at the orchestrator's command.

The container lifecycle phases consist of 3 phases:

1. Image creation, testing, accreditation: the components of the application being containerised are assembled and placed in a container image. Image creation is performed using automation and creation management tools (e.g. Jenkins, TeamCity). Testing is performed to verify the functionality of the resulting image, and accreditation is performed by the cybersecurity team after the image is verified.

2. image storage and retrieval: images are stored in centralised repositories - image registries that also perform version control, tagging, cataloguing. Registries can be internal or external (e.g. Docker Hub, Google Container Registry).

3. Container deployment and management: this step is performed by orchestrators (e.g. Kubernets, Docker Swarm) - software tools for retrieving container images from registries, deploying to containers, managing running containers. When deploying an image in a container, the image itself remains unchanged, and a copy of it is placed inside the container and run. The orchestrator is responsible for managing containers - monitoring the state, restarting in case of an error, managing container networking. When an application is updated, the latest version is added to the image registry, and the orchestrator receives a new container image and replaces the previous one. In smaller infrastructures, the orchestrator may not exist, and the host will request and manage the container image from the registry.

NIST SP 800-190 also lists the following cyber risks to various aspects of containerisation technology, with countermeasures to minimise them.

1. Container image cyber risks

1.1 Vulnerabilities in images: if a vulnerability exists in an image, that vulnerability will ‘propagate’ into the deployed container; while the initial deployment of the software in the image may have no known vulnerabilities, over time vulnerabilities are likely to be found and exploited by attackers. Countermeasures would be to integrate processes and tools to control the absence of vulnerabilities at all stages of the image lifecycle, handle vulnerabilities at all levels of the image (including frameworks and application software), and enforce policies to ensure that published applications comply with internal rules for controlling the absence of vulnerabilities.

1.2 Configuration weaknesses: if insufficiently secure settings are used in an image, the corresponding container will be vulnerable to attackers exploiting these weaknesses in the configuration. Countermeasures can include checking configurations against vendor recommendations and best practices, a continuous process to ensure images are compliant with internal requirements, prohibiting non-compliant images from running, and using only trusted base components to create images.

1.3 Embedded malware: If insufficiently trusted components are used in an image, malicious code can compromise the container or host OS. Countermeasures include signature and behavioural detection of malware indications.

1.4 Embedded secrets/passwords stored in plaintext: when creating an image, developers may include passwords in plaintext, private encryption keys, connection strings, API keys, etc., allowing anyone with access to the image to obtain this information. To minimise this risk, modern orchestrators offer secure secret storage, you can also use third-party solutions for secure storage of authentication information.

1.5 Use of untrusted images: when using images obtained from untrusted sources, there is a risk that they contain malicious components, weak configurations, vulnerabilities. Countermeasures would be to control trust in images and registries, use cryptographic image signatures and verify them before running images, create image resolution lists, update trusted image repositories when they are updated.

2. Registry cyber risks

2.1 Insecure connection to registries: when using insecure communication channels, both the transferred images themselves and administrator and developer credentials used to connect to registries are at risk. To minimise this risk, secure communication channels should be used to ensure that data is protected during transmission and that endpoints are authenticated when the connection is established.

2.2 Obsolete images in registries: storing obsolete images with known vulnerabilities in registries increases the likelihood that they will be deployed in containers. Countermeasures would be to clean registries of old images and use version indication when naming images.

2.3 Insufficient authentication and authorisation restrictions: insufficient authentication and authorisation requirements (weak or non-existent passwords) expose both the information within images and the images themselves, which can be spoofed with malicious images. For protection, authentication of all access subjects should be applied, as well as the principle of separation of powers and privilege minimisation, with logging and auditing of all write events to registries.

3. Orchestrator Cyber Risks

3.1 Unrestricted administrative access: if administrative rights are not sufficiently granularly granted, then orchestrator administrators may accidentally or intentionally make changes to third-party containers. The orchestrator-provided access differentiation model can be applied as a countermeasure.

3.2 Unauthorised access: orchestrators often use inbuilt authentication mechanisms, which may result in a simpler password policy or obsolete accounts. Countermeasures would be the use of multi-factor authentication for administrators, the use of the single sign-on concept, and containerised data encryption.

3.3 Insufficient separation of network inter-container traffic: in containerisation systems, traffic between containers is routed through overlay virtual networks managed by an orchestrator, which leads to a lack of control by corporate network security tools (e.g. IPS/IDS), and is also fraught with the possibility of network attacks by a compromised container against neighbouring containers using the same network. To minimise this risk, dedicated networks can be allocated to carry information of different privacy levels and different purposes.

3.4 Mixing container privacy levels: by default, orchestrators distribute containers based on load and may host multiple containers with data of different privacy levels on the same host, which may result in a more sensitive container being compromised after an attack on a less secure container. Countermeasures can include segmentation of containers by purpose of use, information sensitivity level, threat model, and manual distribution of containers to different hosts.

3.5 Trust in the orchestration node: if the orchestrator configuration is not secure enough, the orchestrator itself and other components of the containerisation technology can be compromised, including trust between hosts, compromise of the entire cluster due to a single host, disabling encryption and authentication for data transfer between administrators and hosts. Countermeasures are the use of orchestrators that are resilient to the compromise of a single node without risk to the entire cluster, capable of providing isolation of the compromised object.

4. Container cyber risks

4.1 Vulnerabilities in container software: If vulnerabilities allow attackers to perform a container escape, the security of the entire host and all containers on it will be compromised. As a countermeasure, the vulnerability management process procedures should be applied to all container applications and components.

4.2 Unrestricted network access from containers: if a container is compromised and no proper measures are taken to restrict container network traffic, attackers can launch network attacks that target neighbouring containers and the host itself. To minimise this risk, container-optimised network access control tools that identify network connectivity context and traffic anomalies should be used.

4.3 Insecure container configurations: if there is no differentiation for executing highly privileged commands from containers, the host OS and neighbouring containers can be compromised. Countermeasures would be to apply vendor guidelines for container configuration, use OS built-in access control tools, apply seccomp Linux profiles to limit the ability of containers to affect the OS.

4.4 Vulnerabilities in containerised applications: if a vulnerability is discovered in an application that has been hosted in a container, the consequences of its exploitation may include compromise of the host OS and other containers. To minimise this risk, specialised tools can be used to build behavioural profiles for containerised applications, with the ability to detect and respond to anomalies.

4.5 Redundant containers: if a container is unauthorised or unplanned, it may not be subject to strict configuration restrictions and vulnerability checks. This risk is bought down by organisational measures governing the use of different environments for development, testing, operation.

5. Host OS cyber risks

5.1 Wide attack surface: when containers are available from the Internet, the threat of compromising the host OS or containers in it is relevant. A countermeasure would be the use of specialised minimalist OSes optimised to host containers.

5.2 Shared OS kernel: when containers run, they gain access to some kernel components of the host OS, which can lead to its compromise. To avoid this scenario, containerised and non-containerised applications should not be run on the same host.

5.3 Host OS component vulnerabilities: if vulnerabilities in a host OS component are exploited, containers and applications running on it may be compromised. Applying a vulnerability management process to the host OS, placing updated OS components with all permitted dependencies in the container, will serve as a countermeasure.

5.4 Improperly configured access rights: by allowing a user to manually manage containers past the orchestrator layer, the health of other containers on the host OS may be compromised. In response, all authentication attempts should be monitored, user login anomalies should be detected, and privilege escalation attempts should be checked.

5.5 Spoofing of host OS file system objects: if incorrectly configured, a container may be given the right to modify host OS file system objects, which may lead to compromise of the host OS itself and all containers on it. As a countermeasure, tools should be used to control attempts to modify host file system objects.