Part 2 Explanations
Video Activity
This lesson opens with an overview of threat modelling. Essentially, threat modelling involves the following key points: • Identify exposure points in the design • Identify areas of the system that might go wrong in coding, design and deployment The instructor shares a few resources about threat modelling such as books and you can purchase as well ...
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or
Already have an account? Sign In »
Video Description
This lesson opens with an overview of threat modelling. Essentially, threat modelling involves the following key points: • Identify exposure points in the design • Identify areas of the system that might go wrong in coding, design and deployment The instructor shares a few resources about threat modelling such as books and you can purchase as well as downloads. When performing threat modelling; it is important to keep the following four questions in mind: 1. What are you building? 2. What can go wrong? 3. What are you going to do about the stuff that can go wrong? 4. Did you do an acceptable job on points 1-3? There are different approaches to threat modeling, including: • STRIDE: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege • Attack trees • Privacy tools All of these work in different ways and have their own advantages. The main focus of this lesson is STRIDE as it has many steps.
Video Transcription
00:03
Welcome to the cyber Eri i t secure coding course.
00:09
This is the threat modeling section. So what exactly is threat modeling? Well, to describe it would be
00:17
an exercise where programmers and designers
00:22
and even business analysts could work together to identify exposure points that are in the design of a system.
00:32
Basically, what you're trying to do is identify the areas of a system that could go wrong,
00:38
whether it's in the design, the actual coding or the application code,
00:45
as well as during the deployment or after the application has been deployed in production.
00:52
Now,
00:53
to tell a programmer to think like a hacker
00:56
doesn't always resonate with programmers. Lot of programmers learn how to program by thinking about only happy paths. And so it takes a little bit of practice
01:10
and also some tools to actually help programmers and designers to work together in order to identify these exposure points in the design.
01:21
Now the reference tool that I'd like to recommend to you is Adam Show Stacks book on Threat modelling. We're actually going to take a look at the card game that he produced from this book that helps teams in threat modeling will
01:38
describe. I'll describe the game to you, and we'll also look at a demo of thegame later in our module. Now, when performing threat modeling, you basically want to ask yourself four questions.
01:53
What is it that we're building? Is it a new application, or is it a new module or functionality that were adding to an existing application?
02:01
So the requirements become very important in understanding the scope of your threat model?
02:07
Now, the second question to ask is What can go wrong?
02:10
Think about Instead of the Happy Path.
02:14
Try thinking about exception, case scenarios, errors that could occur
02:20
and any possible bugs based on more details about the application and about the flow.
02:28
Now the third question is, What are you gonna do about the stuff that can go wrong? So this is where our mitigation techniques start coming into play. We need to apply our secure design principles that we learned about the secure coding techniques,
02:45
any search standards, basically anything that we can draw from,
02:49
whether it's from our coding standards or lessons learned in the past that we can use to mitigate the areas of problem.
03:00
Now, once I show you the elevation of privilege card game.
03:04
That game is actually going to help you
03:07
to identify those exposure areas, as well as identifying mitigation techniques or possible mitigation techniques that can be applied to address the problem.
03:17
And then, finally, the fourth question is, Did you do an acceptable job at 133? Now
03:25
the last question takes some time to get answered because you really need to have
03:31
a review off the architecture again. You need to go through your security secure coding review. Whether that is using static code analysis tools, dynamic analysis tools, manual code reviews,
03:46
um, so and then you need to also include, um, the results of the Q A security test cases and the success criteria associated with that
04:00
as well as any kind of results from using programmer fuzzy ing, whether it's with a proxy tool or fuzzing tool that basically help you to assess how well you've done in the 1st 3 questions. Now there are different approaches to threat modeling.
04:19
We're going to take a look at stride in detail until I'm going to save
04:25
explanation for that. For later slides.
04:29
You can also use attack trees now attack trees, air generally generated from a red team exercise, which is basically
04:38
some company that's either hired
04:40
ah from the outside or could be an internal group that acts as an adversary against your network against your applications.
04:48
And what they do is they generally graph out the points of intrusion, the points of exposure, where they've done some pivoting inside of your network in order to perform the attack.
05:02
And then, basically, you can take those graphs. You can take that analysis and actually study it to better understand the vulnerabilities and exposure points in your system.
05:13
Now the other way that you can do some threat modeling is with the use of privacy tools. Privacy tools are very handy if you need to expose where M. P I or PC I data may be hidden inside of your network, and this is not necessarily
05:31
malicious intent at all. It could be that business processes over the years
05:36
have created a ah way of sort of sharing information that actually makes a vulnerability. For example, in a business process where data is exchanged through
05:53
spreadsheets and those spreadsheets actually contained credit card numbers or so security numbers and they're placed on a share Dr. Because that's the easiest way to
06:02
share information across the globe. And so that actually creates, ah problem for the for the company because that information actually needs to be protected. But it's just being exposed unencrypted
06:17
on a shared drive, so privacy tools can help you to identify these things.
06:23
Now, as I mentioned, we're going to to spend a lot of time looking at stride. And so first, let's go ahead and look at the acronym and see what it stands for. The essence Dr stands for spoofing. It's spoofing, tampering, repudiation,
06:38
information, disclosure,
06:40
denial of service and elevation of privilege. So let's understand stride and why it's useful now. The threat of spoofing
06:48
is basically a violation of authentication. This is where someone is pretending to be somebody else. Or it could be that there's the spoofing of an I P address that's pretending to be something other than what it really is.
07:05
Tampering has to do with a violation of integrity. So this is where there's some sort of modification that has occurred in the middle of a transmission or a modification that has occurred, maybe with a file on a disk,
07:21
and so a tampering. Of course, we have to have integrity checks to fight against repudiation.
07:30
Repudiation is a violation of non repudiation. Basically, repudiation is a claim that an attacker or someone can state that they didn't actually do something. Aah! And they're not responsible for that action. The reason why
07:47
they can reputed is because there's actually no
07:51
validation or verification that's provided to basically counter their claim. So
08:00
now repudiation CA NBI honest or faults? And the key question for system designers is what evidence do you have? So this is where authentication becomes very important rate, as well as thean formacion that you log,
08:13
uh, in so
08:16
information disclosure is basically a violation of confidentiality.
08:22
This is where information is able to be seen when someone is not authorized to actually see it.
08:28
Denial of service is a violation of availability.
08:33
This is where resource is on a particular system, are so overwhelmed or absorbed that they make a particular service completely unavailable,
08:45
and it doesn't have to just be a Web service or a Web application.
08:50
It could also apply thio
08:54
anti virus scanners. Particular threats and attacks can actually disable any virus scare and scanners in order to
09:03
allow for the distribution of a payload into a targeted system
09:09
followed. There's elevation of privilege.
09:11
This is a violation of authorization.
09:16
So this is where
09:18
someone is allowed to do something that they're not authorized to do. And generally it starts with a lower level of privilege and then elevating that level of privilege to be rude or to be admin or to be system admit something that is much higher in order for the
09:37
in order for the violation to be even greater. So if we look at spoofing more closely, we can see that the threat targets can include a person,
09:48
a file,
09:50
Ah, a network address. You know what I P address could be spoofed or Mac address could be spoofed
09:56
and even a program in memory.
09:58
So what are the mitigation strategies for each of these? Well, when we talk about people, we know that in order to keep
10:07
people from being spoofed, we've gotta have some kind of identification, some sort of I d or user name, and then we've gotta put an authentication method around that. So generally we have user name and password, which is basically
10:24
and identify their along with something that the person knows, right? They know their password. Now, if we have multi factor authentication or two factor authentication, we generally have more than just the user name and password. We may actually add something like a biometric
10:43
reading of some type. Maybe a fingerprint,
10:46
maybe a Palm scan, something like that. And so that is something that they are. And the third type of ah factor for multi factor authentication could be something that the person has. This could be a a token Bob
11:03
say. You have evolved with a secure random number that's generated every 10 seconds. And so
11:09
when they go to law again, they also provide this number, and then they can receive authentication and authorization to get into the application.
11:20
Now spoofing of a file, actually can be mitigated a couple of different ways. We've got leveraging the OS. This is basically something inherent to the Colonel. There are other ways, though. We could look into FIM
11:37
Service's, which is basically file integrity monitoring.
11:41
This is where all the files on your file system can actually be. Check summed.
11:48
Should anyone actually tamper with them in any way? Then there would be an alert created.
11:54
That would be a difference done, and you could pinpoint exactly where that tampering had been
12:01
performed.
12:03
Also included could be any kind of cryptographic authentication on a file. This could be an H macro digital signatures that associate ID with the file, and you also have an added layer of of the authentication as well as Thean integrity. Check there.
12:20
So the techniques, from a coating perspective, we can weaken, basically, can Annika lies
12:28
and then verify any kind of paths that we might look at a side of our code before
12:35
we actually receive a file in.
12:39
And so that way we know that the file is is legitimate. It's the type of file were expecting to receive, and it's going into a place where it's supposed to be. And then, of course, we've got some ackles. We could always look at us. Well, now protecting the network address.
12:58
This is going to be best through encryption.
13:01
If we can apply Deanna security D nsx
13:05
course t l s is our main go to protocol for rapping, rapping around T c p i p.
13:13
And then there's our i p sec between land segments
13:18
now spoofing a program in memory.
13:22
This is where we want to actually leverage the kernel inside of the operating system.
13:28
There's what's known as a reference monitor there, in the reference monitor, sort of acts like a police cop where,
13:35
UM, it enforces user space from privilege space. So there are
13:43
when a program is run,
13:46
there are certain areas inside of the operating system inside of the memory where the program should be allowed to run. It should be allowed to see and then other places where it should not.
13:58
And so Ring zero is a privileged area that should only be accessible by the colonel. And so this reference monitor basically tries to police that have unauthorized access into this privilege areas. Now, with tampering course, we know that a file could be tampered.
14:16
There are also raised conditions that we should mitigate for,
14:22
And then the last targeted example here would be tampering. A network package
14:28
Now tampering with the file.
14:31
I've already mentioned the operating system as well as the fem service. What you could do, of course, is around that fem service. Have some access control layer where you basically either permit or deny particular user accounts or service accounts from
14:50
excess ING files in certain directories.
14:54
And so that's certainly ah viable mitigation technique. Now when it comes to raise conditions,
15:01
this is where you've got to programs that are trying to either
15:05
create or modify the same file, and it's a it's a race to see who wins.
15:13
This is a pretty difficult thing to mitigate. Generally, you have to have some kind of manual code review
15:20
to have senior level developers look at code and find where race conditions may be possible, and and it definitely can be exploitable.
15:35
Now. You could actually try to use your FIM service if you want to wrap that around some sort of Accola as well.
15:43
And, um, and you could use a file system level encryption with the Ackles to permit what programs can actually write to certain directories.
15:56
We'll be able to write files to certain directories so this could help you with also making files non execute herbal. So say an attacker places some sort of payload somewhere on a on a server.
16:11
If you control the permissions of the of the file as it's uploaded or downloaded and control the directories and make it non excusable. That's just one more layer of of protection, One more hurdle that would have to be overcome. Now tampering with a network packet.
16:30
The best mitigation here is gonna be cryptographic. So the use of tear last remember that that's already got integrity checks inside of it. We've gone through several several of the examples of the mitigation techniques here, but I also want to bring out the V land. Segmentation is you can have virtual land
16:48
segmentation sze that separate.
16:51
You're different environments from each other, so you want to segregate your production environments, your production network or sub net from your development sub net
17:02
Now information Disclosure. The threat targets here would be processes, data stores and file system transfers.
17:11
So you're mitigating techniques in
17:15
in. All of these are going to involve some sort of encryption protocol or even application layer encryption, for example, to organization system transfers. Of course,
17:26
this is where your you're sharing information between processes or systems or applications,
17:33
and particularly when they cross over data centers and things like that. You want to ensure that sftp issues or something equivalent
17:42
now repudiation, as I mentioned before, is where someone can claim that they actually did not do something, and you don't have any kind of proof to prove them otherwise. And so
17:56
if we take a look at the threat targets, there can be a network monitoring repudiation,
18:04
even writing contents to a file or a directory
18:11
as well as a P I information disclosure. Now let's go through each with monitoring. We know that we can use encryption as our mitigation strategy.
18:21
So of course, T. L s has folded in their integrity and confidentiality. And so we should be able to identify the particular source for where information or traffic is coming from, too,
18:40
to give us that non repudiation
18:44
with a directory or file name, really probably file system level encryption with ankles around it is going to be a very good mitigation technique. This is, for example, where you could tie your active directory accounts to permissions on the file system
19:03
and so generally file system encryption, which is transparent to to your files or to your application, uh, generally doesn't seem like very good medication technique. However, when you think about applying it to access control layers you can realize is how powerful it is
19:23
now file contents. This could be the use of digital certificates, any kind of cryptographic authentication that basically ties a person with their changes that they've made. And you could also
19:40
look into the fem service's we talked about as well as using something like PGP
19:45
ap I information disclosures. An interesting one.
19:48
This is where in the calling of your program or the inter process calls, you actually are divulging information that you should not, and this is gonna be an in memory type attack. This is very interesting because it z
20:07
it would be difficult to find
20:10
you could do manual code reviews you could even use did buggers, which we don't have listed here. But you could use D buggers to analyze the way that your calls look in memory on the stack.
20:22
Um, you could also consider passing by reference or passing by value, and that really is dependent upon the language that you're using and the program flow.
20:33
So denial of service. This is where we could have our network targeted, as well as program resource is or system resource is
20:42
now for network flooding. We're going to look at
20:48
particular resource. Is that usually are targeted. They tend to be Web servers, Web farms. And so we want to put some sort of load balance or devices in front of those servers so we can protect them. Now. Load balancers in particular are nice, because
21:07
depending upon how intelligent they are,
21:10
not only do they round robin traffic, but in some instances they can even detect some kind of denial of service, attack and turn off, Um, the traffic from flowing to certain spot. Um,
21:26
it depends on ah, vendor products available,
21:30
but basically these are the types of things that we want to use for elasticity in reacting to possible denial of service attacks. Now, when it comes to your application code, this is where you need to protect your program. Resource is,
21:48
you want to avoid multipliers that give Attackers amplification of their attack.
21:56
Now, what do I mean by that? Could be the insertion of malware.
22:00
Whether that is through, maybe a file upload process where you are not checking the you're not doing any kind of validation. You're not ensuring that the uploaded file, you know, it's not excusable. You're not checking file sizes or file
22:19
any kind of limits on the size of the file.
22:23
There are zip bombs out there that can look very innocuous. They can be in like four K four kilobytes, but in actuality, once they are exploded and extracted, they are gigs and gigs of data in size.
22:44
So
22:45
it's up to us as programmers to make sure that not only do we have our authorization steps in check,
22:52
but also to place any kind of size limits inside of our code to to basically mitigate against that.
23:00
And then finally, system Resource is, of course, we've got our operating system. We want to monitor that. We want to have some kind of threat monitoring for CPU usage on our systems. If there's some sort of spike that's abnormal in nature, we want to be able to be alerted to that.
23:18
And then, finally, the last letter of stride is elevation of
23:22
privilege.
23:23
Now here we've got several threat targets, just listing a few here, but we've got elevation of privilege against the process by corrupting that process,
23:36
elevation of privileged through mist authorization checks in our application code
23:42
and then elevation of privileged through buggy authorization checks. Now let's talk about the 1st 1 and that is corrupting a process. This is where we could have maybe a buffer overflow situation,
23:57
the use of dangerous functions, which we certainly talked about in our secure coding areas.
24:03
And so we would have leverage any kind of reference monitor given by the colonel
24:11
to ensure that user programs to not get,
24:15
uh, into the privileged areas the privileged address spaces, as we've mentioned earlier.
24:23
Really, you need appear code review for
24:27
some protection against these types of things because you need someone to kind of go through your program flow, understanding the flow understanding, potential,
24:38
uh,
24:41
potential exploitation that could occur due to various programming errors
24:48
now elevation through mist authorization checks. Just this is just
24:52
going back to our missing function level access control.
24:57
Where we talked about that, we've got to make sure we've got authorization checks around our sequel statements and around our functions
25:07
Thio and make sure that it's properly done on the server side.
25:11
So here, ah, mitigation techniques could be the use of static ood analyzers which
25:18
could be able to pick up some. But really, you're Pierre. Code reviews is gonna be probably the better technique to use, and then for the elevation of buggy authorization checks is where you could have authentication, bypass or authorization bypass.
25:34
Um, insecure direct object reference in these types of things, you definitely should have a peer code review to look for these types of software errors.
Up Next
Instructed By
Similar Content
