How to Scale IAM Rules with ML Risk Analytics

TL;DR

Start identity risk analytics by defining business objectives, maximizing existing capabilities, and evaluating the technical factors needed for future growth. Machine learning can support dynamic, contextual access decisions and post-runtime analysis, but it is unnecessary when static controls already satisfy policy. Success also depends on aligned teams, suitable processes, and continuous operational care.

Transcript

Good morning, everyone. The next session is Scaling IAM Rules with ML-based Risk Analytics. You don't need to be a ninja. Um, just a couple of notes. Uh, after this session, we have another session coming in, so if you could please clear the room. Um, the speakers will be available to answer any questions outside the hall. And if you brought in you... Read More

Key Insights

• Identity risk analytics requires sustained care, knowledge sharing, and collaboration across teams because technology alone does not create a successful identity security program. Organizations also need appropriate processes and a shared understanding of how analytical decisions and insights will support business and security outcomes.
• The identity technology stack can become difficult to manage because it combines numerous technologies, vendors, integration partners, and guidance sources. This complexity contributes to inconsistent approaches for implementing, measuring, and valuing identity risk analytics across different enterprises.
• A common identity risk analytics baseline is missing across the industry, according to the presenters. Unlike established social expectations that guide other long-term commitments, organizations lack consistent unwritten rules for applying analytics, so unsuccessful programs often encounter problems that are specific to their own environments.
• The core implementation framework has three parts: identify business enablers and objectives, maximize capabilities already available while planning future growth, and evaluate the associated technical factors. These building blocks are intended to help enterprise teams ask practical questions before expanding their analytics programs.
• Identity access controls have evolved from simple whitelists and blacklists to directory-based rules, attribute-based access control, and dynamic contextual policies. The expansion toward access from any location, device, and time has increased the complexity of individual authorization decisions.
• Risk analytics can help reduce rule complexity when organizations adopt a zero-trust mindset, but it is not required for every situation. The appropriate choice depends on the access policy, the identity-specific need, and whether analytics provides useful decisions or insights beyond existing controls.
• Mandatory MFA can remain the correct static control when an enterprise prioritizes regulation and compliance for every user interaction. Risk analytics can still add value after authentication by examining runtime activity and producing insights, even when it does not determine whether MFA is required.
• Operational readiness is essential for extracting value from identity risk analytics. Even when a relevant security threat and technical requirement exist, an enterprise must have people and processes capable of interpreting insights and acting on decisions produced by its analytical capabilities.

Questions & Answers

Q: How should an enterprise start identity risk analytics?

An enterprise should begin by identifying the business enablers and setting clear objectives for identity risk analytics. It should then determine how to maximize capabilities it already possesses instead of immediately expanding its technology stack, while also planning for future growth. Finally, the organization should evaluate the technical factors, people, and processes required to make those objectives and capabilities successful.

Q: When is identity risk analytics unnecessary for access control?

Identity risk analytics may be unnecessary for a particular access decision when a fixed policy already defines the required control. The presenters describe a retail enterprise that wanted MFA before every user interaction because regulation and compliance were its highest priorities. In that case, analytics does not need to decide whether MFA is applied, since the organization requires it universally.

Q: How can risk analytics add value when MFA is mandatory?

Risk analytics can examine information generated during runtime authentications even when every user must complete MFA. The access control remains static, but the organization can use analytics afterward to gather insights and support additional decisions based on observed authentication activity. This separates mandatory enforcement from analytical evaluation and allows the enterprise to preserve its compliance policy while still developing risk visibility.

Q: Why is collaboration important for identity risk analytics?

Collaboration is important because protecting and validating identities requires more than deploying technology. Teams need to share knowledge, remove organizational barriers, and establish processes that help analytical capabilities succeed. The presenters characterize identity risk analytics as something that requires ongoing care and nurturing, which means participating teams must remain engaged with both the technical system and the operational use of its insights.

Q: Why have IAM access rules become more complex?

IAM rules became more complex as organizations and supply chains expanded. Simple whitelist and blacklist decisions were followed by directory services, broader rule sets, and attribute-based access controls. Expectations then expanded toward access from any location, device, and time, requiring dynamic and contextual rules. Each stage introduced more factors into access decisions and made policy management more difficult.

Q: How can risk analytics support a zero-trust approach?

Risk analytics can potentially reduce the complexity of access decisions and help organizations minimize the number of rules used in a zero-trust approach. The presenters do not claim that analytics must replace simple rules in every case. Instead, they recommend deciding when analytical evaluation is useful and when straightforward controls already provide the outcome the organization needs.

Q: What prevents organizations from succeeding with ML-based risk analytics?

Organizations may face several barriers, including uncertainty about whether analytics solves a specific authentication or SSO need, a belief that they do not face meaningful security threats, internal misalignment, differing business objectives, and inadequate operational readiness. They may also lack people and processes capable of obtaining practical value from the decisions and insights generated by risk analytics.

Q: What should teams evaluate before deploying identity risk analytics?

Teams should evaluate the identity-specific need, such as authentication, SSO, or another access-control requirement, and determine whether existing static rules already satisfy it. They should also consider relevant security threats, business goals, current technical capabilities, future growth, and associated technical factors. Finally, they should confirm that appropriate people and processes exist to interpret and use analytical results.

Summary & Key Takeaways

• Identity and access management evolved from simple whitelists and blacklists to rules, directories, attribute-based controls, and dynamic contextual decisions. As access expanded across locations, devices, and times, policy management became more complicated. Identity risk analytics may reduce that complexity, particularly when organizations pursue smaller rule sets and a zero-trust mindset.

• The proposed framework begins with three questions: which business needs should the initiative enable, how can current capabilities be used before adding more technology, and which technical factors will support present objectives and future growth? The framework reflects common themes observed while the presenters worked with enterprises over two years.

• Identity risk analytics is not necessary for every access decision. An organization that requires MFA for every interaction can retain that static policy while applying analytics to runtime authentication data afterward. Before adoption, organizations should also assess identity-specific requirements, relevant security threats, and whether their people and processes can use analytical insights effectively.