---
title: "Tony UV -- Threat Libraries in the Cloud"
url: https://appsecpodcast.com/tony-uv-threat-libraries-in-the-cloud/
date: 2018-10-16
duration_seconds: 1854
guests: ["Tony UcedaVelez"]
topics: ["Threat Modeling", "Cloud and Infrastructure", "API Security"]
audio: https://www.buzzsprout.com/1730684/episodes/8122668-tony-uv-threat-libraries-in-the-cloud.mp3
transcript: true
---

# Tony UV -- Threat Libraries in the Cloud

*October 16, 2018 · 31 min*

with [Tony UcedaVelez](https://appsecpodcast.com/guests/tony-ucedavelez/)

on [Threat Modeling](https://appsecpodcast.com/topics/threat-modeling/), [Cloud and Infrastructure](https://appsecpodcast.com/topics/cloud-and-infrastructure/), [API Security](https://appsecpodcast.com/topics/api-security/)

[Audio](https://www.buzzsprout.com/1730684/episodes/8122668-tony-uv-threat-libraries-in-the-cloud.mp3)

## Show notes

A list of weaknesses is not the same thing as an understanding of the threats facing a business. Tony UV returns to explain how a threat library can connect industry intelligence with evidence from an organization’s own systems. He distinguishes threats, attacks, and vulnerabilities, then describes how cloud logs and configuration signals can add context to a threat model. The conversation examines the feedback loop between modeling, detection, and real incidents, with examples involving sabotage, data loss, and extortion. Tony recommends starting with a manageable set of business concerns, substantiating them with evidence, and mapping the relevant attack paths and technologies. His approach gives teams a way to make threat modeling reflect what could actually harm the operation they support.

The Application Security Podcast is brought to you by [Security Journey](https://www.securityjourney.com/).

About Security Journey  
Security Journey provides application security education for developers and everyone in the software development lifecycle.  
→ [Learn more about Security Journey](https://www.securityjourney.com/)

Connect with Tony UcedaVelez:  
→ [Tony UV on LinkedIn](https://www.linkedin.com/in/tonyuv/)  
→ [VerSprite](https://versprite.com/)

Mentioned in this episode:  
→ [MITRE CAPEC](https://capec.mitre.org/)  
→ [MITRE ATT&CK](https://attack.mitre.org/)  
→ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)  
→ [FS-ISAC](https://www.fsisac.com/)

Chapters:  
00:00 Threat libraries in the cloud with Tony UV  
01:16 Continuing the threat modeling conversation  
02:30 External intelligence and internal evidence  
05:25 Validating threats in business context  
08:12 How the library supports a threat model  
12:09 Cloud platforms as sources of threat context  
18:13 The feedback loop between models and incidents  
18:55 Connecting business threats to attack patterns  
22:23 Starting with a manageable threat library  
23:14 Beyond STRIDE: evidence, extortion, and business impact

## Transcript

*4,594 words · assemblyai*

**0:00 Chris Romeo:** Welcome back to the Application Security Podcast. We're up to season 4, episode 12, which takes us to an interview with Tony UV. This is Tony's second time on the podcast, so he dives right in talking about threat libraries in the cloud.

**0:12** Enjoy.

**0:12 Tony UV:** The Application Security Podcast. Here we go. Welcome, friends. We're here for another episode of the AppSec Podcast, Application Security Podcast. It's season 4, and today I am joined by Tony Uceda-Velez, and we've had Tony UV, as he's probably better known, on before in season 1, episode 10. And we want to welcome him again. Welcome, Tony.

**1:09 Chris Romeo:** Thanks, Robert. Great to be back and looking forward to talking on what's on your mind today.

**1:16 Tony UV:** Fantastic. Last time you were here, we talked about threat modeling. Again, one of our topics that we enjoy quite a bit, and you and I have talked about it offline as well. And so that was a great episode. And you're continuing to, it looks like, speaking on threat modeling as well.

**1:36 Chris Romeo:** Correct. Yeah, I was recently in London for AppSec EU just past month and had a good crowd in London to basically address them on an interesting topic on how to build your own threat library and how to apply that threat library for some DevSecOps operations in the cloud. So it was trying to fuse some DevSecOps themes in there, trying to tie it to cloud security, and then take one facet of threat modeling, which is the building your threat library piece.

**2:11 Tony UV:** Okay. Okay. Yeah. So tell me about that. So in terms of a threat library, You know, where do you build that? How do you build that in terms of the kinds of threats? I'm assuming for cloud-based applications, you know, what is your source for those kinds of threats in particular?

**2:30 Chris Romeo:** Sure. Yeah. So the 2 sources really for building a threat library in general, and then I'll kind of dovetail into clouds more specifically, is going to be really based upon 2 key sources. Number one is threat intelligence that you can get from the outside perspective. You know, those might be industry players from the outside that you might be operating in that have— that want to share information on cyber threats, cybercriminal activities that are within your industry. So those are important to know because they speak to things like threat motives. They also speak about new techniques and attack patterns that are supporting Threats in that space. So basically, in simple terms, outside perspective. The second one is the insider perspective. So every day, networks, applications, cloud infrastructures are being attacked, and your systems are logging a lot of this type of nefarious traffic, both from the inside the organization and outside. And so a lot of times, organizations don't look at what their systems, applications, and serverless technologies are actually saying to them. So if they can harvest the power of threat data, which is the other place to get a good source to build your threat library, you can actually qualify a good threat library and say, I'm concerned about the following threats because of data that I'm actually seeing on my infrastructure and data that I know is affecting me and my industry. And then Lastly, you know, specific on cloud, cloud is that generic term that we all love to hate. Really kind of narrowing it down into platform as a service or software as a service or infrastructure as a service and now even containers as a service, cloud means different things to different people, whether you're a hosting provider or you're a software provider in a shared infrastructure. So In essence, the talk in London was really meant to— how do you create a threat library that means something to you as a cloud provider, if that's, you know, your space, and tying in elements of what you as a cloud provider might serve? For example, there might be a healthcare SaaS provider that is serving the healthcare market. So you're concerned about trends in cloud security. You're concerned about, for example, threats to multi-tenant hopping, as an example. But you also might be concerned about threats to the healthcare industry, especially the healthcare technology industry, where there might be some threat motives that might be evolving. So that, in essence, is basically the key ingredients to a great threat library.

**5:25 Tony UV:** Okay, so it sounds like, like you said, from external sources as well as internal sources and collecting those, how do you validate what is a threat? Is it just based on industry, you know, if you see these kinds of things, that's how you know you're being threatened or there's a threat here? Is that essentially the way you can identify that these are the threats that we have collected from all those data points?

**5:54 Chris Romeo:** So that's a great question. Now, on the threat data, the internal logs and alerts and incidents that you're going to be seeing, you know something's a threat when you have something amiss on your network. You know something's a threat when you have, you know, brute force attacks against an authenticated web API that's tied to, you know, a cloud component, for example. You don't really kind of have to say, hey, is this a threat? You know, because you're saying that the nefarious actions, you're able to look at the alerts that you might have in the cloud, maybe with an in-the-cloud web application firewall or some level of layer 7 inspection that is looking and saying, hey, this is bad, this is not good. But to your— on the industry threat intel, yeah, there is some level of review that has to be done. But the idea is this, that if you're in financial systems or you're a financial technology company and you happen to operate in the cloud and you happen to be moving money, there's some inherency to financial crimes. And, you know, a lot of the industry threats of I want to get into accounts, I want to move monies illicitly, I want to do money laundering, stuff like that. are things that we still have to be cognizant about even in today's digital age. So we take some of the more traditional financial fraud and financial cybercriminal, you know, criminal measures, and then we basically say, how does this happen from an industry perspective against the infrastructure that I have? Now, there's a lot of great resources. I'll stick with financial since I'm on it. FinCEN is one, FS-ISAC is another. Each country has an ISAC— or I'm sorry, each country has a CERT that is basically looking at different crimes in general, but that could also be correlated to financial systems, brokerage houses, etc. And so those are all good things, but it doesn't mean that they're a one-to-one mapping. You're gonna have to as a threat modeling expert or security champion, you're going to have to see, does this belong in my threat library? And that's where you do some level of cherry-picking.

**8:12 Tony UV:** Okay. So now that you're building out this threat library, and you mentioned about threat modeling, so what's the relationship between— now that I've accumulated this threat library, how does that help, I guess, as input into your threat model? What are some ways that you can use this threat library?

**8:29 Chris Romeo:** I mean, look, You know, threat modeling, you know, from my viewpoint in talking about this worldwide and doing this with different organizations, it is supposed to model threats. But yet when we look at how threat modeling is done status quo today, we see a lot of information, but there's no threat analysis. You see a lot of weaknesses analysis and vulnerability analysis and attack patterns. But where are the threats? And so, you know, in order to understand the value of threats, I first began talking about this in London about defining what a threat is. And many times in InfoSec, people are erroneously putting threats and attacks as synonyms. And if you look in the English dictionary, they're not. And so the benefit of a threat library is that it serves as a cornerstone to everything else in your threat model. So, you know, as a kind of a big picture of what threat you're trying to mitigate, you have underneath that attack patterns that support the threat. You have, in order to attack something, you're not going to waste your time on something that is, you know, resilient. You, as a cybercriminal, want to attack things that are observed to be weak. Right. And so you start to have this hierarchy and relationship between what is the threat, what is the attack to support the threat, what is the weakness that enables the attack to happen, and what is the target that has the vulnerability. So to answer your question in somewhat of a long-winded fashion is threats provide context. Threats provide context of what you should be worried about. And one of the things I said in London was that The great thing about a threat library is that it messages a lot better than CAPEC number 66, or if you're using CAPEC as an attack library, or, you know, an injection, you know, type of attack that you're trying to articulate. Threat models have the ability to involve architects, designers, you know, project managers, development managers, security champions. In a broader group of people than if we were just talking about weaknesses and attacks. So the value of including threats into your threat model is that it provides, A, a messaging boost to your threat model once complete. B, it provides really a kind of a parent node to your ATT&CK tree where you can start to map ATT&CK and weaknesses and affected components to the root threat that you're trying to mitigate against. And lastly, you know, one of the problems that I see, you know, worldwide with different industry groups is that you have developers always asking the quintessential question, who would do this? How would they do this? And why is this even a problem? If threats— a threat library has a way to really disarm that question. Because threats— a good threat library is going to be pretty simple, pretty obvious, and it's not going to be very extensive. And it provides a way so that you could rationalize how threats are related to the other parts in a threat model, like your attacks, like your use cases, like the weaknesses that might be affecting those use cases, et cetera.

**12:06** Okay.

**12:09 Tony UV:** Great. I was looking at the description here of your talk at AppSec Europe, and it mentions that you were looking at both Azure and AWS components to leverage when adding threat context and ultimately an amazing threat library. So I'm curious about if you can speak to it today about, you know, what are some of those components that are out there then available? I know those are a couple of the options for cloud-based applications. Obviously, there are many more, but those are probably the most well-known, Azure and AWS. So what are some of those components, if you can talk about that?

**12:47 Chris Romeo:** Sure. I mean, the great thing about— now, I will clarify when we talk about cloud that we're not talking about the virtualized instances that you might have of your virtualized you know, CentOS box or your virtualized Ubuntu server, Windows Server, etc. We're not talking about that. We're talking about the cloud abstraction layer that governs things like access control and policies for routing traffic between virtual private computing groups and domains, you know, defined VPN endpoints that are in your cloud. We're talking about things that are typically governed through a web interface. Cloud insecurities is really a byproduct of the lack of proper configuration on access control, on architecture, on so many different things. And that, of course, sits on top of yet trying to harden the, you know, the different instances like your databases, your caching systems, etc. So when we talk about the talk in London, there's things in Azure and in AWS that can lend to feed into a great threat library. For example, if you enable CloudTrail and you enable certain types of logging on different types of cloud components in Azure, you can really feed your threat library based upon a set of threats that you've defined. In the talk in London, I picked on the oil and gas industry because it's one of those industries that is late to the game in terms of adopting cloud compared to other industries that are out there. And so I basically talked about how this one international multinational company has developed an oil analytics platform in the cloud, with the help of a 4th party. And it basically provides a lot of great information on where new R&D opportunities are and how the performance of their well spots are performing. And so the business case I provided there is, what are the threats to such a company? And in doing the research behind this, What was interesting is that the competitive landscape for finding resources that can be mined for oil and gas is extremely competitive. Knowing what locations are out there and can be mined, as well as what well spots are going to produce certain levels of quantity and different metrics on that quality of crude, is something that is basically a competitive advantage. So, you know, we talked about, you know, in a very simple way, integrity of information and the availability of those systems is super important for the oil and gas industry. So, if you take those 2 pillars of general security themes, integrity of data, because you're mining this data, Right? And your performance is basically helping you to make decisions. By the way, like going back 30 years, all this would be done by local engineers with laptops at the well spot. But today you have sensors that are talking to the cloud and reporting back data. And so continuity and integrity of data is super key. So just think about the threat of sabotage. You're competing against a multinational company, and you're trying to basically affect their performance levels, their quality levels, or something, and you want to disrupt sabotage is a legitimate business threat. And so, from a technical standpoint, what can you do? Is your cloud-related SaaS platform that is governing the effectiveness and measurements of your data mining operations, of your wellspot operations, how is that actually affected by a complete disruption? So we begin, you know, there provides an example where we could look at Azure, we could look at Azure Hybrid or now formerly Security Manager, and start to pull in the types of incidents or events, better said, that could actually be concerning to us. You know, when we see security events that relate to downtime, that relate to deprecation of service and performance, then it fits in our threat library because we're concerned right now with continuity. And let's say we have other types of logs that feed into violations of access control. Well, because it fits in our threat library node of sabotage, we can now start to feed events from our infrastructure in Azure to basically support and say, hey, we have some heightened events that actually we're concerned about because it's part of our threat model. So therein lies kind of how it all ties together.

**18:13 Tony UV:** Okay. So it's kind of a full circle here, right? So you're gathering data and that's input into your threat model. But then you now you have your threat model which then can help guide into what you're looking for, or when you see some incidents or you see some data that comes out and say, aha, that goes in this bucket, that goes in that, and we see that it's happening and we have a better idea or understanding how our threat model works and how it's proven by the data that we see. And so it's kind of again the kind of that full circle of of getting the data and reinforcing what we know and improving with that, of course, with mitigation and so on, it sounds like.

**18:55 Chris Romeo:** Right. Yeah, absolutely. I mean, the first step is to define your threat library, and that's really a human effort that is driven by evidence, right? Evidence from the outside, evidence from your systems from the inside. And you could say, well, I'm concerned about threats related to sabotage because you know, oil wells have been sabotaged before, or there has been R&D leaks. So I'm concerned about information disclosure of R&D data related to, you know, some new discoveries that we're doing, maybe some underwater discoveries or some satellite imaging or whatever. So just right there, those are 2 threats, right, that you could basically begin to map out. Well, if I'm concerned about sabotage, What are the types of, you know, associated technologies, use cases that I have in my applications or systems that support attack patterns that would actually realize this threat? And so you start to tie all the pieces. Once you basically fast forward to the end and you say, okay, I've connected how sabotage could happen logically for a cloud-based system because— and I've substantiated it with events that are happening to establish credibility that, you know, like, for example, let's say that we had talked about access control. Let's say there are some access control violations that are happening a lot for this SaaS platform that was discussed. Well, do we care? Do we not care? Devoid of a threat library, we would have— we would ask that question and say, well, we care because it's not best practice to have that. And that's true, but where do we put that in the queue of tackling for remediation, right? You know, usually it's like, oh, you know, we'll assign a criticality based upon something that's really just subjective, like a framework or a best practice or a top 10 or whatever. And the reality is this: those top 10s and those industry frameworks, they know nothing about your business. They didn't develop, you know, they didn't fund your business. They didn't go out there and do the R&D for where the, you know, oil reserves you're going to try to research. They didn't lay down the pipeline and infrastructure. So I always kind of laugh at this because it's like, how does an outside security best practice framework know some of the damaging things that are affecting your business? And the reality is it doesn't. And so the threat library provides that level of context that helps to build a great threat model, but it also helps the message to the people that actually care about the business. And it could be vertically up or horizontally within the organization.

**21:41 Tony UV:** After the break, Tony explains more about how you can get started with building a threat library. The Application Security Podcast operates with support from Security Journey. A Security Belt Program provides the 3 pillars of successful AppSec training: learning, application, and experience. Visit us on the web at www.securityjourney.com to learn how you can teach and empower your developers using a new kind of security training. Tony dives back in with some steps to begin building a threat library.

**22:23 Chris Romeo:** Well, it's a lot easier than one might think. I mean, the first step is really begin with a manageable threat library. And my 101 version of that is to begin with the CIA triad and say, let's begin with, like, themes of threats that you're concerned about. You know, are you concerned about the threat against confidentiality? Are you concerned about the threat against integrity? And think of it from the context of the business operations that that application or system supports, whether it be in the cloud or on-prem. And so, you know, so the first step is build your threat library. Stride is not going to be your threat library because it's a mnemonic, and it's helpful to remember what you could, you know, throw into those 6 buckets, but—

**23:12 Tony UV:** Yeah.

**23:14 Chris Romeo:** You know, what happens if you're concerned about extortion? Where do you put extortion underneath STRIDE? You don't put it anywhere. And extortion is a rising threat that's affecting different types of systems. In fact, there's been several cloud operators that have actually gone out of business because of poor code security, and they actually shut their doors. And this was going back, I think, 7 years ago. There was a company out in San Francisco because of extortion. So if— think about the things that are going to be detrimental to your application, to your business, and just write those down. Is it insider threat? Is it sabotage? Is it, you know, data exfiltration? Go ahead and begin to define things based upon what you know of your industry. And then once you basically— and you can work with that collaboratively with other key members of your organization. Step 2 is now it's time to substantiate stuff. Let's not play Chicken Little. Let's try to build some credence into this library. Get some resources from the outside in the form of threat intel and get some evidence from your infrastructure that supports maybe that these are some concerns that you actually might be having right now. If, for example, if one of your concerns is insider threat because maybe you operationally, your organization or your dev team has a high mix of non-employees that are from outside organizations and you have less visibility on what is being done, combined with, let's say, you recognize that your contracts with external companies within your company is really poor. then you could be at risk for some intellectual property theft. So you basically, you know, you want to be able to substantiate that threat claim with evidence of, let's say, that you maybe have some illicit access control violations to code repositories, to, you know, servers, systems, cloud infrastructure, whatever the case may be. And so you start to map your threat library with evidence from the outside, evidence from the inside. And then the next step is just simply, it provides a blueprint for what attacks are going to realize these threats. So, you know, let's talk about pen testing for a second, and let me stick with the same vein of access control violations. So you're concerned about access control violations that are superfluous, and you're concerned about insider threat. Well, when you're doing a pen test, one of the abuse cases that you oftentimes do is you basically provide for what could be done using PrivEsc or privilege escalation under certain user contexts. And so if you're— therefore you're testing what are the abuse cases you can do with certain roles in the application. And so now you're testing the viability and the impact of that attack in support of that threat. And then you map the weaknesses. Well, okay, let's say the attack is successful. Why was it successful? Well, is it because of the poor entropy on a session token on a web API that allowed the attacker to actually escalate their privilege to another role or user by guessing a token ID for a higher user role?

**26:48** Yeah.

**26:49 Chris Romeo:** then all of a sudden, now you have a weakness that's correlated to an attack pattern that's correlated back to your threat, that's correlated back to your threat library. So, you know, in this example that I've provided, the beauty is that it provides an outline for even how to pen test. And, you know, based upon a threat library that you care about. Now, if you want to pen test everything in the world and do things status quo, that's great too. But time is money. And oftentimes, a lot of these engagements are timeboxed, but that's a good way to get started.

**27:21 Tony UV:** Yeah, I was going to say for pen testing, like you said, a lot of times timeboxed. You don't have infinite amount of time, infinite resources. You only have a limited amount of time, only so many things you can test. And like you said, you can test the world, but you're not going to get there. And if you could be more specific, especially focusing on the things that actually do make sense in your system, things that you've actually seen or have been seen that are in your threat library, and verify, are we still, or do we still have that issue? Is it still there? And so on. So yeah, no, I definitely see the value. And that's true anyway of threat modeling and in terms of helping you understand better about what could go wrong. It sounds like the threat library can certainly as input help you not just think about what could go wrong, but you have a pretty good idea of what is potentially going wrong with some of the data that you've been collecting.

**28:15 Chris Romeo:** Right, exactly.

**28:17 Tony UV:** Or potential, right? Because that's when you're building it initially, you're thinking about some of those things about those areas and the types of threats. So, okay, very good, very good. All right, well, thanks, Tony. I appreciate it. It was good to talk with you again here. Curious, are you speaking on this topic or any others Coming up in any conferences soon?

**28:41 Chris Romeo:** Yeah, I'm actually speaking at the ISSA chapter here in Atlanta on this topic, but, you know, looking to evolve this talk into other industries, especially in the United States with more critical infrastructure. So my goal is to basically take a different slant on it and really maybe address Department of Energy or Department of Transportation. and how building a threat library can actually help to lead for more poignant security, you know, testing and measures for those, you know, different industries. But that's what's next up for me. And, you know, hopefully we'll get just as good of a rewarding— it was a great audience in London, and hopefully looking forward to the same here stateside.

**29:27 Tony UV:** Great.

**29:29** Great.

**29:29 Tony UV:** Any last words to our listeners? on this topic or any others that you've been covering?

**29:33 Chris Romeo:** Just, you know, adopt threat modeling. You know, it's a great practice if done correctly. It's extremely collaborative. It's gaining a lot of speed and attention. And I would just invite anyone to, you know, check out a risk-centric approach called Process for Attack Simulation and Threat Analysis, also known as POSTA. as a risk-focused approach on threat modeling things that matter. So invite all the listeners out there to check it out. And if they do have any interest or questions, they can always follow me on Twitter @t0nyuv, and I'll be able to DM them back.

**30:15 Tony UV:** Okay, great. Well, again, thanks, Tony. Appreciate your time.

**30:20 Chris Romeo:** Thanks, Robert. Great being on the show again and talking you soon.

**30:24** Thanks for listening to the Application Security Podcast. If you enjoy the podcast, please do us a favor and visit the iTunes Store and give us a 5-star rating. Our intro music is 8-Bit Kung Fu by Born and TJ, and the outro is Southern Delight by Stefan Cartenberg. You can find us on Twitter @appsecpodcast or on the web at www.appsecpodcast.org.

---

Source: https://appsecpodcast.com/tony-uv-threat-libraries-in-the-cloud/