Unifying Threat Detection for Cloud and Containers to Reduce Risk Using Sysdig

By Vicente Herrera, Product Manager at Sysdig

Implementing effective threat detection for applications in the cloud requires visibility into all aspects of your infrastructure and workloads.

Your application stack is composed of a number of elements: hosts, virtual machines, containers, clusters, stored information, and input/output data streams. When you add configuration and user management to the mix, it’s clear there is a lot to secure.

As you move applications to the cloud, you can expect to increase development speed, performance, scalability, and availability. You’ll also gain access to new kinds of capabilities like AWS Lambda functions and AWS Fargate deployments.

By taking advantage of the services offered by Amazon Web Services (AWS), you’re freed to focus on the applications that drive your business.

AWS puts great effort into keeping its cloud services secure and to provide you with tools to improve your security posture. The reality, however, is that security in the cloud is a shared responsibility between AWS and the customer. This means that you, as a user, have to be vigilant and ensure you have the proper visibility and controls to safeguard workloads (increasingly operated as containerized apps) and data in the cloud.

In this post, I will highlight key aspects of both cloud and container security, risks you may encounter, and share best practices to help secure your infrastructure. I’ll also share how Sysdig’s cloud security platform, available on AWS Marketplace, helps you follow security best practices and simplify the work of securing your AWS account and workloads.

Sysdig is an AWS Partner that’s driving the secure DevOps movement, empowering organizations to confidently secure containers, Kubernetes, and cloud services. Sysdig has been validated for AWS Competencies in DevOps and Containers.

Securing Credentials and Cloud Access

Protecting access to your cloud accounts is a fundamental first step to protecting against unauthorized activity and threats. There are a number of ways that credentials can be exposed, such as connecting to unsecured wireless networks or having a laptop stolen. A common agreement among security specialists is that you should design security by thinking your credentials have already been compromised.

By setting up multi-factor authentication (MFA), users will require two or more methods of verification to gain cloud access. MFA is a simple best practice intended to add an extra layer of protection on top of username and password.

Beyond using MFA for a standard web console login, it’s important to establish this security measure for command line interface (CLI) credentials stored in the .aws/credentials file. AWS has documented how to implement MFA for CLI authentication. This security measure is something that’s often overlooked, or considered prohibitive, but is critical to reducing risk, especially as more cloud operations are CLI and API-driven.

Implementing Proper Permissions

Security-conscious organizations are increasingly adopting and enforcing the principle of least privilege. This means you grant only enough permission and access for a user to perform the tasks required for a particular job or role.

Least privilege helps reduce the risk of attack by gaining access to critical systems or sensitive data through a low-level user account or application that’s too permissive.

As a best practice, you should create users with the least number of privileges required. Just as important is for you to restrict the ability to create new users or modify credentials, permissions, and other security settings.

Along the same lines, you should avoid using the root account for daily activities. This access should be considered most sensitive and kept protected.

For protecting workloads, setting up the most restrictive virtual private cloud (VPC) and networking configuration is essential to prevent unsanctioned communications.

In addition, if you’re using Amazon Elastic Kubernetes Service (Amazon EKS), you should take care in managing users and identity and access management (IAM) roles for your cluster. For instance, the user with permission to create clusters has a special consideration and can add other users to the role-based access control (RBAC). It’s best to use one specific user for the creation and RBAC configuration.

Finally, good hygiene around credentials for former employees should be practiced. This means identifying and removing unused users and credentials.

To learn more, check out AWS security best practices for IAM and permissions.

Monitoring Cloud Service Activity

Beyond access and permissions, keeping track of account and service activity across your cloud infrastructure helps you proactively identify and remediate unexpected or unauthorized activity. Failing to quickly address a threat could have major consequences.

To help you with visibility into the activity across AWS accounts, AWS CloudTrail can be enabled to log activity on your AWS account. CloudTrail will, for instance, record actions taken through the AWS Management Console, AWS Software Development Kits (SDKs), command-line tools, and other AWS services. This event history is extremely useful for resource change tracking and security analysis.

You can integrate CloudTrail data with Amazon CloudWatch, and integrate with an Amazon Simple Notification Service (SNS) queue to help with validating events against your security policies. This helps you to cut through the noise and notify the right users in your organization.

Protecting Workloads

If you’re operating with containers and Kubernetes in the cloud, implementing security checks from development through production is an important responsibility for AWS users following the Shared Responsibility Model. There are several practices that provide visibility and protection to help protect your workloads.

Scanning Images for Vulnerabilities and Misconfigurations

Scanning your container images prior to running in production is a best practice for managing risk. Image scanning helps by detecting known vulnerabilities and misconfigurations that open the door to security breaches and exposure of confidential data.

Performing vulnerability scans in development is a key practice that embodies the “Shift Left” practice gaining momentum with DevOps teams. This means finding and addressing defects early in the software delivery process to prevent them from coming back to haunt you later in production.

When integrated with AWS container services like Amazon Elastic Container Service (Amazon ECS) and EKS, Amazon Elastic Container Registry (ECR) provides built-in scanning capabilities to analyze container images and provide you with a list of scan findings.

In addition, third-party solutions like Sysdig deliver image scanning for vulnerabilities that can be deployed in CI/CD pipelines and perform inline scanning without requiring images to leave your cloud account. Critical checks include analyzing operating system (OS) packages, third-party libraries, and Dockerfile configuration issues, as well as checking against compliance standards like PCI and NIST.

Beyond image scanning, with ECR you can activate image tag immutability to prevent reusing tags with images. This helps ensure an image verified during the CI/CD pipeline will not differ from the image deployed in a container cluster, bypassing image scanning security checks.

