CompTIA CYSA+ CS0-002 – Identity and Access Management Solutions Part 2

4. Certificate Management (OBJ 2.1)

Certificate management. In this lesson, we’re going to talk all about certificate management, which has to do with digital certificates. When you deal with certificate management, this is the practice of issuing updating and revoking digital certificates. Now, in this lesson, we’re not going to go and review everything we talked about back in security. Plus you should already understand how PTI works and digital certificates in general. Instead, we’re going to focus on what you need to know for the Cysaplus exam. Now, the principal means of assuring the identity of machines and application code is to use digital certificates. That’s why they’re so important. We talk a lot about digital certificates in this course in their various uses.

Now, when you’re dealing with a digital certificate, one of the ways to check it is by using third party utilities. You can do this using something like SIG Check, which is a sysinternal utility that allows you to verify root certificates in the local store against Microsoft’s Master Trust list. This will make sure that your operating system certificates are actually trusted and they are the ones that Microsoft signed. Now, another way you can do this is by using OpenSSL. Now, OpenSSL is a library of software functions that support SSL and TLS protocols. Now, because of that, OpenSSL has a large amount of commands that are there for you to be able to create and view digital certificates, generate private keys, and even test the SSL and TLS functions.

In addition to this, you can use third party open SSL binaries for Windows. But if you’re already running Windows, there’s already a built in tool for this. It’s known as certutil. This is a Windows utility that allows you to display certification authority or CA configuration information. It’ll allow you to configure certificate services, back up and restore CA components and verify certificates, key pairs and certificate chains. And all of this uses parts of OpenSSL to do it. Now, when we start talking about certificate management, there are lots of different tasks that we’re going to do. For example, with certificate management, we’re going to install, update and validate trusted root certificates. Root certificates are the top of the tree, and so we have to know what that root is for everything else below it to be trusted.

So if somebody has compromised a root certificate, that’s a big deal. And if they did, we would need to install a new one. And so that’s an important function here. Another thing we’re concerned with is deploying updating and revoking subject certificates. Now, I talk about a subject certificate. This can be a user certificate, like a digital email certificate that I might use to sign my emails. Or it can be a machine certificate assigned to my laptop and used as part of my Radius server as I’m trying to log on using 802 one X. If I’m using that using digital certificates, all of these can be deployed, updated and revoked using the certificate management tools that we’re talking about in this lesson. Another thing we can do is prevent the use of self signed certificates by doing proper certificate management.

We can say no self signed certificates are allowed only one signed by our root CA and that would make sure that we are gaining things we trust and not allowing self signed. Now, why do we want to prevent the use of self signed certificates? Well, because a lot of malware code will actually sign itself. So that way you see a digital certificate and go, oh, this must be something I can trust and you’ll install it anyway. Or people will create an SSL self signed certificate and put it on their web server and then they’ll use that as a way to do a man in the middle attack. So from you to the web server to your final destination. And they sit in between collecting all that information as a proxy.

Or people might create a self signed SSL or TLS certificate and they’ll use that as a way to be a man in the middle. So you’ll connect to them, you’ll see that digital signature and think everything’s good. And then you’ll go right through from them to your file destination and they’ll be sitting in the middle collecting your information the entire time. Another thing we want to focus on is SSH key management. If you’re dealing with SSH, most of the time you’re going to be using cryptographic key pairs to be able to do the log on and authentication. Well, that all has to be managed and that, that’s what certificate management does. It manages all those key pairs and all those digital certificates that are being used as part of SSH.

5. Federation (OBJ 2.1)

Federation. In this lesson, we are going to talk about an identity federation. Now a federation is a process that provides a shared login capability across multiple systems and enterprises. For example, if you want to log into one website, but you start using your Google sign in to do it, that’s actually part of the federation. Now, a federation allows the company to trust accounts created and managed by a different network. For instance, on one of my older websites, we used to allow LinkedIn logons or Facebook logons or Google logons to get into our site. And that meant we had a trust relationship. If they said you were authorized, we would allow you in, because that’s the way our website was set up. It was a trust relationship.

And these trust relationships are set up between two different networks. The identity provider, in this case, it would be Facebook or LinkedIn or Google, and the service provider, which was me, it was my website. And so that’s a way that these things work. Now, as you look at this, this is what we’re going to see. You have this trust boundary that goes beyond your organization now. Now the RP here is going to be your relying party or your service provider. So think about that as my website. Now, if you want to be able to sign into my website using your Google login, first I’m going to make a request, a discovery request, over to the ID provider on the right, which is google. They’re going to look at that and they’re going to validate your credentials.

