Light in the Labyrinth: Breach Path Analysis for Anyone

I've got uh our next speaker for you, Parker Shelton, and I will let him take it away. Thank you. U and just a reminder, if you have questions, please go in to uh Besides SF uh look for Q&A and I'll be monitoring the questions and then we'll have time for a couple minutes of questions at the end. Thank you. Besides SF, Thesius really needed a map. So, let's brush up on some Greek mythology. Thesius, our brave hero, lands on the island of Cree to be sacrificed to King Minus' frightful Minotaur, living in a labyrinth constructed by the great inventor Datalus. The king's daughter, Ariadne, sees him ste off the ship, however, falls madly in love with him,

and she smuggles him a spool of thread with which to escape the labyrinth. Thesius finds his way to the heart of the maze, slays the minotaur, uses the thread to retrace his steps, and escape. Thesius takes Princess Ariadne back, and sails happily home to Athens. The end. As cyber defenders, we'd like to think we're the hero of this story, Thesius, winning the day. But from King Minus' perspective, an unknown actor entered his environment, disabled his defenses, and ran away with his most prized possession. But I actually think we're the most like datalus, having constructed a terrible, terrible, complex puzzle in which we're lost trying to find our way around our environments in the dark with the wrong

tool. These should have used a map. I love maps. Let's talk about a few real fast. This is the Sombake slab. One of the world's oldest maps. Imagine it's 4,000 years ago. You're the ruler of a prosperous little bronze age kingdom in Britany, France, and you want to immortalize your kingdom, and so you have some craftsmen go to town on some stone, and then you're forgotten. The map was not discovered until 1900 when it was acquired by France's National Archaeological Museum, and then it was forgotten again. It was lost in their basement until 2014. But if we dive into it a little bit, we can see even from these early examples of mapmaking, we can see some useful

things. The map is actually very accurate. It's topological. This is the terrain and the surrounding area that the king needed to defend. This is one of the most expensive maps in the world. This is the Voltz Mueller map. It was originally published in April 1507 and it's the first map known to use the name America. And in 2001, the only surviving copy was acquired by the US Library of Congress for about $10 million. It's not quite as accurate as the last map as we can see from what they thought of America at the time. And while that may be one of the most expensive maps, one of the most valuable maps is the map to the treasure

in your company. It's the map you should really care about. You have some sort of valuable data hidden away, maybe even behind a firewall. But regardless of segmentation, there must be ways to manage or administer your most secure systems. There must be ways to get to your most valuable data. Do you know what they are? Can you see the paths by which thread actors would attack you and your company? For example, do you have a bug in an internet exposed service that has credentials and a network position to talk to that database? The insight that you can gather here is a very valuable thing to your company. And I can make these assertions because my

team owns one of the world's most valuable treasure maps, the internal asset graph and breach path database for Microsoft. Now, before I continue, I stand on the shoulder of giants. I don't do this alone. Many folks have contributed the thoughts you're going to see presented here and the service and the code that we run, of which I'm actually one of the last and least experiences. But I joined the team last year and I'm here sharing with you today because I think these lessons are critically important for our roles in cyber security. You need a map of what you're protecting. That map must tell you what the terrain looks like around you accurately. And thread actors are going

to be constantly charting ways into and out of your connected systems and your environments, even if just a teenager named Thesius with a spool of thread. To be effective in cyber defense, your organization needs a treasure map. What does this map do for you? It allows you to understand how you can be attacked. Just as real world maps have infrastructure marked like highways or hiking trails and labels on them to help us understand how to move around, your treasure map needs to tell you how attackers would move around in your company. We call these either breach paths or attack paths. A breach path is just a sequence of steps that a thread actor may use to

infiltrate and to compromise a network or a system or once inside to move laterally or to elevate privileges. So then breach path analysis is the techniques that we use to scan the graph to identify and expose possible breach paths. The best way to think about breach paths is to think like an attacker. What would they do? How would they move? What are they going to do next? And so let's dive into some examples to think about how we can turn some of this adversarial mindset to our advantage. When you use the CLI or the portal to create an Azure function uh Microsoft serverless platform, you specify a storage account. Azure functions use that for several purposes

including potentially storing code. As you can see kind of in the documentation here, if you follow that link, you get a whole page called storage consideration for Azure functions that outlines several different ways that storage may be used by your function and includes the money quote. Important data such as code, access keys or other sensitive data can be persisted in that account. You must carefully manage access to the storage accounts used by function apps. problem is that in early 2023, this documentation didn't exist and it didn't have that quote in it. And Net Spy produced research and presented at Defcon 31 and at Besides Portland 2024 that write access to that storage account may allow a privilege escalation

