Tyson Garrett: [00:00:00] I'd like to give a shout out to probably one of the most underloved controls in security, which is asset management. Threat models mean different things to different people, like best practices or like governance, et cetera, et cetera. And so define in a structured format what your threat model is going to have.

Don't just do all this work and then someone says so what? And part of it is that control prioritization there. But understanding how it's going to be used and how it's not going to be used, you need to be intentional around that as well. I think that's a really good way of getting started.

Ashish Rajan: Have you been looking at threat modeling on cloud? Yes, not threat modeling applications, but threat modeling on cloud. We've been talking about how the pentesting world has evolved and network pentesting 2. 0 is here to stay with cloud also being part of your regular application pentest. Similarly, threat modeling is going through a similar journey as well, where it's not just about the application, but because most of the applications are being hosted or being built in cloud, it is also important to understand threat modeling should include cloud as well as part of your application testing.

If you haven't done one of these before, fortunately I had Tyson Garrett, who is from [00:01:00] TrustOnCloud, and they've been working on building threat modeling for services in AWS, Azure, and Google Cloud. I was very interested to hear from his perspective, how other organizations are doing threat modeling at scale.

What does that look like from threat modeling in cloud? How do they even define what that is? And what should you do when you are a large enterprise and you have a lot of applications that you've threat modeled? What should it look like from a roadmap perspective, skillset perspective? Do you need dedicated resources?

A lot about threat modeling in cloud, which I thought was really interesting because we don't speak enough about threat modeling in the cloud landscape and how different it is to on premise. So I'm glad we had Tyson to come and talk about this as well. If you know someone who's looking to do some threat modeling in the cloud or even a starting point, I think TrustOnCloud has a few free threat model on their website.

They even gave us a link so that you can use to have at least one more threat model on yourselves for free. If you wanted to, I'll definitely leave that link in the description or in the show notes as well. But I just wanted to say, if you're not thinking of doing threat modeling on cloud, you probably should look at it as someone who's responsible for looking after security and managing risk for your [00:02:00] organization, should definitely consider looking at threat modeling. You can use the approach of doing threat modeling per AWS service or Azure service, or GCP service, or you can go to the other route as well where you can have a threat model being done based on the critical workload you may be running or a crown jewel well that you may have as well.

Whichever approach you pick as the option that you prefer. I would definitely say consider it. And if you get inspired after listening to the conversation we had with Tyson on making a threat model and you make a threat model of your own, I would love to see it as a LinkedIn post or a Twitter tweet somewhere.

Just tag me in there. I would love to see the threat modeling you're doing because we clearly don't talk about it enough in the industry. So all of that and a lot more in this episode with Tyson Garrett from TrustOnCloud. I hope you enjoy this episode of Threat Modeling in Cloud and I will see you in the next episode.

Peace.

Welcome to another episode of Cloud Security Podcast. Today we're talking about Threat Modeling. And I think for this I have Tyson. Do you mind giving a brief intro of yourself and what got you into cybersecurity man?

Tyson Garrett: Yeah without making me feel too old, I started playing around with cybersecurity back in the late 90s.

Doing firewall work and such and more often than not proving it [00:03:00] wasn't the firewall but DNS or something like that, which was broken and then went across to doing more security consulting, we had a startup in the mid two thousands, which me and some friends worked on and then started playing around with the cloud in. 2010, when there were two regions for AWS and I was trying to host a three tier Microsoft application with a SQL database off an EBS volume, when my customers were in Australia and Asia and my servers were in somewhere around the East coast of America, which became a lot of fun and made me a CDN customer very quickly, but that sort of made us realize the possibilities of the cloud as well which was pretty exciting.

And then I moved on to another startup where we're doing big data security stuff in the cloud, which was quite fun. And then worked at a DDoS vendor for a bit as part of the acquisition we had. And then AWS heard I was free [00:04:00] and I started working there for just under five years, initially in their professional services business.

But then I spent the last two years or so there, I was seconded to work with two service teams, which was an amazing experience. And then 18 months ago, I joined Trust on Cloud with my friend, Jonathan Rault, who I've worked with at Amazon as well, helping customers greater confidence in using cloud services.

Ashish Rajan: Which brings me to a good segway to confidence comes with knowing what threats you're trying to protect against. How do you define threat modeling in cloud? And I feel like threat modeling is usually slapped right next to an application security conversation, never a cloud conversation. So how do you define threat modeling in cloud?

Tyson Garrett: Great question. And yes, it is often associated with an application logic. And look, I look at the cloud and I'm not going to try and define the cloud for the purposes of this podcast, which otherwise we'd go forever. We look at the major cloud providers being AWS, GCP and [00:05:00] Azure in no particular order and API nature of them.

And the fact that we treat them like there's APIs, we can treat that like an application. Threat modeling in the cloud, though. And why we do it to go to that confidence piece is Jonathan myself spoke about this concept when we had a customer who said, look, I've done my regulatory frameworks.

I have to do. I've done the best practices that the cloud providers told me to do, but we just don't have the confidence to put X next level of data classification into the cloud. And that's a problem. And they believe they had the capability that just didn't have this confidence. And so we spoke to them and said what if we enumerated the threats?

