[0:00] Welcome everyone to our webinar, “Think Like an Adversary: Identify and Visualize Potential Breach Points with Attack Path Analysis.” During the webinar we’ll present a live demonstration of the Attack Path, which is a dynamic interface that illustrates potential vulnerabilities through attack paths. We’ll discuss the fundamentals of the Attack Path and its benefits...
[0:00] Welcome everyone to our webinar, “Think Like an Adversary: Identify and Visualize Potential Breach Points with Attack Path Analysis.” During the webinar we’ll present a live demonstration of the Attack Path, which is a dynamic interface that illustrates potential vulnerabilities through attack paths. We’ll discuss the fundamentals of the Attack Path and its benefits in your company’s security strategy, provide a detailed examination of its components, and discuss reachability and exploitability. My name is Raviv Vinnik and I’m a product manager at OX Security.
[0:41] Hey everyone, my name is Itai Ganzer, I’m an engineering manager here at OX Security.
[0:49] So Itai and I will run the webinar together. We’ll start by providing some background about the Attack Path and the challenges customers face that it addresses. In the last years there has been an exponential growth in software supply chain attacks, for a few reasons. First, attackers have become more skilled and the tools they use for initiating attacks have become more sophisticated and more easily available. Another important reason is that AppSec teams find themselves overwhelmed by the complexity brought on by rapid development cycles and the nature of modern applications, including APIs and cloud environments. So that’s the challenge; now let’s get to the solution.
[1:49] The solution required is a systematic, actionable approach for understanding and mitigating attacker behaviors and techniques. The solution Itai and I will go over provides the ability not only to see but to really understand the attack paths that attackers might exploit, and this involves adopting an attacker mindset. It enables AppSec teams to differentiate between critical issues, less critical issues, and issues that are merely hygiene. The solution is, of course, OX Security’s Attack Path. It integrates applications, APIs, and cloud context with the function call graph. The Attack Path addresses security concerns across code, APIs, and cloud by visualizing and mapping those attack paths and providing evidence that lets users view security from an attacker’s perspective and prioritize critical, reachable issues. Now I’d like to hand over to Itai to tell us about the most common challenge we heard during our discussions with customers and prospects.
[3:10] Thanks. One of the most common challenges faced by application security teams today is getting the development teams to acknowledge and address security issues. Often developers underestimate the risk or dismiss the issue based on information that isn’t always visible to the application security team. When both development and security teams have complete insight into the application life cycle, it promotes transparency and accountability for both. This enables AppSec teams to provide concrete evidence of the severity of each security issue, facilitating a more collaborative approach to resolving them.
[3:55] Thank you. Now we get to the live demo of the Attack Path, and I’ll show my screen, the OX Security issues page. To make the demo more interesting, I’ll filter by code-to-cloud exposure “directly exposed to the internet,” and also filter by exposure “API exposed.” I see a list of 24 issues, and I’ll pick the first one and click on its Attack Path tab, and open it in full screen. You can see the issue name on the left, below it the description and the recommendation, and in the upper part actions that can be triggered on this issue directly from this page, such as opening a ticket, sending a Slack message, and more.
[4:46] I’ll start with a quick scan of the attack path left to right, a high-level overview, and then we’ll do a slower deep dive of the components. On the right of the issue node we can see a node for the application, a node for the APIs exposing the issue, a node for Amazon ECR, nodes for Kubernetes clusters, nodes for cloud accounts, the node for the internet, and next to it the exposure status of the issue, and a node for SaaS services. That was the quick scan; now let’s deep dive.
[6:16] For the issue node, we can see the issue category, it’s an open-source security issue, its severity is high, and the issue node is funneled by info nodes. To the left there’s a node called detection and response; let me expand it. It provides information about the issue owner and commit-related information, such as the file that was committed, when, and by whom, and you can click to see more details, plus when the issue was first seen by OX, here about two months ago. Above the issue node we have the severity-factor nodes; this issue has several severity factors grouped by reachable, exploitable, and damage, and you can click each to get its description. A red eye icon pointing up tells us these are severity factors that increase the severity; factors that reduce it would show a green icon pointing down. Below the issue node we have a node called intelligence nodes (Itai gets the credit for the name), which shows a lot of intelligence about the issue, varying by category. This is an open-source security issue, so we have the vulnerabilities, showing the CVEs with the highest severity first, a node for the library and information about it, nodes for compliance (click each for the standard, category, and control), and the items of the OSC&R framework and CWE items. When we designed the Attack Path, we made sure the user has all the information required to understand and resolve the issue, in one page, without navigating between many tabs, and that the most important things show first.
[9:22] On the right of the issue node we have the node for the application. You can see the repo name, here it’s the famous Juice Shop repo, the business priority of this application, here 100, very high, and the main language, here TypeScript, and you can click the language node to see all the languages in the repo. There’s a node called process data that tells us this repo processes PII and payment-related information. By gathering all this, business priority, processed data, and soon the APIs, we’re actually creating a threat model of everything that impacts the application and the issue, and we’ll have future webinars elaborating on threat modeling. We also have a “link to the app” node that navigates to this specific application in the OX application page.
[10:48] On the right of the application node we have the nodes for the APIs that expose this issue. For each API we can see the port, name, the input method, the framework, here it’s Express JS, the file in which the API definition resides, and in this example two functions that are executed when this API is invoked, with links to their location in the code. Above the API node there’s a button called call stack, which shows the function call stack from the API definition via the handler function to the location of the issue in the code. This is what we at OX call evidence: evidence that this API exposes the issue, and where it’s defined and located in the code. This is helpful when AppSec teams collaborate with development and other teams and need to understand together why this specific issue is important to fix and where. For this issue we have several APIs exposing it, and there’s also a gray APIs node giving information about all the APIs in the repo, including ones that don’t expose the issue, with a link to the API BOM.
[12:55] Thanks Raviv. As mentioned, the Attack Path visualizes the way the issue travels from the code to the cloud. The first step after the code information is the image container: we match repositories into container images. In this example we found that this Juice Shop repository is built into an image with the same name residing on this Amazon ECR account, and we provide a link to the ECR console. Here we have only one image matched, but in general a repo can be built into multiple container images on multiple registries, and we’ll show all of them. If any of you have questions, please write them in the chat and we’ll address some by the end. Some advantages of matching container images to repositories: we can match SCA issues where we found the vulnerable dependency in both the container and the code and merge them, so you solve both in one place and reduce the number of issues; we can have issue owners for container security issues based on the repository, making the owner more accurate; and it lets you better prioritize container security issues based on reachability.
[15:48] To the right we have the Kubernetes, in this example EKS, nodes, where we found this container image deployed as a workload. In this case we have two clusters, one development and one production. It’s very common for our customers to use multiple Kubernetes clusters for development, staging, and production. If you click the cluster, you get its name, the cloud, the region, namespace, and the specific Kubernetes platform, here EKS, with a link to the cluster in the AWS console. Expanding the Kubernetes node gives a list of workloads; here we have a deployment named Juice Shop, with a link to the console, using the Juice Shop image with a specific hash and tag. We add severity factors to each workload; in this example this workload has an internet-exposed API, is running in an internet-exposed cluster, and is a long-running workload. When the workload has an internet-exposed API, we also provide information about the Ingress that exposes it to the internet, with its name, a link, and related severity factors.
[18:05] The icon you see next to the data is used to copy the property information when you want to share it with development or other application security members; you can just copy the property value and share it. The ability to know which repo is built into an artifact running in a specific Kubernetes environment provides clarity, and it helps you know whether issues that were fixed really reached production, or are still waiting in dev or staging. So this is a really important capability for application security teams, to track issue fixes along the pipeline.
[19:11] Those two Kubernetes clusters are deployed in an AWS account; we can see the account ID, the DNS used to access the clusters from outside, and the region, and if you expand, a list of load balancers that route traffic into this Kubernetes cluster, each with its DNS name and listening port. Next to the Kubernetes cluster nodes and the internet node, we provide network analysis. In this case this workload running in this cluster is directly exposed to the internet. If the workload itself were not exposed but another workload in the cluster was, we’d write that this is an internet-exposed cluster. Before the internet node we have a summary of the internet exposure of the overall issue; in this case it’s an internet-exposed issue, exposed by an API as Raviv mentioned, and the workload is also exposed directly to the internet. To the right of the internet node you can find all the SaaS applications accessed from the application, and clicking each gives concrete evidence in code for why we found this SaaS service to be used, whether it’s a dependency we import and use, or direct API calls. To summarize, the graph offers a complete view of a security issue from its origin in the code, through the application, container image, Kubernetes workloads, exposed APIs, and internet exposure, giving application security teams comprehensive information for prioritization and solid evidence for the development teams.
[21:42] That’s amazing. To add to what you mentioned, here we see the SaaS services of this application, and I want our audience to know we also have a SaaS BOM page that shows all the SaaS across the entire organization and all applications. We had a webinar about it about three weeks ago, the recording is on our website, and the SaaS BOM feature is available to all our customers. Before we answer a few questions, I want to mention our platform. OX Security has an open PLG platform, which means any of you can go to the OX Security website and either book a demo or start a free trial. After you click Start Free, you create your account, select your source controls to scan them, and get results of issues, each with a tab for the Attack Path. The attack path will show, before adding more connectors, information about the issue, application, and APIs as I demoed; to view the full attack path you need to define several connectors, which Itai will mention. You can also start for free even without connecting source controls, by exploring with demo data. Itai, can you elaborate on the connectors required for the full capabilities of the attack path?
[23:43] Yes. In order to get the full code-to-cloud reachability information in the attack path, you’ll need to connect your cloud deployment, in our case AWS, connect your registry or registries into OX, and connect your Kubernetes platform, in this case EKS, which is currently in beta and will soon be open to all customers.
[24:35] I’d like to highlight again that before those connectors you’ll still see the Attack Path tab with the basic attack path I demoed; to see the full version with the cluster and cloud information you’ll need to add the connectors Itai mentioned. I see we have a few questions. You mentioned the APIs exposing an issue; can you elaborate on where else in OX this information is available?
[25:13] Sure, excellent question. When I demoed the attack path I described the API nodes, with the APIs exposing the issue and a link to the API BOM page, but there’s another place: on the right of the attack path there’s a tab called APIs, with a list of all the APIs that expose this specific issue. That’s useful for people who like looking at lists and grids, especially when the list is long. And I’ll open the attack path again. We did a webinar three weeks ago about the API BOM; I’ll click the link here, and since we’re looking at an issue connected to the Juice Shop application, I’ll be navigated to the API BOM page filtered to Juice Shop, with a list of all the APIs discovered by OX, including those that expose issues. The circles represent groups of issues by severity, meaning each of those APIs exposes issues, and you can click to get to the issues page. The API BOM also shows APIs that don’t expose any issues, because it should give visibility of everything we discovered and prevent what we call shadow APIs, giving the AppSec team full awareness of the APIs in their organization. I see another question: you demoed a cluster with one workload, what’s the experience if we have a cluster with several workloads? Itai, would you like to answer?
[28:05] Sure, let me find an example. As we mentioned, we show the list of workloads when you expand the Kubernetes cluster node. In this example I have two workloads, two different deployments, one named “bank website deployment” and the other “bank deployment no service.” One is exposed to the internet and the other is not. If we had more, you could scroll down and see all the relevant workloads. In this specific case only one image is running in both, but as mentioned a repository can be built into multiple images, and then we’d have the list of images here and all the workloads belonging to all the images shown in a list.
[29:27] That’s very cool, and a good experience, because if you have three, four, or five, you want the user to first see it consolidated and then expand to a longer list to keep it usable and friendly. I mentioned the API BOM and said a few words about the SaaS BOM that we demoed in another webinar; I want to note again that OX has the SaaS BOM feature, an inventory of all the SaaS services discovered by OX, which we use in the attack path and also show at the organization level. By the way, the API BOM and SaaS BOM are under this menu, and we also have a BOM overview. So we’ve reached the end of the webinar. I’d like to thank Itai for joining me, and you, the audience, for participating.
[30:50] It was a pleasure. I hope you enjoyed this webinar and that it provided value, and I hope to see you in the coming webinars we’ll do. Have a good night or good day depending on where in the world you are. Bye everyone.
[31:06] Thanks for joining.
