Automating and Scaling of Threat Modelling for Cloud Native Archit... Hanna Papirna & Emma Yuan Fang

In this talk, Emma Fang and Hannah from EPAM Systems introduce key issues surrounding threat modeling in cloud-native environments characterized by microservices, managed services, and serverless functions. They discuss the challenges of identifying and managing attack surfaces in dynamic architectures, particularly in cross-tenant setups. The speakers propose a block decomposition approach to streamline threat modeling, allowing teams to focus on high-risk threats while integrating methodologies such as the DREAD framework for evaluating risks. They also highlight the importance of automating threat modeling processes through techniques like Threat Modeling as Code, which enables better integration within CI/CD pipelines. Additionally, they demonstrate the application of AI-assisted tools to enhance threat modeling accuracy by providing contextually relevant outputs.

there are hundreds there could be hundreds of attack surfaces and the average fraoding process wouldn't be able to solve that. So I Emma and I have my colleague here Hannah from EPAM systems together we will be sharing some solutions that might be able to solve your problem today. All right let's get started Hannah. Yeah. Hello everyone. I'm Hana. Uh I'm a lead security engineer in EPOM systems.

So my primary uh knowledge sphere is in cloud security engineering also threat modeling. Uh yeah and >> yeah so my name is Emma Emma Fang. Um I'm also from EPAM. I'm a consultant and senior security architect. Um so uh I've been involved in a field diversity and inclusions initiative including the women in cyber security. Um I'm affiliate leader at the UK affiliate. Um so I'm specialized in

cloud native okay so that is the state of the uh of the cloud native probably familiar. So we have a lot of um as you can see that we have a lot of managed services and microservices and um cross tenant it could be uh depending on the hosting um style of your of your environment and we have a lot of um containers serless functions. So what are

the challenges of uh threat modeling this kind of uh environment? So there are some of the challenges that we like to discuss here share responsibility models. So that means that sometimes um as a customer we are really uh struggle to understand what is the uh what is the security controls that within our limits and we have a lot of APIs and it's a distributed uh system and

a lot of times that we are not able to um encounter all the um the attack surfaces within this um we have a lot of shortlived workloads within this environment as well containers and serless functions. So the problem that we are trying to solve here is how can we automate and scale this environment I mean the threat modeling of this environment. So that is what we are

going to propose is to use the AI assisted approach and also be using um a method that can be integrated within your CI/CD pipeline. So this is a typical uh threat modeling process. I just going to briefly go through this. Um so at the very start we will define the architectural diagram. We defined the trust boundaries. We defined everything to do with the technical component of the

uh architecture. Um we defined the data classification and so on. And then we can break down the system into smaller manageable uh components or subsystems. So that would allow us to easy um threat model this um this very big complex architecture and then we can identify and attack uh actors and map them to the uh attack uh vectors um like surfaces with that we can identify the

list of threats. So after you have a list of threats the next step is to uh evaluate the risk. So in this uh this uh the the purpose of this call this talk we are going to propose a methodology called dread. Uh we'll talk about that in uh in a few minutes and then um and um after we have all the risk evaluated we can um put

we can uh plan the mitigation. So um the the key point that I already talked about this um earlier is that we would like to propose the threat modeling as a code as approach to automate this process. Also Hannah is going to present the AI enable assisted based on the ALM um methodology that can be used to automate and um scale your machine modeling process. All right.

Yeah, thank you Emma. So let's start with the basics maybe uh what is the existing framework for threat modeling. So maybe all of you majority of you know stride is an old golden standard for threat modeling. It was developed by Microsoft but in the 90s. So it categorizes threads into six types like spoofing, tempering, repudiation etc. But why do we still using it nowadays even in Kubernetes

era? So the answer is simple. It's because it's simple, comprehensive, it's structured coverage. So not no major threat category gets missed. And also CNCF and security tech group uh my tech all of them kind of adapted this framework to kubernetes but at its core tried it's still some monolytic checklist from pre microservices era. uh that's why there are still gaps in the existing frameworks even though they've

