Gartner defines identity and access management (IAM) as “the security discipline that enables the right individuals to access the right resources at the right times for the right reasons” and suggest that “enterprises that develop mature identity and access management capabilities can reduce their identity management costs and, more importantly, become significantly more agile in supporting new business initiatives.” Many software and cloud services vendors offer various turnkey IAM solutions ranging from on-premises products and systems to cloud-based ones like those available in Microsoft Azure. But fundamentally IAM isn’t about utilizing vendor products or services, it’s about practicing good security hygiene. Why is this important? And what are some best practices you should follow when you want to implement any kind of IAM solution for your business? To gain some insight concerning these questions I recently talked with Jeffrey Harris, an information technology engineer who has worked with every version of Windows since Windows 3.1. Jeffrey has over 30 years’ experience with IT, and much of that experience is in the areas of IT security and with identity and access management. For those of you who are still relatively new to this subject, Jeffrey’s edited responses below to the questions I asked him can serve as kind of a primer on the raison d’etre behind identity and access management and how to implement and perform IAM properly.
What are the basic concepts underlying identify and access management?
Let’s start with some definitions. I’m going to mainly focus on IAM in the context of large companies (but with some guidelines for smaller companies and service providers) and on the company workforce, not customers (since IAM for customers is evolving faster than workforce IAM).
First, an identity is the data representing a user or actor. In the business setting, it normally includes the name of the user, the department the user is assigned, the job code assigned to the user, the manager of the user, a start date, etc. An identity can be assigned to a person, someone working for or on behalf of the organization, such as a contractor or vendor, or a non-person identity (also known as a bot or service account). A non-person identity typically has an additional attribute, one or more owners who are responsible for the identity. Identities can also be assigned to devices, but that’s an advanced topic so we won’t discuss it here. Note that a specific user (person or non-person) should have only one identity, but can have as many accounts (and entitlements assigned to those accounts) as necessary. If users have more than one identity, then it is difficult (or impossible) to manage those identities and the accounts and entitlements assigned to the user in an effective way.
Next, an entitlement is an access granted on behalf of the identity. I say “on behalf of” because identities are not granted entitlements directly. They are granted to accounts associated with the identity, and accounts themselves can be considered a type of entitlement, because the account entitles the user to access one or more systems or resources. Accounts and entitlements can be assigned to the accounts associated with either a person or non-person identity.
If users have more than one identity, then it is difficult (or impossible) to manage those identities and the accounts and entitlements assigned to the user in an effective way.
An identifier is simply the name or label associated with an identity or account, and normally follows a standard convention, for example, an employee number, last name first initial, email address, etc.
An authenticator is a mechanism for verifying that the user claiming an identity is whom he claims to be. The most common authenticators are passwords, but an authenticator can also be a digital certificate, a physical device (such as a pass card), or a logical device (such as one time code generation app on a smart phone) or a combination of these types. Accounts normally have authenticators; identities never have authenticators.
A credential is a combination of an account identifier and an authenticator.
And finally, privileged access is any entitlement that grants a user the ability to modify, bypass, or disable security controls. For example, anyone who has a domain administrator account in a Windows domain has privileged access because the user can add/delete accounts (normally not a user capability), enable/disable access for users, modify audit policies, and remove audit data (manual removal of audit data is almost always a violation of policy in most organizations).
Why is good IAM so important for companies nowadays?
Target, Home Depot, Yahoo: These were some of the biggest data breaches of all time, and they all have one thing in common — stolen credentials! But while stolen credentials are complicit in many data breaches, it’s not the only problem. Credentials can and have been misused (improperly shared) to cause data breaches, and used by terminated or disgruntled employees to create data breaches or seek revenge on employers. And even when data breaches do not rise to the level of those of the Target or Yahoo events, IAM is important to security practitioners and service providers at all levels. First, data breaches can be caused by stolen or misused credentials and result in financial or reputational damage to the companies we may provide services to (either as employees or service providers), as noted in the link above. Second, they can cause security practitioners loss of jobs (for employees) or liability or simply loss of business (for service providers) if we are negligent in our management of IAM data. By one survey, 74 percent of data breaches are related to misuse of privileged access. Some organizations and practitioners consider identity and access management the new control plane, particularly for cloud environments, because connections to most systems requires some kind of credentials.
What are some best practices to follow for identity and access management?
First, enforce strong identity hygiene. Every user should have an identity in a security identity management system (separate from any HR systems) that correlates identity data from various systems that source identity data. In most organizations, these source systems are HR systems or contractor onboarding systems. If there is only one identity data source system (particularly in smaller companies), it can be used as the security identity management system, but that approach may limit the ability to expand the capabilities of the system to be used for more advanced identity management purposes, or it may simply put more load on the system or more responsibilities on the staff of those systems, who may understand the management of data in those specific systems, but not the larger functions of security identity management. For smaller organizations without a separate onboarding systems, it is fine to use active directory as the source identity system (in this case, the data in the active directory domain will function both as identity data and account data). Again, however, this approach is not scalable as companies grow from 10s or 100s of users to thousands of users. For larger organizations, with multiple systems that provide sources of truth about users, it is essential to consolidate the data from such systems about each individual user into a single comprehensive record in the security identity management system.
Credentials can and have been misused (improperly shared) to cause data breaches, and used by disgruntled or terminated employees to create data breaches or seek revenge on employers.
Second, separate account and entitlement provisioning from identity management. The security identity management system should feed identities into the provisioning systems (i.e., the systems that actually manage accounts and provision entitlements). No account should be provisioned without an underlying identity associated with the account. The reason for this is that when the user associated with the identity changes jobs or terminates from the company, the accounts and entitlements can be disabled/deleted or access reviews can be initiated (more on that below) based on the user’s changes in the source systems. In smaller organizations without a security identity management system, there should still be some kind of formal approval process for assignment of accounts and entitlements (i.e., the owner or general manager sends an e-mail message to the account administrator to create an account, and provides the necessary details for the account). In larger organizations, separating identity management from provisioning improves the scalability of both systems, and provides better separation of duties (the identity system administrators are not provisioning accounts, and the provisioning system administrators cannot create accounts and assign entitlements without a corresponding identity record which they do not manage).
Third, set up an entitlements warehouse, which identifies all the entitlements in all the systems within the organization, who is assigned to those entitlements, and includes risk rating and privileged access flags for each entitlement. Although in smaller organizations this may be not necessary if all entitlements are assigned in an active directory domain, or locally on a small number of servers or desktops and therefore can be easily collected when needed, and there are a limited number of entitlements, an entitlements warehouse is important for larger organizations, because you cannot manage what you do not know about! The entitlements warehouse can also be used to conduct peer analytics to identify unusual patterns of entitlement assignments based on entitlements assigned to other users with similar job functions, or assigned to users in similar or the same department. The entitlements warehouse can also be used to flag entitlements for privileged access reviews (discussed below) and to assign risk scores to users based on the risk ratings or privileged access flags for entitlements which have been assigned to users. Every entitlement needs to have at least two owners who are authorized and responsible for approving (but not necessarily provisioning) the assignment of the entitlement to other users, and entitlements should only be approved based on job functions and business needs.
Fourth, implement privileged user management. Any access considered privileged should be assigned to a separate account within the system for which the access is granted, and such accounts should be assigned to the user after an appropriate review of the user’s duties and justification for both the privileged account and the specific access (these accounts will still be tied in the provisioning systems to the user’s identity record). Any privileged access defined or granted should be limited in both scope and the number of users to which it is assigned and tailored to the needs of the business. For example, if a user requests domain administrator, but only needs account operator to perform his duties, give him only account operator (least privilege). In some cases, access can be also scoped in time (i.e., 30 days to stand up a new system), or scope (administrative rights to servers in a certain OU, rather than all servers in the company). A privileged user management system manages privileged accounts and passwords by resetting passwords daily or upon checkout and will significantly reduce misuse of such credentials. One technique to secure Active Directory administrator groups is given in this recent TechGenix article. Privileged access can also be strengthened by implementing multifactor authentication when users access end systems; the use of multifactor authentication for authenticating to the privileged user management system itself is a winning combination!
Fifth, invest in and configure systems to use a central authentication or single sign-on solution. Most applications today can leverage active directory for central authentication or a third-party single sign-on solution. Using central authentication better manages access when users leave the company, and reduces the instances of orphaned local accounts (particularly privileged local accounts) being left behind, which could be stolen or misuse.
Sixth, conduct account and access reviews. This can be done periodically in smaller companies, or be event driven in larger companies. For example, if a user changes jobs, trigger an access review based on changes in the user’s job code or department code. Access reviews can also be based on risk, or when users request certain types of access (i.e., conduct a review of all of user’s access if the user requests domain administrator access, or if a user’s risk score reaches a certain level). Access reviews should be done either by the entitlement owners, or the current manager. In some cases, such as with high risk or privileged access, it makes sense for both to do the reviews, with both reviewers needing to approve the retention of the entitlement. The review process should be managed by an automated access review system, or by IT staff separate from entitlement management.
Access should also be removed at the time of, or just prior to, notifying users they are being terminated due to layoffs or for cause.
Seventh, follow through on deprovisioning! User accounts and entitlements should be deprovisioned when a user leaves the company, or after access reviews when entitlements are not approved for retention. In larger organizations, there should be an automated process to do this for all user access. In smaller companies, IT or the service provider should not be the last people to be notified of user terminations or job or department changes. When users no longer need access based on current job responsibilities, it is critically important to remove that access, particularly if the access gives privileged access or access to read sensitive data. Also consider removing privileged and high risk access from users when they submit resignation letters and provide notice of their departure from the company. Access should also be removed at the time of, or just prior to, notifying users they are being terminated due to layoffs or for cause. Access should also be removed if users are not using it, particularly privileged access, but that generally requires auditing and a system to review user activity, and identify such unused entitlements.
By following these principles, and automating the processes as much as possible, you can help avoid the company you work for or provide IT services to from becoming the next Target or Home Depot, or even just becoming a target for retaliation by a disgruntled employee. And finally, note that although I have focused these tasks mainly on person accounts, the same practices apply to non-person account and entitlements. In that case for example the reviews should be done periodically either by the owners of the account, or the managers of the owners. These best practices also apply to cloud environments, and because of the ability to quickly stand up new cloud environments and populate them with sensitive or proprietary data, it is essential that all of the controls identified for on-premises identity and access management be applied to or adapted for cloud environments.
Featured image: Shutterstock
