VerSprite Podcast: Threat Libraries in the Cloud

Tony UcedaVélez is CEO and Founder of VerSprite, a global counterculture security consulting firm based in Atlanta. If you’d like to learn more about his threat modeling methodology, feel free to direct message Tony on Twitter @t0nyuv.

What is PASTA Threat Modeling?

PASTA is the Process for Attack Simulation & Threat Analysis and is a risk centric threat modeling methodology aimed at identifying viable threat patterns against an application or system environment. Learn More →

Transcript of Podcast:

Robert: Welcome friends. We’re here for another episode of the Application Security Podcast. It’s season four, and today I am joined by Tony UcedaVelez. We’ve had Tony on before in season one, episode ten, and we want to welcome him again. Welcome Tony!

Tony: Thanks Robert. Great to be back and looking forward to talking on what’s on your mind today.

Robert: Fantastic. Last time you were here, we talked about threat modeling, one of our topics that we enjoy quite a bit. You and I have talked about it offline as well, so that was a great episode. It looks like you are continuing and speaking on threat modeling as well.

Tony: Correct. I was recently in London for AppSecEU this past month and had a good crowd to address them on an interesting topic – how to build your own threat library and how to apply that threat library for some DevSecOps in the cloud. So it was trying to fuse some DevSecOps themes, tying it to cloud security, and then take one facet of threat modeling, which is the building your threat library piece.

Robert: Tell me about that. In terms of a threat library, how do you build that in terms of the kinds of threats for, I’m assuming, cloud based applications? What is your source for those kinds of threats in particular?

Tony: Sure. The two sources for building a threat library in general – and then I’ll kind of dove tail in cloud more specifically – is going to be based upon two key sources. One is threat intelligence that you can get from the outside perspective. Those might be industry players from the outside that you might be operating in that want to share information on cyber threats or cyber criminal activities that are within your industry. Those are important to note because they speak to things like threat motives, new techniques, and attack patterns that are supporting threats in that space – in simple terms, outside perspective.

The second one is the insider perspective. Everyday networks, applications, and cloud infrastructures are being attacked, and your systems are logging a lot of this nefarious traffic from both the inside and outside of the organization. A lot of the time 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 I’m seeing on my infrastructure and data that I know is affecting me and my industry.”

Lastly, specifically on cloud, “cloud” is that generic term that we all love to hate. Really narrowing it down into platform as a service, software as a service, infrastructure as a service, or now even containers as a service, “cloud” means different things to different people whether you’re a hosting provider or a software provider in a shared infrastructure.

In essence the talk in London was meant to discuss how do you create a threat library that means something to you as a cloud provider, if that’s 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 or threats to multitenant hopping, but you also want to be concerned about threats to the healthcare industry, especially the healthcare technology industry where there might be some threat motives evolving. Those in essence are the key ingredients to a great threat library.

Robert: Okay, so it sounds like external sources as well as internal sources, and collecting those. How do you validate what is a threat? Is it just based on industry? If you see these kind of things, is that how you know you’re being threatened or there’s a threat here? Is that essentially how you identify that these are the threats that we have collected from all those data points?

Tony: That’s a great question. On the threat data, on the internal logs, 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 root force attacks against an authenticated web API that’s tied to a cloud component.

You don’t really have to ask if is this a threat because you’re seeing the nefarious actions and you’re able to look at the alerts that you might have in the cloud, maybe within the cloud web application firewall, or within some layer seven of inspection that’s looking in.

This is not good, but on the industry threat intel, there is some level of review that has to be done. But the idea is 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 is some inherency to financial crimes. A lot of these industry threats of “I want to get into accounts. I want to move monies illicitly. I want to do money laundering” 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 cyber criminal measures and then we ask how does this happen from an industry perspective against the infrastructure that I have?

Now there are a lot of great resources. I’ll stick with financial since I’m on it. Finsent is one, FFISEC is another. Each country has a CERT that is looking at different crimes in general that can also be correlated to financial systems, brokerage houses, etc. and those are all good things, but it doesn’t mean that they’re a one-to-one mapping. As a threat modeling expert or security champion, you’re going to have to ask “does this belong in my threat library?” and that’s where you do some level of cherry picking.

Robert: Now that you’re accumulating this threat library, how does that help as input into your threat model? What are some ways you can use that threat library?

Tony: From my viewpoint in talking about this worldwide and doing this with different organizations, threat modeling is supposed to model threats, but when we look at how threat modeling is done status quo today, we see a lot of information but no threat analysis. You see a lot of weaknesses analyses, vulnerabilities analyses, and attack patterns, but where are the threats? In order to understand the value of threats, I first defined what a threat is, and many times in InfoSec people are erroneously putting “threats” and “attacks” as synonyms.