been modified for containers and it happens due to dynamic complexity. So all the ephemeral ports meshes etc. they create shifting trust boundaries. That's why Strike doesn't see critical threats, cross tenant identity risks like uh identity propagation loss and stuff like this. And also all this manual threat modeling, manual assessments, they don't keep up with CI/CD process. So basically your model becomes outdated by your next deploy. And

finally of course you cannot threat model what you can't see. So monolytic classical models they assume you have a single static perimeter but it's something which doesn't happen in kubernetes. So trust boundaries became dynamic you have tenant isolation boundaries you have cluster internal pod etc etc. That's why it doesn't really always work. That's why in this talk we propose the block decomposition approach. So it makes Stripe

more scalable focusing on high-risk threats and uh no matter the level of security expertise in your team. Uh people usually get stuck when you give them an assignment to do threat modeling because they've been working on the product or platform and then all of a sudden they need to sit and brainstorm and fontain with brilliant threat ideas. So it's not always feasible. That's why we believe we

will give you a practical example which might help here to give you some inspiration. So let's move on. Uh this will be a high level reference architecture for cloud native cross tenant identity governance platform. It is built on Kubernetes technologies and this will be a base for our threat modeling exercise. So the platform centralizes on user life cycle management across multiple tenants and this diagram represents just

one implementation scenario but in practice tenant A and B they could belong to the same organization or different entities. It can be run in cloud on prem or hybrid. And uh some real world example can be a company acquiring other company and they retain separate identity tenants for legal reasons but they automate user user provisioning without merging their networks or directories. So I tried to make this

example as diverse and suitable for many scenarios. So you can use it as an inspiration for your next red modeling session. So let's dive in a bit into the diagram. You can see here uh tenant A. This is our managing tenant. So it acts as a central control H and it initiates all the identity governance uh procedures. So the right users have right access across distributed environments.

Uh so basically how it works the authorized external traffic it enters through your W through your API gateway and securely routes requests to the cluster and once inside the microservices do all the magic of orchestrating events like provisioning a new hire. So in brief uh this tenant manages the identity life cycle locally and then securely pushes it to other tenants and what's happening the inside the cluster

at its core it's just two microservices the user service and work one. So the user one acts the source of truth for identity data and workflow service orchestrates processes like on boarding access revocation access review and so on. So when some new identity event happens like a new a new employees join in the user service triggers workflow service they exchange data and do all the necessary changes

in tenant B like updating permissions or stuff like So this is our target tenant. It can represent like a legacy or managed service environment. I intentionally didn't put here Kubernetes because this is more realistic scenario when organization needs to integrate acquired companies and they cannot immediately uh migrate to cloudnative platforms. So instead tenant B relies on standalone components and enforces identity operations delegated by tenant A. And

the component which keeps this all together it's a dedicated Kubernetes management cluster. It hosts just two key components. The Argo CD for GitHubs based deployment and SPF spire for workload identity. So Spy X has a root of trust. Basically it provides verifiable identities to workloads in both tenants and of course all operations are lo and audited there. So why I've been telling you all of this? You

see now how tenant A manages identity workflows. Tenant B receives delegated operations. But here's the challenge. How do we as a team supposed to create a single threat model to cover the dynamic nature of independent services of containers of cross tenant trous boundaries in this sample application. So this is where most of the teams actually tend to skip the threat modeling exercise completely because they assume okay

we develop secure by design and it's an unnecessary activity like my best bet they do it just to tick the box for compliance purposes that's why uh our block decomposition approach may help here uh to make your threat modeling truly useful. So here we break down the system into manageable security domains. For our example, it's just four blocks. And for each of these blocks, we define the

most critical threat categories by stride. So this doesn't mean other categories do not exist. We just focus our attention on highest risk area. Uh so for this talk because of time constraint we're going to concentrate only on block three which is cross tenant identity and API but you can find the whole thread model in our deck you can download it. So why we focus on block three

