Securing AWS Fargate workloads: Meeting File Integrity Monitoring (FIM) requirements

Securing AWS Fargate serverless workloads can be tricky as AWS does not provide much detail about the internal workings. After all… it’s not your business, AWS manages the scaling of underlying resources for you. :)

While the security and stability of Fargate’s system is an inherent feature, Fargate follows a shared responsibility model, where you still have to take care of securing those parts specific to your application..

To protect CaaS environments like AWS Fargate throughout their lifecycle, we should cover all use cases. This includes cloud security, image scanning, runtime protection, cloud threat detection, as well as establishing a comprehensive audit trail if possible.

In this article, we’ll see how to secure AWS Fargate workloads with Sysdig from right to left.

A nasty security event happens

Let’s start by setting an example here.

We have our AWS Fargate workload tasks running with the Sysdig agent installed. A policy was triggered due to “Suspicious Filesystem Changes,” one of our out-of-the-box Falco runtime policies:

This policy contains rules for common suspicious activity. In this case, the rule that triggered the policy was Modify binary dirs.

The actual Falco rule looks like this:

- rule: Modify binary dirs
  condition: >
    bin_dir_rename and
    modify and
    not exe_running_docker_save and
    not user_known_modify_bin_dir_activities
  output: File below known binary directory renamed/removed (user=%user.name user_loginuid=%user.loginuid command=%proc.cmdline pcmdline=%proc.pcmdline operation=%evt.type file=%fd.name %evt.args container_id=%container.id image=%container.image.repository)
  description: an attempt to modify any file below a set of binary directories.
  tags: SOC2_CC7.1, PCI_DSS_10.2.7, SOC2_CC6.8, NIST_800-53_CM-5, SOC2, filesystem, mitre_persistence, NIST_800-190_3.4.4, PCI, NIST_800-53_SI-7, NIST_800-53_SI-4, NIST_800-190, NIST_800-53

If you take a closer look to the tags field, you’ll see how this policy is mapped to several compliance standards. Because this is a common check for File Integrity Monitoring (FIM), it is provided out-of-the-box by Sysdig.

For most compliance standards, FIM is a requirement. Taking the Payment Card Industry Data Security Standard (PCI-DSS) as an example, it specifies the following in its Requirement no. 11.5 : “Deploy a change detection mechanism (e.g., file integrity monitoring tools) to alert personnel to unauthorized modification of critical system files, configuration files, or content files.”

This policy alerts you about any data breach, coming from internal breaches, exploits of zero-day vulnerability, or malware. Having proper File Integrity Monitoring in place, even inside Fargate tasks, helps you achieve PCI compliance, and also makes you more secure and trustworthy.

Digging deeper into the issue

Let’s take a closer look at the information provided in the alert:

• agent.tag.aws-account-id 845151661675
• agent.tag.aws-container-image 845151661675.dkr.ecr.us-west-1.amazonaws.com/qa/secure-event-generator:0.1.5
• agent.tag.aws-fargate-cluster-arn arn:aws:ecs:us-west-1:845151661675:cluster/lugobad-stack-QASecureEventGeneratorCluster-yPudobodwok6
• agent.tag.aws-fargate-task-arn arn:aws:ecs:us-west-1:845151661675:task/lugobad-stack-QASecureEventGeneratorCluster-yPudobodwok6/1dddc34c883f4dd9b26b39af1a8b30be
• agent.tag.image-id sha256:1a8d6454ed77bd59f19d6204d453fceb8ceceefea432ce5da8796f21dd807071
• container.name QASecureEventGenerator
• process.name touch /usr/bin/2597de70-c942-4424-b039-5e15a86fd380

We can see that someone created a file under /usr/bin (process.name touch /usr/bin/2597de70-c942-4424-b039-5e15a86fd380).

From a particular Fargate task (arn:aws:ecs:us-west-1:845151661675:task/lugobad-stack-QASecureEventGeneratorCluster-yPudobodwok6/1dddc34c883f4dd9b26b39af1a8b30be).

Running in an ECS cluster of us-west-1 zone, in our 845151661675 AWS account.

With this kind of information, we could already continue investigation and manually check if other cloud assets on the same account have been compromised. However, this would be a tedious task.
Luckily, Sysdig Secure provides Unified Threat detection for both container workloads and cloud infrastructure, and we can take advantage of that to speed up our investigation. We’ll be able to use cloud security features like Cloud Activity Insights, and find out any suspicious activity related to this incident in just a few clicks.

So, after heading to the Cloud Activity Insights, and filtering by the name of the cluster…

Oops! Someone actually deleted it!

And that’s not a minor movement…

In the details of this event we can see who did it:

aws.user  badlugo

With the name of the user, we can fine-tune our search in the Cloud User Activity Insights section:

It is clear that this user is not behaving correctly. They have Logged in without using MFA in an environment where there’s a need for this particular security control access. They also have deleted a CloudTrail trail, which could mean they are trying to erase their tracks. And let’s not forget what we found out previously; they deleted a cluster!

We now have a very clear picture of what happened. And we can take actions like revoking user permissions on the cloud account, or re-enabling the CloudTrail trail.

Could this have been prevented?

At Sysdig, we continuously highlight how important it is to shift security left. By implementing security as soon as possible in our applications lifecycle, we can respond to security risks before they become a real problem.

Applying this principle to AWS Fargate workloads can be done by automating image scanning for images running on AWS Fargate tasks.

Had we done that in our example, we would have seen a big warning in the image scanning results. That is, our image violates one of the most common bad practices many developers (still) do: running the container as root.

Conclusion

We have seen how securing container workloads running on AWS Fargate tasks shares elements of container and cloud security.

AWS Fargate tasks need to be secured, as any other cloud asset. You need to keep an eye (or two) on your container workloads, independently of how they run (Docker, Kubernetes, Fargate). Threat detection is easier with hosts, nodes, and virtual machines, but it’s a little trickier with containers. And when it comes to workloads running on CaaS platforms, it’s a different challenge.

Sysdig brings the same ability to instrument system call policies and events, that has been proven rock-solid for securing containers, into AWS Fargate tasks. By being able to do things like FIM for PCI compliance inside AWS Fargate, you no longer have to worry about not meeting compliance if you choose to run your applications in a CaaS environment.

The ability to add context from the cloud provider into a unified timeline view is key to understanding which clusters, regions, and users are involved. Also, it maps a story that tells us what happened before, and after, the security issues.

We are going to be talking about Securing AWS Fargate lifecycle very soon. Join us to hear how you can confidently secure AWS Fargate environments with Sysdig Secure and AWS.

Want to try these features yourself? Request a 30-day free trial for Sysdig Secure. No credit card is required, and you’ll be up and running in just a few minutes!