Back

TechnologySep 01, 2017

4 Things You Should Know Before Tackling Identity and Access Management

Brittany Wadsworth

Identity and Access Management (IAM) is a crucial part of any organization’s IT strategy. This often-overlooked process has gained a lot of traction over the last few years. Given the rapidly increasing threat of cyberattacks, the prevalence of cloud technology, and the changing structure of IT, information security plays a valuable role in not only IT strategy but also in corporate strategy. Understanding who has access to what is a critical piece of this security-focused strategy.

Gartner defines Identity and Access Management as the “security discipline that enables the right individuals to access the right resources at the right times for the right reasons.” At its core, IAM creates a unified identity for each user in an organization comprised of personnel information and application specific information. This identity captures who the user is (job title, department, cost center, etc.) and what any given user can do within the applications connected to the IAM solution. Using this identity, organizations can run periodic scans that capture what access a user has and send it to a designated individual, be it a manager, an application owner, auditor, etc. This individual will review the access a user has and say “yes, this access is correct” or “no, remove it please.” Depending on how the IAM solution functions, the access will be automatically removed or a task will be generated and sent to the appropriate party(s). These solutions can also be configured to alert designated individuals if a user has compromising access that violates internal policy or a regulatory policy like SOX or HIPPA. Depending on organizational need and chosen IAM solution, features such as password management and automatic provisioning can be configured as well.

Taking on an IAM implementation is a daunting task that can be time consuming, bumpy, and tedious. Below, I will discuss four things to be aware of before embarking on an Identity and Access Management project.

1. This Is Not Just an IT Initiative

While I called this “a crucial part of any IT strategy,” the scope of IAM is not limited to just IT. This solution will have an impact on an entire organization and will need to involve all aspects of the business. When working to understand a user’s access, an organization needs to have a clear understanding of not only the privileges a user has but what those privileges allow them to do in an application and, even further, what that application is used for. For this reason, involving the business owner and power users of the application provides valuable context and insight into these complex analyses. This knowledge is critical for configuring an IAM solution. Once this information is solidified, it can be used to even further to determine what groupings of access should sound alarms because of a regulatory violation, as well as to identify any patterns in access that can be used to define roles based on an identity attribute such as job title, department, etc.

2. The Data Captured by the IAM Solution Is Only as Good as the Data Within the Applications

Implementing IAM will not automatically ensure that an organization can validate that the correct individuals have the correct access. As mentioned above, these solutions build identities for each user and aggregates the access they have. The organization will identify one or more authoritative source(s) for the user’s personnel information to pull from. This establishes the base of the identity. For accounts to be aggregated within the identity, a unique identifier is needed. This identifier can be different for each application, i.e., employee ID may be used in a handful of applications while email address is used in others. The caveat being that the identifiable information must be stored in the user’s identity and it must match what is in the application. Below are a couple of scenarios that can cause hiccups within an IAM solution:

  • If an application does not have a unique identifier or has an identifier unique only to that application, the solution will not be able to aggregate access to the correct user account.

  • If the application is not up to date with a user’s information, aggregation cannot take place. For example, Application A aggregates from email address. If User B has recently changed their last name and their email address has been updated in the identity profile but not within Application A, the IAM solution will not be able to link User B’s account in Application A to the identity with the updated email address. The same goes for mistyped information.

If an organization wants the IAM solution to identify groups of access or roles for automatic provisioning of new accounts, the organization should ensure that the data going into the application is clean and standardized. As an example, if an organization wants to create a role for all employees in the “Finance” department, the organization should ensure that the correct users have “Finance” listed as their department. They should also ensure that the department field does not have variations of “Finance,” such as “FNC,” “F,” “FIN,” etc. Having incorrect or non-standard data in these fields could result in inappropriate, incomplete, or multiple roles for each of the variations of “Finance.”

3. This Project Will Probably Require a Change in Process(es) and Data Cleanup

The most common process changes that an IAM solution will force are those surrounding the modification of a user, whether that be a name change, a job change, a promotion/demotion, or a termination. To utilize all parts of an IAM solution, understanding the workflows that surround user creation, modification, and termination is crucial. Mapping these processes will allow organizations to identify gaps or grey areas and determine where IAM fits in. Depending on the application, IAM solutions can be configured to automatically change a user’s access or deactivate a user’s account given a job title change or a termination. To configure this feature, organizations need to understand what the current termination process looks like for each application and be willing to modify or adjust this process to fully utilize the IAM solution.

Organizations may not realize that their data is not clean or standardized until the IAM project has kicked off and is well underway. When this happens, applications might need to be placed on a temporary hold until data within the application can be cleaned up. As explained in the “Finance” example above, user attributes need to be standardized to get the most out of an IAM solution. For larger organizations, standardizing and cleaning up data can be political and time consuming. Considering the apathy toward change in an organization is key when cushioning the timeline to uncover grey areas and clean them up.

4. There Is Not a Guaranteed Outcome of Increased Efficiency or Profitability

Efficiency and profitability gains are at the heart of most projects a company takes on, so it will be challenging to realize that the goal of an IAM project is not to make things better, faster, or cheaper. While organizations can see these gains when using the role and provisioning features of IAM, the heart of IAM is the insight it provides to the information security team, auditors, and application owners.

The aim of these projects is to provide helpful insight and allow for better compliance and regulation of user access. A common occurrence in organizations, especially large ones, is for users to retain the access they already have as they transition into a new role. There are two major risks when this happens. The first is that a user could potentially capitalize on the power of their old and new access to damage or harm the organization. The second is that if the user’s account is compromised, a hacker would have access to all applications from a user’s current and previous role(s). This not only poses a threat, but it also makes it more challenging for a security team to respond to a compromised account. A successful IAM project would alleviate and protect against these scenarios. Periodic review of user access would ensure that, as a user transitions into a new role, their old access is modified or removed. Given a user’s identity, the information security team has a complete list of applications and access that the compromised account had privileges to, allowing them to respond accordingly.

Sound identity and access management practices are the hallmark of a mature IT organization. Clearly defining roles, birthright access, and entitlements can be a huge mountain to climb depending on the size and complexity of your organization. Credera has extensive experience in IT strategy and identity management solutions. If you have questions or would like to discuss IT strategy or identity management, contact us at findoutmore@credera.com.