and a compromise of the app service and the functions running on it as well as any identities associated with them. So that might look a little bit like this. that user can't directly access the function but can move laterally through the storage account. This is potentially privilege escalation. Another example is we find leaked credentials all the time and something like an X509 client certificate on a developer machine could lead to lateral movement or privilege escalation. If the thread actor is able to use that to log in to another application which itself has access to maybe your key management systems which themselves are going to have secrets and credentials in them and so on and so

forth. SSH keys stored on developer machines could grant access to your cloud resources or everyone's favorite we check in API keys to Git repositories all the time and those can grant access to cloud resources. More breach paths. Another example of breach path is the password reset capabilities granted to different intra directory roles. Your users are inevitably going to forget their passwords and you can create help desk roles to help them with those password resets. And intra has this nice little table which explains when to use which role and the risk of potentially resetting more privileged users passwords. And research by Andy Robbins and the Spectre Ops team recently in an article called the most dangerous intra

role you've probably never heard of raised awareness that in this little blue box here uh the partner tier 2 support role in intra can reset all users passwords in the tenant including global administrators providing a path to tenant compromise. And similarly, if I can compromise a user with that partner tier 2 support role or manage to assign myself those permissions, I can reset the passwords of my tenant admins and proceed to my objectives. Similar elevations of privilege exist if I can reset the password of an owner maybe on a highprivilege application or a group or reset the passwords of people in the application administrators groups and take over all applications. All of these potentially leaving me just one step

short of domain dominance. And we can't forget our old friend Kubernetes. Containers are not a foolproof security boundary at the same level of things like hypervisors. So you may be running external customer code in the same cluster uh as other workloads. Uh this includes AI models. Uh whiz has made a strong argument here that AI models are code. And so whether it's your external customers or your own uh internal code, if you have low confidence code running next to critical code, you could have a problem if there were a container escape, right? Our pods and containers likely have identities to fetch secrets or interact with other downstream dependencies. And a container escape would allow me to potentially

steal those identities and maybe the ones used by the node for system processes or for other pods on that node potentially for customer workloads. Even worse, what if the pod has permission to interact with the API server? And PaloAlto network research presented at Black Hat22 showed that at the time over half of container escapes could result in a privilege escalation to cluster admin which would lead to the permission to deploy new pods or compromise workloads in any node in the cluster. So even breach paths within a cluster in Kubernetes. So having covered a number of examples when we take a bunch of paths and we put them together we get a graph. All of these breach paths that

I've covered are examples a graph can identify and ours has identified in Microsoft owned tenants and services by putting all of this stuff into the same place. This graph this graph helps us visualize potential breach paths and our security teams to understand vulnerabilities, risks and threats. So it might look something like this, right? These are the different ways an attacker could move throughout your ecosystem and the steps they could take once they compromise each individual node as they get to the next thing in their objective. Now, it's important to note we're not covering activity data. This is an asset graph. We're we're covering the multiverse of possibilities an attacker could do. Um, you could certainly add activity data to a graph

or you could use a similar graph-based analysis approach to investigate activity data, but this is not designed to tell you an attacker is in your system, but what they could do to get into your systems or what they could do once they're in. Analysis of the graph helps our blue teams understand uh discover risks that need to be mitigated and go mitigate them. And it helps our red teams at Microsoft find new ways in the sensitive systems in order to detect uh test our detections. So if I've convinced you that there's value in having a graph and looking at this treasure map for your company, there exist real products to do this today. You may be better off buying

one of them or seeing if the security vendors you use have a cloud security posture management, an exposure management, an attack path management tool as part of their offerings and then turn it on and learn how to use it. Uh if you're already using these tools, kudos, props to you, amazing. But your business may have unique business needs that are not supported in an out-of-the-box solution. For Microsoft, this includes the number of custom internal solutions and on-prem things that we have in our environments, as well as the fact that we're a cloud service provider underlying the cloud itself and can't necessarily work with vendors that integrate at a cloud layer. You may want to own your own data end to

