CISSP Domain 5 Study Guide

CISSP Domain 5

CISSP Domain 5 focuses on Identity and Access Management, or IAM.  Managing access can be considered one of the important tasks of a security professional and if not taken seriously can affect all 3 pillars of the CIA triad. Compromising an identity or an access control system to gain unauthorized access to systems and information is the biggest reason for attacks involving the confidentiality of data. .

Topics covered in the CISSP Domain 5 include identity management systems, single and multi-factor authentication, accountability, session management, registration and proofing, federated identity management, and credential management systems.

CISSP Domain 5 – Authentication

LDAP

The Lightweight Directory Access Protocol (LDAP) is an open-source application protocol that allows applications to access and authenticate specific user information across directory services. LDAP is popular for on-premises corporate networks. An LDAP directory stores information about users, groups, computers, and sometimes other objects such as printers and shared folders. It is common to use an LDAP directory to store user metadata, such as their name, address, phone numbers, departments, employee number, etc. Metadata in an LDAP directory can be used for dynamic authentication systems or other automation.

The most common LDAP system today is Microsoft Active Directory (Active Directory Domain Services or AD DS). It uses Kerberos (an authentication protocol that offers enhanced security) for authentication by default.

Kerberos

Kerberos is a computer network security protocol that authenticates service requests between two or more trusted hosts across an untrusted network, like the internet. It uses secret-key cryptography and a trusted third party for authenticating client-server applications and verifying users’ identities. Kerberos is used in Posix authentication, and Active Directory, NFS, and Samba. It’s also an alternative authentication system to SSH, POP, and SMTP.

Here are the principal entities involved in the typical Kerberos workflow:

  • Client: The client acts on behalf of the user and initiates communication for a service request
  • Server: The server hosts the service the user wants to access
  • Authentication Server (AS): The AS performs the desired client authentication. If the authentication happens successfully, the AS issues the client a ticket called TGT (Ticket Granting Ticket). This ticket assures the other servers that the client is authenticated
  • Key Distribution Center (KDC): In a Kerberos environment, the authentication server logically separated into three parts: A database (db), the Authentication Server (AS), and the Ticket Granting Server (TGS). These three parts, in turn, exist in a single server called the Key Distribution Center
  • Ticket Granting Server (TGS): The TGS is an application server that issues service tickets as a service

How Kerberos works?

The protocol flow consists of the following steps:

Step 1: Initial client authentication request. The user asks for a Ticket Granting Ticket (TGT) from the authentication server (AS). This request includes the client ID.

Step 2: KDC verifies the client’s credentials. The AS checks the database for the client and TGS’s availability. If the AS finds both values, it generates a client/user secret key, employing the user’s password hash.

The AS then computes the TGS secret key and creates a session key (SK1) encrypted by the client/user secret key. The AS then generates a TGT containing the client ID, client network address, timestamp, lifetime, and SK1. The TGS secret key then encrypts the ticket.

Step 3: The client decrypts the message. The client uses the client/user secret key to decrypt the message and extract the SK1 and TGT, generating the authenticator that validates the client’s TGS.

Step 4: The client uses TGT to request access. The client requests a ticket from the server offering the service by sending the extracted TGT and the created authenticator to TGS.

Step 5: The KDC creates a ticket for the file server. The TGS then uses the TGS secret key to decrypt the TGT received from the client and extracts the SK1. The TGS decrypts the authenticator and checks to see if it matches the client ID and client network address. The TGS also uses the extracted timestamp to make sure the TGT hasn’t expired.

SSO

Single sign-on is an authentication method that allows users to sign in using one set of credentials to multiple independent software systems. Using SSO means a user doesn’t have to sign in to every application they use. With SSO, users can access all needed applications without being required to authenticate using different credentials. The SSO experience will last for a specified period, often enough time to do work, such as 4 to 8 hours. The main benefit of SSO is also its main downside – it simplifies the process of gaining access to multiple systems for everyone. Which means, the bad guys can also take advantage of the convenience. Multi-factor authentication (MFA) can help mitigate this risk.

Single sign-on options