So what if we shine a light on what are the threats that actually do exist on the customer side of the shared responsibility model when they want to consume a cloud service. And then once we've identified those threats, then let's look at the controls and their [00:06:00] effectiveness against those threats. So then you can then say, based off my risk appetite, and everyone will have a different risk appetite, I will choose the controls that I want to implement to satisfy that appetite.

And then I've got the confidence because I know what the threats are. I know what the controls are. I've implemented the ones that I deem to meet my appetite. I've tested them. I've now got that confidence. And I can now go forward and consume the new funky cloud service that I want to consume.

Ashish Rajan: Maybe another thing to add to this as well, because we started by talking about application security and most applications these days are in the cloud.

What you said, most of those applications that are using cloud, they may have confidence in the application threats. But they may not have as much confidence in the cloud threat. So I guess my question is, have we been doing threat modeling the wrong way in the cloud?

Tyson Garrett: I don't think we've been doing threat modeling the wrong way.

I think we've been doing it, looking at it from a, it's funny, right? An application team [00:07:00] will look at it from their application perspective and they'll say, I've done this application, et cetera. But then organizations with strong security governance and heightened risk and that can mean, it's not just a government and financial institution thing. There's lots of organizations out there that are systemic to a country, like food distribution, et cetera, all very important things. And they'll go through this. Before we let the application devs use XYZ application, they have to go through, they might call it service sanctioning, service onboarding process, where they need to understand what does Amazon Bedrock, for example, what does that mean from my threat perspective? What does it mean from a control perspective? Application developers may often just think about data plane activities where the cloud team are also thinking about the control plane activities. And how to manage that, because if you don't manage that correctly, like you don't manage VPC [00:08:00] endpoints, you just install it, activate it, but then have no policy on it, you've got all these data exfiltration risks, which the application developer might not think about, because they're thinking about the app versus the environment, and you need to be thinking of both because even with a cloud service, there is this infrastructure, which the developer will be dependent upon to use, which both of them have to be equally secure

Ashish Rajan: And also adding another lens of the whole on premise world considering we're talking about cloud for people who may be coming from an on premise world, they might look at cloud and threat modeling as like we have done threat modeling on premise.

How different could it be in the cloud? Are the principles changing?

Tyson Garrett: Great question again. Firstly, a lot of customers on prem weren't doing threat modeling, but it was like the frog in boiling water. You got the data center. That was all okay. No one really threat modeled that, that had ISO certifications.

So tick, and then, you put some servers in Iraq, then he connected the internet. This is going back in the 90s, et cetera, they probably weren't threat [00:09:00] modeling. I don't know how much of a term it was then. And then they expanded slowly and slowly, three tier web applications, et cetera, et cetera.

But they didn't really do a massive deep dive threat model of it. They may probably started threat modeling at some point during an application development process, as you mentioned earlier. But a lot of that infrastructure, it was best practices like, do you have logs enabled, do you have encryption enabled, is the management of it federated tick, it's time synced.

I guess that's good enough. And they weren't most likely threat modeling those parts of the environment. We go to the cloud. And all of a sudden they have, as I mentioned before, this risk, this fear of the cloud, the FUD around that. I think the cloud has a higher bar from a security perspective to meet for customers, not because it's less secure, but because it's a change and it's giving us an opportunity to now think about.

Okay, I probably do need to think about how I'm managing my environments and bad [00:10:00] insider threats as well. What's great about the cloud, and this is the double edged sword of it, is that API nature of it. So if you're now using, a vanilla cloud service, like you're using the security features in that cloud service, you're not going to third party firewalls , the networking, et cetera.

Everything is accessible by that common set of APIs. So it's not like I've got my Cisco firewall, my F5 load balancer, my, X, Y, Z, IDS system or whatever, or with different APIs, if they exist or whatever, it's all a common set of APIs, and a common set of identity, which has its own risks then as well.

But it's a great opportunity then to really examine. What's possible there. Having said that change control changes quite a bit in the cloud because the cloud provider will update and introduce new APIs without you deciding to upgrade to the next version of, IAM [00:11:00] it's there and you have to go with that flow of how they do that as a service.

Ashish Rajan: It's an interesting point because I think that the threat landscape is different and maybe I might challenge a bit over here, then I guess in terms of the threat modeling example, and I'm not going to use a common service like AWS, I just use unusual services, maybe from an AWS perspective, Azure perspective, or even GCP perspective, what would you say are example threats for, I don't know I think just take a non common example of AWS, which service would you say would be an uncommon service?

Tyson Garrett: Whatever we pick, some customer will be listening on the call going, that's our most common service which is the great thing about the cloud. Some places are serverless shops. Some places are, more IaaS consumption of the cloud still.

I'd say you've got, and this is where the customer's risk profiles and such really come into play. Like some of the services you can buy error messages, inject things into CloudTrail messages, right? And [00:12:00] so we've got some customers that, data exfil is a massive concern for them and they will look at things like if I, not what's allowed, but even if I get denied.

Can I exfiltrate data, can I send my VPC flow logs to another account. We're looking at the ability to send VPC flow logs to another account and by dropped entries in the VPC flow logs, you could basically put in hex format, IP addresses and exfil via that mechanism and re encode off to another place.