end due to security or regulatory requirements or just wish to limit the risk of a third party having access to those environments. The rest of this talk, we're going to deep dive into some of the concepts of making your own graph. If you're already using one of these existing tools, great. It might be interesting to think about how some of them are working under the covers to understand some of their strengths and weaknesses. If you know you're already not going to build your own, awesome. I hope some of these concepts will help you to evaluate your vendor solutions and pick the right one for your business. But I'm an engineer. I do cool engineering stuff every day

and I want to highlight some of the cool work that we've done that goes into building this security graph. So, we're going to go into the weeds a little bit. Hold on to your spool thread so we can find our way out. How do I architect a security graph? We're going to need to talk through seven concepts. Inventory, labels, data movement, data storage, queries, UI, and computation. So let's dive into inventory. It is the first thing that you have to know. What is it that I am protecting? It is the first of NIS's five functions. Identify, protect, detect, respond, recover. You have to understand what you are protecting. You have to discover the people, the assets,

the data that you need to protect or that impact your security story. Examples here include programs for asset management, understanding your supply chain, or tracking asset vulnerabilities for your environment. This probably includes at least cloud identity secrets and depending on your business, probably a lot more. But let's dive into cloud inventory. This is what's in your AWS environment or your Azure environment, right? This is assets. This is virtual machines, load balancers, maybe assigned IP addresses. This includes your data assets such as your databases and blob stoages. Where is the important data stored? This includes user permissions and management hierarchies. Who has access to those resources? What could they do if they access those resources? And this might even include things like

applied policies such as SCPs or Azure policy that restrict how much bad could be done if someone were to use that access to those resources. How do we do it? How do we collect that data? collectors, uh, console driven projects, anything to a cloud hosted, you know, fully managed service. Uh, most of the plan, most of the time you could use something like a functions or a lambda architectural approach to just run cron jobs against the cloud providers APIs. Maybe you already have a tenant or subscription management solution. Microsoft has previously open- sourced the Azure tenant security solution and storm spotter projects and there exist open source solutions to help you collect this inventory like

Jupiter 1's starbase project. Any of these might help you to either pull that inventory information or learn how to build a dynamic infrastructure to collect that information from your cloud provider. It should be noted this can be slow if possible. You want something that's going to work in bulk. Um, Azure provides the Azure resource graph APIs. AWS has shell commands like EC2 describe instance. These can give you sort of an order one dump of all of the assets in your cloud. You may also find something like a security sender or a defender product that could give you that dump of assets. Anything that's going to take your operation from an order in, let me find, identify, enumerate, you know,

scan each resource independently to an order one operation of just here's my resources is really going to speed that up and give you a better sense of truth of what's going on in your cloud. How do we get identity inventory? This is your intra, your octa, right? If you're a very fancy Fortune 500, you maybe have different tenants. you have accounts used for testing or you have acquisitions and subsidiaries. What are all the tenants that you care about? How are they configured? Do they all have MFA or a conditional access policy configured according to your company's policy? Uh what trust relationships do they have with each other? And once you figured out what all your tenants are,

what are in those tenants? What are the identities that you care about? the users in those tenants including guest users. Have you invited a lawyer to read some document and thus given them a account in your tenant? What are the directory roles for people who have privileged access? What are the groups and group memberships? So thinking transitively about nested group memberships is a canonical graph problem, right? And so don't forget groups and group memberships. And you care about nonhuman or workload identities. These typically don't have MFA. We know thread actors add credentials to them for persistence and not all of the workload identities in your environment are owned by you. Have you granted the appropriate

limited consent to an app to work in your environment or have you given it a highly privileged permission beyond its intended function? One thing not to miss is federated IDPs. So if you use something like a GitHub actions to perform a token exchange, you allow tokens assigned by an external identity provider in exchange for secrets into your environment. You need to understand how those things are federated, what those trust relationships look like and be able to monitor uh what's going on with them. And similarly to the cloud story, you can collect all this data through REST API scraping uh or uh sort of common areas that pull all of that data into uh order one

projects. You need to care about secrets. So this is your key management systems, your key vault, your hashy corp vaults, right? This is your SSH keys that are issued to your developers and what they give access to. This is your X509 TLS certificates for server authentication. This is your MTLS certificates for client authentication. Who has access to these objects? Who has access to the KMS? What are the access policies on that key management system? And are they least privilege? What do the secrets give access to? Don't miss this one, right? Um, edges in a graph require both a source and a target. And so understanding the target here of credentials, particularly plain text API keys, is frequently the hardest part. So

