Time
5 hours 54 minutes
Difficulty
Intermediate
CEU/CPE
6

Video Description

This lesson introduces the core security requirements; which are often referred to as the C-I-A triad: • Confidentiality • Integrity • Availability The instructor also touches upon overt and covert attacks on cryptography and offers examples of core confidentiality, integrity and availability security requirements.

Video Transcription

00:04
Now let's talk a little bit about the different types of requirements. We've already said that our requirements should be smart. Now we're gonna discuss what type of requirements that we have. And one of the first elements that will look at is, well, look at core security requirements.
00:18
So what we need to address is we need to address how we're going to satisfy the C I. A.
00:25
Confidentiality, integrity and availability. That's our starting point and will address other areas of security as well. But we start with the C I A. So when we talk about confidentiality, we may think about encryption. We want to protect and keep secrets secrets. So we will document
00:43
how we're going to protect. For instance, personally identifiable information
00:48
will list out specific algorithms, or at least minimum key links. Minimum degrees of security will address overt attacks on confidentiality like, uh, cryptography and masking requirements to prevent data loss if you will not data loss. But
01:07
that a compromise.
01:07
So when we talk about cryptography, of course, we're talking about encryption when we talk about masking, Um, when I enter in a password, for instance, and you see the ask risks instead of my password. That's masking. And that'll keep customer service reps for interest before instance from seeing vital information
01:26
like if they pull up your account, they'll see nothing that asterisks.
01:29
And in the last four of your Social Security number, for instance, so that helps with overt attacks on cryptography. Covert attacks on cryptography might be steganography and steganography. Now, now, again, this doesn't apply in all instances, but that's just an example with covert
01:47
attack. Steganography is
01:49
a message inside another message or, um
01:53
ah, essentially embedding a message in another or in some other format. So we might want to document how we're gonna dress steganography and guarantee that that's not an issue
02:05
we also want to think about when we're addressing confidentiality. We also want to think about the three states in which data can be it can be at rest, in process and in transit. So when we talk about confidentiality, were going to say OK, data at risk
02:22
at rest should always be encrypted, using no less than a S 2 56 bit encryption.
02:28
When dad is in process, there's not a whole lot you can do to protect data in process because once status, even their dad is encrypted on the hard drive, it must be decrypted
02:39
to get loaded into RAM while representatives working on that information. Then it gets re encrypted for storage. So you can't really do a lot to protect to encrypt data in process. But you can follow good security requirements like a clean desk policy,
02:57
making sure that someone can't read your screen. You avoids, um,
03:00
shoulder surfing. You know, some of the basic security requirements don't leave your desk without locking your system.
03:07
That in transit, we might say all that in transit must use a secure transition protocol like maybe SSL or T l S r I p sec, but must be protected and trains it as well.
03:20
So some various examples of confidentiality requirements again, how are we going to address the needs for privacy with our software
03:30
now? Other secure requirements for ah, the C I A triad. The next is we look at integrity.
03:37
So how are we going to protect against modification off of system modification off the data, making sure that the system performs as it should, you know, for instance, when we talk about system integrity, making sure internal and external values are consistent.
03:55
Making sure that we protect against it code injection and code injection is a huge problem. Anytime that we allow user input, we'll talk about code injection More later. Data integrity. Making sure that the data the file hasn't been modified Log files, whatever
04:14
in transit and for those types of modifications,
04:17
we look to see our seas check sums. Ah, we looked a hash is our message digests Max for email messages. We think about digital signatures. Umm,
04:30
So again, this is how we address integrity and we might document certain integrity requirements like input validation should be used on all forms. Software should require anything that we publish should also provide a message digest so that when the user downloads, they could be guaranteed that they
04:49
the application they downloaded
04:51
were the file they downloaded hasn't been modified. All of those are ways that we would address the system and data integrity
05:00
now for availability requirements. Again, C i A. Don't forget availability is the A in CIA. Try it. So how can we guarantee that this product is available to meet the customersneeds? Well service level agreements where we commit to a 99.999% up time.
05:19
Ah, and
05:20
if our product doesn't meet customers needs or doesn't meet that up time, we generally compensate safe then and some means, um, we can provide for our customers. Um
05:32
ah, meantime, between failure in meantime to repair metrics so they can assess whether or not this mechanism will meet those needs
05:40
our recovery point objectives meaning, what is the customers tolerance for data loss? How current must the data be? What's the longest maximum tolerable downtime? What's the longest the customer can be without this system so you can see down below some examples of availability requirements
06:00
software where must meet the availability requirements per the S. L. A.
06:06
Also would about support. How many users should be able to access the software simultaneously?
06:14
How is replication gonna happen? Those would be issues that we'd address with our availability requirements.
06:20
Then we move on to think about authenticity and we talk about authenticity. We want to validate and entities claim
06:28
of identification. So I'll identify to you by saying, I'm Kelly Hander hand the authentication place piece says I must prove it.
06:36
So do I. Um, you know in
06:42
some applications, like usually Web based applications, we allow anonymous access. Anybody can access the Web page because I want anybody to go to the website and purchase things from me.
06:53
We can use basic authenticity where there's a password now with basic the passwords transmitted in clear text. That's a problem with Digest. It's a challenge response system, so the password doesn't appear on the network. In plain text.
07:08
We can use certificates. We can use tokens. They're all sorts of me smart cards by metrics.
07:15
They're all sorts of ways that we can authenticate, but ultimately that should be specified As part of the requirements for our program. We might also address multi factor authentication, mutual authentication. So when we talk about multi factor authentication, ah, you must provide a password
07:33
and a smart card,
07:35
or you must provide a thumbprint in the password. Something like that. More than one factor of authentication mutual authentication means that client off indicates to the server. But then the server also has to authenticate to the client
07:51
Ah, from authenticity. We also look att authorization, so making sure that the subject is authorized to access the object, but that the subject on Lee has the rights based on least privilege, and we've talked about the principle of least privilege. You're giving the absolute
08:11
minimum rights and permissions
08:13
to do your job. So we want to make sure that principle of Lise privileges always followed with authorization. Ah, that needs to be addressed. I love the cruddy operations. Love the crowd. Acronym create, read, update and delete, but again making sure that
08:28
based on job requirements and role within the organization,
08:33
you have just the bare minimum permissions. And we talk about some access control models. Dak Mac, and Are back are back standing for role based access control. One of the models. I did not mention his room back, which is rules based Access control
08:48
rules faced access control would be used, for instance, like on fire walls or any sort of filter rules based systems. Follow if then, logic. If traffic is coming from the 10 network than allow it
09:01
if traffic is coming from this network, then deny it.
09:05
So that idea, based on rules, would be another way that we control access and we require authorization before we authorize Ah, an entity a subject to access an object.
09:16
Okay, so some authorized authorization requirements might be
09:20
access to highly sensitive information is limited. Users with secret or top secret clearance on authenticated users will have re permission to public access page. You know, whatever those requirements are that meets your needs, we have to address the address authorization,
09:37
accountability.
09:39
When we talk about accountability, we want to be able to trace an action to a subject accountability and often go hand in hand.
09:48
And the success of auditing is really based on the identity of the subject, and action is gonna be map to the identity. So if you go back, you know, 10 15 years ago, in many offices, there would be one user account that everybody in the office would use, and this was in smaller offices. But you might have an office of 10 people
10:07
and everybody had
10:09
a single account,
10:09
and I won't even address the fact that that single account usually had a minute administrative privileges. We won't even go down that trail. But the problem with users multiple users sharing the same account is we get no accountability.
10:22
User. One is an account shared by 15 people. So who was it that actually went and modified the registry. We don't have that knowledge because we don't have separate identities. So identities air really important part to allow authenticate. I'm sorry to allow accountability and auto.
10:41
So accountability requirements all failed. Log in. Attempts must be logged. There must be source. I d There must be a time stamp. Um, lab. We could go back and add integrity requirements that say audit logs must be hash to guarantee no modification. So you can you know, you can
11:00
reference multiple requirements at the same point in time. You know that accountabilities only accountability. If we can guarantee the integrity of the audit files.
11:11
How long must we retain those audit logs? How about overriding events? What happens if the log files get full again? These air, all requirements that we would address?
11:24
All right. Uh, authorization.
11:26
So, of course, authorization is what you are authorized to do what activities you can perform. And we've already talked about that a little bit.
11:37
All right, those air, the core security requirements from there, we're gonna talk about general requirements

Up Next

ISC2 Certified Secure Software Life-cycle Professional (CSSLP)

This course helps professionals in the industry build their credentials to advance within their organization, allowing them to learn valuable managerial skills as well as how to apply the best practices to keep organizations systems running well.

Instructed By

Instructor Profile Image
Kelly Handerhan
Senior Instructor