And that's a real propellerhead thing, but there are customers who are if all the easy stuff's gone, I need to think about that. It's the old school DNS tunneling via, your own domain and getting out past the internet that way from a open hotspot type of thing.

There's those possibilities. The more obscure services like everyone's talking about AI. So we've got to tick the bingo card for AI on this, in this podcast, [00:13:00] like another one there is obviously, there's the prompt injection capabilities, but then there's also for customers using this in their own environment, the ability of, selecting different models and a different model.

Think of them like I think of them as like different personalities. They may answer things differently. So you have a chat bot with AI, you change the model on the back end, the behavior of the application may change, which then depending on how that process is used within the organization can then change the outcomes.

And so you need to think about all these things. You need to think about what you test and what can change under your control, what might be changing out of your control. And you just need to be aware of it as well.

Ashish Rajan: And maybe we'll continue the AI theme, cause Amazon has a Bedrock and you mentioned that earlier as well.

Like what's your recommendation for approaching threat modeling? Cause is that more start from data flow?

Tyson Garrett: When we start threat modeling at TrustOnCloud, we'll firstly read the documentation. It definitely helps people often forget to [00:14:00] just do those simple things. And once you've got that understanding, we then look at each API. And each property from the API, and out of that, we build a data flow diagram, which is during the researcher phase of the work, that's becomes a living thing that they fine tune.

We will argue about the direction of an arrow, that's an important thing, which way is the data going in or out? Is it going to another account? Is it saying within my org? How can the data move around? What services does it talk to? Because have I sanctioned that?

We spoke to one customer recently and I can't remember the exact number. They previously weren't using that cloud provider, but they wanted to use that particular AI service. They looked at all the foundational services they needed to use. They're about 25 just to get that AI part because it talks off to that cloud provider storage service.

It talks to, how they do accounts. Their equivalent of subscriptions, et cetera, et cetera, but all of a sudden you've got to go, okay, I need to worry about that that I'm going to use these controls. I need [00:15:00] log monitoring, et cetera, et cetera. And all of a sudden you're actually a threat modeling 20 services if you're lucky just to use that one service on the top.

So how they serve dependent services work, and then we try and understand those APIs and go, okay how could this API be used in a bad way? There's not bad APIs, there's just some APIs could be used in a poor fashion. Like a delete API with the wrong person can delete data when you don't want to delete it.

You've got to think about those basic threats and the controls around there, but also things around like exfil, changing models, for example, how would that change application behavior, et cetera.

Ashish Rajan: To what you're saying, have a look at how the data flows across. So let's just say application A. Yeah. I'm just going to make up an application and it could just be that number of touch points it has across different cloud services, what controls you would want to have. Maybe even to your point, going a layer deeper for how is the interaction or what is asked or done in the interaction with all these other services that the [00:16:00] application A is communicating with and then building security controls around for, okay, what do I need to be worried about and whether it's an API or whether it's a database query or whatever, or it's like a, I don't know, SQL induction or whatever else you want to put in that way,

would you say that's a good starting point?

Tyson Garrett: Like I think a good starting point is especially with cloud services is understanding what part of the cloud service you're using. Some of these services have got thousands of APIs. Do you give the development team, service colon star, or are you giving them, hopefully not wildcards are bad if people haven't realized that already, or do you give them a cut down set? And so it's really then, and during this application development phase, they may not know exactly which permissions they need to use, but they'll know, oh, if I'm going to use SageMaker, an example in Amazon land, I'm going to be using hosted models.

I'm not using notebooks. I'm not using training jobs. Okay. Let's just worry about the API is related to hosted models under that [00:17:00] service and we'll threat model that and the controls and the threats around there instead. I think that's really important for customers to look at. Another thing I'd say they need to think of is I don't want to be on the Microsoft bashing bandwagon here.

Like they've had a hard couple of weeks and security is hard by all means. Don't use wildcards in your policies, Microsoft's documentation talks about this for custom roles. Don't do it. They're managed roles, which they recommend customers use where possible instead of custom roles have lots of wildcards in them for allows.

And so I understand how you're using the cloud apply the principle of least privilege that will then help you reduce the amount of controls. You have to really worry about because the applications can actually execute less of the threats in the first place.

Ashish Rajan: Yeah, awesome. The reason I asked that question because I was on the website for TrustOnCloud

I was looking at the control catalog and you guys have those three free Amazon S3, Azure Storage and Google BigQuery. I was [00:18:00] looking at the BigQuery one. I'm going, oh thats a lot of touch points.. To the point you don't even realize data flows in a certain way. There's so many Okay. Interactions that are happening to at least check out the BigQuery, or depending on what you work on, Azure, AWS, whatever, but there's definitely a version that people can see on your website, because I also feel looking at that, the first question I had was, shouldn't the CSPM be telling us all this?

Tyson Garrett: I've worked on some of the CSPMs at AWS as well, and they're great for what they do, 100%. But. I think my poor analogy, but work with me on this one is, and I'm wearing glasses and I'm going to put binoculars on my glasses.