is just because it represents best the core purpose of our platform. uh it sits at the ultimate uh trust boundary and this is also where the delegation patterns the policy drift the token context loss they create highest impact attack surface. So here is the example of a detailed threat modeling for this block. Uh the components associated from our platform here are Kubernetes management cluster with GitHubs controller

workload identity and airbach and of course API gateways from both tenants. So in terms of trust boundary we are talking here about cross tenant calls and workload identity at a station. Uh so it's important when you start your threat modeling to identify existing cloudnative security controls and this is where actually CNCF graduated projects can give you strong foundation. For example, Spire can provides verifiable workload identities. So

it eliminates basically shared secrets. Also Argo CD gives you declarative GitHubs workflows with audit trails and everything like this. However, all these tools they do not prevent over permission roles or trust boundary shift or some misconfiguration across tenants. So the biggest gap here is policy drift. So you may have perfect today but uh without continuous validation permissions tend to grow. Uh so the critical threats here are

the ones CNCF stack cannot prevent on its own. So these are your focus areas when you do threat modeling. uh exercise and on the next step uh we should do the detailed stride threat mapping which should be based on a real world incidents and threats. So the block de composition isn't basically about modeling every single threat equally. It's about focusing your team's effort on what actually brace

cross tenant system. So you start with real incidents you prioritize them like obviously a spoofing vulnerability in gway will affect all tenants or elevation of privilege in identity pain can affect cross tenant operations and governance. So you work backwards and the the block uh gets the deepest right analysis. So here the top categories for this block going to be spoofing and elevation of privacy of privilege sorry.

So this is the delegation drift we already covered and identity forgery. So on practice many of these delegation and identity threats they start with GitHub supply chain bridge like compromise helm chat or argo CD repo which then can turn into cross tenant privilege escalation. So uh the detailed blocker composition approach can be obviously expanded for the whole architecture. And the main conclusion I want to leave you

with is that when you uh start your threat modeling, you start with a good architecture diagram. Then you divide it into the blocks and reach treat each block as a focused security domain with concrete stride examples real incidents and existing security controls. And this will make your threat model more precise and realistic. And with that uh we can move to the next section. Thank you Hannah. Right.

So let's talk about our spread actors. So understand what what other type of actors exist in our environment could help you to assess the risk and prioritize mitigation because not every threat actors have the same motivation and understand this could help to determine what's actually at risk and there are four four main types that we have identified in this um talk. So um the external attacker as

you know that they might be targeted they could be optimistic and they they sometimes prop your uh about your endpoint and APIs inside could be someone who's um malicious or could be someone um could just be an internal employee who's just accidental misconfigure something like you know um and also depending on the permission this actor may already have access to to your environment or even have admin

access. So this is probably the most dangerous one. Um so the supply chain actors are normally pointing to your um uh container images get ops repos and and those threats sometimes propagating from the supply chain your like your supply as a third party suppliers. And the the last type that we are um pop um we we have presenting here is the type that is um bots and

scanners. So so these ones that um are automatic and and they normally just um just attackers setting up the pop the bot to automatically scan your environment. Now uh in the next slides we will map to the uh attack vectors. First of all, I'm sorry about this full uh screen. So you don't need to read every single one of them. And and of obviously I'm not going

to read them and so in this slide we have put together everything about the threat actors mapping across different attack vectors and um and which is the me mechanism for threat actors to exploit and to cause damage. So we also used the strides and mapping each of those str examples with the stages in the miter. Uh some of you probably aware about the miter attack framework. So

it's a cyber Q train um that um it can tell you where the threads are present in the stages. So we have observed here that in in terms of the common patterns at the interfacing g gateway we observe that spoofing threads are the most dominant and at the service to service plane is the uh it's the privilege escalation. Um so these are the sometimes is the compromised

