Prioritize the greatest risks and reduce the mean time to respond with Exposure Polygraphs

Lacework® is on a mission to prioritize risks that pose the greatest threats to customers. Today, we take a big step forward: Lacework is introducing exciting new capabilities for cloud attack path analysis. By combining exposure path visualizations with data about what’s actively happening in production, the Lacework Polygraph® Data Platform empowers customers to easily prioritize the most impactful attack vectors in their unique cloud environment. Organizations can easily and accurately pinpoint risks, collaborating across teams to investigate and remediate from a single source of truth.

The power of attack path analysis

Given the complexity of cloud environments, attackers seeking to compromise a system will look for the path of least resistance. They lurk within these complex spaces, waiting for just the right moment to exploit disparate risks: vulnerabilities, exposed secrets, misconfigurations, excessive privileges, internet exposure, and more.

Attackers rarely use a single loophole to breach a system. Instead, they often take advantage of multiple, successive risk factors. By following a series of risk factors, attackers discover an exploitable path to sensitive assets and data.

Attack path analysis is essential to uncovering and preventing this malicious behavior. With our new capabilities, Lacework helps users track which assets an attacker could target when they enter a cloud environment — as well as why the attacker has targeted those assets.

Here’s how it works. Lacework leverages our platform to show possible exposure paths within a cloud environment by correlating multiple risk factors — vulnerabilities, network reachability, misconfigurations, secrets, and identity and access management (IAM) roles — from sources including configuration data, activity data (CloudTrail), and runtime data. With this information, Lacework creates visual Exposure Polygraphs that tie together the risk factors to illustrate potential attack chains.

Exposure Polygraphs are made available as alert context. By clicking on an alert, users can see existing tabs (e.g., details, investigation, events, related alerts, integrations, and timeline), plus a new tab that shows the Exposure Polygraph. The Exposure tab displays details about host and container reachability, critical vulnerabilities, exposed secrets, misconfigurations, and more.

Exposure Polygraphs are also used to prioritize vulnerabilities. Lacework uses the graph to determine if a host is exposed to the internet, and then includes that context in our Host Vulnerability Risk Score, as well as making it available as a filter for custom prioritization.

By providing such a wealth of information, Exposure Polygraphs make it simple for teams to understand the connections between their most vulnerable assets, allowing them to look at the opportunities from an attacker’s perspective. Most importantly, this knowledge helps teams take action to reduce the risks that pose the greatest threat in their environment.

Attack path analysis meets anomaly detection

Alerts with Exposure Polygraphs are powerful because they combine attack path analysis with our best-in-class anomaly detection capabilities. While other vendors offer point solutions for attack path analysis by highlighting potential cloud security risks, Lacework goes farther.

We are the only platform that offers automatic anomaly behavior detection (without requiring endless rules) and exposure path analysis as part of our context-rich alerts. With our data-driven approach, all teams (including posture management, incident response, and security) receive a visualized single source of truth that helps them more effectively secure their environment.

To capitalize on this combination of features, customers start with our base CSPM product. The more capabilities they enable, the more detailed their graph will become. For example, a customer with a CloudTrail integration will see CloudTrail data in the graph. Similarly, agentless workload scanning adds vulnerabilities and secrets to the graph. If customers have deployed agents, Lacework will also correlate data from workload context to pinpoint exactly what risks exist in their unique environment.

It all boils down to how Lacework uses data to provide insights. By leveraging the config data from our platform and audit logs to deliver attack path analysis, Lacework enables organizations to prioritize risk-based remediation and alert investigation. The more data we can ingest, the more information we can uncover, and the more attackers we can help you stop.

Attack path analysis in action

To underscore the necessity of strong attack path analysis, we’d like to share a real-life example. It highlights how an attacker can exploit multiple risks and compromise the most important parts of a user’s cloud environment.

In this scenario, the attacker’s end goal is reaching the Jenkins controller within the front end of a classic three-tier application that’s running in Kubernetes. Here is the step-by-step process — the attack path — they use to get there.

1. Use the Log4shell vulnerability to establish a reverse shell to the vulnerable application. The front-end web app in our example has the Log4j/Log4shell vulnerability, which allows an attacker to get a reverse shell. Once the attacker establishes this, they can control the application frontend.
2. Perform reconnaissance and find other interesting destinations within the same environment. Now that the attacker has a foothold, they will want to see what else is around them: how can they move laterally to exfiltrate or infiltrate other parts of the environment? As they look around, they can identify one interesting destination in particular: the Jenkins worker.
3. Leverage instance privilege to use AWS CLI with EC2 Instance Connect to inject a public SSH key. Everything that the EC2 instance can do is managed with IAM privileges. Often, developers don’t know exactly what privileges an instance needs to work, so they’ll grant excess permissions — which gets the application to work, but also enables the front end to do other things in the cloud environment. The attacker can implicitly utilize these privileges using the AWS command line interface to interact with the AWS management plane. In this case, the attacker leverages EC2 Instance Connect to inject short-lived SSH keys, which are temporary keys that allow users to remotely log into cloud instances.
4. Establish a persistent shell on Jenkins worker using the injected SSH key. Jenkins is a popular code build tool that developers use to construct a new version of an application and push it out to production. Since a Jenkins worker needs to communicate with so many parts of the environment, it has ample avenues for lateral movement. Once the attacker injects that SSH key and jumps on the Jenkins worker with the newly pushed key, the attacker is no longer dependent on the vulnerability. Essentially, the attacker has created a new SSH key — one that does not disappear after 60 seconds. Even if someone were to patch the vulnerability, the attacker would still have access to the environment.
5. Install Hydra and brute force to Jenkins controller. With the new SSH key, the attacker has a real foothold on the environment, which means they can download tools like Hydra onto the Jenkins worker and use that to brute force get the credentials into the controlling member of that group. The Jenkins controller is the crown jewel. Now, the attacker has the keys to the kingdom. They can get database access, create new users in AWS, or mine Bitcoin, to name just a few. Anything is possible.

With attack path analysis, it’s possible to see the successive steps that an attacker could take to exploit an application and reach the crown jewel within a given environment. Posture management or security operations teams can start by identifying the most important part of that environment — the Jenkins controller. Then, using attack path analysis to map risk, the teams can take measures to prioritize risk-based remediation and actively watch for exploits before they become a problem.

Next steps

The above scenario is just one of many situations where an attacker can tie together multiple risks to exploit a cloud environment. Stay tuned for a follow-up blog post that details the three primary use cases of this feature, exploring how these attack paths help security teams increase their prioritization and remediation abilities from a single platform.

Attack path analysis capabilities described here are generally available today. This feature is for Amazon Web Services (AWS) environments only. To learn more about these features and others, check out our blog or get started.

Any unreleased products, features or functionality referenced in this blog post which are not currently available may not be delivered on time or at all. Product roadmaps do not represent a commitment, obligation or promise to deliver any product, feature or functionality, and customers should not rely on them to make purchase decisions.