They're only going to tell you about the controls that they can detect. Okay. So if they have integrated with, CloudTrail for log events, et cetera, then they'll alert you to an event. If they can only pull the APIs, they'll only tell you about what they can typically pull. We're talking to one customer about this. Shouldn't my CSPM tell me what I need to do? [00:19:00] And when you go off piste, so to speak, we looked at, SageMaker's onboarding that and I had this conversation this morning and we looked at the CSPM they were using, how many SageMaker controls have they got? And it was four, four sort of threats or whatever, and when SageMaker launched, there were about 35 APIs, there's now over 130 APIs, and that's just in the SageMaker space, including SageMaker Studio or doing scope creep on API namespace

and we then I looked at our one and I didn't know this wasn't a pre-canned, let me make you our SageMaker so I can give you a great answer to make me look clever. We had over 67 threats and we had over 289 controls for SageMaker. Wow. Yep. And that's a thing. 'cause now our controls go down into what nist.

The new NIST CSF2 call govern a lot more. So we call them directive controls. There's a lot of controls around that space which support the [00:20:00] technical controls. So my classic example, my salespeople are sick of hearing about, there'll be a mandate, there should be no open S3 buckets in the organization.

They're great for static websites and a whole bunch of stuff. So we're allowed to have some public S3 buckets, but then they'll still have a CSPM rule of detect open S3 buckets. And so you've got that, yes, the SOC will pick it up, et cetera. Then when they onboard the CSPM, they allow list the open S3 buckets.

Then a new application gets launched. It's got an open S3 bucket, the SOC person gets an alert. They're like, open S3 bucket. That's bad, but I don't know, maybe it's meant to be part of that app. I don't know. My friend, Harry got in trouble last week because he shut something down and it caused an outage.

I'll just punch it to the morning crew. I'll send it to the application team. They can figure it out in the morning. Okay. And that was because the customer didn't have a control, which like we have in our ones, which is maintaining the inventory of authorized public [00:21:00] S3 buckets.

You have that inventory, you then give the SOC person the agency to go, not on the list, lock down. And it's not my problem at that point. Right now, you could argue test should have locked it, found it, et cetera. You do application. There's a lot of people on this call have done operational work.

You do an operational work to make a go live work at 4 in the morning. People, if stuff ain't working, people start changing stuff in a crazy fashion. Sometimes shouldn't be done, but they do. And. you end up with mistakes made. Oh, I just opened it for five minutes to troubleshoot and then I forgot to lock it down.

And so you look at those directive controls and a lot of our controls are these directive controls which are, required by and give it, and these detective controls and your CSPM, your log control detection controls as well. They had that dependency on that directive control. And so we'll call out.

That life cycle of them, not just the CSPM. Yeah. What did the API return control as well.

Ashish Rajan: We also have a lot of cybersecurity leaders [00:22:00] and CISOs listening as well cause I think they might listen to this conversation and go, okay, what am I really looking at as a skill set in my team cause a lot of people, I mean we are still in February, so I imagine it's a lot of people re still working on the roadmap or what can that look like from a cloud security program that they might be building?

What do you see as people should include in their roadmap to have threat modeling in the cloud as a topic they're covering for the same way they were doing that threat modeling for applications. Is there a specific thing they could be looking at skill set? I don't know, like what's required.

Tyson Garrett: I had a different customer I was talking to a few weeks ago and they realized that for a large part of their cloud environment, it was never threat modeled.

It was, the backdoor dev team launched it and the, some of the basic services were just grandfathered in to an environment and it's the new service, which they're like, we probably should threat model this. And then they realize, Oh, let's look [00:23:00] at the old threat model for I'm going to use a different service name, but let's just say Azure service storage.

Let's look at the threat model for Azure storage. Oh, there isn't one. How did that happen? And cybersecurity is hard. There's staff rotations and organizations. It's lost to time, why, where, how that occurred. So I would say if you're thinking of how am I going to look at this?

I'd look at your existing environment and look at you may have, have different data classification levels for application criticality, the content of what's data can be stored in there. Look at those highly critical ones and go, am I threat modeling those applications correctly with their use of cloud services?

And am I threat modeling the cloud services that they use on a regular basis of some sort, because it's not just threats that may be introduced by a new API change or whatever, but a lot of the cloud providers introducing [00:24:00] better controls. So the old school way of doing S3 bucket security behind the CDN with CloudFront, you'd put a hash, you'd put a shared secret across them both.

But, 18 months ago, Amazon introduced a new feature, which was, so it's done it in a better fashion, but a lot of customers, they're still using the old one because they didn't even know the new one exists. So it's not Oh, there's a new threat I need to worry about. There can often be more effective controls within organizations like, allow lists for console access, better encryption, or the ability to encrypt the service provider key.

All those things are introduced as features, but if you're not set up to date. Then you may not know about it and then you may not have as a secure environment as you could potentially have. So look at that data criticality and then ask the teams of all, when did we last threat model that environment and the services there and how are we doing it?

A lot of customers will say we do annual assessments of the cloud services. There's a company that does it. [00:25:00] It's really hard. And unless you've got a dedicated team doing it, it can be very hard to do in a deep fashion as well. So figure out how you're doing it properly.

Ashish Rajan: Because I think it sounds like for, especially for people who may have not done threat model in the cloud so far, they went down the path of doing threat modeling of the application itself.

