Part 6 Defenses
Video Activity
This lesson covers mitigation, countermeasures and defenses. The defenses section of this lesson talks about protecting sensitive data at rest, data in motion and data in use. Participants also learn about encryption standards, with the emphasis being on "never roll your own," as it is too predictable and not random. Also covered in this lesson is ...
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 covers mitigation, countermeasures and defenses. The defenses section of this lesson talks about protecting sensitive data at rest, data in motion and data in use. Participants also learn about encryption standards, with the emphasis being on "never roll your own," as it is too predictable and not random. Also covered in this lesson is how to minimize man in the middle (MITM) attacks and eavesdropping.
Video Transcription
00:04
Hello and welcome to the cyber very secure coding course. My name is Sonny Wear and this is a loss Top 10 for 2013 a six sensitive data exposure medications, countermeasures and defenses.
00:18
So we're gonna take a look at the defenses and what would be involved in protecting sensitive data.
00:26
Now there are generally speaking three main areas. There's dead at rest, data in motion and data in use. Now protecting data at rest and data in motion is what we're going to spend the bulk of our time discussing.
00:42
So first, the possible solutions for applying encryption of data at rest. And when we use this term,
00:50
it means data that might be sitting either on a file system in a directory. Or it could mean data that resides inside of a database. But basically somewhere where it's sedentary and it's sitting there either waiting to be processed
01:07
or waiting to be retrieved, either through queer ear would have you.
01:12
Now there are various different strategies that can be used to encrypt data at rest. They include application level, database level, file, system, level media or device level starting at the top application level. Encryption
01:30
is absolutely the very best. Not only does it provide you
01:34
data at rest protection for your data, but it can also provide protection for data in transit and data and use, so it really covers all three areas. However,
01:47
it's usually pretty expensive to implement because you have to roll it into your actual source code. And so you generally have some sort of either third party A p I or it could be done even in as a built in part of a framework. But
02:06
it is costly to implement
02:08
the data base level. Encryption of data at rest means that it's it's usually provided by the vendor of the database
02:19
and for some additional licensing costs, generally speaking, and so
02:23
it's transparent to the application, which is really nice. But it doesn't provide a lot of protection in the way of
02:31
unauthorized viewing. And so that's where the next section below here really comes into play. And that's adding access controls around that encryption that database level encryption. The same is true for file system level encryption, so
02:52
you can
02:53
specify what directories on a file system would require encryption.
03:00
But it would even be better to wrap access controls around that where you specify which accounts have privileged to actually view those directories
03:12
and then media end of device level being probably the lowest level of encryption for data at rest. And this is where your encrypting, maybe sand storage are. You are encrypting logical partitions. So continuing.
03:29
Let's now talk about protecting sensitive data in motion.
03:32
So
03:34
probably the most prevalent solution in this area is the use of transport layer encryption or T l s
03:43
People still may refer to SSL our secure socket layer, but SSL is
03:49
not to be used any longer. It is deemed insecure and so
03:54
T l s has become the standard and it would be later versions of T. L s.
04:00
Digital certificates, of course, can be used now. Digital certificates also provide T l s. There are other ways to get t l s over UDP, for example. But digital certificates are probably the most common way I'm actually going to go into a diagram and just a few slides
04:21
describing the handshake between the client and the server
04:26
in regards to
04:28
two way T l s. What used to formally be called to a SSL to show the digital certificates at work.
04:38
And then there's also payload encryption.
04:41
Now an example of this would be PGP. This really
04:46
falls into some of the more application layer type encryption that I described on the earlier slide.
04:54
This is where you are going to either encrypt an entire file or you could encrypt the sensitive fields that are contained within a file,
05:04
and so it would be protected both while in transit as well as at rest. And then, at the point of it, needing to be used is when it would be decrypted.
05:17
Now, I also want to mention memory leaks because I did have an example of some memory leakage in the explanations portion of the module. So I mentioned that there was an optimization compiler setting
05:33
that could cause some dead code to stay around resident and memory.
05:41
So you basically want to look into what would be some secure compiler settings for your particular compiler, based on the language that you right in
05:53
Now I do reference the's in my book in my textbook, so please consult the textbook if you need more information in this area,
06:01
code quality and clean up issues, really, this has to do with? Are you setting local variables back to know when you're done with them, to allow the garbage collector to clean up? Are you properly de allocated memory once you're done with it, things like that,
06:19
these are really just a programmer. Good habits.
06:25
And then finally, you want to make sure that you don't have any insecure, direct object references,
06:31
and we spoke about this quite a bit in Owe Us a Four.
06:36
Now, as faras encryption standards, the go to is tthe E. U S government's Phipps 1 40 days to, at least in the United States. This publication will describe all of the current secure encryption algorithms, as well as theme hashing functions
06:56
and the pseudo random number generators. So it's going to describe what is currently considered secure.
07:04
Now, a word of advice is. Never roll your own, too.
07:09
Programmers should never try to come up with their own encryption algorithms or patterns because in the end, this ends up being predictable in some fashion,
07:20
and it's not securely random.
07:24
And also there's the whole obscurity maintenance issue behind doing this particular programmer that writes a function to do this or to perform their own encryption than they leave the company. And nobody really knows how the algorithm works or how to decrypt it anymore.
07:44
Now, in this particular example that we're looking at,
07:46
this is application level encryption that I'm showing, and it is from C sharp dot net. You'll want to use the R N G crypto service provider class. This is just a small snippet of code to show you how it would work.
08:03
Also, there's a similar type of class in Java secure random. It's literally what the class is called. And so you want to make sure that you use these secure versions of random number generators.
08:18
So I wanted to go into a little more detail about two way as to sell or two way T l s. As I mentioned earlier. This is for the encryption of data in motion or data in transit. It's also known as
08:31
now to wait
08:33
to a T. L s is where you have both a client side certificate as well as a server side certificate, and you want to implement this,
08:43
uh, if at all possible in order to minimize men in the middle attacks as well as ease dropping meaning
08:52
people or Attackers sniffing your traffic as the communication flows from a client browser to the Web server and back and forth.
09:03
Now, the initial handshake that occurs when a client browser actually has a client side certificate is when the client goes to access in https website,
09:18
and this is normally what happens just with one cited
09:22
A T. L s.
09:24
Immediately. The server is going to respond by presenting its public digital certificate to that client,
09:33
and you'll see this a lot of times you will be presented with a page that tells you about the problems that are with this particular digital certificate. It might be a warning, and it says
09:46
this digital certificate has expired.
09:50
Who are this? Digital certificates? Name doesn't match the name of the company or something like that.
09:58
And so
10:00
at that point, it's really up to the client to decide whether they want to receive that digital certificate or not.
10:07
Could it be a man in the middle attack? Yes, but it could also be just a simple notion that the production support has just not gotten around to installing a new, updated digital certificates so it could be benign it could be hostile. We really don't know.
10:28
So continuing, though with our handshake. So after the server presents its public digital certificate to the client,
10:37
the client can then verify what's presented
10:39
and if successful, then we continue to the third step, which is where the client is going to present its public digital certificate to the server. And then the server can decide.
10:54
Is this digital certificate on a revocation list? Is this digital certificate
11:03
still active or is it expired?
11:07
Does this digital certificate match doesn't have a good name? According to the certificate authority, that should be vouching for it. And if all of that is a success, then you have the two way T l s established. And so this is gonna be
11:26
one of the most secure ways that you can
11:30
that you can prevent man in the middle attacks. So now let's move on to the lab portion of our module
Up Next
Instructed By
Similar Content