you need to find and understand a way to inventory and create a program in your company for when developers are creating API keys or managing API keys. How are they tagging them or providing you context on what those keys are used for so that you can understand what they unlock. So if we put all this together, we can take our cloud portions, our VMs, our KMS, our storage accounts. We can add our identities, so our users, our groups, and our applications, and we can add our secret inventory. And all of them can come together to make a large portion of what makes a useful security graph. But what's missing from our picture? On-prim components, an LDAP or

an active directory, your physical devices your developers used. We haven't talked about supply chain security, your GitHub, Azure DevOps, the package dependencies like npm. You use your SAS applications, your Google Workspaces, Adobe Salesforce M365, right? Do you know who has access to them if a user is fished? Is there anything that you're worried about an attacker getting access to? That's probably a node in the security graph and the permissions are edges. It's okay to invest in parallel construction here. You can have a source of truth spreadsheet and you can compare that with the real security group inventory that you have in your directory. You can union data from different sources. So if you have a

census that's doing outside in scanning and looking at what certificates are deployed in your environment and visible to the public versus what's in your key management system, that can give you a better picture of a unified view of what is going on with your certificates. An OS query agent running on a machine versus a cloud inventory versus your EDR products view of the world will almost certainly show you gaps in inventory coverage. Right? You can think about these as vin diagrams, right? If I have things that are covered by two policies but not the third one, I probably have shadow IT or some sort of risky asset that I need to find a way to sustainably

deploy my EDR onto it in order to make sure everything is covered. And it's important to recognize and acknowledge your map will be incomplete. In many ways, it will be wrong. Ask me over drinks what adversaries have taught me about how our systems actually work. And you can uh go back to the Voltz Mueller map at the beginning of this presentation. Most of North and South America weren't even on the map. All maps are wrong. Some are useful. Maps are inherently an approximation or a representation of the real world, not reality itself. Security graphs are based on what you think are connected and how, which is almost certainly not how they're actually connected and how a threat actor would

use them in reality. As an example here, a street map won't show you underground infrastructure or maybe missing train tracks or hiking trails. And we see real robbers break into banks by using sewers, right? One way to compensate for this is to look at activity data or your threat actor behavior, including red teams to help you learn more about the ground truth reality of your systems and how they're actually connected and how they actually behave and using that to improve your map. You could also start with a highly detailed map of one area. So, you know, the Sonda slab, right? The thing that is most important to my company or that I need to have the most

insight into. But missing inventory means an incomplete map means missing breach paths, yes, but maps get better over time as one explores more. So don't let perfect be the enemy of good. Let's talk about labels and ontology. Maps have legends or labels to help orient new viewers. A graph has nodes or edges that need labels, and this is called an ontology. Modeling your assets and putting the right labels in place is a hard problem. Not least of which because everyone involved will have an opinion. To understand a bit more about how graphontologies work, we can steal from the semantic web layer cake. What a fun project uh from W3C as a guide. And they start with a triple as their

fundamental. Say subject, verb, and an object. So we have these examples of triples. Alex pets buffalo. Buffalo eat grass and buffalo buffalo buffalo. Whether these are real or valid or helpful to you is not something that a triple can do. We need an additional construct and this is the resource description framework which allows us to start adding things like this is a subject or this is a predicate and classes. So I may have this little RDF description here in XML. It says there exists a book. It's called Cat in the Hat. It has a title. It has an author. There are properties of this uh object that are associated or required on it. And the web ontology language

delightfully abbreviated owl uh adds semantics to this representation such as transitivity. If A is married to B, this implies B is married to A. Uh you can also have equality of different relationships. So if a relationship word in French is the same as one or more words representing that relationship in English, then I can stick to different schemas that are expressing the same things but in slightly different ways together. What's the point in talking about this? Well, ontologies you find online or share in the industry are likely going to be in one of these formats. And the best way to understand what labels your graph needs is to borrow one from somebody else. So you

could look at something like blood hounds ontology for example and study how they've chosen to name and model relationships between the types of objects that they are interested in. We can see here that they've made the decision that an as VM an Azure VM is different from a computer which is different from a device or an Azure device. Do those make sense to you? It's totally up to you. Right? Ontologies are a custom thing about you and your business. Uh we also have a ontology that you could explore from Microsoft. So this is uh a new open source project that we've released this week as part of this talk uh that is covering a sample toy graph