I feel like there'd be a scale challenge as well. Because to what you said earlier, 2010, most people were still only had one AWS account and probably by 2014, 2015, whatever, people only had one Azure subscription, one GCP account. Now that's not normal. Like normal now is like most people have over a hundred AWS accounts, similar for subscription and tenancy for Azure.

I guess my question is coming from is that It could be like an overwhelming problem to look at it straight away. Oh, Jesus, I started doing this right now. I'm probably spending the whole year just doing AWS. Forget Azure GCP. So how do you see people do threat modeling in cloud at scale?

Maybe you might have spoken to customers or whoever is it?

Tyson Garrett: [00:26:00] So firstly, I'd like to give a shout out to probably the most underloved control or one of the most underloved controls in security, which is asset management.

People don't really like doing it. It's really important. You look at all the frameworks that have something around this. And people are like, Oh yeah, I've got that. Yeah. Chances are you may not. And firstly, understand what you have. And it's not even taking a bite of the elephant at the time.

You don't even know how big the elephant is. And so that's very important. Because it's the thing you don't know about at all that existed, which may often well be the thing that's going to hurt you at some point in the time. A, yes, asset management and then B, what services are you using? C, what parts of the services are you using?

And go back to that mention like SageMaker, colon star, Azure Storage, colon star, et cetera, or Microsoft Storage, sorry, dot colon star, I should say instead. Those services. Understand what parts of it you're using because then it [00:27:00] reduces what you need to thread like in our threat models. We call them feature classes and they made it be dependencies there.

Like you can't do replication unless you have object version enabled and you don't have object versioning unless you have a bucket in the first place, etc. So understand the dependencies between, features or components of the service and threat model those parts and part of that is going to understand how the application works, what the data flows are, what services are talked to as you saw in our big query threat model diagrams, massive, it's complex, a lot of customers when we talk to them, they go, Oh, yeah, I saw your diagram and because the diagram, Picture says a thousand words, a picture says a thousand APIs, and it tells that story of how the service can be.

But understanding your specific data flows, it would be really important. And then you can start there. Obviously we do it as a service. We threat model the API component. So you can worry more about business logic. Versus figuring out what are all the bad things with this particular permission or API?

You can worry [00:28:00] about the other parts instead, but to, use our threat models effectively, depending on your consumption pattern, you have to understand how your application works.

Ashish Rajan: Would you say, because it seemed like there are two schools of thought on the whole threat modeling. One, to what you said.

A lot of people have gone down the path of picking up what are the, some of the common services that are being used for AWS, Azure, Google cloud. Let's just make a list of them and start doing threat modeling like that. Another approach that I've seen that a lot of people use is that they go with the critical workload, like the crown jewels for lack of a better word.

People would just go, okay, start with the crown jewels and see what services are being used as we develop the threat model for it. We start creating the kind of going back to what you were saying, where you have a set of controls for services. You just keep adding the more critical work that you add to grow like that.

Have you found, and I don't know if you agree, disagree with it, that approach

Tyson Garrett: and this comes down to, I don't know if you've heard the term paved road or gravel roads in terms of experience. So some customers will like to go [00:29:00] understand what the threats are, create the secure consumable.

So here is your secure OpenAI deployment for example, and this is what the developers can use. It's pre done off you go. Other customers will say, look, we want our developers to develop and do crazy things. And so we may give them rain in different environments, et cetera, for how they're going to consume the cloud.

So it is part of it is horses for courses of what an organization's approach for how they want people to use the cloud is it is either of them have challenges because, you create the secure consumable, then you realize when it talks to this other service, it doesn't support, the encryption you want or something like that, then you have to have, two or three or four different consumables, but it allows the developer to access it quickly versus battling the pipeline because you've shifted left, you Hopefully, but then by trial and [00:30:00] error, they figure out how to get through and which if your controls are 100 percent effective, they may have got through the wrong way and as well.

And so it's your fuel consumable is this is how I want you to use it. Please use it this way. But it becomes a. Then you have to maintain and understand all the interoperability around that as well, which, is difficult unto itself.

Ashish Rajan: You referred to challenges what can be some of the challenges people can expect as they walk the path of, all right, I'm going to start doing threat modeling in cloud in my organization.

Are there any common challenges that they might face that you can share with them?

Tyson Garrett: So a couple of common challenges like the depth we go to, we find challenges quite often. We find challenges where vendor documentation is incorrect and that's fun. I've done GitHub commits and issues, et cetera, around different providers of, Hey, that's a flat out a hundred percent, 180 of what you're saying versus other things.

So you need to test your controls and your understanding of how things work. Cause it can be [00:31:00] incorrect. We've seen this a couple of times in the AI space where permission logic or control plane versus data plane things can be slightly different to how you think it might be.

And one could argue these are the rush to getting AI services out the door, is it just, symptomatic of other issues in play? Don't take anything for its word, test it yourself, test it in your environment to see how a behavior may work. That would be one thing.

I'd say another thing is, as I mentioned before, understand the part of the service you're using and focus on that. And then what we do is also understand the controls that you can implement the way we do it. We look at, I think of it as like a return on the investment on the control. Cause for me to threat model a service, I'm in our research is if it's a big service, we might take up to six or eight weeks to threat model a very large service.

