1. Authentication and Authorization (OBJ 1.5)
In this section of the course, we’re going to discuss authentication and authorization. Throughout this section, we’re going to be focused on domain one security architecture. Specifically, Objective 1. 5 given a scenario, you must analyze the security requirements and objectives to provide appropriate authentication and authorisation controls. Now, when a user attempts to use an enterprise network, they first have to be identified and then authenticated before authorization occurs. Authorization is considered to be the act of granting rights and permissions to a user in order for them to utilize a network and its resources. So in this section, we’re going to focus on authentication and authorization, and we’ll begin by discussing the five different types of access controls mandatory access control, discretionary access control, role based access control, rule based access control, and attribute based access control.
Then we’ll move into our discussion of Credential management, which includes password repositories, hardware, key managers, and privileged access management. Next, we’ll discuss password policies and the use of multifactor authentication. After that, we’ll discuss the different protocols used for authentication and authorization, including radius, TAC, s, diameter, LDAP, kerberos, OAuth, 802, one, x, and EAP. We’re also going to discuss one time passwords such as HMAC and time based ones, and the concepts surrounding Federated authentication and authorization. Finally, we’re going to complete our discussion by covering concepts like hardware, root of trust, single sign on JavaScript, object notation, web tokens, attestation, and identity proofing. It’s going to be a busy section as we dive deep into all the various concepts surrounding authentication and authorization in this section of the course. Course.
2. Access Control (OBJ 1.5)
There are many different types of access controls out there, but in this lesson we’re going to focus on the five primary types that are known as mandatory access controls, discretionary access controls, rule based access controls, rule based access controls, and attribute based access controls. The first type is known as mandatory access controls, or Mac. Mandatory Access Control uses security labels to determine which users are authorized to access a particular, particular resource. This type of access control is complex to configure and more expensive to maintain. Therefore, it’s generally going to be reserved for high security systems. Under this system, anything that is not specifically allowed is going to be considered forbidden and not accessible by your users. For this system to work effectively, every single user and every single resource has to be assigned a security label.
If the user’s level is not equal to or higher than the resources level, that user is going to be blocked from accessing that resource. For example, if you work in the military, you have something that’s been labeled as secret, and you may have a secret clearance. So you can access anything on that system that’s labeled as secret, confidential, or unclassified, because your secret clearance is going to be at or above those three levels. But if you try to access a file that was labeled as Top Secret in this Macbased system, you’re going to get denied because your secret clearance is lower than that required from a top secret clearance, and therefore, you can’t view that file. The second type is known as Discretionary Access Control, or DAC. With Discretionary Access Control, a resources owner is going to be allowed to specify which users can access each resource using Discretionary Access Control.
The access is determined based on a user’s identity profile or the role, and this is going to be considered a form of need to know access control. For example, if you decide to share a file on your computer with me over the corporate network, you could easily use discretionary access controls to add my username to that list of authorized users for that particular file that’s being shared now. The third type is known as role based access control. Role Based Access Control allows an administrator to assign each user to one or more roles and then use those roles to assign the permissions to the organization’s resources. In Windows domain environments, role Based Access Control is normally going to be implemented by using groups, and these groups can also be set up in a structure that mimics your organization’s hierarchy.
For example, we might create one group for the accounting department and another group for the human resources department. Then, based on those groups or roles, we can assign each group with access to different resources. Additionally, we could put both of these groups into a higher level group called Employees, and that group might have access to other resources that every employee at the company needs. Access to. Rolebased access control can be used to enforce minimum privileges for that subject based upon all of their associated groups. And the different users can be members of one or more groups based on the different roles they fulfill within the organization. This type of access control works really well for organizations who have a high rate of employee turnover because those permissions are going to be based on a work role rather than on an individual’s own username.
The fourth type is known as rule based Access Control. Now, Rule based Access Control allows an administrator to implement security policies across all of their users. This allows for the use of rules that may be quickly changed and frequently modified. For example, access control lists that are going to be set up on your routers or your firewalls are a great example of a rule based access control. And this is because we’re going to implement these and it’s going to affect all users on a given network segment all at once, based on the rule we put in place. The fifth type is known as Attribute Based Access Control, or ABAC. Attribute based access Control relies on a set of characteristics of an object to make its access control decisions.
User attributes include things like the username, the role, the organization, the ID, or the security clearance level. Environmental attributes can include things like the time of access, the location of the data, and the current organization’s threat level. Resource attributes can include things like the creation data, the file or object, the resource owner, the file name, and the data sensitivity. Depending on these various user, environment and resource attributes, access is going to be permitted or denied based on the individual requesting access. For example, your company’s SharePoint site on your intranet may look different when you log into it versus one of your coworkers. This is based upon what access rules are being applied based on your individual accounts and where you’re logging in from, either from inside the corporate office or from your home office, over a VPN or directly over the Internet. So remember, when it comes to access control, you have five different types that you can implement mandatory access Control, discretionary Access Control, rulebased access Control, rulebased Access Control, and Attribute Based Access Control.
3. Credential Management (OBJ 1.5)
IFR the most common type of authentication mechanism in use today is a username and password. Unfortunately, it seems like every single website or application is going to require you to enter a different username and password for you to log in. This can become a huge security risk because most users can’t remember a lot of different passwords, especially if they’re all going to be long and strong passwords. So what do most users do? They either write down their passwords, making them more vulnerable, or they use the same password for every account, which is known as password reuse. The problem with password reuse is that data breaches seem to be a daily occurrence now, and many times usernames and passwords are included as part of those data breaches.
So if you’re using the same username and password across lots of different sites and one of those gets compromised effectively now all of your accounts are going to be compromised too, because you use the same username and password across many different sites. So to help with this challenge, users can instead rely on using a Credential management solution. Now, a Credential management solution is a piece of software or a piece of hardware that’s going to be used to create and manage strong passwords while allowing the end user to only have to remember one master password. There are many software based solutions out there, like LastPass OnePass, Dashlane, and others, that allow you to create one long, strong password. Or even better, they can allow you to use multifactor authentication to secure your credentials. And then that Credential manager can create a unique and complex password for each and every account that the user needs to access.
These Credential management software solutions rely on encryption to keep your central repository of usernames and passwords secure from attackers. This repository can be kept on premise or in a cloud based repository based upon the configuration you set. While software like LastPass, OnePass, and Dashlane are commercially available options directly for your end users, there are also many password repository applications that can be installed and configured within your own enterprise network for all of your users. Enterprise level Credential management solutions can also organize employees and customer identities for your organization, since many organizations provide user accounts to their customers via a customer portal too. But if you want to have a higher level of security, you can instead rely on a hardware key manager.
Now, a hardware key manager is a hardware device or module that stores usernames passwords or encryption keys. For example, end user models are often sold under the name USB Security Keys, and it would be inserted into your laptop or desktop every time you need to access one of your accounts to log in. There are many variations of the hardware key managers out there, depending on the specific technology and the equipment that you’re going to utilize with them. But the underlying concept is really the same. It’s a piece of hardware with some built in memory that stores your encryption keys or other credentials used to authenticate with another system or device. Another type of credential manager is known as a privileged access management solution, or Pam solution.
Now, a privileged access management solution is an information security mechanism that’s used to safeguard the accounts that contain special access or capabilities beyond those of a regular user, such as your administrator or service accounts. In general, a privileged access management solution works by taking all of the privileged account credentials and placing them inside a secure repository or vault. Now, once they’re inside this vault, the credentials are going to be stored in an encrypted format. When the system administrator needs to use one of those privileged credentials, they’re going to authenticate with the Pam solution. The Pam solution will log this access, and then it’s going to authenticate with the target system on behalf of the system administrator. The way this is actually done is going to depend on the Pam system you’re using and your architecture, as well as what systems it’s going to support.
For example, I once used a Pam solution that relied on setting a new password each and every time somebody logged in. So when the system administrator need to log into one of the routers, the Pam solution will actually log them in, and then it lets them perform their work. Once they’re done, the Pam solution would change the administrative password on that router to a new, long, strong, complex, random password and then store that into its vault. When the next person needed to log into the router, they would again authenticate with that Pam solution using their own credentials. And the Pam would then log them into the router using that recently reset long, strong, random password. This way, the administrator never knew what the password was to the router. Instead, it’s all being controlled by that Pam solution. And this is a really secure way of doing things that allows you to change that password to something long, strong, and complex each and every time you log into a new device.
4. Password Policies (OBJ 1.5)
In this lesson, we’re going to examine password policies and how they can affect the security of your authentication and your authorization systems within your enterprise network. First, though, let’s define what we mean by a password policy in terms of the certification exam. Now, a password policy is simply a policy document that promotes strong passwords by specifying an acceptable length, complexity, character classes, history, maximum or minimum age, auditing requirements, and reversibility of your encryption. Depending on how you configure your password policies within your organization, your user accounts and credentials will either be more or less secure from being compromised by an attacker. Now, for most of us, this lesson is going to be a review, but I recommend you don’t skip this video, because there has been some big changes in the world of password policies in the recent years.
Now, according to the NIST special publication 863 B, this is the Digital Identity Guidelines, and it’s going to be considered the source materials for what should be implemented in order to have a strong password security policy. Some of the traditional elements of a strong password policy are now considered to be deprecated or obsolete. For example, let’s consider the length and complexity of a given password. Ever since I started working in It and Cybersecurity, we’ve been told that you need to use a long, strong, and complex password. This is defined as having at least eight characters, or at least twelve characters, or at least 16 characters long. And it seems to get longer all the time. Now, in addition to this long password, we’ve been told to have a complex password.
Now, complexity is defined by having different characters being used, such as lowercase letters, uppercase letters, numbers, and special characters. You see, if we just use lowercase letters, then you’ll only have 26 characters in your character set. But if you use lowercase and uppercase, you now have 52 characters in that set. If you add numbers, we now have 62 characters in that set. And if we add symbols, we’re now somewhere in the range of 70 to 80 characters in that given character set. The more in different types of characters we use, the more complex the password can be. And this is always going to be considered a stronger password. At least it was historically. Now, while that’s true from a purely mathematical and code breaking perspective, it neglects the fact that we have to account for one important thing human nature.
If my password is something like Exclamation, four R, Q, six 3% at, ah, WJ, semicolon two XA, it is really long, strong, and complex. But I’m never going to be able to remember that. So most people would end up writing down that password on a notepad, or even worse, on a digital text file on their desktop. So now that long, strong, and complex password is simply out in the open and can be retrieved by anybody, including attackers. For this reason, the new guidance in the NIST special publication 863 B states that you should no longer enforce complexity as part of your password policy. Instead, NIST recommends that passwords should now be between eight and 64 ASCII characters in length. Your users can have a nice long password, and they can use uppercase and lowercase letters and maybe even some numbers or special characters if they desire, but those should not be required.
When it comes to security, having a long string that is not repetitive is just as secure as a complex eight character password, which is why the NIST no longer recommends the complexity rules be enforced. Another change in the latest NIST publication is that maximum password age enforcement is no longer considered a good idea either. If you’ve been in cybersecurity for a while, you’re probably used to seeing most systems configured to require a user’s password to be changed every 60 or 90 days. But this is no longer considered a best practice. Why? Well, again, it comes back to human nature. If we’re asking people to create these long passwords of up to 64 characters, even if it isn’t complex, it’s going to be harder for them to memorize, especially if they have to change it every 60 to 90 days.
So by allowing for a longer password age time, it increases the chances that your users will actually memorize their passwords instead of writing them down someplace. Another reason for this change in the enforcement rules is that most people are migrating towards the use of password or credential managers. This allows them to create very long and randomized passwords as their credentials.And this leads to overall stronger passwords. And these are going to be securely stored by your password manager in an encrypted format, where they remain secure until the user actually needs them. If your users are using a password manager, then there is less need for them to have to change the password every 60 to 90 days.
And it minimizes the chances of those passwords being compromised because users are no longer subject to password reuse because every password manager will use a new and unique password for each and every account or website that that user is going to visit. The other side of the coin here, when it comes to password age, is the minimum age. Now, minimum password age is a setting that can be enabled in your password policy that requires a certain number of days to pass before a user can reset their password. If you’ve set this to zero days, that means your users can immediately change their password. But if you set this to one day, they have to wait 24 hours before they can reset their password again. Now, why does this minimum age of a password really matter? Well, it really has more to do with the concept of password history than the age itself.
Password history is a setting within your password policy that dictates how many different passwords have to be used before you can return to a previously used password. Let’s assume I have a password history policy of five. Then I set my first password as password one, and a few days goes by and I forget my password. So I use the forget password feature to reset my password, and I created as password two. But I really want to use my old password of password one again. So since I have a password age set of five, I can’t do that. Instead, I have to keep resetting my password until I do this five times. Then I could reuse my old password of password one again. Now, if my minimum password age was set to zero, I could simply reset my password five times in a row and go back to my initial password on the same day.
If this password was previously compromised by a data breach, for example, this would lead to a big vulnerability of my user credentials. For this reason, it is a good idea to have your password history setting set to a really high number, something like 25, because this will help prevent password reuse. When configuring your password policy and your authentication systems, you should always enable auditing on these systems. Auditing is the process of reviewing your password policy to ensure you have the proper settings, as well as reviewing any accounts created, changed, deleted, renamed, disabled, enabled, locked out, or unlocked. This will also allow you to monitor when a user’s account password is set or changed in a window system. You can perform this password audit by creating a group policy that enables user account management audit policy on your system.
The final password policy setting you need to consider is whether or not to allow passwords to be stored using reversible encryption. The best practice from a security standpoint is to disable the store password using reversible encryption setting in your password policy. But depending on your enterprise architecture and your business needs, this may not be possible. Some applications still use older protocols that require the user’s password to be provided for authentication. In these cases, the system has to be able to decrypt the user’s stored password and present it on their behalf to that application in order to authenticate the user and get them access or authorization to the application and its resources. For example, the Chat Protocol Challenge Handshake authentication protocol is commonly used for remote access, and it requires the store password using reversible encryption setting to be enabled in order for it to properly function.
Unfortunately, a knowledgeable attacker could break this reversible encryption, and then they could use that to log on to the network resources by using that compromised account. Because of this, it is recommended to never enable the store password using reversible encryption setting for all your users in the domain, unless your application requirements outweigh the need to protect password information. In general, you should move your remote access authentication to a more secure method instead of relying on something older like Chat. And then you could disable the remote reversible encryption setting to have a more secure enterprise network.
