In this Q&A, we focus on IDS security and why a Network IDS based system is necessary to achieve intrusion detection.
Where should companies start if they do not have a container security solution in place? Should they choose a network intrusion-based approach over a more traditional host-based system?
Answer: With a host-based product, you get a deep look at what’s going on in that host, but you need to remember this is an isolated view. By contrast, a network intrusion detection system (NIDS) approach like the one we use focuses on the whole environment — the big picture, if you will. Here’s why that difference matters: If you have an attack focused on a particular container or cluster and it propagates, you need to have a good way to see everything in the same view. This is the only way you can see the attack in full context, truly understand it, and respond appropriately. This holistic vantage point is particularly important for aggressive, wide-spread attacks. That way, you can see all of the individual components in one consolidated view. This big picture view tends to get lost when you are dealing with host-based products or things that are local to the cluster.
A network IDS-based approach provides that comprehensive view so you can determine how much of your environment has been impacted. In many situations — especially in containers where any single node could be running numerous containers — it is vital to improve visibility, simplify tasks, and ease management of the security function. What’s important is what you miss if you are inspecting just the traffic coming into the node. You don’t see what is happening with all the deployed containers. If you do not have visibility into container-to-container traffic within the node or container traffic across the network to other nodes, then you’ve missed that bigger security picture.
Container security should allow you to look at everything that is within that node including all the running containers. It also should provide visibility into any traffic that comes across that node from any other source so it can be captured, analyzed, and provide context.
[Related Article: What is Container Security?]
How do you identify a particular container in an environment in which there are thousands of containers? What’s the “secret sauce”?
Answer: It all comes down to metadata. It could be as simple as the name of the container, the container image, it could be the deployment — where it is actually deployed within the infrastructure. There are a lot of different things that customers (and our own security analysts) need to focus on in a given attack scenario. We knew that it was critical to gather all published metadata — whether it be from Docker or Kubernetes, or whatever a customer is using — and to ensure that the metadata fields are then captured in the incident. So, when somebody needs to look at it, they can say specifically which containers and clusters were impacted. This also helps us to determine what happened during the attack, where the impact is, and what remediation might look like.
Metadata supports security, integration and orchestration. All of the metadata being created by the different flavors of container deployment is gathered by the Docker API. So, if you are running Docker, and Kubernetes on top of Docker, and Rancher on top of Kubernetes, we see all of the metadata available from all three platforms just by pulling the Docker API.
Access to the metadata provides the backbone necessary to understand a container attack. There are two scenarios that can illustrate what I mean. First, consider this pre-deployment scenario: If you are dealing with something like a zero-day vulnerability, then as soon as you are able to identify that vulnerability, you can just prevent that vulnerable container image from being deployed. Problem solved. But, if the container is already out there, post-deployment, identifying the affected container by, say, the image ID metadata, allows a customer to quickly go back to that base image, fix the vulnerability, and then re-roll the new container out into production.
It goes back to that context concept we talked about earlier. If you see an attack successfully target a container, you want to understand why that was. Was it a bad configuration (again, like a misconfigured security group that left the door open) or was it something potentially more dangerous in that whatever you are running inside that container is now vulnerable to whatever has been compromised?
At Alert Logic, we have the ability to paint the picture of all the different containers and all the metadata within a node. So, take for example, one container on a given node is being attacked — we can show you the network traffic that shows that container is being attacked but we can also provide all the metadata associated with that container and potentially any other container in that node that is also impacted. We can even go a step further and highlight things such as what image that container was born from. And the beauty in that is, rather than trying to solve that one singular container security incident, you can take a bit more of a holistic approach. So, you can look more broadly at the security issue and say “Oh, that’s not actually a problem with my container, that’s a problem with my image and if I go fix my image, then I can reduce my overall security risk.” That way—customers aren’t just fixing that one problem, but instead can address issues across their entire fleet. We even provide remediation advice, so our customers have support when making a change like that.
How important is proactive notification to a customer when an attack type is ramping in their containerized environment?
Answer: That’s one of Alert Logic’s key advantages, regardless of where the attack may be in a customer’s environment. Whether the attack is coming from a container, a traditional cloud instance, or a hosted environment, we provide deep contextual data to our customers. That way, we deliver a first-class security response to issues, incidents, and attacks.
The key is being able to get down to the granular level of what specifically was attacked and provide really good information about what the impact was and where it occurred. It’s not only being able to recognize when an attack is happening, or that it is legitimate and needs to be addressed but also being able to do so in a way that is holistic and across the spectrum. Again, no matter where the attack is coming from and where it is going, you want to be able to say, ‘Hey, this is where the attack is, this is where it is headed, and these are the specific systems that it hit.’
What’s Next?
If you want to know more about what it takes to stay ahead of container-based attacks, download Container Security | Alert Logic Solution Brief. This guide walks through some of the best practices to leverage while building your container security strategy and provides a useful workbook to put some of these ideas into practice in your organization. Or take a view of our 3-minute container security video to see our network IDS security for containers capabilities in action.