Us doing that can still be the tip of the iceberg of how long it takes the customer to implement the controls that come out of that threat model. SageMaker, I'm looking at the [00:32:00] threat model for that, 289 controls. Now, some of the more assurance controls, so the more testing control versus the actual coding a control, but a lot of it is governance and process controls and the dependencies between them.

And so you want to really understand, yeah, I can do all these things, but what's the most effective control? And how long is that control going to take to implement, because depending on how you're working with insourcing, outsourcing, et cetera, there is still finite capability from an implementation perspective.

Yes, if you're under regulatory requirements, you've got compliance to think about then from a security perspective, because as most of the listeners will know, security doesn't equal compliance and vice versa. What is the most effective control for this? And if you, oh, wow, I just need to, implement this SCP size limits notwithstanding, or do this little one tick here on the account.

And the controls lockdown done and it's really high impact, then that's a great return on [00:33:00] the investment. If there's something which is monitored for this log entry, which is going to have lots of false positives. And one in a million might be a problem. Then we rate that as a very low impact with a high level of effort to maintain.

So it's less. So think about that. And then out of that. Really be disciplined on what controls you're going to implement to make sure that you're getting the most bang for your buck for your time of implementation and the ongoing management of the controls as well, because Threat Modeling is fun, but, we use Threat Modeling as a way of control identification. We look at it as a way of identifying the controls you need to have in place for your risk appetite.

Ashish Rajan: Actually, that leads me to another point about the scale thing as well. I agree, threat model more than for the fun activity, trying to identify what security you should implement.

What do you find as the right way to, maybe I guess the word is store all these threat models, because most enterprises these days have hundreds of applications. Take ANZ, [00:34:00] CBA, whatever bank you want to take or any other popular big bank out there, you will find that everyone, each one of them has more than 400 plus applications.

And each one of them on both potentially on cloud, multiple clouds, where do you find what are some of the other things people should consider, especially a cybersecurity leader who's trying to put this into a roadmap? There's a skillset that we spoke about where you need enough resources to be able to look at the to what we were saying about how big the elephant is in the first place to have an asset for being once you identify that I can start doing it, where do you find as the right way to a how often you should do it?

And is there a tool that you recommend to like at some places,

Tyson Garrett: One of our things is we don't want to become shelfware within organizations, cause there's enough documents written by consultants of how you should do something properly, which no one ever reads. So we make our threat models, we make them human readable.

Which is important for humans to read and consume for most humans. And we also make it machine readable. So some humans like to read it in JSON language, but [00:35:00] systems love to read it and parse it that way. So we've got customers where they pull down via shared GitHub repos, our threat models, they convert it to their own speak.

So they might not call a threat. They might call it something else. They only might want parts of our things. They might not want to have the MITRE. Tactics, or they might don't want to have the severity in there in CVSS format, et cetera. They might want to have it mapped to their own control framework, IDs, et cetera.

So they'll publish that sort of information that way. And like some stuff like, security issues, notwithstanding confluence is great to have that there. Cause then you can integrate that into Jira. So you can go, okay, have I done this control? When did I last test the control? What's the status of that ticket?

Other systems have similar functionality though as well, and so we want our knowledge to be actionable. Not just knowledge, some consultants read it and they feel a bit more clever, but it's worked in to how do we most quickly get it from someone thinking, yep, we need that control [00:36:00] to it becoming a Jira ticket.

So we write our controls as like in Jira ticket type format. So it's really simple. Okay, I'm just going to take it there, paste it in. They don't have to do a huge amount of research. We'll never say apply best practices in a control because what does that mean really? And you want to, so in terms of how to store them, you can store them as operations.

So they're like that. ticket type of logic, we've decided to implement these controls because remember that's why you're doing the threat modeling. Your controls have life cycle, should be tested regularly, etc. So where are you storing your controls? If you're not storing your controls, you should store your controls.

And it helps with audit, helps with evidence, and helps making sure it's actually done.

Ashish Rajan: Would you say, so how often is Too often,

Tyson Garrett: It's one of those ones of, I don't want to sound like a solution architect and say, it depends on what I'd say a big thing is what's the criticality, right?

Do I have to drop something now? Now the cloud providers do a great job of, you don't have to do anything. [00:37:00] Sometimes it's, you need to reboot, reprovision, redo something to be on the latest fix of whatever that code might be. So there's that part of it. Yeah. Some critical events. You've got to jump on quickly.

If it's something like that, the cloud providers will typically have a notification bulletin service you can subscribe to keep an eye on. And someone should be parsing that for the other ones where it might be. Hey, this is a new control for, it makes it a bit better, but it's not, the applications are going to fall over the next day if it doesn't happen or whatever.

We see mature customers looking at like potentially for services quarterly. Backlogs, if they're really good, we update our customers. If it's critical daily, if it's non critical, they'll get a weekly update they can get from us because when they all decide to do it is different times of the quarter, et cetera.

But quarterly is a good one, enough one to do without making it feel like I have to do my annual taxes because you don't want to get too far behind in a service. Some services [00:38:00] change frequently. I looked at elastic beanstalk for a customer though, because we're talking about that as a concept. There's been no API changes for that, I think, since 2020, which is understandable.

And that's no shock to me at least, but other services, they change on a real frequent basis. Like Amazon Connect is changing all the time, but that's the nature of, I think what that service is, there's always going to be a lot of changes around that one.

