Implmenting new technologies for the business is already a daunting task. Cloud and SaaS have made some of the implementation easier, but it also makes it easier to not fully comprehend the risks you’re taking on. All it can take is a company credit card. Organizations struggle with shadow IT, misconfigurations, and unauthorized access across multiple cloud environments, often lacking visibility into their actual cloud assets.
In this episode, Tyson Garrett, CTO of TrustOnCloud, explains how their platform provides constantly updated threat models for major cloud services, helping organizations implement controls based on their risk appetite. Joining him are Derek Fisher, Director of the Cyber Defense and Information Assurance Program at Temple University, and Davi Ottenheimer, vp, digital trust and ethics at Inrupt.
Got feedback? Join the conversation on Linkedin.
Huge thanks to our sponsor, TrustOnCloud
Full Transcript
[Voiceover] Connecting security solutions with security leaders. Security You Should Know starts now.
[David Spark] Welcome to Security You Should Know. I’m David Spark, the producer of the CISO Series, subbing in for Rich Stroffolino, your regular host of the show. And today we are talking about TrustOnCloudand what they are doing in cloud security. The problem they’re addressing is understanding the risks you take on when you adopt a new cloud service and heck, we’re doing it all the time. I know it.
So, it seems like a much-needed service. Helping us to get answered to these questions about this are Derek Fisher, who’s the director of the Cyber Defense and Information Assurance Program over at Temple University. Derek, say hello to the audience so people know your voice.
[Derek Fisher] Hello, audience.
[David Spark] There you go. And one of our favorites coming back again, Davi Ottenheimer, the VP of Digital Trust and Ethics over at Inrupt. Davi, say hello to the audience.
[Davi Ottenheimer] Hello, audience.
[David Spark] Derek, I’m going to start with you, and I’m going to ask you this question. Why is getting a handle on cloud service risk, essentially when they’re introduced into your environment, why is that still a problem? Why do we still struggle with this?
[Derek Fisher] Well, we still have fundamental issues with just general cloud security. Look at things like misconfiguration, unauthorized access, shadow IT. All of these are problems when it comes down to deploying services into the cloud, regardless of whichever cloud service provider you’re using. The age-old issue of someone with a credit card being able to stand up typically infrastructure in an application and in just a short period of time still poses a significant risk to the organization, and if you don’t have the ability to see your assets in those cloud environments, you got problems.
[David Spark] All right, very good. Davi, I’m going to ask you the same question. Why do you think this very issue of getting a handle on cloud service risk when they’re introduced in your environment is still a problem?
[Davi Ottenheimer] Well, I think cloud is a variation on a theme. It’s kind of like asking, “Why do we still have to brush our teeth if we eat?” It’s fundamental to using technology that you have issues with it, and it’s fundamental to cloud because it’s technology that you’re going to continue to have some of the issues you had before, but also new issues that are unique and different. You wrote a book about this in 2012, if I remember right.
It was so old, it had a DVD. And a lot of those things that we warned about have come true multiple times and will continue to be true. So, I think it’s a journey. It’s not a destination when we’re working on security, and we’ll keep being gainfully employed as long as there’s cloud.
[David Spark] Very,[Laughter] very good. All right, so that sets the table of what we’re dealing with, and today we are going to be talking to Tyson Garrett, CTO of TrustOnCloud. Tyson, say hello to the audience.
[Tyson Garrett] Hello, audience.
[David Spark] All right, that’s Tyson’s voice right there. So, to start out, we want you to answer the three questions we ask all our guests to answer. So, Tyson, how do I explain the value of your solution to my CEO? What does your solution do, and what does it not do? Essentially, what lane do you swim in? And lastly, what is your pricing model? What can I expect when someone adopts TrustOnCloudthe kind of pricing they should be dealing with?
[Tyson Garrett] Sure, so at TrustOnCloud, we help customers innovate in their use of cloud technologies. We do this by ensuring they’re armed with the knowledge that they’ve implemented the controls to meet their risk appetite, and we do this by providing constantly updated threat models for the major cloud providers. So, for example, Amazon Bedrock, Azure OpenAI, Google BigQuery, etc. And these threat models contain a rich set of prioritized controls accompanied with the threats that they mitigate. I
n terms of what we don’t do, look, we aren’t a CSPM. We thoroughly believe the world has enough CSPMs, and the market is not screaming out for another one. We’re not scanning your environment. The data we’re providing here is customer agnostic, but we do it in a way which ensures the customer has the level of detail required to transfer this knowledge to their implementation. As for the pricing model, it’s subscription based. So, that can be on either a per cloud service basis.
So, for that example before – Amazon Bedrock, Azure OpenAI, etc., or for an entire cloud provider. So, all of AWS. And for that one, you get all the threat models that we currently cover and any we add during the subscription period. If you don’t renew, you get to keep the threat models we’ve provided you. You just don’t get the updates.
[David Spark] Excellent. Okay, now the point where we ask our security leaders to ask some questions they have about your product. I should let the audience know that our guest doesn’t know about any of these questions. I don’t know what any of these questions are. So, I’m going to ask you, Derek, what’s your first question for Tyson?
[Derek Fisher] So, I’ve been spending a lot of time recently digging into threat modeling. In fact, I’m on a tail end of a book right now with PACT that will be published hopefully at the end of the year. So, threat modeling is very near and dear to my heart. And so, I’m really interested in your process for how you detect threats in cloud service providers. You can take any example you want. Bedrock or something else is perfectly fine.
[Tyson Garrett] Awesome. No. Great, great stuff. Look forward to reading the book when it does come out. So, what we do is we firstly construct a data flow diagram, and we interrogate all the REST APIs from the provider at a property level to try and answer the questions of can this go across accounts, can this go cross-region, for example?
And fromthose threats we’ve determined, we then look at the controls that you can implement to address that threat with their level of effectiveness as well as the level of effort it takes to operate that control to give you a more prioritized approach for how you should tackle a service.
[David Spark] Excellent. Now, Davi, I’m going to go to you. What question do you have?
[Davi Ottenheimer] Yeah, we’ve evolved from CIA – confidentiality, integrity, and availability – into trying to squeeze it all into STRIDE, which really adds in the AAA to the end of the CIA authentication authorization and auditing. And so, what’s your preference? STRIDE, CIA, AAA, or PASTA even, which is a new standard that’s more business oriented, talks about the risks to the way the business operates.
[Tyson Garrett] And then you’ve got DREAD, which goes with STRIDE. Look, we’re in IT, right? So, we have to have acronyms for everything humanly possible. That’s probably an acronym in itself. So, look, I don’t have a favorite. What we do want though, we recommend customers do is consistency.
And when you’re doing this work within customers, we find that you might have department A does STRIDE, department B does PASTA, and then someone else in department B does a different mechanism as well. And then you get inconsistency with the results and then how things are communicated. So, I don’t necessarily have a favorite, but my favorite is consistency within a customer to ensure that the level of severity or whatever is consistently expressed.
[Derek Fisher] Yeah,if I understand this correctly, you’re threat modeling specific services within name your cloud provider here, say AWS, but if you… In every environment or every organization, their configuration’s going to be different. The way they utilize those services are going to be different. So, how do you take those, what I would kind of consider out-of-the-box standard threat models of a specific service and a cloud service provider, how do you then morph that into something that’s actually more aligned to what the organization is doing on a daily basis?
[Tyson Garrett] Yep, great question. So, what we do is – and part of our business model is very much that we’re not trying to scan customers’ environments or do somethingoverly customer specific – but what we do is to allow customers to choose what they do. We break the service down to what we call feature classes or modules. And so, for example, if you’re using S3, Amazon S3, it might be a bucket. It might be you’ll have…
But you may be doing replication, you may not be doing replication. You may be doing object lock, you may not be. And each of those feature classes then have different threats and controls, and we describe the relationship between those things. So, if you want to use object versioning…or if you want to use replication, you have to be using object versioning, etc. And that way you sort of break down a threat model from maybe 200 controls to potentially 20 or 50 controls, depending on how the customer is consuming that, and we express those feature classes based off the permissions required to unlock that part of the service.
[David Spark] Davi, back to you.
[Davi Ottenheimer] Well, you mentioned mapping controls. What happens when there’s no control to map?
[Tyson Garrett] Yep, and that’s a great question, right? So, we haven’t had a situation where we’ve got a threat where there is no control, but we have got the situations where the controls aren’t really, I would say desired or the lack of, where potentially a service is not offering API-based ability to interrogate things. It’s more console-based experience where you’ve got tolog on and look at what is reported, which is not ideal. And so, we have seen customers look at our threat models and go, “Well, the controls that are currently possible are not to my risk appetite. I’m not going to use this service.”
[Davi Ottenheimer] So, I’m thinking the way you described threat modeling, you’re going to model S3 threats, you’re going to model EC2, Lambda, but these are three different things, but in an actual attack, you’re going to have somebody who compromises EC2 and then pivots through IAM and then accesses S3 and goes to Lambda. How do you look at the cumulative risk when you’re across dozens of these things connected together?
[Tyson Garrett] Yeah, no, great question. So, look, what we do is we look at, for each of the attacks, we look at both the MITRE tactic that is being executed here, as well as what the attacker goal may be. So, for example, a MITRE tactic, if you’re, say, modifying a bucket policy in S3, that’s defense evasion, but the goal of that attack is most likely for data theft, for example.
And so, what we try and do there is we look at each of those threats that can be atomically executed, what that impact is, but then also what the goal of that maybe is. And we look at each of those as permissions, right? Because each REST API requires a permission to execute here as well.
[David Spark] Derek, you got a follow-up?
[Derek Fisher] So, if you, based on your threat models, you find controls, you understand what the threats are on the different services that are being used in the cloud provider. How does that get implemented back into policy or into control? So, whether it’s being able to develop infrastructure as code scripts or policy as code scripts and making sure that those controls are actually implemented, is that something that TrustOnCloud allows in terms of that feedback loop and getting it into the development lifecycle?
[Tyson Garrett] Yep. So, what we do is for each control, we define them as, is this a directive control? Is this a detective control? Is it a preventative control? Is it a responsive control? And then we tie the dependencies between there. Often to implement a technical control, you need to have a process which defines what is good and what is therefore not good. And we provide the level of detail like at a JsonProperty level, which is then relatively implementation agnostic of how to do it via Terraform, CloudFormation or something else.
And then for each control, we also separately list how to test it. And sothen it’s very much like how an auditor could test it or someone else could test it. Do this – this should be the expected result. And that way it makes it a lot more assurable that the control has been implemented correctly, and we write each of the controls in like a user story format. So, it’s very much assignable to an individual level.
[Davi Ottenheimer] I feel like in my own threat modeling, I always get stuck spending 90% or more of my time on the what, what can happen, and not enough time thinking about the who, the why, the what next. How do you contextualize this enough so you really understand insider, outsider, user mistake, true nation-state attack that will never give up and has all the money in the world versus somebody just poking some buttons? Where do you get the real detail on the threat modeling versus the cataloging threats?
[Tyson Garrett] Yeah, so you can go down a very intellectual introspection route of something which helps, but maybe not helps in terms of the time you have. And so, what we do is, for each of the threats, we try and be very concise. And that is very muchwe set the scene of, using S3 bucket policies as an example, what do S3 bucket policies do? And then we say an attacker can do X. And so, we have a very formulatic way of describing it so it’s consistent.
And we don’t think of attackers as an insider or an outsider or a malicious or an insider making mistakes. It’s just the impact of what that threat may entail as well. And it’s very much – because we’re trying to use threat modeling as a way of determining what are the controls we should be implementing for our risk appetite – and so it’s very muchwe try and bethreat modeling is the process to bring to bear the controls, and we’re very much controls focused but with a lineage to back to the threat.
[David Spark] Awesome. Well, I want to thank you, and I want to thank Davi, and I want to thank Derek as well. That’s it for our episode of Security You Should Know. To learn more, just head to trustoncloud.com.If you have any feedback or questions for Tyson, find him on LinkedIn. We will provide a link to his LinkedIn profile, but you can also just send them over to us at feedback@CISOseries.com.
So, huge thanks to Davi Ottenheimer and also Derek Fisher for helping us learn more about TrustOnCloud. And thanks to youTyson Garrettfrom TrustOnCloud for your time and being game to answer all these questions. As I mentioned, you didn’t know any of them before we started this show. And I thank you to our audience for listening to Security You Should Know.
[Voiceover] That wraps up another episode of Security You Should Know. If you like this program, please subscribe, tell your friends, and leave us a review. All companies showcased on this program are sponsors of CISO Series. If your company would like to be spotlighted and interviewed by our security leaders, go to our contact page on CISOseries.com or just email us at info@CISOseries.com. Thank you for listening to Security You Should Know, connecting security solutions with security leaders.