Container Security Part 2 – Benchmarks to the Rescue

EH-Net - Container Security Part 2 - Shipping PicContainers are like BYOD (Bring Your Own Device). They are infiltrating our ranks, and InfoSec professionals’ gut reaction is to hesitate in including them in their environments. But instead of dismissing containers out of hand, I thought it would be wiser to study them not only to be prepared for the inevitable but also to understand their usefulness and most importantly the security aspects of incorporating them into our organization. That initial exploration was covered in Part 1 of this series on container security, “Quick Dive into Containers, Kubernetes and Security”.

That quick dive showed that containers are an extremely useful tool and securing them wasn’t too dissimilar to what most are doing already. But I had never implemented them myself and have no one hear in my organization to lean on. So I went to the tried and true method of following existing, published best practices like the ones at the Centre for Internet Security (CIS). Part 2 of this series reminds us that we’re not alone. In most cases, some really smart people have already done the heavy lifting and were kind enough to share. Although free and at our fingertips, the right information can be a little tricky to find. This tutorial will attempt to accomplish 2 goals. First is to help save you time and frustration by avoiding the pitfalls I faced in getting the information, and second is to take a detailed look into the benchmarks themselves.


Quick Links ToC: Center for Internet Security | Seek and Ye Shall Find | Benchmarks – Not the End All, Be All | Summary


Center for Internet Security

EH-Net - Container Security Part 2 - CIS Website
Image 1

Overview of CIS

The Center for Internet Security (CIS) is a non-profit entity that provides a vast number of resources for Cybersecurity Best Practice, Tools, Threat Intelligence and more. We’re going to focus on the “Best Practices” section that includes controls and benchmarks to safeguard private and public organizations against cyber threats. For those not familiar with these terms, CIS Controls are described as the following:

IT security leaders use CIS Controls to quickly establish the protections providing the highest payoff in their organizations. They guide you through a series of 20 foundational and advanced cybersecurity actions, where the most common attacks can be eliminated.

And CIS Benchmarks are described as:

Proven guidelines will enable you to safeguard operating systems, software and networks that are most vulnerable to cyber attacks. They are continuously verified by a volunteer IT community to combat evolving cybersecurity challenges.

The benchmarks are what we’re after. On a side note, they also provide a few virtual OS images hardened with their benchmark recommendations. Here are a few examples:

With all of this brilliant content, there’s got to be loads of documents on containers, right?

Finding Benchmarks!

Gaining access to the treasure trove of content requires registration on CIS, but all of the information is free as downloadable PDFs. The frontend site itself is beautiful and engaging, but as you’ll quickly find out, the backend interface for the repository of benchmarks is a little clunky. You most likely won’t find what you need on your first attempt. I could see how many might just give up. But hang in there with me. I did eventually find my way through, and I’ll show you the way.

When logging in, the main page is presented:

EH-Net - Container Security Part 2 - Image 2
Image 2

The only link with the word “benchmarks” is “Published Benchmarks List” (in red below).

EH-Net - Container Security Part 2 - Image 3
Image 3

So I clicked it and was taken to view of all benchmarks organized by publication date. Unfortunately, there is no word search for this, and the only way to find something is to click through each page. To boot, this page is not helpful as you cannot search it.

EH-Net - Container Security Part 2 - Image 4
Image 4

The only way to navigate through the vast library is here:

EH-Net - Container Security Part 2 - Image 5
Image 5

After a little digging, I found a better way to search. On the left is a table of contents under your name as shown below. Select the “Benchmarks” link.

EH-Net - Container Security Part 2 - Image 6
Image 6

You will be greeted with a page that allows a word search. w00t!

EH-Net - Container Security Part 2 - Image 7
Image 7

Type in “Docker” and you will find various benchmarks:

EH-Net - Container Security Part 2 - Image 8
Image 8

Logically it would be expected that clicking the link will allow you to download it, however this is not the case. Instead it loads a page with basic information, version number and contributors. Again, we are saved by the table of contents on the left:

EH-Net - Container Security Part 2 - Image 9
Image 9

Click the “Files” section to be taken to a page where downloads for the benchmark are available. Here you will be able to find different versions of the benchmarks you are looking for. In this case we have found a Word document, PDF, and Excel document for Docker 1.13:

EH-Net - Container Security Part 2 - Image 10
Image 10

Phew! As you can see, they are there, but finding them is not quite intuitive. Now that we found them, let’s take a look.

CIS Benchmark for Docker
https://www.cisecurity.org/benchmark/docker/

