Container adoption is on the rise as more organizations transition from virtual machines to micro services-based architectures. While containers have an added layer of security due to their ability to isolate applications, this doesn’t mean the containerized environment keeps your business safe from malicious attacks.
Your security posture for your containers is just as important as it is for your overall IT estate. Having visibility into your orchestration logs, container logs, network traffic, and any signs of vulnerability is critical to respond to threats immediately.
As you develop your security strategy for your Amazon Web Services (AWS) containers — whether you are using Amazon ECR, ECS, EC2 or Fargate — there are four key areas to consider.
A container registry is a repository — or collection of repositories — used to store and access container images. This repository can contain vulnerable source code. If you pull items from the registry with vulnerabilities inherent in them, you’ll expose yourself to running vulnerable containers. In addition, as you can configure a registry using open source, you must exercise caution. One of the lessons learn from the Log4j saga was that while open source adds efficiencies, it’s not without error and can have insecure components.
Tight access control is one way to secure your registry. Always know who is accessing and changing items within the registry. Regularly scan images and encrypt them for better protection from attack while in transit so they will be less likely to be viewed or tampered with. Also, be sure to use HTTPs for any transfers.
Just as orchestration allows you to easily automate much of your containerized environment, someone can maliciously step in and run your containers. To avoid orchestration vulnerabilities, monitor configuration settings closely, regularly update your technology, maintain tight access, and ensure the public cannot access your orchestration layer. If you make your orchestration public, then you are exposing yourself to risk. It’s like someone constantly knocking at your door; if they keep knocking, they may find their way in.
As with orchestration and registry, maintaining tight access with your host is critical. With your host, look for what might be vulnerable and shared by your container(s). Regularly review applications for potential vulnerabilities. Be sure to monitor your host’s traffic and its behavior through logs and network packet inspection.
When it comes to scanning, scan the images before going live and then also scan the active containers during run time. This should make you aware of any exposures that introduce risk.
As part of an in-depth defense strategy, you also need to monitor your deployed containers to identify suspicious or malicious use. As a best practice, you should analyze both logs and network traffic. When we monitor container traffic, we look at both inter- and intra-container traffic, which allows us to pinpoint an issue to a specific workload. If an issue is identified, the identified microservice can be addressed and remediated without pulling the entire cluster down and starting from scratch to find the problem. If you experience a compromise, there should be less downtime and impact with this approach to container traffic monitoring.
Partnering with Alert Logic for AWS Container Security
No matter what combination of AWS containerization you have chosen, Alert Logic Managed Detection and Response provides the needed visibility into orchestration logs, container logs, and network traffic. In deciding to use containers for the modernization and optimization they offer your business, you can ensure the security of your codes, data, and software when you bring Alert Logic along with you on your container journey.
To learn more about securing containers on AWS with Alert Logic, view our webinar Security by the Slice, check out our ebook, Secrets to a Stronger Strategy for Container Security, or take our 2-minute cloud security assessment.