If you look in the dictionary, they’re not. The benefit of a threat library is that it serves as a cornerstone to everything else in your threat model. As a big picture of what threat you’re trying to mitigate, you have underneath that attack patterns that support the threat, and in order to attack something, you’re not going to waste your time on something that is resilient. You as a cyber criminal want to attack things that are observed to be weak.

So you start to have this hierarchy in relationship between what is a 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, threats provide context and context of what you should be worried about.

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 66” or if you’re using CAPEC as an attack library or an injection type of attack that you’re trying to articulate. Threat models have the ability to involve architects, designers, project managers, development managers, security champions in a broader group of people than if we were just talking about weaknesses and attacks.

The value of including threats into your threat model is that it provides A) a messaging boost to your threat model once complete, and B) it provides a parent node to your attack tree where you can start to map attacks and weaknesses and affected components to the root threat you’re trying to mitigate against. Lastly, one of the problems that I see 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?

A threat library has a way to really disarm that question because with a good threat library, which is pretty simple, pretty obvious, and not going to be very extensive, it provides a way so that you can 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, etc.

Robert: Okay, great. I was looking here at the description of your talk at AppSecEU, and it mentions that you were looking at both Azure and AWS components to leverage when adding threat contexts and ultimately amazing threat modeling library, so I’m curious if you could speak to it today. What are some of those components out there then available?

Tony: Sure. I will clarify when we talk about cloud, we’re not talking about the virtualized instances that you might have of your virtualized Centos box or your virtualized Ubuntu server, Windows server, etc. We’re talking about the cloud extraction layer that governs things like access control and policies for routing traffic between virtual private computing groups and domains, defined VPN endpoints that are in your cloud.

We’re talking about things that are typically governed through a web interface. Cloud insecurity is really a biproduct of the lack of proper configuration on access control, on architecture, on so many different things, and that of course sits on top of trying to harden the different instances like your databases, your caching systems, etc.

When we talk about the talk in London, there are things in Azure and AWS that can lend to feed into a great library. For example, if you enable CloudTrail and you enable certain types of logging of cloud components in Azure, you can really feed your threat library based upon a set of threats that you can find.

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. I talked about how this one multinational company has developed an oil analytics platform in the cloud with the help of a fourth party, and it provides a lot of great information on where new R&D opportunities are and how well their well spots are performing.

What are the threats to such a company? The research behind this was interesting in 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.

The different metrics on that quality of crude is something that is a competitive advantage. We talked about in a very simple way integrity of information and the availity of those systems is super important for the oil and gas industry, so if you take those two pillars of general security themes – integrity of data because you’re mining this data, and your performance is basically helping you to make decisions. By the way, going back thirty years, all of this would be done my 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.

Just think about the threat of sabotage. You’re competing against a multinational company, and you’re trying to affect their performance levels or quality levels, and you want to disrupt. Sabotage is a legitimate business threat, and from a technical standpoint, your cloud related SaaS platform that is governing the effectiveness and measurements of your well spot operations – how is that actually affected by a complete disruption? There provides an example where we can look at Azure or Azure Hybrid, formerly Security Manager, and start to pull in the types of incidents, or events better said, that could actually be concerning to us.

When we see security events that relate to down time or deprecation of service and performance, then it fits in our threat library because we’re concerned right now with continuity. Let’s say we have other types of logs that feed into violations of access control. Because it fits in our threat library node of sabotage, we can now start to feed events from our infrastructure in Azure to support and say we have some heightened events that we’re concerned about because it’s part of our threat model. Therein lies how it all ties together.

Robert: It’s kind of a full circle. You’re gathering data that’s input to your threat model, and then now you have your threat model which can then help guide into what you’re looking for when you see some incidents or data that comes out and say “aha, that goes into this bucket and that goes in that,“ and we see that it’s happening and have a better idea or understanding of how our threat model works and is proven by the data we see. So it’s kind of a full circle of getting the data, reinforcing what we know, and improving with mitigation and so on.

Tony: Absolutely. The first step is to define your threat library, and that’s really a human effort that is driven by evidence that’s from the outside, from the systems from the inside. You could say I’m concerned about threats related to sabotage because oil wells have been sabotaged before, or there have been R&D leaks, so I’m concerned about information disclosure of our R&D data related to new discoveries that we’re doing. Maybe it’s some underwater discoveries or satellite imaging. So just right there, those are two threats that you could begin to map out.

If I’m concerned about sabotage, what are the types of associated technologies use cases that I have in my applications or systems that support attack patterns that would actually realize as threats, and so you start to tie all the pieces.