https://workbench.cisecurity.org/benchmarks/363

CIS Docker 1.13.0 Benchmark [imported] v1.0.0

Each individual benchmark can be overwhelming upon first glance. For more detailed benchmarks such as Windows, the list of controls can appear to go on forever. For the document “CIS_Docker_1.13.0_Benchmark_v1.0.0.xls”, it is separated into 4 different Excel tabs:

  • License
  • Level 1 – Docker
  • Level 1 – Linux Host OS
  • Level 2 – Docker

Although the tabs are convenient, the Word Document version of CIS Docker 1.13 Benchmark explains what each of the above levels means, so let’s take a look.

EH-Net - Container Security Part 2 - Image 11
Image 11

The Overview section is definitely worth reading. It gives you an idea of what to expect from the document, and the intended audience section is especially helpful.

In this case it provides prescriptive guidance for establishing a secure configuration posture for Docker container version 1.13.0.

I have installed Docker on my Windows computer, and the version is 18.03 as shown below. The benchmarks are a little out of date but are still very much relevant.

EH-Net - Container Security Part 2 - Image 12
Image 12

Seek and Ye Shall Find

I don’t know the exact reason why it’s such an old version, although it probably has to do with the amount of time it takes to create such in-depth benchmarks and the amount of changes between versions needed. In an attempt to find out, I tweeted @CISecurity, who promptly responded that there were not enough significant changes to make another version. The tweet is shown below:

EH-Net - Container Security Part 2 - Image 13
Image 13

EH-Net - Container Security Part 2 - Image 14
Image 14

@DevSecOpsGeer also replied to the tweet with a Docker Community Edition Benchmark for 17.06. Found here https://docs.docker.com/compliance/cis/docker_ce/

EH-Net - Container Security Part 2 - Image 15
Image 15

Now that we have an updated Community Edition, let’s dive in to the finer details and get some specific recommendations for Docker security.

The Profile Definitions AKA Sections

CIS breaks up the recommendations into configuration ‘profiles’, a group of recommendations based around certain intentions.

Level 1 – Docker

As stated in the benchmark itself, this group of configurations is intended to:

  • Be practical and prudent;

  • Provide a clear security benefit; and

  • Not inhibit the utility of the technology beyond acceptable means.

In normal terms, this means configurations that make sense, are easy to implement without affecting the container operationally, and won’t affect its use, speed or reliability.

Level 1 – Linux Host OS

Also being a level one, the Linux Host configurations have the same exact bulleted intentions as above for Level 1 – Docker but focused on Operating System configurations.

Level 2 – Docker

Recommendations for this configuration have one or more of the following characteristics:

  • Are intended for environments or use cases where security is paramount

  • Acts as defense in depth measure

  • May negatively inhibit the utility or performance of the technology

The configurations are important for critical systems, whether that be from an uptime perspective or the data its holding. Due to these configurations being ‘serious’ and further tightening security, they may sacrifice usability or performance for the sake of security.

Key Format Difference Between the Excel and Word

In the Excel spreadsheet, the different profiles are separated by tabs, and in the Word document the recommendations are just in order.

EH-Net - Container Security Part 2 - Image 16
Image 16

Another item of note is that in the Word document, a Level 2 configuration will be mixed among Level 1s.

EH-Net - Container Security Part 2 - Image 17
Image 17

EH-Net - Container Security Part 2 - Image 18
Image 18

If you want to configure all Level 1 recommendations first, I would suggest using the Excel version. As it is all grouped together. Keep this in mind for all of the benchmarks, as they all have the same format.

Analysis of Each Section

The document breaks recommendations into sections:

  1. Host Configuration
  2. Docker daemon Configuration
  3. Docker daemon configuration files
  4. Container Images and Build File
  5. Container Runtime
  6. Docker Security Operations

Analysis of Host Configuration

Some people may be asking the question why does a Docker benchmark guide have host configuration guidance? Recommendations here are nothing groundbreaking, as most know security is best done in-depth. As such, having a strong host machine to then use for docker containers is a smart way to go.

Most of this includes hardening the host as expected. However there are recommendations on the way docker is installed and configured on the host, such as limiting the docker user from being able to alter the host system.

As with any benchmark, there is an audit section of all the docker daemon activities (basically advanced logs of what is going on in the containers). They also include logging docker related files and directories. These recommendations are great to use. As with defense-in-depth, it’s not just removing vulnerabilities, its reducing access that a malicious user inside a container could do as well as reviewing logs for anything malicious.

