Large enterprises often have very complex environments to manage. There are internal users to manage, there are internal services and external service providers. There are customers to consider, for guest users, within Business-to-Business (B2B) relationships. Federation services can be utilized to ensure robust, centralized authentication and access control are addressed in these hybrid environments. To manage all these interactions with information systems, the correct protocols must be chosen to make sure we have secure authentication and authorization. Many modern environments require the use of an additional factor as a single factor, such as just a user password, is known to be weak. In this chapter, you will learn how to effectively select the appropriate solution.
In this chapter, we will go through the following topics:
Credential management is critical for an enterprise. We must consider the day-to-day management of user credentials, including effective management of passwords. We must ensure passwords are created, stored, and destroyed securely. They must always be processed securely as well.
The goal of SSO is to allow users to use a single account to access many services. This relies on robust authentication so ties in nicely with MFA. The weakness of SSO would be the account credentials being stolen. It is important to protect the account. SSO is very convenient for users. They must only remember one set of credentials.
Tip
When you sign in to Google to access Gmail, Google Docs, and content on YouTube, you will only need to sign in once with your Google account.
Organization goals should include the use of SSO wherever possible. This allows a single account to be used for multiple applications or services. This goal, however, is not always achievable as some online service providers may not support SSO and insist upon creating local accounts. To allow users to store these additional accounts with passwords in a safe way, a local secure password repository can be used. Microsoft provides Credential Manager; Apple provides iCloud Keychain. This allows the use of a secure vault to store the required account password and transmit it to the application when required. See Figure 4.1 for a depiction of Microsoft Credential Manager:
It is important to have a secure, easy-to-use container for authentication credentials.
As hybrid cloud models become the new normal for a business, they present a challenge for secure credential management. Should passwords be stored with the cloud provider? It is worth considering many cloud providers will have advanced access control, behavioral analytics, and continuous validation as part of their security offering. However, there is often a choice to use federation when accessing cloud-based services. When using Microsoft 365 services, it is possible to manage all identities on-premises, including passwords, and gain federated access to cloud portals.
Federation will be covered in detail in the Identity federation section.
Traditional password management software relies on the local operating system and stores the keys locally. Another option is for a hardware key manager that is quite popular and is relatively low cost but offers additional security just like having a separate smart card. A hardware key will typically support strong encryption algorithms to protect passwords. These devices may include tamper protection, erasing the contents after a number of failed attempts. Figure 4.2 shows a hardware implementation of a key manager:
When we look at the use of multiple accounts that are privileged, there are better-managed solutions to handle this requirement.
Privilege access management systems are very useful for allowing an employee to log in with their individual account and when necessary, they can check out an elevated credential password. This system will also allow the use of a shared account, but still makes that user accountable because their access to that privileged account will have been logged against their individual user account. This is even more useful nowadays as many organizations have hybrid cloud models, where we need to administrate on-premises and then with multiple cloud providers.
Password policies need to be enabled to make sure that users will change their passwords based on the organization's requirements. Passwords can be chosen to have a certain level of complexity and/or meet a minimum character length. Password complexity is used to enforce the use of different character classes (uppercase, lowercase, numbers, and special characters: @~#!"£€%&). It is also important to have a password history so that users cannot reuse old passwords. Guidance has changed over recent years. Instead of enforcing super-complex passwords, it is accepted that Two-Factor Authentication (2FA) or MFA is the preferred option to protect identities. A long passphrase is proven to be much more secure overall than a complex password. To enforce password requirements, we could use a policy such as the one shown in Figure 4.3:
If we do not have a baseline password requirements policy, users may choose weak passwords.
Password requirements will often have a requirement for complexity. This will require at least three from four character classes: uppercase, lowercase, numbers, and special characters.
Eight characters is generally recommended as the minimum length of a password; any greater than this and users will adopt bad practices, such as repeating the password to meet this requirement, for example, Bertie26Bertie26.
Password history is important. Without password history, compromised accounts may be reset to the original password, allowing the attackers to gain access to the account again.
It is important to have a password minimum age as without a password minimum age, users may reset their passwords multiple times to get back to the original password. A password maximum age, however, is not really recommended anymore. Requiring users to change their password frequently (often every 30, 60, or 90 days) can sometimes mean they choose a weak password by simply incrementing a sequential number at the end of the old password. The passwords that are then chosen are often a poor choice and are vulnerable to attack. Also consider the fact that a compromised password is exploited immediately.
Password auditing is important as it allows the organization to check for weak passwords. Password checking can be done when users reset their passwords. We could use a dictionary word list to generate hashes and check that the users are not using those weak passwords. The National Cyber Security Center (NCSC) has listed 100,000 passwords taken from https://haveibeenpwned.com. The list can be found at the following link: https://www.ncsc.gov.uk/static-assets/documents/PwnedPasswordsTop100k.txt. The first 20 words from the list are shown in Figure 4.4:
If you find any of your passwords that are in use shown in this list, you should change them immediately.
Passwords should be stored in a secured format within a password database. They are normally hashed, prior to being written into the database. Password reversible encryption allows passwords to be stored in a plain text format. This is used for some legacy applications (perhaps a remote access management solution). These should never be used. An example would be Microsoft Remote Access Service (RAS). This allows users to be authenticated using Challenge Handshake Authentication Protocol (CHAP).
As well as being able to authenticate user accounts within our own sites, it is also important to work with external entities.
Identity federation allows you to use your identity with a third party. Many organizations will use services in the cloud such as software as a service. This allows the user to use SSO in their own enterprise and when accessing these third-party applications. Users only need to remember one identity. Typically, a token will be generated by an identity federation service and passed securely to the third party. Microsoft provides a service called Active Directory Federation Services (ADFS), which allows an authenticated enterprise user to use their credentials on a third-party site. They support many of the standard protocols in use out there including Security Assertion Markup Language (SAML).
Transitive trust can be very useful within complex enterprise environments. When using directory services, we can create security boundaries referred to as domains or Kerberos realms. It is common to create these boundaries to separate account management geographically. For example, a bicycle manufacturer has a Taiwanese engineering and production plant in Taipei. They have sales, marketing, and distribution in Santa Cruz, US, which is the head office, and the same business function in Morzine, France. Each location has a separate domain, with the US being the root and Taiwan and France being child domains. In Figure 4.5, we can see the trust relationships between the domains:
There are direct trusts between the root domain and the child domains. There is, however, transitive trust between the two child domains. The relationship is similar to the concept of an authenticated Internet Protocol Security (IPsec) tunnel. An administrator would still need to provision access to resources, but there would be inherent trust between all parts of the organization. The sales team could then be given read privileges to production data from the manufacturing plant.
Cloud-based Identity Providers (IdPs) such as Google, Facebook, and Twitter support a standard called OpenID. This is often used to access third-party services (referred to as the Relying Party (RP)) who support this standard. The current standard is version 2.0, and it is administered by the OpenID Foundation, a non-profit entity.
Once an identity has been validated by the OpenID provider, a secure token is generated and forwarded to the requesting service provider in the form of a JavaScript Object Notation Web Token (JWT). Figure 4.6 shows the OpenID SSO process:
While OpenID is standard for cloud-based identities, there are other options used when enterprise users access third-party corporate portals.
SAML is an open standard typically used to access corporate cloud-based portals for access to applications. It requires an IdP. The IdP will typically use directory services internally; the service provider will be the cloud entity. The service provider will require a secure token generated by the IdP. It also makes the experience for the user transparent, makes it easy for them to access third-party services, and supports SSO. Microsoft allows SAML to authenticate identities to Microsoft 365 services. SAML actually creates assertions. It uses the XML language and is secure. Assertions could include authentication attributes and authorization decisions.
The experience will be completely transparent to the user if they have already authenticated with the IdP:
SAML is a good choice for accessing third-party corporate portals.
Shibboleth is similar to SAML. It is, however, used mainly by educational establishments such as colleges and universities. It also allows for SSO by passing a token to the service provider and requires an IdP.
Once we have authenticated accounts, we may give access to resources.
Access control can be used to control authorization once a user has been authenticated. There may be many different requirements; for example, developers may need to share their code with one another. There may be requirements for very strict access control when there are sensitive documents that must be accessed. There may be a requirement to give privileges and rights to administrative role holders or perhaps to give fine-grained access based upon the location or the country of origin of the account holder. In the following section, we will investigate these choices.
MAC is generally seen as the most secure way of controlling access to assets. It requires clearance levels. It requires the data to be classified or labeled. It can be time-consuming but offers the most security. Government agencies such as the Department of Defense and other such entities will typically use this system. Figure 4.8 shows the classification options for a filesystem folder:
It is important to ensure strict adherence to a MAC framework; no write down and no read up (this stops a user with a lower clearance level from seeing data they are not cleared for).
DAC means the authorization to the resource is controlled by the owner. This works well in the Windows NTFS filesystem where the owner of a file or a folder can assign permissions to other users or groups. This allows for decentralization. Another good example could be a SharePoint portal. While ownership is assigned to a team leader, they can then add their co-workers to give them access to the site:
DAC could work well for smaller integrated teams (such as developers).
Role-based access control can be used with existing roles, such as administrators, network configuration operators, and backup operators, or groups can be created for business units such as sales, marketing, production, and research. Role-based access control is centralized. It requires the administration to be done centrally. It works well with directory services. In Figure 4.10, we can see a list of Microsoft Active Directory groups. There are built-in role groups such as Cert Publishers and DHCP Administrators. Bill and Ben have been added to the ITAdmin group:
Roles or groups are commonly used to manage a large enterprise user base and are considered a good way to implement the best practice of least privilege.
Rule-based access control can be good for things where we need a common set of controls; for example, a particular department may require all their users to only work within certain hours or the requirement is that certain users can only log on from certain workstations. In Figure 4.11, we can see two student accounts have limited logon hours and can only log on from two workstations (intern01 and intern02):
Rules can be very useful when we have a set of requirements to assign to multiple accounts.
Attribute-based access control offers another level of granularity. It also works well with directory services. Attributes are associated with objects; for example, a user can have a department or a country attribute associated with their account. These attributes could be used to give more granular access to resources. For example, you may have research data that can only be accessed by scientists in the US. You could put extra controls in place so that members of the Scientists group can only access the data if they have United States as the country on their Active Directory user account:
In order to capture user credentials and authorize access to resources, there are industry-standard approaches.
There are many protocols associated with authentication and authorization in an enterprise. A common approach will be to log on within the domain using directory services. This may use Kerberos as an SSO protocol. In other cases, we must look at solutions where this is not possible. Remote access could be an example, or securing access to the network using the new zero-trust approach. In this section, we will take a look at the available protocols.
RADIUS is a well-supported Authentication, Authorization, and Accounting (AAA) protocol. This is used to gain access to networks, so it could be used to grant access over a Virtual Private Network (VPN) or anything that will require remote access. Radius could also be used to gain access to a switch that is Ethernet 802.1 X-compliant. This could also be used to gain access to a Wireless Access Point (WAP). AAA allows the RADIUS client (network device) to pass on authentication requests to the AAA server. The server will often pass these requests back to a directory services server, as RADIUS may not actually hold the user account database. RADIUS supports two networking protocols or port numbers. It can operate on UDP port 1812 or UDP port 1645 (this is normally used by Cisco). Figure 4.13 shows clients (supplicants) accessing networks through 802.1x-compliant RADIUS clients:
While RADIUS is the most widely adopted AAA protocol, there are other solutions.
TACACS was originally developed in 1984 and was very common on UNIX networks for the purpose of authenticating access to a network. It has been further developed by Cisco and the current standard is TACACS+. This has no compatibility with earlier versions. TACACS is like RADIUS but does not have as wide support as RADIUS. It uses TCP ports for AAA, making it more reliable, and it is said to be more secure because it encrypts the entire authentication process (it uses TCP port 49).
Diameter is the next version of RADIUS. It is based upon RADIUS but uses TCP ports to make the connection and the authentication more reliable. It has wide support from many vendors. It has been assigned TCP port 3868.
LDAP is a standard for accessing directory services. It was chosen as an alternative to Directory Access Protocol (DAP), as it is more straightforward. LDAP allows for access to directory services and the creation of content, such as user accounts, computer accounts, and other types of objects in directory services. It is usually used to administer directory services. It is defined in RFC 4511. LDAP uses port 389 for regular access. Alternatively, we can use Transport Layer Security (TLS). This uses TCP port 636 and allows for the connection to be secured (LDAPS). Figure 4.14 shows the typical administration of objects in an LDAP database. In this instance, we are resetting a user password and creating a new user account:
LDAP does not provide the authentication for the user login.
Kerberos is a secure SSO protocol that was developed by the Massachusetts Institute of Technology (MIT) and is protected by export restrictions to use within the US. This is now supported by the Internet Engineering Task Force (IETF) and has been assigned several RFCs defining the implementation (RFC 3961, 3962, 4120, and 4121). Kerberos is in widespread use and is supported by many operating system vendors, including Red Hat, Oracle, and IBM. It has been the standard for Microsoft Active Directory services for over 20 years. Kerberos supports encrypted communication and anti-replay. Kerberos is very time-dependent. It is important that the clocks are in synchronization; otherwise, Kerberos authentication will fail. Figure 4.15 shows the Kerberos SSO mechanism. The server hosting the Key Distribution Center (KDC) and Ticket Granting Services (TCS) could be a Windows Domain Controller (DC) running Active Directory services:
Kerberos is used on enterprise networks but is not used when accessing third-party sites or B2B partners.
OAuth allows for SSO. Users can sign in to their OpenID provider such as Facebook, Google, or Twitter and they can access third-party services. Users do not need to remember multiple credentials. It is used by many service providers, including Microsoft, Tripadvisor, Hotels.com, and many merchant sites requiring payment authorization. There are currently two versions of Open Authorization (OAuth): V1 and V2. OAuth V2 is the current standard. PayPal would be a good example of a system we use every day. If you make a payment on a merchant site and you choose to use PayPal, you will end up being prompted to authorize that payment. A token will be securely generated by PayPal and sent to the merchant site. This will authorize the transaction.
Figure 4.16 shows typical sites supporting SSO using OAuth:
Once you have indicated the account that is to be used, the connection can be transparently made in the future.
Important Note
OAuth defines the flow of requests and responses to authorize a transaction, while OpenID defines the role of the IdP.
802.1X is an Ethernet standard. It defines Port-Based Access Control (PBAC). It can allow devices or users to be authenticated to a network connection and is supported on switches, remote-access VPNs, and WAPs. It can be easily configured with the use of Public Key Infrastructure (PKI) certificates. Certificates can be assigned to devices such as computers, mobile devices, IoT devices, and network printers. A wide variety of devices can be connected securely to networks, removing the need for actual credentials to be typed in.
EAP is a framework. This allows more secure authentication methods to be implemented when using PBAC. PBAC is implemented when network devices support 802.1x Ethernet standards. For more details, see Chapter 1, Designing a Secure Network Architecture.
Tip
For the certification exam, it is important to recognize the appropriate authentication protocols to provide both security and compatibility within complex enterprise networks.
A single factor for authentication is always a risk. Compromise of a password may be all that is needed for hackers to take control of an account. Having a second factor is the best protection against this threat.
MFA is becoming an important consideration for many enterprises as passwords alone are not considered secure enough. Guidance from the NCSC in the United Kingdom recommends that MFA should be used to counter the threat of compromised passwords. Microsoft strongly promotes the use of MFA when accessing their cloud services. It is becoming more and more straightforward to implement multiple factors; for example, Microsoft automatically supports the use of smart cards with Active Directory accounts. There are many third-party solution providers offering mobile authenticator apps. We will take a look at some of the choices in the following sections.
2FA simply means using two different methods or two different factors during the authentication process. You must combine two different factors. Factors are assigned a unique identifier (there are five factors: Type I through to Type V).
The factors include the following:
Tip
Two factors could be password and smart card, pin and ATM card, or biometrics and a physical token such as an RFID card. One of each type (Type I and Type III, for example) is required.
Additional authentication can be triggered by a change of context; maybe you logged in from a new location, or from a device that you have never logged in from before.
Two-step verification is supported by many online IdPs. Think about when you log in to Google from a new workstation you have never signed in from before. You would receive a push notification in your Google app on your smartphone and need to respond:
When using two-step verification, it is preferable to use a second channel. Imagine a fraudster phished the credentials of a user. They would have to gain control of something else as well, such as the user's smartphone.
In-band authentication would mean doing all the necessary authentication checks using a single channel, such as your internet browser connection to your bank. This would be seen as inferior to other mechanisms. Reliance on in-band authentication makes the possibility of Cross-Site Request Forgery (CSRF/XSRF) very real. Imagine you are connected to your bank and have logged on with your user account and password. A malicious script could authorize a payment to a criminal.
OOBA would require the use of a secondary channel, such as when you log in to your bank, you receive an SMS message on your smartphone, or when you log in to your Google account, you are asked to verify your identity using your smartphone. Your bank will use OOBA to send you an authorization request, to prevent fraud.
OTPs mean you are prompted for a password that you did not previously know or set; this is typically a password that is generated for you for one-time use where you must enter a strong password for future use to continue.
HMAC-based systems generate OTPs on demand. The device will have a seed or a key. It will generate codes or passwords based upon an incrementing counter. These passwords do not have to be used immediately, which means this could be less secure. HMAC OTPs do not always have to be used sequentially, which means this system could be exploited.
TOTPs are based on the same principle as HMAC-based OTPs. There is a key that will be embedded into your token (or smart app) that creates codes based upon the current time. The password will only be relevant for 30 seconds (although this set time can vary); then, a new password will be generated. This reduces the chances of passwords being compromised. Figure 4.18 shows an RSA SecurID token device:
Time synchronization with the authentication server is important. This type of MFA is very popular and with more and more online digital identities to manage, you need to ensure access is secured to these online portals. When you complete your tax returns, you can secure this with MFA TOTP or connect to your bank to perform electronic banking. Figure 4.19 shows typical TOTP prompts:
There are many other solutions allowing for secure attestation.
A hardware root of trust is a secure container. A good example would be a hardware implementation of a security module such as the Trusted Platform Module (TPM) incorporated into many modern computer systems. This allows for values to be stored that could be used for secure boot, as we can validate the information that is stored in that container. We can use it to store cryptographic keys for BitLocker Drive Encryption, providing security while encrypting and decrypting drives.
TPM can store other types of information that can be used to validate or attest that certain conditions or information are correct. It is used for mobile device management, as we can store software and hardware values in a secure container. If we trust that container, we can extract the information from that hardware root of trust. When you enable BitLocker with TPM support, you will need to configure additional settings, as in Figure 4.20:
Users will be able to remember a single set of credentials more easily. Whenever we ask users to authenticate with multiple sets of credentials, we introduce the risk of unsecured user behaviors.
JWT is based upon an open standard (RFC 7519). It is used for securely sending information between parties where a secure trusted payload is important. The attestation service will validate a piece of information so this could be very useful within a cloud environment where we are not already directly trusting one another. Microsoft could be the attestation provider; they will sign a requestors information package and if the third party trusts Microsoft's attestation service, they will be able to trust the JWT. It is a similar concept to PKI; if you trust the root CA, then you automatically trust certificates generated within that hierarchy. JWTs can be used for both attestation and identity proofing. A common use of JWT is when using federation services such as OpenID and OAuth V2.
In this chapter, we have studied the challenges large enterprises face when they must support complex environments, needing to manage internal users and their authentication to external service providers. We have looked at the role of federation services, to ensure robust authentication and access control are addressed in hybrid environments. We have looked at the use of MFA as a single factor is known to be weak. We have studied the options to ensure authentication is needed to gain access to a network.
In this chapter, you have gained the following skills:
These core skills will be useful as we move into the next domain: security operations.
Here are a few questions to test your understanding of the chapter:
3.144.30.62