Once you fast forward to the end and you’ve connected how sabotage could happen logically for your cloud based system and substantiated it with events that are happening to establish credibility – for example, let’s say that 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? To void up a threat library, we would ask questions like we care because it’s not best practice to have that, and that’s true, but where do we put that in queue of tackling for remediation? Usually it’s like oh, we’ll assign a criticality based upon something that’s really just subjective like a framework or a best practice or a top ten, and the reality is this – those top tens and those industry frameworks know nothing about your business. They didn’t fund your business. They didn’t go out there and do the R&D for where the oil reserves are orlay the pipeline infrastructure, so I always kind of laugh at this.

How does an outside security best practice framework know some of the damaging things affecting your business? The reality is that it doesn’t. The threat library provides that level of context that helps to build a great threat model and also helps to message to the people that actually care about the business, and it could be vertically or horizontally within the organization.

Robert: It’s really applying what the data says, like you said, gathering the evidence and building the threat library based on real world scenarios because it’s your business and you’re trying to understand it better, how customers use it, how internal customers use it, and so on to help you better understand what’s going on, the security, and improve it.

Tony: Exactly.

Robert: So say we have a listener who has something they’re hosting on the cloud or is wanting to, what do they need to do to get started with something like this?

Tony: Well, it’s a lot easier than one might think. The first step is really to begin with a manageable threat library, and my 101 version of that is to begin with a CIA triad and with themes of threats that you’re concerned about. Are you concerned about threats against confidentiality, or 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.

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 throw into those six buckets, but 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. This is going back seven years ago. There was a company out in San Francisco because of extortion. So think about things that are going to be detrimental to your application, to your business, and just write those down.

Is it insider threats? Is it sabotage? Is it data exfiltration? Go ahead and begin to define things based upon what you know of your industry, and you can work with that collaboratively with other key members of your organization. Step two is now it’s time to substantiate stuff. Let’s stop playing 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 these are some concerns that you might be having right now.

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 outsider organizations and you have less visibility on what is being done combined with you recognizing that your contracts with external companies within your company is really poor, then you could be at risk for some intellectual property theft.

You want to be able to substantiate that threat claim with evidence of you having some illicit access control operations to code repositories, server systems, cloud infrastructure, whatever the case may be. So you start to map your threat library with evidence from the outside and from the inside, and then the next step is it simply provides a blueprint for what attacks are going to realize these threats.

Let’s talk about pen testing for a second, and let me stick with the vein of access control violations. You’re concerned about access control violations that are superfluous, and you’re concerned about insider threat.

When you’re doing a pen test, one of the abuse cases that you oftentimes do is you provide for what could be done using PrivEsc or privilege escalation under certain user contexts, and so therefore you’re testing what are the abuse cases you could do with certain roles in the application. Now you’re testing the viability and the impact of that attack in support of that threat, and then you map the weaknesses.

Say the attack was successful. Why was it successful? Is it because of the poor entropy in 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? Then all of a sudden now you have a weakness that is correlated to an attack pattern, your threat, and your threat library.

In this example, the beauty is that it provides an outline for even how to pen test, and is based upon a threat library that you care about. 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 time boxed. That’s a good way to get started.

Robert: Like you said, pen testing is time boxed. You don’t have an infinite amount of time and resources. You only have a limited amount of time, and there are only so many things you can test. You can test the world, but you’re not going to get there.

If you focus on things that actually do make sense in your system, things you have actually seen that are in your threat library and verify if you still have that issue, if it’s still there, and so on.

I can definitely see the value, and that’s true anyway of threat modeling in terms of helping you understand better what could go wrong. It sounds like the threat library could certainly as input help you think about not just what could go wrong but you have a pretty good idea of what is potentially going wrong with some of the data you’ve been collecting.

Tony: Right, exactly.

Robert: Or potential because that’s when you’re building it initially when you’re thinking about those areas and the types of threats. Okay, very good. Thanks Tony! I appreciate it. It was good to talk with you again. Curious, are you speaking on this topic or any others at any conferences soon?

Tony: I’m speaking at the ISSA chapter here in Atlanta on this topic, but I’m looking to evolve this talk into other industries, especially in the US, with more critical infrastructure.

My goal is to take a different slant on it and maybe address the Department of Energy or Department of Transportation on how building a threat library can actually help the lead for more poignant security testing and measures for those different industries. That’s what’s next up for me. It was a great audience in London and hopefully looking forward to the same here stateside.

Robert: Great. Any last words to our listeners on this topic?

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

Robert: Okay, great! Thanks again Tony, appreciate your time!

Tony: Thanks Robert. Great being on the show again, and talk to you soon!