Introducing Managed Policies for Sysdig Secure

By Nigel Douglas - AUGUST 24, 2022

SHARE:

Facebook logo LinkedIn logo X (formerly Twitter) logo
Managed Policy Life Cycle

Whether you’re learning cloud-native workload protection for the first time or running all your microservice workloads in production, you probably already noticed that cloud-native security is much different from security design used for traditional monolith applications. The dramatic increase in complexity and the evolving threat landscape make cloud and container security even more critical and harder to manage. Maintaining your Falco rules and security policies when there’s a change to the application lifecycle is a real challenge for many users.

Terminal shell in a container’ is a simple policy condition that requires very little tuning. The only reason you would change this rule is if you were excluding specific workloads or namespaces from detection. However, runtime threats continue to change in complexity, and assuming we have to make constant changes to policies to prevent these new runtime threats across dozens of existing policies which are potentially reflective of hundreds of workloads in production – this quickly becomes a tedious task.

managed policy Sysdig falco rule
Falco: Alert only for each successful spawn of a shell in a container, adding appropriate event type & direction to the condition

Sysdig Secure, which utilizes open source Falco under the hood, provides an intuitive user interface for DevOps or DevSecOps engineers to quickly implement best-in-class rules to prevent malicious behavior in your Kubernetes Clusters, Hosts, and Cloud environments. However, many engineers would turn on a rule and would feel assured that this rule will provide total security going forward. While that is true in many cases – ie: policies that don’t require many changes – adversaries are continually improving their methods of attack, and therefore, our policies should be updated in line with these behavioral changes.

Solving the problem with Managed Policies

That’s why Sysdig is announcing an all-new managed policy feature for Sysdig Secure!

Locked Policy

When new managed rules are created, they will appear within the assigned managed policy. You no longer need to check for updates to existing policies, and you can rest assured that the Sysdig Threat Research Team is updating those policies to keep you protected. The goal is simple: How can the Sysdig Threat Research team get default rules and policies to end-users automatically, while respecting their individual configuration choices and still maintaining as few disruptions as possible?

How does the new managed policy look?

Policy List
Runtime Policies: Date and Time of Policy Update is visible on the right side pane

Managed Policies can be identified by the locked padlock icon, and while they cannot be modified, they can be copied to make your own custom policies if needed.

Sysdig added a new managed policy rule to the existing runtime threat detection ruleset to identify attempts to find GPG private keys.

GPG allows you to encrypt and sign your data and communications; it features a versatile key management system, along with access modules for all kinds of public key directories. Assuming an attacker had gained access to your systems, a common task they would perform would be to search for other credentials. Once found, they will try to use those GPG keys to infect other systems or move closer to their goal. Without knowing how the rule was configured, you would now have this rule enabled within our existing managed runtime threat detection policy.

Within the Sysdig UI, go to ‘Policies’. Under ‘Runtime Policies’, search for ‘sysdig runtime’ in the search field. Since it’s a new release, you can see that the rule was updated only 14 days ago (as of the time of writing this blog).

If you scroll further through this policy, you can see that the GPG context has been added.

Rule Conditions
Falco rule with condition, output, description and tags – as seen as seen within the policy view

How did users manage policies in the past?

Historically, users would have to manually check for similar changes to policies. Since Sysdig Secure provides a SaaS-first, API-driven architecture, end-users quickly receive rule changes without the need for specifying specific cron jobs.

Whether using Falco OSS or Sysdig Secure, users are given a set of default policies, with some also enabled by default. This is great in the sense that we immediately detect certain threat vectors out-of-the-box, however, the market has identified a clear requirement to detect new threat vectors as they are identified. The existing challenge is that end-users are responding too late to these threats, for instance with the Log4J critical vulnerability.

When solutions were addressed for common vulnerabilities via newly-created rules, these rules were not pushed to existing policies which could have quickly protected the end-user. The onus in this case was entirely on the end-user to enforce these new rules. Although default rules were updated regularly for finding new threats or false positives, if the rule is no longer part of a policy because it was noisy or obsolete, the end-user would not get those updates. This was the main driver for a managed policy approach.

Furthermore, there was no indication in the user interface that a rule was either added or updated, so if a rule was added it could change behaviors at any time, leading to confusion.
If there’s no indication that a new rule was created, users would likely end up not adding those new changes to their existing policy. We have also addressed this in the latest release, as seen by the update time of the managed policies. Users can now easily identify when the changes have occured, and confirm the new rule was added to a managed policy.

Policy Timestamp
Time reflecting change to managed policy


Recap on Managed Policies

The beauty here is that the managed policies generally lead to a low rate of false positive detections. In Sysdig Secure, policies are adjusted by a team of security analysts to identify the latest attack patterns executed by our attack actors. You can see how the alert was triggered, immediately excluding any potential false/positives from future detections via the ‘Insights’ view.

Policy Tuning
Sysdig Secure Tuner Suggestions to exclude Nginx images from triggering alerts in future terminal shell activity

Many DevOps engineers are ill-equipped for Day 2 security operations – once the application is initially deployed and stable. They require extensive knowledge of the Kubernetes Threat Landscape, and often don’t have adequate tooling to identify lateral movement from the latest MITRE ATT&CK conditions. An example of this is according to Sysdig’s 2022 Cloud-Native Security And Usage Report, 27% of teams use the root user account for administrative tasks.

CDR Report
REPORT. 2022 Cloud-Native Security And Usage Report

Sysdig Secure is a Cloud Detection and Response (CDR) solution capable of cloud-native threat mitigation. Whether you are looking for deeper visibility into vulnerability lifecycle management or limiting lateral movement via Kubernetes threat detection, you can test Sysdig Secure today with a 30-day free trial.

Get started in minutes without a need to provide a credit card.

Subscribe and get the latest updates