You’re going to send it back to my website and say, hey, I have verified John Smith, let them into your website. Then I’m going to check what attributes they say he has that’s the registrar attributes, and then they send me back whether they were approved or not. And now I say, okay, john Smith was approved by Google. He does have a matching account on my system that has these courses. So I’m going to let him in and let him see those courses. That’s the way this works. So I never really do the authentication of that person. I let that all be done by the ID provider, which in this case is google or facebook or LinkedIn or whatever third party SSO you want to be able to use. Now that’s the idea of how these things work.

Now, I know this sounds a lot like single sign on, and I even just said single sign on when I mentioned google or LinkedIn or Facebook. And people often use those terms interchangeably like I just did there by mistake. They’re not the same thing. When you’re dealing with single sign on, you have a cryptographic hash of the credentials being passed between the two systems. That’s the way we share it when we’re dealing with single sign on. So I still have to do the ID verification as the service provider inside a single sign on. But when you’re part of a federation, the sign on is actually provided as a service by the identity provider. And so I’m never actually verifying that person myself. I do all of that trust through that third party ID provider.

And so that’s why this is a dangerous thing that you have to think about when you’re setting up your federations. Now, setting it up with something like Google or Facebook is not that big of a deal. In fact, usually we’ll configure it not so much as a trust relationship, but more as a single sign on type of relationship, using them as an ID provider. But if you’re going to do this with another company, for instance my training company and another training company, I’m taking all the risk by creating that trust relationship between us. And that is something an attacker could take advantage of. So you want to keep that in mind if your organization is thinking about doing it.

Now, some other problems you have to think about when you start dealing with federations is how are you going to provision and deprovision accounts. Now when I talk about provisioning, this is creating an account and giving the user authorization to a particular role, an application or file share. Now when I make changes to a user account, those changes have to get back to that ID provider. So we need to make sure that we quickly propagate that between the ID provider and the service provider. So if they make a change to their user account and change their username or their password or some of their attributes, we need to know that pretty quickly. And so you have to make sure there’s this propagation that happens between the two.

Now you can manually provision an account and this occurs when an account is being configured by an administrator on the service provider site. So when you come to my site and you buy something, we actually don’t use manual provision most of the time, but if something goes wrong, my team can log into our website and create an account for you manually. It’s more time intensive, it’s more prone to risk, but we have that ability. That’s where one of our administrators logs onto our site and creates that account. Now automatic provisioning on the other hand, is when users are enrolled with the service provider without intervention. So if you go over to my website and you buy a product, for instance, a course, you’re going to end up buying that course.

And if it’s the first course you bought with us, we will automatically create an account for you, send you an email with your username and log on and then you can log in and use your account. No human will ever touch that in that process. But if something goes wrong, then we go back to manual provisioning. Now when you reset your password, who are you resetting your password with? Well, if you’re using a federation, you’re going to be doing that with the ID provider, right? Because the ID provider is the one who’s handling all of those password resets. So this is one of the reasons why we didn’t like using federation for our users and passwords.

The reason was we didn’t have any control over helping our students when they said, hey, I lost my password, we couldn’t reset it for you because we don’t have access to that. That was done by the federated provider, in this case Google or LinkedIn or Facebook. And so it was more complex for us to support that system. So in new versions of our websites, we don’t support that, at least currently, as of this recording. Instead, we rely on regular usernames and passwords because we have the ability to reset those for you. Or you can reset them yourself using your challenge questions or using reset links using that two step verification process.

6. Privilege Management (OBJ 2.1)

Privilege management. In this lesson, we’re going to talk about the different forms of access control because all of those relate to privileges. Now, when I talk about privilege management, which is the name of this lesson, this is the use of authentication and authorization mechanisms to provide an administrator with centralized or decentralized control of user and group rolebased. Privilege management, essentially, we want to make sure we’re able to control what privileges a person or a group has and we’re going to do that based on their role. That is the best way to do it. So if I have people who work in accounting, they’re going to have one set of permissions. If I have people who work in it, they have a different set of permissions. If I have a regular user, they’re going to have a different set of permissions.