EH-Net - Container Security Part 2 - Image 19
Image 19

Docker Daemon Configuration Section

The Docker daemon of course has its own section. The daemon is the foundation in Docker. In short it is the building block for everything else.

Again, defense-in-depth is important here. So there are recommendations on restricting network traffic between containers, adding logging and even TLS for accessing the docker daemon over the network.

These recommendations are quite detailed with the exact commands to enable or disable certain items. As a result, an inexperienced user can go through these lists and secure their docker daemon.

EH-Net - Container Security Part 2 - Image 20
Image 20

Docker Daemon Configuration Files

Containers are small and generally for very specific uses; therefore, what runs on them should be known especially specific files and directories. As such the CIS Benchmark covers Docker related files, directory permissions and ownership. It steps through which files should be set restrictive such as 644, and which directories to verify are set to root:root. This is especially useful for inexperienced users, as it covers many files that one would never think of.

EH-Net - Container Security Part 2 - Image 21
Image 21

Container Images and Build File

There is no better way to explain the importance of container images and build files than to quote the document itself: “Container base images and build files govern the fundamentals of how a container instance from a particular image would behave.”

Similar to ensuring that the host is as secure as possible, the container images and build files are the next level foundation for container security.

This section starts off with the basics such as creating a non-root user for the container and using only trusted base images. It also cover not using unnecessary packages and scanning images. This is defense-in-depth in just container images itself. Does it sound simplistic? Absolutely. Remember, these documents are meant to set the baselines of security and don’t assume any prior knowledge or experience.

EH-Net - Container Security Part 2 - Image 22
Image 22

Container Runtime

Once a container is deployed, it will be in this state the longest compared to other states. Because of this, the recommendations are all about restricting what can be done while the container is running. CIS suggests leaving security enabled during runtime for such things as seccomp.

EH-Net - Container Security Part 2 - Image 23
Image 23

Docker Security Operations

Detection is extremely important in any security program or application. Being able to tell when a container has a remote shell on it, or is acting strange, is critical. Again, the Center for Internet Security knows this and has recommendations for monitoring docker containers usage, performance and metering.

Backing up is always important and for more than just security. Seeing as though this is also a makeshift checklist, it’s good to see that they also included some items that should certainly be in one’s overall program but just might need a gentle reminder not to forget.

EH-Net - Container Security Part 2 - Image 24
Image 24

Benchmarks – Not the End All, Be All

There is a great talk called “Hacking and Hardening Kubernetes Clusters by Example” that covers the fact that while benchmarks and best practices are great, they do miss a lot of context on what the container is actually being used for. They do not take into account add-ons, plugins and customizations you require. Therefore, benchmarks are a great starting point but should not be the only way security is handled.

EH-Net - Container Security Part 2 - Image 25
Image 25

And an additional note that although this article focuses heavily on CIS, there are other places to find good benchmarks for securing Docker and Kubernetes.

NIST

The National Institute of Standards and Technology is a United States Department that focuses on innovation and industrial competitiveness. Surprisingly they have a whole cyber security framework. Within their framework is the “Application Container Security Guide”.

EH-Net - Container Security Part 2 - Image 26
Image 26

Similar to the CIS benchmark, it is about container security:

EH-Net - Container Security Part 2 - Image 27
Image 27

Docker

Docker has its own document repo as well including Introduction to Container Security and the CIS Benchmark for the Docker Community Edition. This series of articles focuses on not just Docker but also Kubernetes. So not to be left out in the cold, there’s the CIS Benchmark for Kubernetes.

Summary of Container Security Part 2

Importance of Digging and Community

This second part in the series on Containers, Kubernetes and Security is almost 2 articles in 1. The first shows how even though the content is out there and free for the taking, it is not always easy to find. And once you find it, it might take a little bit of a hacker mindset to get the latest and greatest versions. But in the end, leaning on the security community at large is never a bad idea. Much more often than not, it bears fruit. So don’t be shy!

Importance of Benchmarks and Best Practices

From walking through the CIS Benchmark as an example, it is quite easy to understand the importance of benchmarks and best practices.

The benefits include:

  • Not having to be an expert to secure Docker and Kubernetes
  • Having a checklist to follow along
  • Not having to create it yourself, time and resources saved
  • Having multiple experts review the benchmarks prior to publication

Even if you’re a one-person shop, I advise not doing this alone. Security is very much a group effort. So, I highly recommend benchmarks for anything security related.