Detecting and Responding to Runtime Threats

Once in production, there is a wide range of activities and issues you should continue to be diligent about detecting to make sure your workloads and data are secure. Many of these threats are human-originated actions happening in real-time, or zero-day threats, that practices like image scanning cannot help you resolve.

The practice of cloud service monitoring with CloudTrail as described above fits within this category, especially as it relates to monitoring activity for solutions like Amazon Relational Database Service (Amazon RDS) or Amazon Simple Storage Service (Amazon S3) buckets. You’ll want to recognize when something is happening that’s not following your established policies and expected behaviors.

For containers and Kubernetes, observing and filtering activity can help you quickly address runtime behavior that’s deemed suspicious. You can achieve this by tapping into data sources like event logs, system call data such as that provided by the Sysdig solution and open source Falco, as well as Kubernetes audit logs.

Armed with the right information and context, you’ll be able to spot and stop runtime activity that may cause harm to your applications, data, and business.

How Sysdig Helps

Sysdig’s cloud security platform for AWS builds upon the practices and solutions described above and helps you follow security best practices that will simplify the work of securing your AWS account and workloads.

Cloud Security Posture Management and Compliance

Sysdig provides cloud security posture management (CSPM) to help you continuously assess the state of your cloud security. It performs static configuration analysis of your cloud infrastructure based on Center for Internet Security (CIS) benchmarks.

Sysdig reports on misconfigurations and offers guided remediation steps to help you address what should be changed. To help you measure progress, a global score quickly tells if your posture is improving or if an increasing number of assets are being exposed.

By checking the configuration of your environment, you’ll know if your IAM policies are secure, see what S3 buckets in your account are exposed to the public, and understand things like which VPCs allow ingress traffic. The CIS standard also provides details on how to remediate issues found.

Threat Detection Based on CloudTrail

To identify potential security events, Sysdig analyzes AWS CloudTrail audit log events against a rich set of security rules based on open source Falco. A comprehensive Sysdig Cloud Best Practices default policy will warn you about most of the issues covered earlier in this post, including:

• Inline policies allowing all commands.
• Accounts without MFA activated.
• Access to the root account.
• Public Amazon S3 buckets.
• Interactive shells in containers.
• Disabling security features like AWS CloudTrail or AWS Security Hub.

Figure 1 – Cloud and container security visibility with Sysdig.

Amazon ECR and AWS Fargate Image Scanning

You can configure the Sysdig solution to automatically scan all images pushed to an ECR repository in your AWS account for vulnerabilities and Dockerfile best practices. You can trigger alarms if vulnerabilities are found, and even block them from deployment by using a Kubernetes admission controller.

In a similar way, Sysdig will scan all of the images requested to run as AWS Fargate tasks, whether they come from your own ECR, other private registries, or any public registry like Dockerhub. This ensures you always have a vulnerability report on all running containers, no matter the underlying technology.

Cloud Workload Protection

Cloud security is the door protecting your workloads from being compromised. With this in mind, you can also implement Sysdig as a cloud workload protection platform (CWPP) to unify application security with cloud service security.

For example, Sysdig Secure offers a number of CWPP capabilities:

• Kernel real-time runtime threat detection that can detect activity such as a terminal shell in a container. It captures all system calls taking place in a time interval when the detection policy was triggered, even if logs are deleted or the container is destroyed.
• Kubernetes audit log threat detection with rules that detect conditions like attaching ClusterRole with wildcard permission creation, executing an attach or exec command on a pod, or creating an ingress without a full TLS certificate.
• Inline image scanning that integrates to CI/CD pipelines and scans vulnerabilities without sending image contents outside of your control.
• Admission controller that enforces vulnerability scanning on deployed images and prevents deployments if the scan doesn’t comply with the policies.
• CIS AWS Foundations, and Linux, Docker, and Kubernetes benchmarks periodically check for misconfigurations in your hosts and clusters.
• Compliance policies help you adhere to controls as defined with standards like PCI DSS, SOC2, NIST 800-53 rev4, and NIST 800-53 rev5.

These features are intended to help you gain a deep level of visibility for workloads. When combined with CSPM, the result is a single view across cloud, workloads, and containers that will help you identify and respond to threats faster.

Conclusion

In this post, I’ve discussed some of the areas that, if left unaddressed, can pose a risk to your business when operating in the cloud. Beyond using the secure services offered by AWS, it’s just as important to implement practices within your organization to secure not just your cloud infrastructure, but also your workloads.

AWS, together with partners like Sysdig, provides you with tools to detect and stop potential attackers and protect your business.

To help AWS users get started, Sysdig has launched a Free Tier of its cloud security tools. It provides “free forever” security capabilities for a single cloud account that includes:

• AWS CloudTrail detection rules based on open source Falco to identify suspicious cloud configuration events.
• AWS CIS Benchmark checks to help you manage your cloud security posture.
• Image scanning for ECR and AWS Fargate to identify container vulnerabilities.

Visit AWS Marketplace to get started with the Sysdig Free Tier. To learn more, visit Sysdig’s AWS website.

The content and opinions in this blog are those of the third-party author and AWS is not responsible for the content or accuracy of this post.

.

.

Sysdig – AWS Partner Spotlight

Sysdig is an AWS Partner that’s driving the secure DevOps movement, empowering organizations to secure containers, Kubernetes, and cloud services.

Contact Sysdig | Partner Overview | AWS Marketplace

*Already worked with Sysdig? Rate the Partner

*To review an AWS Partner, you must be a customer that has worked with them directly on a project.