mesh identities and container escape could happen there and in at the management plane um is normally the credential threat um and abback abuse and um workloads identify forgery and so on at the data plane. This is when all of your abstinence threat vectors has been ultimately uh targeted and now the data dis could be disclosed or tempered at this layer. So this is the worst scenario. You

don't want to get to that. Um so we use dat framework to calculate and evaluate the risk for the thread depending on the risk the the risk level we can prioritize we can prioritize them. So the dread breakdowns into five factors. So these five factors are used to determine the average score of your likelihood and the impact for the particular threat. So this is a semi-qualitative approach

to uh the risk evaluation where calculation is involved but um is mostly determined by this heat map that is on the screen. So um in the next slides we are going to present an example of how to calculate the um the the risk based on this hea. So in this example we have a githops repo compromise which is have was covered earlier in uh uh harness slides.

Um so this enables a compromise or stolen git uh credentials um to be um to be used and utilized to um to compromise your further systems. So based on our evaluation of the architecture we have assigned a score to each of those factors and giving the justification of reasoning. So the risk is then calculated based on the score which gives us the risk level of high. So

next step for this um threat modeling is to identify the mitigation. Here we have proposed a mitigation for this one. So um I would like to talk a bit about how to automate and scale your threat modeling process. So here I'm proposing this uh approach is called thread modeling as a code um process. So this process is a codify version control um automatic um process that can

be integrated into your CI/CD pipeline. we use the practice of configuration as code or policy as code. So the approach is we first define the resources the um the technical component and data flows trust jones and boundaries in the declarative format like in your terraform um yaml files and then and then with thread model the um we can put those files in our ripple. And next step

is that we are going to uh threat model this um using this code by using some of the tools that we are recommending here. So they are the tools that supports this approach. Um so you can use any of those tools. So it doesn't really matter. Um so um and then we can run run analysis to the um with the with those tools and those tools can

be enabled automatically if you are uh in integrated in the CI/CD pipeline and then you can as a as a regular CI/CD pipeline. You set the the triggering of the of the um of the scan of the of your thread model and you can set the quality gates and and you can use you can detect the drift of in your architectural such as the architectural change and

uh drift in the trust boundaries whenever your code is changed. And lastly, you can even uh automate this process by sending a a ticket to the uh your ticketing system like Jura. So uh the dre framework can also be um embedded within this uh code because everything is codified. Well um so this slice is just to tell you within this four stages of the uh four different

um stages of the threat modeling what is the uh what can be automatic and what cannot be uh automat what has to be stay as manual. So I'm not going to go through the slides too much uh but it's just for your reference. The conclusion here is that no matter what you do with your thread modeling exercise, there will be some level of human judgment required. So

even you want to automate fully automate that's impossible but yeah uh so just an example of what the inputs look like in this YAML input example we have uh got it from the thread. So the data assets uh assets are declared with the data classifications. Um as you can see that stricted confidential was classified for the customer data and this also means that will automatically flag any

um flow um handling this data without appropriate security controls and trust boundaries are also explicitly um defined. Um so uh we are separating the tenant A's uh communities cluster from the the tenant B's uh cloud accounts for example and this and this uh code that we also uh sharing that the um the communication links also describe the actual data flows. So you can see that we have

added attributes like a authentication methods and uh encryption and whether a flow is crossed the tenant boundary. So basically you defined everything like that um in the in the input. So this is an example of the output in the JSON uh risk report. So this has been generated by shred and each of the interest map directly back to the architecture that you defined earlier in the uh

uh in the YAML file and we have identified every um uh every list in uh with a category seity ratings and likelihood and impact rating evaluated by the framework. Um so depending on the tool that you use it could be different approach. So yeah, it's just an example for you to um you know for you to have a kind of reference have a look at this. Um

so next we are going to I'm going to pass on to Hannah to present the AI assisted threat >> Yeah, thanks. So let's move hopefully to the fun part of this presentation. So this is will be just a short demo. How can you use the AI assisted threat modeling? So you can integrate entire process we've been describing here uh to to your threat modeling. So I'm going