Choosing an SSO method depends on how the application is configured for authentication. Cloud applications can use federation-based options, such as OpenID Connect, OAuth, and SAML. The application can also use password-based SSO, linked-based SSO, or SSO can be disabled.

  • Federation – When you set up SSO to work between multiple identity providers, it’s called federation. An SSO implementation based on federation protocols improves security, reliability, end-user experiences, and implementation. With federated single sign-on, Azure AD authenticates the user to the application by using their Azure AD account.
  • Password – On-premises applications can use a password-based method for SSO. This choice works when applications are configured for Application Proxy. With password-based SSO, users sign in to the application with a username and password the first time they access it. After the first sign-on, Azure AD provides the username and password to the application. Password-based SSO enables secure application password storage and replay using a web browser extension or mobile app.
  • Linked – Linked sign-on can provide a consistent user experience while you migrate applications over a period of time. If you’re migrating applications to Azure AD, you can use linked-based SSO to quickly publish links to all the applications you intend to migrate. Users can find all the links in the My Apps or Microsoft 365 portals. After a user has authenticated with a linked application, an account needs to be created before the user is provided single sign-on access. Provisioning this account can either occur automatically, or it can occur manually by an administrator.
  • Disabled – When SSO is disabled, it isn’t available for the application. When single sign-on is disabled, users might need to authenticate twice. First, users authenticate to Azure AD, and then they sign in to the application.

Multi-Factor Authentication

Multi-factor authentication (MFA) is a security measure that requires two or more proofs of identity to grant you access. Multi-factor authentication typically requires a combination of something the user knows (pin, secret question), something you have (card, token) or something you are (finger print or other biometric).

Businesses as well as individuals should implement MFA wherever possible. Some MFA options include, but are not limited to:

  • Physical token
  • Random pin
  • Biometrics / fingerprint
  • Authenticator app
  • Email
  • SMS

Biometrics Method

  • Retinal scan – a map of retina’s blood vessels.
  • Iris recognition – a map of the Iris.
  • Fingerprint – a picture of the fingerprint.
    • Minutiae are the specific plot points on a fingerprint. This includes characteristics such as ridge bifurcation or a ridge ending on a fingerprint.
  • Palm print or structure – a picture of the palm print of a picture of the structure of the palm.
  • Walk recognition
  • Keyboard typing recognition
  • Signature recognition
  • Face recognition
  • Voice recognition

Biometric Functions in Two Modes

  1. Verification (or Authentication) mode, the system performs a one-to-one comparison of a captured biometric with a specific template stored in a biometric database in order to verify the individual is the person they claim to be.
  2. Identification mode the system performs a one-to-many comparison against a biometric database in an attempt to establish the identity of an unknown individual. The system will succeed in identifying the individual if the comparison of the biometric sample to a template in the database falls within a previously set threshold. Identification mode can be used either for ‘positive recognition’ (so that the user does not have to provide any information about the template to be used) or for ‘negative recognition’ of the person “where the system establishes whether the person is who they (implicitly or explicitly) deny to be”.

Performance Metrics in Biometrics

  • Type 1 error – FRR is the probability of type I errors or false non-match rate (FNMR).
    • It’s the probability for a valid user to be rejected.
  • Type 2 error – FAR is the probability of type II errors or false match rate (FMR).
    • It’s the probability for a unauthorized user to be accepted.
  • CER – CER where the ratio of the FRR and the FAR are equal.

Remote Access Control Administration

Remote access protocols provide authentication, authorization, and accounting (AAA) services. Some common AAA protocols include the following.

  • RAS – Remote Access Service servers utilize the Point-to-Point Protocol (PPP) to encapsulate IP packets. PPP incorporates the following three authentication protocols: PAP (Password Authentication Protocol), CHAP (Challenge Handshake Authentication Protocol), EAP (Extensible Authentication Protocol).
  • RADIUS – The Remote Authentication Dial In User Service protocol is a widely used AAA protocol in remote access systems and by Internet Service Providers (ISPs). Radius is a third-party authentication system. It uses UDP and encrypts the password but not the entire authentication session. RADIUS is described in RFCs 2865 and 2866, and uses the User Datagram Protocol (UDP) ports 1812 (authentication) and 1813 (accounting).
  • Diameter is RADIUS’ successor, designed to provide an improved Authentication, Authorization, and Accounting (AAA) framework. RADIUS provides limited accountability, and has problems with flexibility, scalability, reliability, and security. It can be used with wireless devices, Voice over IP (VoIP), Mobile IP, and smartphones, but it is not backward-compatible with RADIUS. Diameter also uses Attribute Value Pairs but supports many more: while RADIUS uses 8 bits for the AVP field (allowing 256 total possible AVPs), Diameter uses 32 bits for the AVP field (allowing billions of potential AVPs). This makes Diameter more flexible, allowing support for mobile remote users, for example.
  • TACACS -Created by Cisco, the Terminal Access Controller Access Control System is a centralized access control system. TACACS separates each element of AAA in three processes.  It requires users to send an ID and static (reusable) password for authentication. TACACS uses UDP port 49 (and may also use TCP).


Source link