then we'll go back for the deficit. Cops less than 3.7, its threat modelling. But we're gonna do another demo here. Just take a look at the old wasp
threat Dragon Tool. Just going to give you a perspective of actually
performing threat modelling. If you're doing this for your application, will use their their demo database that they have but help. You can understand the concepts.
So in this video, just again the objectives what we're gonna go through is developing a threat catalog with the Threat Dragon tool. And then you'll see that PW that one which maps back to the niss S S d f. With your software framework where we have some requirements were going associate threats to risks. That's again pw dot to,
and we're gonna take a look at that. See that different components of its actors. The data stores where obviously, where the data is located,
uh, data flows and then trust boundary between each one of the components.
So here's the link. If you want to follow along, if you want to try it out as well, you goto lost project This threat dragon downloaded. It works on several different operating systems.
And then I've also brought in this ah security intelligence dot com blogger have information about threat modelling just to kind of talk through some of the components. Aziz looking at threat modelling
because I've opened up the loss threat Dragon application here. It's a little bit cut off here, but the good bonus you need to look at her are what, since in the window here,
you would start off. If if you were creating a threat threat model, you would you would use this open you create your own model. What's nice is that they, like Teoh, just have a tutorial. So they've created a demo model so you can just click on the bottom right there.
Load the model and it's already pre populate with some of the information you might be interested in. Just in just learning
one of the components you need toe, just understand, so that as you're building, this is pretty simple. It really only
five pieces here you can work on. So the first idea is the actor. So in this, this would be a trusted insider or it could be an untrusted insider. You do document at any of these thes thes components. This could be trusted external, untrusted, external and even said you want associate or understand who the actor is, and it could be a person,
or it just could be a piece of software.
So, for example, we have, ah browser here. It's sent to a user behind a browser. But if it was a P I or or a different type of interactive software or non interactive saw for application, you were deploying. That could be your actor.
And so the next is the data store. So in here it is the just a line above and below it where it's a store. In this simple application, it could be a message queue. There there's a worker configuration. There's an actual data base. There's a Web application configuration,
so the idea of data stores anything so you might have a database that's internal. You may have a database. It's external.
They could be a configuration file like we see here a message queue. You could have structured any unstructured data. Any of this is where your data stored, and so it's important to model that in the in the in, in this threat, modelling
The next idea is a data flow. So you'll see here between the browser and Web application. There's a request and there's a response. So a data flow similar to the store could be trusted. Internal data You could have trusted external data
are untrusted external data. So again, we have this idea of internal, external, trusted untrusted. We wanna make sure you explain exactly exactly what that is within a threat model. So if anybody's looking at it that you really have a good idea or an understanding what the threat is,
and when you start looking at data flows you want, you want to start thinking about what security controls are in place.
What trust boundaries, which is the next component will talk about and really understand how to follow the data.
The last component is you'll see. Here's the trust boundary, which is the dotted line, so that delineates between the actor of the data store and the data flow to show that this is decided trust or this side I don't trust,
and it could also it does not to be completely trusted untrusted. It's just different types of security control. So you may have
one database that has more security in it, or how it is set up that you have a little bit more trust. Do it.
The idea is to look at the source of the data and identify the targets. And then you could have multiple data flows like we see in a request their incoming outgoing
any type of encryption. Anything you want to put into their or yeah, you need. That's part of the threat modelling.
And then, for example, you could have 1/3 party that you might have might be a little bit more trust in the general public. So he would look at what happened mou with them a memorandum of understanding anything where we understand each other's secure security controls and how we're protecting the application.
And at this point, just when I kind of jump investigated and said it was just talking about the tool again and just have a another one, these questions for you, why are we interested in threats?
So we're interested because we need to make sure we have the right tools. So if that for the vulnerabilities and these threats that are specific to your organization. So if you have again, if you're in the medical field, whatever field you're in, you may have some specific specific threat, or you may have a specific application.
And if you just go out, pick whatever tools I tell you or somebody else tells you may not actually be
testing the threat, so these possible risks specific to that threat. So we want to make sure we know our organization. We know the application. We know that risks and the threats, and then we have the right tools that can evaluate those and find them. Hopefully, in the deficit got process.
It's an alley. We defined each one of the types who can take a look at the threats that have been. Did you can associate with the components and specifically here in the demo model
that's loaded by the wife's tool.
So in here, let's take a look First. You could look at this Web application. Config is that this is a component, they added, that says it stores credentials, and when you click on the component
gets populated, we're up. Here are the threats that you've defined. So this one there was only one threat.
You can have multiple threats against you that little bit later.
So this one says there is The threat is credential should be encrypted.
And then you'd if you define the stride threat type,
which is a little too much did to look at in this demo, but
you take a look at it. But it's enough to just understand that that Stride is the acronym for spoofing, tampering, repudiation, information disclosure, denial, service or elevation of privilege that you picked that our map it to the threat you're interested in
for your application, and you can have a threat status of open or mitigated. You might want to keep threats there and label Miss Mitigated. Just so you understand what controls were put in place in case anything changes in the future. You don't lose. The concept of threats are already there.
You pick a severity,
and then you have see at a description here and then if if there are any mitigating controls, for example, this one says the message to credential should be encrypted, so if they are, then that would mitigate this security risk.
There's other ones. So, for example, there's there's there's a read worker here This one doesn't have any threats, but you can mark it as out of scope. You can say whether it's encrypted anything like that.
You can associate threats with processes. So, for example, this background worker process that they mentioned has two different threats here.
It's actually one
threat they've defined.
This is the attacker could generated malicious messages that the background worker cannot process. Looks like the reason they broke this out to two is because they have two different mitigating or mitigations for this risk, and they want to do instead of keeping it one, break it out to multiple mitigation steps, which is interesting way to do it. And if you want to capture that way, that
that would be a way, especially if you think in the future or at some point
you may be able to mitigate one and not the other one.
They see they picked the different stride threat type here of denial of service
so you can really go through. And this is it's the great step, just or even a process just to understand the applications try to go through each one of these, labeling all the components, identifying the threats and then obviously mapping your tools in the depths Checkups pipeline to make sure you are capturing or are
checking whether these threats have been mitigated as they were stated in a mitigation control.
A demo of Threat Dragon
in this module hope you learned a lot and can use those concepts in your depths. Takeoffs when you're looking for tools
and next will recap the model since we've reached the end.