Ashish Rajan: So as part of planning for this, they should also consider that if the service is being used by critical workload is periodically updating, then to your point, it makes sense to have threat model done more frequently. Whereas if there's services that haven't been updated much API or API update only happens, say, I don't know, once a re invent.

Tyson Garrett: There's sites out there third parties like awsapichanges. info. We took some inspiration from that. We've got like GCP API, changes. com, et cetera, where you can get an RSS feed to see the changes we do a similar thing around permissions, awsiamchanges.com, we use that internally. So we just figured [00:39:00] let's publish it externally as well for people to subscribe to, and that's free, make sure it sells out and that helps you keep an eye on it, obviously they need to figure out.

What's that mean? For the AWS folk out there that aren't overly cloud aware of the other cloud providers, the other cloud providers do this awesome thing called API versioning, where you can change the date on the end of it and you get a different version of the APIs and so those cloud providers will like Azure, for example, they'll just have a new version, but it's a this date off you go, sometimes it's out before that date, but roughly speaking, that's how it works.

And then you can see the differences via diffs in GitHub . You obviously need to sometimes understand what the hell does that mean? Depending on what you're using but, you can definitely stay up to date with these changes in services, which is important versus just the bulletin of what's new, because that's what a cloud vendor thinks is cool and interesting for people.

Depending on the use case, they're not going to mention everything because there's a lot of changes.

Ashish Rajan: I guess another question people [00:40:00] would also ask is that obviously investing resources and time on this as a cybersecurity leader, some of them would have to show ROI for why would someone spend time on this?

Tyson Garrett: Some of the more intelligent regulators, and I'll give a shout out to APRA here in Australia, is they've got a thing in there, and it's not hugely prescriptive guidance for the banks. It's manage your risks, right?

And that can be interpreted a bunch of different ways, but we do have customers like overseas as well and such where they use our update service to prove to the regulator. For regulated workloads that they're staying across changes in the cloud environments, and then they use that as an evidence thing.

And so you may be able to use this as a evidence point to say, Hey, we're managing our risks. We're staying on top of things. If there's, as I mentioned before, there's better new controls out there, we're implementing them. We can show proof of that by audit evidence that's awesome. So that helps those [00:41:00] organizations for the organizations that may not have regulation hooray for you and like I spoke to one customer this morning and they've got to get out of jail free from the government for a regulation because they're owned by the government in essence, and then the government realized they'd just be finding themselves.

Oh, so they're like, you don't have to be compliant with this thing because then we'd have to find ourselves and it's weird, but you should pass an order around it, but you don't have to be like, they're very fine, but you don't have to be compliant with it. But, unless you're the government and you can, I am the law type of approach, you also need to think about the business.

And so when the AI opportunities slash panic slash what the hell are we doing question was asked by executives all around the globe to their I. T. teams. We had quite a few customers say, Hey, we really need quickly the threat model for OpenAI or Bedrock, for example, or a vertex A. I., really quickly because the C. E. O. is asking about this. [00:42:00] It's not. The CIO, it's the CEO wants us to be on this straight away. And so that's important to do. And with the rapid rate of change in these services, and you look at a lot of these under the hood, there's this big preview statement with the AI services, this is in preview or large parts of it are in preview.

And there's a whole bunch of definitions about what that means. You should use it for what you shouldn't use it for, what their warranties are, I'm not a lawyer. Don't quote me, you need to understand that, but that also means there's a huge rate of change in here as well. And so you need to say, okay, cool.

I've looked at this service when it got launched last, October or, a year ago, but if I haven't looked at it more recently, there may be huge parts of it that I don't really understand that have changed that, previously it didn't allow unstructured data to be uploaded. now it does.

And that's a huge concern for a lot of organizations about does a public model all of a sudden know all my data.

Ashish Rajan: So to your point, the ROI could just be the fact that [00:43:00] aligning it with the business and what the business is trying to do. And that becomes the reason for why a threat model needs to be done now versus, Hey, let's say let's wait for the next financial cycle or something for more budget to be there.

I guess one more thing I would ask is in terms of the level of maturity, And where do you find would be a good starting point as level zero, for lack of a better word, for people who are trying to figure it out, okay, we're doing threat modeling today, start working on it to all the way to what are some of the mature, levels

Tyson Garrett: so I firstly figure out, and this is like document writing 101, okay, but a good friend of mine who now works at Google gave me this advice a few years ago, which, stuck in my head said, look, 80 percent of a challenge of writing the document is writing the headings and so figure out how you're going to structure your threat model because you look at a lot of organizations, threat models mean different things, different people, like best practices or like governance.

And so define in a structured format. What your threat model is going to have, because then you're [00:44:00] making decisions in a structured manner, right? Some have threats. Okay. Have a threat severity. Okay. How are you determining that threat severity? Like we use CVSS and then if you need to tweak it to be more cloud aware.

So it's not just like everything falls in these buckets, that's fine for you to do. Like we do that, but then you've got to be consistent with how you've interpreted that language, so to speak. So define that common way of doing threat models within the organization, because if you look under the covers, you may find that there's eight different ways you're currently doing it.

