You may have wondered what application containers are, let alone how to secure them. The National Institute of Standards and Technology (NIST) sets out to explain the benefits and security concerns with application container technologies in the latest Special Publication (SP 800-190) Application Container Security Guide.
Whether you’re new to Information Security or a seasoned vet interested in learning more about application containers, we have highlighted some of the important takeaways from the new NIST container guidelines.
Application container technologies (aka “containers”) are a form of operating system (OS) virtualization combined with application software packaging. Containers provide organizations an easier way to package and run applications. For example, containers can be more portable, reusable and automated.
With the business benefits, come risks. Organizations will need to adapt their culture to the inevitable disruption caused by containerization technologies. In some ways, security and IT pros will find that patching and development methodologies will not apply the same way it has in the past. In other ways, some of the older security principles, such as configuration management, are still very much relevant.
In the latest final release of security publication (SP 800-190) on September 25, NIST explains the underlying architecture that makes up container technologies, the risks and guidance to improve application container security.
Container Architecture
You may have wondered what the differences are between virtual machines and containers. NIST explains the differences briefly below.
Virtual Machines (VMs): “VMs use a hypervisor that provides hardware-level isolation of resources across VMs. Each VM sees its own virtual hardware and includes a complete guest OS in addition to the app and its data.”
Containers: “With containers, multiple apps share the same OS instance but are segregated from each other. Containers share the same OS kernel…”
Often times organizations will deploy containers within VM’s to better utilize their hardware investments and more efficiently package their applications.
The container technology stack is further described in Figure A below as provided by NIST.
The container technology stack includes the following components:
- Host OS (such as Windows or Linux server).
- Container runtime that “abstracts the underlying host OS from each container, such that each container sees its own dedicated view of the OS and is isolated from other containers running concurrently.” Examples of container runtimes include Docker, LXC, rkt, and the Open Container Initiative Daemon.
- Images: Images are packages that contain all the files required to run a container.
- Registry: “Images are typically stored in central locations or services to make it easy to share, find and reuse them across hosts.” Check out examples such as Amazon’s EC2 Container Registry or Docker Hub.
- Microservice: “Sets of containers that work together to compose an application.”
- Orchestrators: “Multiple container hosts can be grouped together and centrally managed by orchestration tools.” Orchestrators are responsible for monitoring, resource consumption, job execution, and machine health across multiple servers. Examples of orchestrators include Kubernetes, Mesos, and Docker Swarm mode.
Risks
NIST breaks out the risks in container technologies by the various components described here.
Container risks
Risks in application containers include:
- Many more entities – for example, apps can consist of different front end containers, each running a different part of the web app, multiple database and cache instances on the backend.
- Much greater rate of change – deploy app changes weekly or daily.
- Security is largely the responsibility of the developer – “the developer is now responsible for performing the patching within the images and providing the new versions of the images to be run.”
- Security must be as portable as the containers – such as their developer workstation, a public cloud test environment, and a private cloud production environment.
- “Networking is much more ephemeral” – The IP addresses assigned to a given container are not typically known in advance; IPs often change, which makes it difficult/impossible to protect containers using security controls that rely on static IP addresses (e.g., firewall rulesets filtering traffic based on IP address).
Host risks
Host-related risks include:
- Improper user access rights.
- Host component vulnerabilities.
- Container runtime risks – such as vulnerabilities within the runtime software (e.g., “container escape” that may allow malicious software to exploit vulnerabilities to attack resources outside of the container).
- Unbounded network access from containers – for example, a compromised container could allow malicious network traffic to expose other resources in the environment to risk; traffic from one container to another may appear simply as encapsulated packets on the wire without an understanding of the ultimate source, destination, or payload.
- Insecure container runtime configurations.
- Shared kernel – level of isolation provided by container runtimes is not as high as that provided by hypervisors.
Image risks
Image-related risks include:
- Image vulnerabilities – a common risk in containerized environments is deployed images having vulnerabilities because the version of the image being run does not include all the necessary updates.
- Image mis-configuration.
- Embedded malware.
- Embedded secrets (such as keys, passphrases, x.509 private keys).
Registry risks
Registry-related risks include:
- Insecure connections to registries.
- Stale images in registries – increase the likelihood of user error resulting in the deployment of a known-bad version.
Orchestration risks
Orchestration-related risks include:
- Unbounded administrative access – a single orchestrator may run many different apps, each managed by different teams, and with different sensitivity levels.
- Weak or unmanaged credentials – compromise of them can lead to system-wide compromise.
- Unmanaged inter-container network traffic.
- Mixing of workload sensitivity levels.
Countermeasures
Given the risks, NIST then goes on to describe good countermeasures or guidance to mitigate the risks to application containers.
Hardware countermeasures
NIST recommends organizations implement a “trusted computing” model, such as the following:
- Measure firmware, software, and configuration data before it is executed using a Root of Trust for Measurement (RTM).
- Store those measurements in a hardware root of trust, like a trusted platform module.
- Validate that the current measurements match the expected measurements. Therefore, it can be certified that the platform can be trusted to behave as expected.
Host OS Countermeasures
Configuration standards for operating systems (such as Windows or Linux server OS) need to be established for each host that include hardening requirements. Deviations to the configuration standard can introduce weaknesses and should be monitored. Tools should be used to regularly check for (and mitigate if found) deviations to standards. Apply updates and patches to all OS and software components used within the OS.
Also, address any improper user access rights. For example, ensure that all authentication to the OS is audited, anomalies are monitored, and any escalation to performed privileged operations is logged.
Container Runtime Countermeasures
Look for and mitigate Common Vulnerabilities and Exposures (CVEs) in the container runtimes prior to deployment. Be sure to upgrade any instances that are vulnerable or at risk, and ensure that orchestrators only allow deployments to properly maintained runtimes.
Address “unbounded network access from containers”: For instance, organizations should control the egress network traffic sent by containers. Also, utilize “app-aware” tools to not just see the inter container traffic, but also to dynamically generate the rules used to filter the network traffic based on the specific characteristics of the apps running in the containers.
App-aware tools should include, according to NIST:
- Automated determination of proper container networking surfaces, including both inbound ports and process-port bindings.
- Detection of traffic flows both between containers and other network entities, over both ‘on the wire’ traffic and encapsulated traffic.
- Detection of network anomalies, such as unexpected east-west traffic flows, port scanning, or outbound access to potentially dangerous destinations.
Prevent insecure container runtime configurations: for instance, automate compliance using container runtime configuration standards (see Center for Internet Security Docker Benchmark). You may also use mandatory access control technologies such as SELinux and AppArmor to provide enhanced control and isolation for containers.
Shared kernel: Segment containers by purpose and sensitivity to provide additional defense in depth.
Monitor for compromised containers – tools should be able to automatically profile containerized apps and build protection profiles for them to detect anomalies such as:
- Invalid or unexpected process execution,
- Invalid or unexpected system calls,
- Changes to protected configuration files and binaries,
- Writes to unexpected locations and file types,
- Creation of unexpected network listeners,
- Traffic sent to unexpected network destinations and
- Malware storage or execution.
Image countermeasures
Image vulnerabilities should be addresses in a timely manner. For instance, organizations should use tools that take the “pipeline-based build” approach and unchanging nature of containers and images into their design to help provide more actionable and reliable results. Organizations will need to have visibility into vulnerabilities at all layers of the image – such as application frameworks and custom software.
Organizations can configure rules in the build process to prevent the progression of images when vulnerabilities are discovered that meet a Common Vulnerability Scoring System (CVSS) threshold.
Similar to host configuration standards, organizations should also enforce image hardening standards, prevent the running of non-compliant images and centralize reporting/monitoring of compliant images.
Implement anti-malware protections: identify malware within images both in registries and on hosts or malware signature sets and detection heuristics based on actual ‘in the wild’ attacks. Be sure to detect malware that may be introduced to a container at runtime.
Prevent embedded secrets: for instance, use tools to provide APIs to retrieve secrets securely as containers are deployed; eliminate the use and need to persist shared secrets (such as passwords and private keys) within images.
Image trust: centrally control what images and registries are allowed to run in your environment. Be sure to use cryptographic signatures for identification of each image and use quality gates to allow trusted containers to be deployed. Ensure all hosts only run images from an approved list. Implement ongoing monitoring and maintenance of image repositories.
Registry countermeasures
Secure connectivity to registries: the key goal is to ensure that all data pulled from a registry is encrypted in transit between the registry and the destination.
Prevent stale images in registries, such as:
- prune registries of unsafe, vulnerable images that should no longer be used and
- operational practices should emphasize accessing images using immutable names that specify discrete versions of images to be used.
Orchestrator Countermeasures
Unbounded administrative access: use a “least privileged” access model so that users are only granted ability to perform the specific administrative actions on specific hosts, containers, and images that their job role requires. For example, “test team” members should have limited or no access to containers used in production.
Weak or unmanaged credentials: Access to cluster-wide administrative accounts should be tightly controlled. Organizations should also implement single sign-on (SSO) to existing directory systems where applicable.
Don’t mix the workload sensitivity levels: Orchestrators should be configured to isolate deployments to specific sets of hosts by sensitivity levels.
Conclusion
In conclusion, the NIST SP 800-190, Application Container Security Guide, should help give organizations a better understanding of application container technologies and ways to implement multiple layers of defense to minimize risks.
Organizations will have to quickly adapt to the inevitable culture changes and how containers are used.
One thing still hasn’t changed: a strong partnership between security and development organizations will help better secure your organization’s environment and brand.
Editor’s note: this article was originally posted on May 15, 2017 and has been updated to include latest release version and link to SP 800-190 recently published on September 25.