Access Management (AM) is a critical area in any cybersecurity strategy that refers to how identities are applied to the data and resources in an organization’s environment, ensuring users have the correct access to the appropriate systems, resources, and applications. While AM is a process of managing authorization, it’s important to recognize it’s not just the process of granting access, but also removing and changing access, depending on where the user is in the identity management lifecycle.
Recently, we discussed the concept of AM as part of an Identity and Access Management (IAM) solution, including the Access Management Maturity Model and how it can benefit the organization as a whole. As a refresher, a maturity model is a tool used to determine the effectiveness of current capabilities in a particular area of focus, which can help provide a decision path and prioritization for increasing the capability through maturity. In our first AM maturity blog, we examined the first two levels of the four part Access Management Maturity Model.
In the first level, Identity Lifecycle Management (ILM) must be implemented for birthright access capabilities. Additionally, attributes and roles based on data from authoritative systems, such as the Human Resources Management System (HRMS), are automatically managed. In Level 2, we start adding requests, so an organization must have a mechanism in place to handle exceptional access requests.
Now that Identity Automation’s Co-Founder and Identity Fellow, Troy Moreland, has walked us through the full AM Maturity Model in our recent webinar, Advancing Your Identity Management Strategy with the IAM Maturity Model, Part 6 - Access Management, we’re ready to jump into the remaining two levels, as well as the steps your organization can take to achieve them.
Level 3: Privileged Access Management
In Level 3, Privileged Access Management (PAM) comes into the mix to protect privileged or high risk accounts, such as shared system or service accounts. For example, this may include organization’s administrative user accounts and root user accounts for systems, like operating systems, directory services, databases, and individual applications that require a super user account.
PAM ensures access is provided to the appropriate users and risk is mitigated through access controls. Typically, PAM is handled by a process known as password vaulting, which is where the service account passwords continuously change until a user is granted access to use them.
So, if the administrative account is in Active Directory (AD), you would check it into the password vaulting service, where the password gets reset as often as every minute, but could be every hour or even once a day. When a user needs to access the administrator account, they send a request that stops the password reset process, and a brand new password is communicated to that user via email or SMS. Once the user authenticates, the account is checked back into the system after a preset amount of time that is defined in the policy has expired. The password is then vaulted and changed immediately, continuing to change randomly at a set schedule.
Password vaulting ensures no user has privileged credentials on a 24/7 basis. There’s also an approval process in place, as well as a record of the approval and check out, which correlates directly back to the user for auditing purposes. This is important because shared service accounts are not used as often as personal accounts, so it’s less likely to be noticed when something seems off. Unfortunately, when a privileged account is breached, organizations often remain unaware for months or even years until major damage has taken place.
Another key differentiator of Level 3 is that organizations have static and dynamic role assignments to entitlements. On the front end, the user’s attributes are managed to grant them certain roles. The role assigned then automatically associates that user with entitlements pertaining to the role. As soon as the entitlements are assigned, ILM acts to automatically add those permission or group memberships for a given application. Most importantly, when the person changes roles or leaves the organization, their attributes, role memberships, and entitlements automatically change. The ILM service removes all access that is no longer valid, while adding newly granted access.
Finally, organizations at Level 3 of the Access Management Maturity Model must centrally manage access policies using an authorization engine, a collection of policies that use data provided by an IAM service, such as attributes, role memberships, entitlements, and other data that doesn’t exist within a system natively, to validate rules. At a minimum, organizations fully manage access within applications and have the capability to monitor activity to ensure the policy implemented is always enforced. The benefit is that all of these rules are managed centrally, so those rules have access to more contextual information than the resource does by itself.
This authorization engine is likely powered by a restful Application Programming Interface (API) that has backend integration with an IAM service. On the front end, an API communicates to applications detailing data from the authorization engine: this user from this device is trying to take this action on this system.
Rather than making authorization decisions within an application, you can send a request to an authorization service to make the access determination. The request would include what device is being used or what principal or subject is performing, along with the proposed action and scope in that particular resource.
As the IAM service grows, it builds more intelligence into authorization, and can even interpret contextual information, such as the day of the week, the time of day, or your network location. This data can all be included as criteria for the authorization engine to tell that application whether the action being taken should be authorized or not.
Attributes in your AD services can even be multivalued. So, if your organization has multiple roles for a given user, you can ensure the filter definition for that criteria supports multi-level attributes, such as a multivalued department, location, and position.
Level 4: Centralized Access Management
In Level 4, the ultimate goal is to fully adopt the principle of least privileged access everywhere— providing users only the access they need for the minimum time they need it, and then removing that access or privilege. This principle affords another critical benefit: every request, grant, revoke, or other access control action is auditable. In this way, organizations will always know who did what and when, so they are always ready for an audit.
Another capability of organizations in Level 4 is that they utilize Security Information and Event Management (SIEM) tools that correlate security events to determine if there are anomalies or potential incidents. SIEM tools allow organizations to define rules that mature over time. The SIEM system ingests data from the IAM system and makes correlations. While there are rules within the organization’s applications to manage authorization, we cannot look at events that are happening between disparate systems without an SIEM tool.
When the SIEM tool finds an anomaly based on the rules defined, such as no user can be in two locations at once, the SIEM tool notifies the IAM service. For example, if a user swipes their building badge at an office in Texas, but they are already logged into the CRM from an IP address originating in China. Of course, the user cannot be in both places at the same time; however, if one were to look at the logs from either of those systems individually, they may not see the issue. The SIEM tool would identify the anomaly, so the IAM service can immediately take the appropriate action, such as disabling the user account’s access.
Organizations in Level 4 also leverage Artificial Intelligence (AI) to better monitor activities in a complex digital world that not only encompasses the individual organization, but the SaaS offerings being used as well. To be effective, AI requires proper training with clean data, but unlike SIEM tools, AI does not need to be given hard rules. Rather, you give AI data, and then, you study the output to help train the model to determine what’s normal and what can be considered a deviation. The AI engine will start recognizing its own patterns to identify what's an anomaly and what's not. Eventually, it will be able to process these events faster than a human is capable.
While it will take good planning and time to deploy, Level 4 of Access Management Maturity Model is certainly achievable with today's technology. Start with your organization’s most important systems and keep expanding.
How Mature is Your Organization’s Access Management?
An organization’s AM can range from a simplified identity birthright perspective to a more complex and centralized approach. However, a robust access management strategy is critical to ensure that existing identities are authorized to access the appropriate resources in an organization, as defined by governance policies. In fact, without strong AM, it’s impossible to enforce the principle of least privileged access— an essential part of any compliance and security program.
Ready to discover where your organization falls on the Access Management Maturity Model? Then make sure to watch our on-demand webinar: Advancing Your Identity Management Strategy with the IAM Maturity Model, Part 6 - Access Management, where IAM expert and Identity Automation Co-Founder, Troy Moreland, provides insights into how to evaluate your organization’s current AM maturity level. In this webinar, you will also gain actionable steps on how your organization can mature through each stage of the AM Maturity Model.
Access the on-demand webinar here.
Comments