that you can build that shows some parts of a security graph that we have talked about. So intra azure and secrets uh as well as an ontology that can talk about how those things are related to each other and that you can use to build your own if so inspired. So now that we know what we need to protect and what we're going to do to model the nodes and edges, what's next? Well, we got to move some data around, right? We need to collect that inventory data and probably in some relational database or maybe even a CSV and we need to transform it into that graphfriendly triple representation of subject, verb, and object, right? Those nodes and

edges. And this ETL process can be basically anything. Um, Apache Spark is really popular, right? Anything that will allow you to sort of reshape data from those relational sources will probably also allow you to insert them into a graph engine or a graph database. So the first question to ask here about graph storage is do you need it? Your ETL processes could write nodes and edges just back into a relational database and you can frequently fake traversals on that graph with joins in a relational database. uh data analytics tools you might already be using like custoto could work just fine for you if they have graph operators. So custoto has recently added a new make graph and

graph match operators on top of relational data. So you can get an output like this that I have a table with just rows and I can turn them into nodes and edges uh that represent uh different security attributes. In this case, users who logged into a server and users who didn't just as a sample existing databases like Cosmos DB and Spanner now come with graph analytic capabilities. And there are solutions in the industry that claim to eliminate ETL with federated queries. So you don't even have to move data at all. And of course, there are a multitude of commercial and open-source database offerings for graphs with various tiers and features and hosting options. These solutions all have fundamental

trade-offs between performance, complexity, latency, and accuracy. Your data is going to be less fresh if you move it to a secondary data store. Queries against non-graph databases may be slower but fresher. Some may some of these graph databases may support large data sets on disk, others better for data sets that fit in memory. How do you pick the right one? That's a question for your business to look into some of these trade-offs and integration points like how do they integrate with your existing data ecosystem? Are they from a vendor that you already use or whether they're written or managed in languages you're already familiar with? But now that I have data in a graph, I want to ask some questions

about it. You got a couple options. Cipher was originally developed by Neo4j as a proprietary query language for property graph databases. In 2015, they actually open sourced it as open cipher and allowed other graph database vendors to adopt it and became widely used and that turned into an ISO standardization effort uh for the graph query language which launched in 2019 aiming to be a fully standardized declarative query language for property graphs similar to how SQL is a standardized language for relational graphs. This was actually completed in 2024. So now all the graph vendors have a ISO standard to sort of work towards and GQL is kind of a visual language of nodes and edges. So you have

uh nodes represented by objects in parentheses and you have edges represented of these little arrows and you can add and query by labels or properties on those nodes or edges. And you can do a lot of the things that are pretty familiar to most relational database folks like windows functions, aggregations, summations, order buys, right? Uh on the other side of the the spectrum is a a language called Gremlin, which is actually a functional data flow language under the Apache umbrella and is much more functional. So I could ask my intro graph find me vertices labeled with high impact find me outbound edges take their inbound vert uh sorry the vertexes that they give access to and

figure out if any of them have a property with this label. Uh Microsoft has uh folks that have used both of these languages on the same graphs or different graphs for various things. They just have uh different uses for different use cases. And now that I've got a way of asking any questions, how do I manage the results? Well, you're almost certainly going to need some UI for exploring the effectiveness of your queries. Are things connected in the way that I expected? Am I getting the results that I expect back? Uh, we have found that pictures here are really helpful for effective communication, particularly with leadership. It allows us to focus in on the node that's the problem or the

edge that needs to be cut in order to get the security outcome that we want. Think of the difference here between an explorer's journal with pages and pages of description and reporting versus a map that can just communicate way more accurately in the insight that's important. And so when we've been able to express security problems in a graph and show them the picture, we find a lot of people rapidly more rapidly understand um the ad hoc exploration through this UI largely supports red team needs at Microsoft. So where am I in the ecosystem? How close am I to my target objective? How do I then get there? Uh, a blue team might use this UI to ask,

given I know an attacker got here, where might they go next or might be their objective? How do you get a UI you can use? Well, if you chose Neoforj, you're done. It's got an out-of-the-box basic UI experience. Uh if you chose something like AWS's Neptune, you can use various visualization visualization plugins, easily discoverable in their documentation and different GitHub repos. Uh you're a cool awesome amazing UX team. You can build your own, right? D3JS has a network graph view where you can take nodes and edges and render them and interact with them. And if I can answer individual questions, I want to actually ask many questions and extract data and insight from the graph in bulk. And this