On my system, instructors have a different set of permissions than students because we have different roles that we have to do. Now, most of our policies are going to be designed with the principles of least privilege and separation of duty. And these are two key concepts that you have to be familiar with. Now, least privilege is pretty simple. That just means doing something with the lowest amount of privilege as possible. If you can do it as a user, you’re just going to do it with a user account. If you need to have administrative rights, do you need all administrative rights or just certain ones? If so, that would be a super user instead of an administrative user. And so you want to use that idea of least privilege. Now, with separation of duties, this is a means of establishing checks and balances against the possibility of insider threats because these insider threats can compromise critical systems and procedures.

Now, when we talk about separation of duties, this is a system of checks and balances, right? So in my company we have a corporate checkbook. If somebody wants to sign a check, one person can’t do that. Each of those checks has dual signatures. Now, that means that I can sign and my COO can sign and that means we can pay our bills. That way it’s a little bit more cumbersome, but it does make sure that nobody can just take the checkbook and do a single signature and steal all of our money, right? My COO can’t go and fly to Vegas and spend all of our money. It doesn’t work that way. She has to have both our signatures. That’s the idea of a separation of duties here. Now, I mentioned at the beginning of this lesson we were going to talk about access control types.

So let’s get into that. Access control types. There are four types of access controls. There is discretionary access Control, mandatory access control, role based access control, and attribute based access control. Now, when we deal with discretionary Access Control or DAC, this is an access control model where each resource is protected by an Access Control list or ACL and it’s managed by the resource owner or owners. If you use Microsoft Windows you’re familiar with DAC because that’s what we use. You can right click on that Properties button on the folder. You can go to a shared folder, you can right click on it and go to Properties. And when you do that, you’ll see the attributes associated with that Access Control list. It’ll say what users can read, write or modify those folders.

That’s the whole idea of discretionary. Access control. The person who owns that resource can change those files and make anybody access it that they want. I, as Assistant Administrator, have access over the entire system as well. But Windows, by default, is a discretionary access control system. It is a DAC system. Now beyond that we can look into Mac and Mac is a little bit more secure. Mac has a lot more overhead though. Mac is mandatory access control. This is an Access Control model where resources are protected by inflexible system defined rules, where every resource or object and every user or subject is allocated a clearance level or a label. Whenever I hear about Mac, I always think about labels. Everything is labeled.

And if you think about the standard military context, this is a Mac context, right? We have a document and it’s either classified as Secret, Confidential, Top Secret. Whatever that document is, that label then tells it how it will be treated inside of our system. Now if I wanted to read this document, it’s going to check my account and say, jason, what clearances does he have? He has top secret secret confidential, unclassified. That means he can read all four of those. Now if we went and checked Mary’s clearance and she only has Secret, she wouldn’t be able to read this document because this is a top secret document so it wouldn’t show it to her. That’s the idea of Mac and that’s how these systems work.

Now most operating systems do not support Mac but there is one that really does it well, and this is Se Linux. Se Linux was actually developed by the National Security Agency, the NSA, and it provides a method for implementing Mac within that network. So if you want to use Mac, remember there’s a lot of overhead involved. But if you have something that’s very classified, it’s a good system to use and then you’d use Se Linux. Now the next one we want to talk about is Rolebased Access Control or RBAC. Now RBAC is an Access Control model where resources are protected by ACLs that are managed by administrators and can provide user permissions based on job functions. So going back to my earlier example, I take all my accountants and I put them in one group.

Then I can give that group permissions. That would be a role based Access Control, right? Because I’m going to be able to implement this through the concept of groups inside of Windows. That’s the idea of doing RBAC. Now, this isn’t a perfect implementation of RBAC, but it does get the job done most of the way. And so we will consider that an implementation inside of Windows. Another one we can use is Attribute based. Attribute Based Access Control, or ABAC, is an access control technique that evaluates a set of attributes that each subject possesses to determine if access should be granted. Now, ABAC can be used to implement controls for separation of duties.

So I can say that I am part of the A group and somebody else is part of the B group. And based on that, we have certain attributes. So there are certain things that A group people can do and B group people can do. And because of those attributes associated with each of us, we can then do certain things, and that would separate our duties. ABAC is by far the most complicated type of access control to implement, but it does give you the most flexibility because you’re not doing things based on groups anymore, you’re doing it based on a single subject. And so I can actually have down to the individual person, what specific attributes they have and therefore what specific things they can do on that system.

• Category: Uncategorized