Identity and Access Management (IAM) consists of the set of safeguards you implement related to how you authorize, authenticate, restrict, track, and revoke access to your information systems/assets. With appropriate safeguards in place, you can reduce the risk of an unauthorized individual accessing and disclosing data.
This guide describes why IAM is important, the critical decisions your company will need to make in this context, and how to balance system access with information confidentiality.
Implementing IAM controls is critical because it is how you ensure that only individuals authorized to access your information systems can access them, and it is the way you ensure authorized individuals only have access to the parts of your system necessary for their specific job functions. By implementing appropriate IAM controls, you can reduce the likelihood that an unauthorized party accesses your system and improperly discloses information.
In order to ensure that only the right people are accessing your most important data, at a minimum you should ensure that accounts can be associated with real people; access to systems is formally authorized; access is granted to systems in accordance with those authorizations (and routinely audited); and users follow authentication and remote access best practices.
Each member of your organization should have a unique “identity”–this is the starting point of IAM. Specifically, this usually means linking an individual’s name with an organization-specific email address or username linked to that employee. This way, in the future, you will be able to link access records (“digital footprints”) to a specific person.
While it is best practice to have a unique user ID for every individual with access to your information systems, it is indispensable for assets that store or process Sensitive/Regulated Information.
A word about shared accounts: sometimes it will be appropriate for you to provide shared access to an account through a general/non-personalized user ID. When you decide to issue shared credentials to a team, the same general principles outlined above apply, and you should take the additional step of ensuring that the shared account does not handle Sensitive/Regulated Information.
Not all of your workforce members need to access every one of your information systems or assets; instead, the only users who should have access to your assets are those who have been authorized to access your assets based on business need. To that end, implementing authorization procedures for determining who is allowed to access your assets is crucial.
By restricting who is authorized to access your assets, not only do you reduce the number of individuals who could disclose important data, but you also limit the potential sources of a data disclosure, which should help to narrow your investigative efforts following a breach.
In creating authorization processes, there are three general principles that should guide your decision to authorize a workforce member to access a particular asset: Deny-by-Default, Need-to-Know, and Least Privilege.
These three principles are united in that they all (in different ways) send the same message: less is more when it comes to access authorization. Your company should plan for a hacker to compromise a workforce member’s identity/ system credentials and for the possibility that a workforce member or customer with access presents an insider threat. In either case, if you apply these principles to your IAM approach, you can reduce the prospect of harm.
You should deny access to company platforms by default. Denial-by-default puts the burden on asset owners to affirmatively authorize individual access to a system. This is a more onerous process than authorizing access to company information systems by default, but denial is the more security-sensitive approach of the two. This approach will limit the prospect of data compromises by restricting the number of actors with access to specific systems (read: restricting the number of threat sources).
Need-to-Know access means allocating system access to individuals based on business needs. If an individual has a specific work-related reason for access to a platform, then that would be grounds for granting that individual access. If that reason does not exist, then they should not receive access to it.
Last is the principle to grant only the minimal level of privilege necessary to execute a business function. If you grant more than is necessary, you unnecessarily create additional chances for data compromise. For instance, if a hacker compromises a user’s ID and password, if you grant least-privilege access only, you will limit the scope of any potential damage. The point here is that even if someone has a business need for platform access, that alone does not mean they should have unrestricted or privileged access to the asset. If baseline access is appropriate for a work purpose, it is important to remember to tier access accordingly.
Role-based Access Controls (RBAC) are access controls that are based on–you guessed it–workforce members’ roles. For example, all members of your engineering team will likely require access to the same systems–so instead of authorizing each member one by one, you can authorize them as a team. That way, if team membership changes, you can easily update access authorizations. The benefits of using RBAC include that they are:
easy to manage;
more aligned with how organizations operate; and
consistent with the authorization principles described above.
If your organization can implement RBAC, we recommend doing so.
Privileged access rights are those that allow a user to perform actions that ordinary users cannot. This includes things like account management (adding and removing users) and information system administration.
In general, you should strictly limit privileged/administrator access to your information systems. Like all access grants, an individual should only have privileged access if it is necessary for their job function.
Once you’ve authorized users and team to access information systems, you need to log those authorizations somewhere. This will give you an authoritative list which acts as the source of truth for all access grants–if someone has access to a system but should not according to your authorizations log, then you should immediately revoke the access (or update the authorizations log).
Once you’ve authorized individuals to access assets, you need to actually grant them access. This usually takes the form of inviting them to create an account for the relevant asset. Although a quick step, the granting of access is important since (1) this is how users will actually interact with the relevant asset, and (2) your access grants will be what you use to perform access reviews.
Sometimes it will be appropriate for your company’s Security Officer to grant limited, temporary access to an information system in order for members of your data-security incident response team to be able to respond effectively. This is expected, but you should remember to revoke those temporary access grants as soon as the data security incident is resolved.
One of the most important safeguards you can implement to protect your data is to routinely review who has access to your information systems. During these “access reviews,” the owner of each asset should determine that (1) access authorizations are appropriate for each user (that is, each user has a business need to access the asset); (2) access grants match the access authorizations (that is, the users who should have access are the ones who do have access); (3) access grants are set at the appropriate level, consistent with business needs; and (4) multi-factor authentication is in place for all relevant systems.
Note that these reviews should include the access authorizations and grants to both your workforce members and to third parties whom you’ve granted access to your systems.
The frequency with which you perform access reviews should be related to the data stored on your assets. We recommend starting with the following:
For assets that store or process sensitive/regulated information, review access monthly.
For assets that store or process restricted information, review access quarterly.
For assets that store or process confidential information or public information, review access annually.
Once a unique identity is created, you need to make sure there is a way for users to prove they are who they are. This is typically done via password selection and, hopefully, multi-factor authentication.
Lots has been written about how to select good passwords. In an effort to not reinvent the wheel, we highly recommend checking out Google Cloud Platform’s Modern password security for users. Some key takeaways (that we fully endorse):
Use a password manager
Use unique passwords for every site and application
Make long, random passwords
Use multi-word pass-phrases
Use single sign-on when available
Use salted pass-phrases or algorithms for security questions
Password managers are ideal since they (1) only require users to remember one master password, (2) help you generate complex, hard-to-guess system passwords, and (3) can sync across devices. But don’t take our word for it–check out NIST’s FAQ answer to the question, What is NIST’s position on the use of password managers?
Two-factor authentication (2FA) and multi-factor authentication (MFA) refer to authentication methods that require a user to present two (2FA) or more (MFA) methods of identification in order to gain access to a system. These additional factors can include something you know (like a password or security question), something you have (like a hardware key or authenticator app), or something you are (like a fingerprint or retinal scan).
But note: not all MFA is created equal. Although widespread, SMS-based verification introduces a number of additional security problems that all but render the additional “protection” useless. For more info., check out WIRED’s How to Protect Yourself Against a SIM Swap Attack.
Workforce members should be required to use MFA whenever it’s available, especially for access to systems that contain Sensitive/Regulated Information.
When you configure MFA on a site, you will often be prompted to save or print out “backup codes”–strings of numbers that can be used to log in in the event you can’t authenticate the normal ways. Importantly, you should not store these in your password manager, as that would remove the usefulness of MFA completely–if your password manager is compromised, an attacker will have both your password and backup codes. Instead, print these out and keep them close–in your purse or wallet.
It is important that you require users to adopt security-sensitive practices in order to reduce the risk of a breach. You can do this by requiring workforce members to use secure, encrypted protocols when connecting to company information systems and to ensure that their remote working location is physically secured (e.g., making sure company information is easily viewable to unauthorized parties).
SSO is a session/authentication service that lets users access multiple assets/systems using a single set of credentials. SSO is a great option for limiting your attack surface. But note that because there are multiple SSO providers and not all sites permit the use of SSO, implementing it won’t solve all your password issues immediately.