The Rise of the Attack Path

In our previous post about the evolution of cloud security, we discussed the correlation of multiple data feeds into a unified cloud security platform, and the overall cybersecurity industry trend towards “platformization.” But what’s the end of an attack path?

Simply put, an attack path shows the connections - physical or logical - that a threat actor would need to traverse to get from outside your environment to something of value. Usually, that’s data. It might be customer data, corporate intellectual property or some other data store. The most important and highest priority attack paths will be those that connect to the highest value data. You’ll often hear the phrase “crown jewels” for that high value data. 

Security experts use attack paths to help identify threats as they pass through the traditional chain- starting at the internet and going through the gateway and virtual machines to exploit the vulnerabilities and reach the data stores, whether object stores, databases or other. These attack paths highlight the connected infrastructure and identity resources.

For instance, in the example above, an attacker coming from the Internet would pass through multiple layers of network infrastructure before connecting to an application on the virtual machine. The red exclamation point in the graph indicates some security issue, likely a CVE that a threat actor can exploit to gain access to the operating system of the virtual machine. From there, the threat actor can leverage the service account, probably via the cloud provider service plane (something like the instance metadata service), and connect to the valuable data contained in the storage buckets. So, to confirm, the attack path is:

• Internet ->
• Network infrastructure ->
• Application ->
• CVE ->
• Virtual machine (operating system) ->
• Service account ->
• Storage bucket

This is pretty similar to the attack path in a notable data breach from 2019, referenced in the evolution of cloud security post.

 But all of this misses one big concern - direct data access, presented front and center through APIs.

The Phantom Attack Path - APIs

APIs enable communications with ubiquitous mobile apps. APIs are how connected devices and IoT talk to central server and data infrastructure. And APIs are how organizations are adopting AI.

So APIs are very often exposed at or near the edge of a network, because they need to be. From an attack path and cloud security perspective, APIs live on a compute platform (server, virtual machine, serverless function, container) and are logically present there, to layer into a complex attack path,

However, APIs are also a shortcut to the data. They talk directly to the datastores via applications. They pass through quietly, creating a phantom attack path that flows through all the other layers of protection (network controls, identity, etc). And although cloud security platforms have come a long way, there still aren’t controls in the infrastructure to be aware of or mitigate these risks.

The figure above shows the phantom attack path, starting from the internet gateway, moving through network layers and skipping straight to the application endpoint before passing through the OS/APP layer and briefly touching it on the way to the data bucket, but bypassing other cloud infrastructure components. So to confirm, the attack path via the API is:

• Internet ->
• Network infrastructure ->
• API (via application) -> 
• Storage bucket

This is a more direct attack path, requiring fewer TTPs like lateral movement. All that a threat actor needs is to find a vulnerability in the API, such as a lack of authentication or broken authorization, the top 2 causes of API-based data breaches. Both of those are vulnerabilities that CNAPPs and other security platforms are blind to, until now.

Merging the Phantom with the Attack Path

Cloud security has come a long way since the early stages in the mid-to-late 2010s. And unfortunately, so have cloud attacks. Attackers now understand cloud, and lateral movement techniques, leveraging cloud identities, dependencies and connections between resources.

Cloud security tools are evolving to combat these risks, but given the scale and pace of change, it’s often hard for security teams to keep up. Attack paths can highlight blast radius concerns, vulnerability scoring can help prioritize higher risks, and CNAPPs are picking up additional capabilities like DSPM that catalogs data stores, classifies the data in each location, and assesses its relative risk and importance.

Organizations need to see and manage the risks around both attack paths. We’re currently tabulating statistics, but we estimate the impact of each attack path might be about the same.

Where do we go from here?

It’s time to merge the phantom attack path - direct access to crown jewel data via APIs - with the attack paths that cloud security professionals are using every day. That’s why we were so proud to announce our partnerships with other cloud security platforms -  Wiz first - and the ability for customers of those partners and FireTail to see API risks in both a unified attack path in the platform. It’s truly the best of both worlds, getting visibility into the cloud attack path, and the API attack path for full awareness of the risks around your data.

Do you want to see both attack paths?

As we roll out the merged attack path, we’re working with select organizations who are customers of FireTail and our partner CNAPPs or other security products. If that describes you, and you’d like to join that preview program, please contact us.