Container Security

Containers are a great idea. A small discrete element that allows a function to operate. They allow software developers to build and run these functions quickly. They contain all the elements needed to run the function within a pre-built package. They run knowing that the underlying architecture doesn’t need all the elements to run the code so that changes can quickly be made. According to recent research, the life of a container is often as small as 5 minutes. They are built at speed, deployed at speed and used at speed.

This is, however, one of the challenges of containers. They often reuse the core systems of the previously built container. That is to say, developers build upon and iterate the previous incarnation instead of building a new container. Any security vulnerabilities in the container and reused libraries/code are taken forward into the new container. It is not the developer’s fault, and this is just the way things happen.

We already saw attacks against containers with the Kiss-a-Dog attack last year.

DNS security is, therefore, a great place to prevent some of the resulting issues. Hackers use Command and Control infrastructures. As we all know, DNS is often used for an infected machine to get back to a control server. Hackers use techniques like fast flux and double fast flux to change where the C&C server is located quickly. This allows the hackers a more extraordinary ability to hide from detection.

Using a DNS blocking solution can help. Let’s be clear, it cannot stop inbound attacks, and it can’t protect the container from these attacks. It can, however, help stop an infected container from going to the C&C infrastructure. This is important. Often containers do not have limits on CPU and other core functions. By blocking the look-up at the DNS level for the infected machine, you prevent the infected container from using all its CPU and allowing it to carry out its core intended mission, not the mission the hacker wants it to do.

DNS security should be installed to help protect containers without the burden of applying local security elements to the container. This doesn’t limit the performance of the container and is a simple matter of using the DNS service that’s required anyway in the network.

So what are the benefits of a Secure64 Guard platform specifically for Container security?

1. Speed. You know the container will have security irrespective of the elements in the container
2. Performance. You are not hampering the performance of the container with unnecessary code
3. Reusability. The same DNS architecture is reused for every container deployed.
4. Visibility. Using the Vizion platform, you can see the calls to a Command and Control infrastructure that an infect container is making. You can then take proactive action to stop this from happening again.

If you would like to learn more about the Guard platforms, Vizion and our other services, please don’t hesitate to contact Secure64.