to use the open-source tool which is called stride GPT. I chose it because there is a wide selection of open-source tools nowadays. You don't need to build AI agent from scratch for threat modeling especially you can uh plug in any similar tool. So what matters here is more workflow rather than specific implementation. For example, you might have seen other options like excellent cloth skills to do similar

automated threat modeling. So those are useful, but I chose this tool because out of the box it supports many models uh including locally hosted ones. So for those of us dealing with some strict data sensitivity or compliance, you can uh take it and experiment right away. So to make the demo work I I just run it as a simple streamlit uh local app on my laptop and

I have local host UI but obviously for production you can deploy it to docker container kubernetes stuff like this. So all the links uh to the tool and small code enhancements you can grab from our deck. Uh so yeah let's move on. Uh so to begin with this tool strategypt it expects you to describe your application to be modeled. So for our case I added the separate

organizational context file to the code. Uh so this makes each thread modeling iteration faster because we don't have to reexplain the environment every time to the system. So in that file I just put a description of cross identity platform we talked about and then I modify prompt function. So every output automatically it includes our context before we type anything into the UI. So if we move to

the UI uh to run GPT you need an API key of an LLM provider. In my case I used Google gin and in that in place we can generate first threat model. So I keep app description very high level just to include our organizational context and with that we can uh see the output. So first threat model is exactly what you would expect from a generic prompt.

So basically it gives you broad cloud risks like database tempering some identity bay pass but the weak point it stays very high level. So it tells you there is a bypass of MTLS or stealing of service account but it doesn't really explain us the cross tenant kill chain. So how is it happening? Also the weak point is some like generic threats like login is not there which

is of course good but it's not very actionable. That's why uh we will try to do second threat model and for that one we kind of constrain it to just one block. the block I presented to you the cross identity and API management. So I specify their components trust boundaries I seeded with some real stride uh threat examples. So it matches the block decomposition slide you saw

earlier today. And if we move to the results of second threat model you can see here that it immediately shifts to identity management plane. It catches spy agent compromise, githubs as supply chain vector and also it highlights for us some high-risk scenarios like airbag delegation drift, policy inheritance abuse, stuff like this. It's still not perfect. So for example, it overestimates DNS spoofing which in strict mesh it

wouldn't happen. But it's still closer to how architect would reason the cross tenant compromise. So here is more consolidated view of these two uh threat models. You can see that generic one tells us someone bypassed MTLS which isn't very helpful. But the block focused one it gives us exact guil chain. It tells attacker might compromise an agent to forge an API getway ID and then try to

completely bypass our airbark in delegated tenant and similar situation for GitHubs compromise. So these are two highest impact threats because they both break cross uh tenant trust boundary and this proves that when you decompose your architecture into specific blocks I gives you more actionable items rather than just a checklist of threats and uh just to wrap up uh the demo let's look a bit to the uh

engine room. uh so if you want your threat modeling to work in CI/CD environment you have to make your AI output kind of stable. So for that reason um in the code I am uh modifying function that parses the Google response and I explicitly passed there three critical parameters like temperature top P and thinking budget. So thinking budget is essential for models that support reasoning like Gy

which I used. So basically it allows your model to do multihop check and some context aware ranking before it gives you the full uh threat model temperature of course to a bit control randomness and creativity. I lowered it down to 0.3 so your outputs are more reproducible and you can actually differentiate them in git and finally the top or nuclear sampling. So this is parameter used to

control probability distribution. Basically it tells your model to ignore react outliers and concentrate on top 90% most likely tokens. Uh with that of course uh these numbers are not some magic numbers out of the box. You need to test them. You need to tweak them for your environment. But they can help you keep the variety of stride threats and also a bit reduce hallucination. So all in

all when you combine block focus prompting with this parameters you might get the stable reproducible thread model which you can version control and use in your pipeline. Yeah with that uh this is this was the final slide. We are open for discussion. What do you think? What is the future of cloud native threat modeling? We're going to be around. Please let us know your ideas. Thank you.