requires some sort of graph computation. So what orchestration framework do you use to analyze the graph? It's probably the same as the ETL you use to populate the graph. Connectors that can write to the graph can probably read from the graph. Um, how do we do the graph computation? Well, we want to go back to that adversarial mindset. We want to encode the things we think attackers might do, their TTPs, their tactics, techniques, and procedures as query fragments. Uh given access to this, they would do this next atomic thing. And so that might look similar to what we've seen before about these individual steps an attacker might take in the graph. And when we can

take those query fragments and combine them together combinatorally, we end up creating a set of all of the queries that will give us an analysis of everything that can be done in a in the graph. Right? We're not predicting what the attacker might do, but we're now analy able to analyze the many different multiverse possibilities that they could do given here and many different possible branches. As long as we've encoded each of those branches as a query fragment, something atomic that attacker could do next, we can now follow and follow where they would go in all of their different branches. And we can understand the right ways to mitigate, to stop, contain, or even preemptively eliminate that risk. And

once we have graph computation giving us tons and tons of answers, you needed somewhere to store it. And so this piece largely supports blue teams who store the data, who look at risk, who try to understand historical trending and analysis and largely support burndown efforts and sort of the cyber defense side at Microsoft. So let's deep dive a little bit into how these query fragments work. And we can go back to the privilege escalation example we talked about earlier about Azure functions. Um, so in order to handle this case, I might have to have a graph that has these nodes and edges. And this is here represented in GQL. So I might have users and I know

that they have permissions to storage accounts. I know my function app has a relationship to the the storage account that I provisioned when I created it. And I know that my function app has an identity uh this AAD object. And for spoilers, we know that AAD object has a further downstream role in other resources. And if that is my terrain, right, if that is my sort of foundational graph, uh, unfortunately, that map can't tell me whether or not it's dangerous to travel over that terrain, right? My my ability to hike depends on my fitness, the skill that I have, the weather. Right? Not all behaviors are necessarily risks or maybe risks accepted by your organization. But if we were going to

try to encode a policy that said,"I don't want someone to create a privilege escalation. I don't want someone to move who doesn't have access to this function to be able to move into this function." We might create a fragment that looks something like this, right? We might try to find a user who has a right role on the storage account where that storage account is then connected to that function app and the function app has an a identity. If it doesn't have an identity, maybe my company accepts that risk. Oh well, they changed my function. Who cares, right? If it's only, you know, like I can define different policies and different risks with these different fragments. Um, now this will

allow me to find anything that a thread actor is doing that might lead to that uh privilege escalation and any managed identities at risk from that action. Uh, this example is actually in that repository we linked to earlier. So, you can go build a toy. you can explore it yourself and you can look for this uh in your own hunting. Now, if I were a thread actor and I had exploited this um what might I do next with that managed identity, you know, do I have a a concern that that identity has access to something downstream? I might create a fragment that looks like this, right? That a object has some sort of high-risk role on something sensitive like my key

management system. So now I can combinatorily combine those two things and I can find risks that a user can get to a function and steal an identity and a risk that the identity has an overpermissioned access to my key management system. So now I have a breach path that's actually two TTPs long and involves multiple resources. It's crossed multiple domains. It may go through multiple teams boundaries depending on how they've set up their architecture or their security boundaries here. Does this path get me all the way to domain dominance or to interesting critical customer assets data? Only you can find out. So I've talked about both our red teams and our blue teams using this and

interestingly enough we had talks uh at three different bides. Uh so last week uh my friend Cristiano on the Microsoft Red team talked about how attackers move laterally through abusing key volt and a lot of the ways that they've either found to do this or that they find within Microsoft um uh fruitful uh key vaults to go attack is by using the security graph that we've created and reviewing the permissions and breach paths within it. And on the blue side, our friends Leah and Patrick from the Microsoft Intra division are talking at Besides Dublin uh next month on variance analysis in the graph. Hey, we saw a threat actor do something interesting in it. How many other versions of that path

can we find? And both of these teams work very closely with ours on the security graph and its data. Building a map is hard, but it's one of the most valuable things you and your company can do to shine light on your ecosystem and the strengths and weaknesses in it and the strengths and weaknesses of your defensive strategies. To accomplish this, well, you have to have a program to collect the inventory of the things that you care about. You need to put it into a map that has high accuracy. It shows you what you're defending and what the terrain around your crown jewels looks like. And you must think like an attacker to model those behaviors before they actually do

them. But all of this, you know, doing it well, putting it together can ensure you're not datalless or Thesus stumbling around in a dark maze with a spool of thread, but you have a map to guide you home. Thank you.