3 Tips to Strengthen AWS Container Security

This piece was originally published on Fortra’s Alert Logic blog.

If you’re building an application, you want to ensure it’s reliable, consistent, and rapidly deployable in any cloud environment. That’s what containers are used for — packaging instructions into a digital object for reuse. Without them, you’ll struggle to run some application components from server to server. But when you deploy containers, there are security risks that you should be aware of and can mitigate. Malicious web actors can infiltrate them and seed all kinds of corruption, stealing data, and disrupting your organization.

In Fortra’s Alert Logic team, we like to start with the constituent or architectural building blocks for container security. That’s because containers have a life cycle: They must be run, executed, and operated. You have to take everything that makes this a reality into consideration.

After all, there’s more to protect than merely the container design; each container holds a registry code and configurations ready for deployment. In other words, the complete container ecosystem. That’s what we’re going to talk about here. Drawing from one of our on-demand webinars, we’re sharing three ways to enhance your Amazon Web Services (AWS) container security.

Set Table Stakes

What are table stakes? Simply said, they are the minimum requirements for an application to do an effective job. Almost everyone uses them holistically, but often leave out certain essential components such as retaining containers for testing and communication instead of security.

When we discuss “stakes,” we’re referring to the role or influence an existing process has within the container process you want to mimic and implement. If something is superfluous, it should take a backseat to other, higher priority development.

Just be wary of rushing container collection and deployment. If you go full speed, you’re impacting a large number of people and almost forcing them to mature as quickly as possible. Careful, iterative pathways are better. They allow everyone in the organization to get comfortable with AWS and understand that you’re never taking jobs away, but rather solving manual lifting. Since there’s also a lot of crossover between DevOps and security practices, automation is tougher to get right from the beginning unless it’s protected without too much strain or oversight.

Make Sure What’s Running Is Expected to Run

Container registries can be exposed to human errors and malicious behavior. One tweak can cause incalculable harm to the rest of your system downstream. Our security experts have seen examples of vulnerabilities within some orchestration platforms, such as a default insecure state where we’ve detected crypto jacket containers running crypto mining. This is great for an attacker because it’s a very direct route to a target’s finances.

Such attacks can arise from “sidecars,” which run alongside your workload, adding scripts on top of regular, functional platform requests. Therefore, you need to know what’s meant to be running without any interference and spot threats when they arise. Without managed detection and response (MDR), they’re easy to miss.

Time scanning is a useful tactic for analyzing container and host behavior. This tracks requests over a period of time and benchmarks them against expectations for every process. You’re interrogating whether there’s a normal state and if sudden changes could be malicious.

Much of Alert Logic’s container security service involves peering at logs and traffic data. That’s usually harder to pull off if you’re building a single monolithic application, but we can deal with the most advanced architecture and scan the entire stack.

Understand the AWS Shared Responsibility Model

AWS container security duties are shared, but never equal. This divides some of the customers who approach us, although it’s crucial to undertake your responsibilities. AWS platforms such as EC2, EKS, and Fargate will take on some of the security burden yet leave the rest in your hands.

Broadly, there are four areas to check: apps, hosts, LAN, and platform security. Customers tend to become more responsible for the first three, while AWS splits the role for the latter. You have plenty of options for protecting the platform on your end. For instance, one of the key things to consider is that most platforms work with AWS through API calls. Logging and monitoring are key. CloudTrail should be kept on and logs must be enabled and maintained on all systems and production environments. Even if you’re running a server list instead of a container, it’s important to know who’s talking to what and who requested it. Subsequently, don’t just lift and shift migration. Audit your system before moving to the cloud and try to find weaknesses.

Several themes persist on the hosting side, too. These include log analysis, threat detection, patch management, and tiered access privileges. Our comprehensive MDR solution is well-placed to help set up and monitor host guards for containers, fulfilling more of your obligation in a security model.