Which isn't efficient and means that some things might be getting skipped or misinterpreted because someone's high is another person's critical, right? So get a common language around it is important. And then I'd start threat modeling, something you deeply understand.

So then you're not having to do the investigation work of trying to load your brain with the knowledge of some service if you've never touched Kubernetes. Don't start threat modeling in Kubernetes, start threat modeling, if you're [00:45:00] a windows admin or whatever, threat model parts of group policy, whatever, if you want offensive, apologies if I've offended a windows person, haven't touched AD for quite a few years, but those things like threat model, something, And then you can understand like the muscle that you need to do that part of it without trying to learn something arcane to yourself as well at the same time.

Ashish Rajan: Awesome. I love that advice. Actually, this is probably my last question as well. What do you find as a I guess a good learning point for people to start learning about how to build threat models?

Tyson Garrett: You gave a shout out to our Threat model stuff already, I'd encourage, look, we've got a couple there for free on the website.

They can look at those as an idea of ways to approach it. We've got some blog posts which talk about ways to use it as well. And I think that's a really other important thing if I think about it is how are you going to use the threat models? Don't just do all this work and then someone's so what?

And like part of it is that control prioritization there, but understanding how it's going to be used and how it's not going to be used. You need to be intentional around that as [00:46:00] well. I think that's a really good way of getting started versus the someone told me I should threat model. So what do I do?

Understand why you're threat modeling and the intended purpose of it as well, I think is really important.

Ashish Rajan: Yeah. I appreciate that. That was my last final one, but I've got three questions just to get you not technical at all. I think basically first for being, what do you spend most time on when you're not working on?

Tyson Garrett: Okay. So if you look at the background, my son and myself love doing Lego models. It's a great way of spending non screen time with family. And having an idle chat and working on something, which is fun. So that's definitely something I like doing.

Warning though, as you can see in the background, space does become an issue over time. And you don't want to necessarily, thankfully it comes apart to assemble. Otherwise it would be dangerous. So definitely like doing that. Yeah, I do running as well. I've got a challenge with a friend over a bottle of Grange of who can run the fastest 5K this year.

So that's my goal is I've done five Ks in 20 minutes in the past. I'm a bit older [00:47:00] now, so that is my goal, doing that without a heart attack at some point. So hopefully this isn't played at my funeral of Oh, you said that already. So that as well, and that's a good way of getting outdoors, Sydney, humid weather or notwithstanding to just, get your mind off APIs and the cloud.

Ashish Rajan: Awesome. And I'll definitely encourage people who are listening to this to watch the YouTube video for them. A massive Eiffel tower that Tyson has in the background. The second question that I have is, what is something that you're proud of, but that is not on your social media?

Tyson Garrett: My social media is limited to following a couple of people like Corey Quinn and that's about it.

So that's probably an easy one. I'd probably say my kids, quite frankly, they're both awesome people, very thoughtful, and, that's not just me, that's their mum as well that's brought them up that way. And you see yourself in your children mostly the good, never the bad and everything, but I yeah, I'm proud of them and, they're thoughtful. good people.

Ashish Rajan: We'll clip this for your kids to see as well. Dad spoke about you. So final [00:48:00] question, what is your favorite cuisine or restaurant that you can share?

Tyson Garrett: And we talked about Sydney and we might catch up there. There's a really nice. little wine bar in Sydney called Dear St. Eloise. I don't know if you've been there. Okay. It's great. I don't like anchovies normally, but they do this anchovy on brioche and you can have a glass of wine with it. I don't know if it's Melbourne good, but it's definitely Sydney good. That's a, like a wine bar slash food restaurant place.

Cuisine, I'm pretty open. Like I do like spice, so I've done the hot wings challenge and survived and all that sort of stuff. I do like to eat a spice in my food, I definitely trying new stuff cause having the same old food every day is a bit boring. Yeah.

Ashish Rajan: Yeah. Fair call. Fair call.

But thanks for sharing that as well. And where can people find you on the internet to connect with you and not let's get to know more about it.

Tyson Garrett: For sure. So look trustoncloud. com it started off as a play on the words of when I was running to, just US East one with my back in 2010 and understanding and looking at the IOP [00:49:00] performance. In 2010 on EBS this little thing that it wasn't great for a database and I registered main called Trust No Cloud and then I was talking to John about that story and he was like, can I use that as a spin? I just wanna change the no to an on around. So trustoncloud.com is a good way of finding, the company I work at, what we do, so if you go to trustoncloud.com/podcast, you can get a free threat model of one of the ones we don't have open sourced already. Knock yourselves out.

LinkedIn, Tyson Garrett will find me that way. I'm not an Insta or Facebook person. I think there's two Tyson Garrett's, it is a weird unusual name, but there is like a Dr. Tyson Garrett and another Tyson Garrett in the US. That is not me. I'm not practicing to be a surgeon on the side or whatever.

Ashish Rajan: Okay. I'll put the right link for your socials on the show notes and the YouTube description as well. Also, the podcast promotion as well, so people can actually get a threat model for free just to get in the sense of what kind of threats they might be looking at their favorite service of theirs.

But, this was awesome. Thank you so much for coming and [00:50:00] sharing all the knowledge you have and for everyone else, we'll see you next episode, but thank you so much for coming across for this.

‍