Giving Back

Being part of a community, be it here on EH-Net or out there on Twitter or any other social platform, requires give and take. Although the information provided in this article did nothing to add to the benchmarks themselves, sharing my experiences does help give back to the community. So even if you feel alone out there, just reach out. And when the community provides for you, give back in any way you, big or small.

Continue that trend by leaving me your thoughts and feedback in the Comments Section below.


Part 1 of this series on container security, “Quick Dive into Containers, Kubernetes and Security”.

 

Author Bio

EH-Net - Containers, Kubernetes and Security - Johnson PicHaydn Johnson advocates Purple Teaming principles as a powerful methodology for improving intra-organizational security and relationships. Having recently moved to internal security, he uses the offsec mindset to create impactful change within his organization. Committed to learning and sharing his skills, he has spoken at multiple conferences in America and Canada, and has published multiple online articles on offensive security. Haydn has a Masters in Information Technology, the OSCP and GXPN certifications. Originally hailing from Australia, Canada is now called home.

Container image source: Shipping containers Birthday, 26 April 1956

Tags:

This topic contains 4 replies, has 3 voices, and was last updated by  MTGreen 2 months, 2 weeks ago.

  • Author
    Posts
  • #169135
     Haydn Johnson 
    Participant

    Containers are like BYOD (Bring Your Own Device). They are infiltrating our ranks, and InfoSec professionals’ gut reaction is to hesitate in including[See the full article at: Container Security Part 2 – Benchmarks to the Rescue]

    • This topic was modified 2 months, 2 weeks ago by  Don Donzal.
  • #169139
     MTGreen 
    Participant

    Hi Haydn, Thanks for the article.

    Your article gave me a great chance to consider containers, and I am always glad to learn.
    I must say that I was thrown a little bit by your BYOD bring your own device reference. Bring your own device expands the attack surface. The purpose of containers is to limit the attack surface through restricting interactions between applications. This happens by maintaining application resources within the container.

    In that sense a container is like an application programming interface (API) but instead of limiting an applications access to the kernel, it is limiting access to the application by other applications. Of course the Cloud plays a big role in all of this. Containers are essentially modularity in the cloud.

    Another analogy is virtual machines, but instead of segmenting up to an entire network, containers are a lightweight version that isolates and secures applications that then can be utilized on existing systems virtual or not.

    I was glad to see that you included some of the challenges of hardening containers. There is a consistent tension between security and functionality, and functionality will win as long as it drives profits. Even though a container is modular in concept, an application still needs to interact with other resources to get the job done, and that will always include the introduction of vulnerabilities.

    • This reply was modified 2 months, 2 weeks ago by  MTGreen.
  • #169141
     MTGreen 
    Participant

    I just read an interesting write up on a Docker for windows hack. The vulnerability was associated with third party access and the availability to join user groups. I think it is an interesting read. The third parties were not following best practices (only allow trusted users to control Docker Damon). The post is here https://srcincite.io/blog/2018/08/31/you-cant-contain-me-analyzing-and-exploiting-an-elevation-of-privilege-in-docker-for-windows.html

  • #169147
     Don Donzal 
    Keymaster

    I took his analogy with BYOD to be more of a big picture comparison in that containers (like BYOD) are springing up and better to get ahead of it rather than ignore it until it gets into the realm of rogue activity. So instead of just complaining about those darned users, figure out how to best incorporate them into your environment and remain under your control.

    He also made the comparison to VMs in the first article. But IMHO this also goes along with the BYOD analogy. Some containers hold minimal stuff while others can be an entire operating env with access to internal networks. They can also be spun up by individuals for their own purposes or groups/departments for dev work. One never knows what any of these ‘devices’ have or can do whether it be phones, tablets or containers.

    Don

  • #169148
     MTGreen 
    Participant

    Don,

    Good points, of course. It seems that containers are more about provisioning and functionality then anything else (Security). Early entry of security considerations will make products more viable in the long term. I read that containers can be distinguished from VMs in that VMs rely upon their own kernel, while containers rely upon the hardwired kernel. This gives less overhead to the container, and makes them easier to spin up, but it actually expands the attack surface because it is another avenue into the user’s kernel in the hardwired machine.

You must be logged in to reply to this topic.

Contact Us

Thoughts, suggestions, issues? Send us an email, and we'll get back to you.

Sending

Copyright ©2018 Caendra, Inc.

Sign in with Caendra

Forgot password?Sign up

Forgot your details?