Part 3 - Core Security Requirements

Video Activity

This lesson covers core security requirements and offers a number of examples: These are: • Confidentiality • Integrity • Availability • Authenticity • Authorization • Accountability

Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

5 hours 54 minutes
Video Description

This lesson covers core security requirements and offers a number of examples: These are: • Confidentiality • Integrity • Availability • Authenticity • Authorization • Accountability

Video Transcription
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.
So what we need to address is we need to address how we're going to satisfy the C I. A.
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
how we're going to protect. For instance, personally identifiable information
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
that a compromise.
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 asterisks instead of my password that's masking. And that'll keep customer service reps for interest before instance from seeing vital information
like if they pull up your account, they'll see nothing but asterisks.
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 attacks. Steganography is
a message inside another message or, um
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
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
at rest should always be encrypted, using no less than a S 2 56 bit encryption.
When dad is in process, there's not a whole lot you can do to protect data and process because once status, even their data is encrypted on the hard drive. It must be decrypted
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,
making sure that someone can't read your screen. You avoid
shoulder surfing. You know some of the basic security requirements. Don't leave your desk without locking your system.
Dad 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 set, but must be protected and trains it as well.
So some various examples of confidentiality requirements again, how are we going to address the needs for privacy with our software
now? Other secure requirements for Ah, the CIA try at the next is we look at integrity.
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.
Making sure that we protect against code injection and code injection is a huge problem. Anytime that we allow user input, we'll talk about code injection Maur Later Data integrity making sure that the data the file hasn't been modified log files, whatever
in transit and for those types of modifications
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,
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
the application they downloaded
were the file they downloaded hasn't been modified. All of those are ways that we would address the system and Dad has integrity
now for availability requirements. Again, C i A. Don't forget availability is the A in the 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.
Ah, and if our product doesn't make the customers nature doesn't meet that up time, we generally
compensate safe them in some means, um, we can provide for our customers. Um
ah, meantime, between failure in meantime to repair metrics so they can assess whether or not this mechanism will meet those needs 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 software where must meet the availability requirements per the S. L. A.
Also would about support. How many users should be able to access the software simultaneously? How is replication gonna happen? Those would be issues that we'd address with our availability requirements. Then we move on to think about authenticity
and we talk about authenticity. We want to validate and entities claim
of identification. So I'll identify to you by saying, I'm Kelly Hander hand the authentication place piece says I must prove it.
So do I. Um, you know, in
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.
We can use basic authenticity where there's a password now with basic the passwords transmitted in clear tax. That's a problem with Digest. It's a challenge response system, so the password doesn't appear on the network. In plain text.
We can use certificates. We can use tokens. They're all sorts of mean smart cards, biometrics.
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 and a smart card, or you must provide a thumbprint in the password. Something like that. More than one factor of authentication
mutual authentication means
the client authenticates to the server. But then the server also has to authenticate to the client
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 Lise privilege. You're giving the
absolute minimum rights and permissions
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 crunch operations. Love the crowd. Acronym create, read, update and delete, but again making sure that
based on job requirements and role within the organization,
you have just the bare minimum permissions. And we talked 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
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
if traffic is coming from this network, then deny it.
So that idea, based on rules, would be another way that we control access and we require authorization before we authorize on entity a subject to access an object.
Okay, so some authorized authorization requirements might be
access to highly sensitive information is limited to 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 address authorization,
accountability. When we talk about accountability, we want to be able to trace an action to a subject accountability and often go hand in hand.
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
and everybody had
a single account, 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 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 auditing.
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
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.
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?
All right. Authorization.
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.
All right, those air, the core security requirements from there, we're gonna talk about general requirements
Up Next