It’s imperative to understand the architectural building blocks of container security. Containers have a lifecycle that includes running, executing, and operating, and all these aspects must be considered for effective security.
It’s essential to protect more than just the container design; each container includes registry codes and configurations ready for deployment, forming a complete container ecosystem. Here are three ways to enhance your AWS container security.
#1: Set Table Stakes for AWS Container Security
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.
Stakes refer to the role or influence an existing process holds within the broader container process intended for mimicry and implementation. If an element is superfluous, it should be secondary to higher-priority development concerns.
#2: Ensure 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 cyber-risk 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.
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.
#3: 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 take on some of the security burden yet leave the rest in your hands.
There are four main areas to focus on: applications, hosts, LAN, and platform security. Customers generally take on more responsibility for the first three, while AWS shares the responsibility for platform security. Numerous tools are available to help you secure the platform. For example, many platforms interact with AWS via API calls, so logging and monitoring are essential. Keep CloudTrail enabled, and ensure logging is active and maintained across all systems and production environments. Even if you’re using a server-based architecture rather than containers, it’s crucial to monitor who is interacting with each component and their access requests. Additionally, avoid a simple lift-and-shift migration. Conduct a thorough audit of your system before transitioning to the cloud to identify potential vulnerabilities.
Several themes persist on the hosting side, too. These include log analysis, threat detection, patch management, and tiered access privileges. Alert Logic’s AWS security solutions are well-placed to help set up and monitor host guards for containers, fulfilling more of your obligation in a security model.
Additional AWS Container Security Resources:
Container Security for Cloud, Hybrid, & On-Premises
