IAM Sprint: Effective Risk Management
04 June, 2024, by Stephen Swann
Do you understand your current risk exposure? Do you know what your users are entitled to do with your systems and data? Do you know which users and departments carry the most risk? Do you have a Zero Trust approach to run-time verification of access rights?
One of the primary drivers of an identity programme is the concept that risk can be dramatically reduced, but is such a reduction ever realised?
The Warm Up
Perform a quick inventory of your estate and ask yourself these questions:
- What sensitive applications and data do we have in our organisation?
- What user types do we have that access those applications and data?
- What networks do those users traverse?
- What end points do those users use to access our services?
- Can we adequately classify our applications and data and rank them by risk?
- Can we assign ownership of those risks to someone who has the authority to define mitigating controls?
The Sprint
Enforce adaptive authentication & authorisation controls
These days, configuring the access controls necessary to adequately manage your risk posture is much more feature-rich - think adaptive authentication controls such as those provided by IBM Security Verify.
The decision to step-up to a strong authentication mechanism at run time needs to consider the following contextual factors:
- the user or user type initiating the request
- the endpoint device being used
- their network location (including geography)
- the privileges they carry
- the application or data elements they are trying to access.
Each metric will naturally increase (or decrease) the risk associated with the access request which can be used to determine whether the access request can be approved or denied; whether the access request needs stronger authentication controls to be applied; or whether the session needs to be monitored/recorded for future forensic analysis.
Writing a strong authentication policy and chaining authentication policies together used to require significant coding and/or redirection handling. But modern access management services provide a wizard-based approach to policy definition in a format that allows the natural language of your IT Risk Department to be applied without a computer science degree.
At sprint time, implementing a simple Multi-Factor Authentication flow to your user logon journey using an authenticator app, FIDO2 device or even TOTP delivery via SMS or email for a small subset of users accessing a legacy system should be your goal.
Define entitlement risks and mitigating controls
An entitlement is any data object assigned to a user/account which grants that user/account the ability to perform a system function or access a data object. For many systems, such an entitlement will be a group or a role. For other systems, the authorisation decision may depend on other attributes associated with the user/account such as the security clearance held by the user, their department details, or in the case of certain governmental department, their nationality.
To complicate matters further, it might be the combination of group memberships and attributes that creates the entitlement to perform a function or access a data object.
Many IGA tools have struggled with this concept in that the definition of risks and the definition of toxic combinations of permissions has been limited to business roles. However, business roles evolve over time and users in your systems may be assigned entitlements that generate a risk without ever having been assigned the business role.
Defining at least one entitlement risk and an associated mitigating control is achievable within a sprint. To do that, however, you need to speak to your friendly Risk Analyst to get a real-world example of a risky business function and what a mitigating control might look like.
You then need to speak to your friendly System Administrators to work out which set of permissions on their systems provide a user with the ability to perform that function.
Then you need to map the risk and the permissions together. Take note, though. We aren’t talking about business roles here because the intention of a business role in 2022 may have no bearing on what it is being used for in 2023, despite your best intentions. In other words, risk assignment should be based on what a user can do rather than what you intended them to do.
If you already have IBM Security Verify Governance, your life is made easier when it comes to defining risks and mitigating controls. If not, speak to someone to arrange for a live demo using a dataset that you provide to see how it can work for you.
The Warm Down
The American Productivity & Quality Centre (APQC) have developed a wide range of business activities for many vertical industries. It’s a great place to start when defining the tasks that can be undertaken within your business. Now is the time to work out how best to extend your risk management process to cover all those risky tasks, assign ownership to those risk definitions, and work with those owners to help define mitigating controls that are meaningful.