This technical deep dive highlights key capabilities released as part of Twistlock 18.11. To learn more about what’s included with Twistlock 18.11, check out our full release blog post.
With each major release Twistlock introduces new features as well as invests in improving on existing functionality for securing cloud native workloads. With the release of Twistlock 18.11, we improved on our support for protecting on-demand containers running on AWS Fargate.
Expanding protection for AWS Fargate
Previously, I shared a deep dive on the background around Fargate and how Twistlock protects your on-demand containers. For those unfamiliar, Fargate is a container as a service offering from Amazon Web Services that runs on top of ECS and allows you to run Docker containers without having to worry about the underlying infrastructure virtual machines or clusters. This architecture gives you the freedom to run containers and scale easily while focusing on development rather than operations overhead. However, there are distinct security challenges present in this design since you do not have access to the underlying virtual machine. Without this access, you can not easily install a traditional security agent, so a new approach is needed.
Users have two options for securing applications on Fargate. Users either embed security as part of your deployment or sideload security from another container at runtime. Both of these methods are discussed in more detail in the previous blog post. At Twistlock, we make use of a sideloading approach. We chose this method because it doesn’t require you to modify your images during the build process. Developers build their images in the same way they do today and secure the containers at deployment. To add a Twistlock Defender to your Fargate task, you simply copy and paste the task definition in our UI and click a button to create a protected task definition. It really is that easy. If you want to do this as part of automation it can also be done through our APIs. With this approach, Twistlock only makes modifications to the Fargate task definition rather than directly to the image.
For several releases now, Twistlock has provided process-level runtime protection for Fargate. Process level protection ensures that only executables found in the original image are authorized to run inside the container — this is done by default. This means that even if you are vulnerable to a CVE and someone attempts to exploit one of the running services in the container, they will not be able to run any programs that are not explicitly allowed. For example, an attacker might try to run rpm to install a package or use a curl command to install malware. If Defender detects any anomalous behavior, Twistlock can alert or enforce on that action based on your chosen policy.
Additionally, Twistlock provides other smart functionality by default. For example, Fargate Defender monitors the running container for any instances of cryptominers. Rogue cryptomining installations are an attack we have seen becoming newsworthy more recently. Attackers look for insecure registries, download images, and add a cryptominer layer without the organization knowing. The attacker then pushes this modified image back to the registry. Unsuspecting companies then deploy their images and inadvertently run cryptominers for the attackers. This attack is an easy way for attackers to make money without ever having to steal your data.
In the screenshot below, you can see how easy it is to create a new runtime rule with the setting Detect Crypto Miners ON:
Preventing unwanted network access
With Twistlock 18.11, Twistlock provides the ability to restrict network traffic between your Fargate containers and external resources. If your containers need to to talk to other assets, we want to be positive that this access is scoped and monitored properly.
For example, if your container needs to access an RDS database or another microservice, you want to ensure that the container only hits that desired endpoint. Access can be scoped based on a host name, domain, ip address, or network. This also prevents your containers from reaching out to malicious endpoints, such as CDNs that are known to host malware or a botnet command and control server.
In the following screenshot, you can see a new runtime rule that will block access to any domains I do not explicitly include myself:
Cloud Native Application Firewall (CNAF) for Fargate
In order to provide even more network protection for your applications leveraging Fargate, Twistlock now provides our layer 7 CNAF via Fargate Defender. This firewall allows you to protect your containers from a whole host of attacks, like those included in the OWASP Top 10, that are difficult to defend against in a cloud native environment.
With a cloud native application firewall, users should put it as far downstream as possible. This differs from a traditional WAF that you want to implement as far upstream as possible. With CNAF, Twistlock protects the containers on their overlay network event if someone manages to penetrate your network. With only a traditional WAF in place, your services would be vulnerable to these attacks. Defense-in-depth is strongest when you have both in place. Previously, we have covered a a full deep dive into the CNAF functionality, I will cover the functionality at a high level here with an image I am deploying on Fargate.
Twistlock CNAF provides protection from the kinds of attacks you would expect from a traditional WAF: SQL injection, cross site scripting, and client side request forgery among many others. Twistlock also allows you to filter attacks based on HTML header values, protects file upload forms to ensure that only authorized file types are uploaded, as well as a full suite of intelligence gathering defense.
In the screenshot below, you can see how I am creating a new CNAF rule called Fargate Protection that will block attacks to any image called fargate_image:latest:
By deploying this rule once, Twistlock will protect every instance of my image against the attacks I have selected from my policy in Twistlock Console.
Dynamic policy updates
On demos, we get asked regularly about how policies are implemented with Fargate Defender. Policies are fully dynamic and are created within our central dashboard Twistlock Console or via the APIs rather than embedding them within your images. This approach provides security architects with control over applications leveraging Fargate, rather than relying on developers to properly implement a policy or potentially remove it. Additionally, as you modify policy over time there is no need to rebuild or redeploy your images.
As more companies adopt containers, managed container services or on-demand containers are certainly becoming a prominent choice at the enterprise. Security for these services are just as important as cluster-based approaches — even when you don’t manage the virtual machine. Twistlock recognizes the need for an easily-deployable security solution and Fargate Defender provides exceptional protection through process protection, network access control, and cloud native application firewalling. You can now deploy your Fargate security as efficiently as your deploy your containers.
To learn more about AWS Fargate, check out our AWS Fargate 101 blog post.
- Twistlock Platform
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
What Integrated Security Really Means — and Why It MattersRead the Blog
A DevOps Approach to Compliance: What It Really Takes to Build Compliant AppsRead the Blog
CISOs: 5 Essential Features in a Cloud Native Security PlatformRead the Blog
Making CI/CD Fast and SecureRead the Blog
Leveraging Webhooks for Security Alerts with TwistlockRead the Blog