This Post builds on the previous post (How to Control Physical and Logical Access to Assets). The subtopics are more operational in nature and go into more detail.
- Identity management implementation. We looked briefly at SSO and LDAP. Now, we will look at them in more detail.
- SSO. Single sign-on provides an enhanced user authentication experience as the user accesses multiple systems and data across a variety of systems. It is closely related to federated identity management (which
is discussed later in this section). Instead of authenticating to each system individually, the recent sign-on is used to create a security token that can be reused across apps and systems. Thus, a user authenticates once and then can gain access to a variety of systems and data without having to authenticate again. Typically, the SSO experience will last for a specified period, such as 4 hours or 8 hours. SSO often takes advantage of the user’s authentication to their computing device. For example, a user signs into their device in the morning, and later when they launch a web browser to go to a time-tracking portal, the portal accepts their existing authentication. SSO can be more sophisticated. For example, a user might be able to use SSO to seamlessly gain access to a web-based portal, but if the user attempts to make a configuration change, the portal might prompt for authentication before allowing the change. Note that using the same username and password to access independent systems is not SSO. Instead, it is often referred to as “same sign-on” because you use the same credentials. The main benefit of SSO is also its main downside: It simplifies the process of gaining access to multiple systems for everyone. For example, if attackers compromise a user’s credentials, they can sign into the computer and then seamlessly gain access to all apps using SSO. Multifactor authentication can help mitigate this risk.
- LDAP. Lightweight Directory Access Protocol (LDAP) is a standards-based protocol (RFC 4511) that traces its roots back to the X.500 standard that came out in the early 1990s. Many vendors have implemented LDAP-compliant systems and LDAP-compliant directories, often with vendor-specific enhancements. LDAP 53 is especially 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.
- Single- or multi-factor authentication. There are three different authentication factors — something you know, something you have and something you are. Each factor has many different methods. Something you know could be a username and password or the answer to a personal question; something you have could be a smartcard or a phone, and something you are could be a fingerprint or retinal scan. Single-factor authentication requires only one method from any of the three factors — usually a username and password. Multi-factor authentication (MFA) requires a method from each of two or three different factors, which generally increases security. For example, requiring you to provide a code sent to a hard token in addition to a username and password increases security because an attacker who steals your credentials is unlikely to also have access to the hard token. Different methods provide different levels of security, though. For example, the answer to a personal question isn’t as secure as a token from a security app on your phone, because a malicious user is much more likely to be able to discover the information to answer the question on the internet than to get access to your phone. One downside to multi-factor authentication is the complexity it introduces; for instance, if a user doesn’t have their mobile phone or token device with them, they can’t sign in. To minimize issues, you should provide options for the second method (for example, the user can opt for a phone call to their landline).
- Accountability. In this context, accountability is the ability to track users’ actions as they access systems and data. You need to be able to identify the users on a system, know when they access it, and record what they do while on the system. This audit data must be captured and logged for later analysis and troubleshooting. Important information can be found in this data. For example, if a user successfully authenticates to a computer in New York and then successfully authenticates to a computer in London a few minutes later, that is suspicious and should be investigated. If an account has repeated bad password attempts, you need data to track down the source of the attempts. Today, many companies are centralizing accountability. For example, all servers and apps send their audit data to the centralized system, so admins can gain insight across multiple systems with a single query. Because of the enormous amount of data in these centralized systems, they are usually “big data” systems, and you can use analytics and machine learning to unearth insights into your environment.
- Session management. After users authenticate, you need to manage their sessions. If a user walks away from the computer, anybody can walk up and assume their identity. To reduce the chances of that happening, you can require users to lock their computers when stepping away. You can also use session timeouts to automatically lock computers. You can also use password-protected screen savers that require the user to re-authenticate. You also need to implement session management for remote sessions. For example, if users connect from their computers to a remote server over Secure Shell (SSH) or Remote Desktop Protocol (RDP), you can limit the idle time of those sessions.
- Registration and proofing of identity. With some identity management systems, users must register and provide proof of their identity. For example, with self-service password reset apps, it is common for users to register and prove their identity. If they later forget their password and need to reset it, they must authenticate using an 54 alternative method, such as providing the same answers to questions as they provided during registration. Note that questions are often insecure and should be used only when questions can be customized or when an environment doesn’t require a high level of security. One technique users can use to enhance question and answer systems is to use false answers. For example, if the question wants to know your mother’s maiden name, you enter another name which is incorrect but serves as your answer for authentication. Alternatively, you can treat the answers as complex passwords. Instead of directly answering the questions, you can use a long string of alphanumeric characters such as “Vdsfh2873423#@$wer78wreuy23143ya”.
- Federated Identity Management (FIM). Note that this topic does not refer to Microsoft Forefront Identity
Manager, which has the same acronym. Traditionally, you authenticate to your company’s network and gain access to certain resources. When you use identity federation, two independent organizations share authentication and/or authorization information with each other. In such a relationship, one company provides the resources (such as a web portal) and the other company provides the identity and user information. The company providing the resources trusts the authentication coming from the identity provider. Federated identity systems provide an enhanced user experience because users don’t need to maintain multiple user accounts across multiple apps. Federated identity systems use Security Assertion Markup Language (SAML), OAuth, or other methods for exchanging authentication and authorization information. SAML is the most common method for authentication in use today. It is mostly limited to use with web browsers, while OAuth isn’t limited to web browsers. Federated identity management and SSO are closely related. You can’t reasonably provide SSO without a federated identity management system. Conversely, you use federated identities without SSO, but the user experience will be degraded because everyone must re-authenticate manually as they access various systems.
- Credentials management systems. A credentials management system centralizes the management of credentials. Such systems typically extend the functionality of the default features available in a typical directory service. For example, a credentials management system might automatically manage the passwords for account passwords, even if those accounts are in a third-party public cloud or in a directory service on premises. Credentials management systems often enable users to temporarily check out accounts to use for administrative purposes. For example, a database administrator might use a credentials management system to check out a database admin account in order to perform some administrative work using that account. When they are finished, they check the account back in and the system immediately resets the password. All activity is logged and access to the credentials is limited. Without a credentials management system, you run the risk of having multiple credentials management approaches in your organization. For example, one team might use an Excel spreadsheet to list accounts and passwords, while another team might use a third-party password safe application. Having multiple methods and unmanaged applications increases risks for your organization. Implementing a single credentials management system typically increases efficiency and security.
Learn More: