Optimizing controls to enterprise resources: Part 2 of 4

Last week I published part one of my four part series on “Enterprise Patterns for Modern IAM” in which I discussed the principles that should inform the design of a modern IAM architecture. This week, in part 2, I am offering up a way to think about the kinds of systems your IAM architecture is meant to protect and a means to align controls to that goal.

Optimizing controls to enterprise resources

Armed with these principles, and before we get to every architect’s favorite thing—a boxes and arrows diagram—let’s consider a conceptual framework for the kinds of IAM controls that are required and the systems that those controls protect.

Systems and Users

A workable analogy for the kinds and volumes of the systems and applications that power the enterprise is a pyramid - lovingly dubbed Ian’s Pyramid of Pain by early reviewers. The Pyramid is likely a simplification of ways that identity and security practitioners think about their organizations’ systems, especially those practitioners in multinational, multi-product line organizations. Feel free to re-complicate it to suit the kind of organization you are in.

At the bottom are productivity suites and other common enterprise systems. Most, if not all, employees (and potentially even contract staff) have user accounts in these systems. While they do not present zero risk to the enterprise, they present, relatively speaking, low enterprise risk. The next layer of the pyramid includes line of business (LOB)-specific and other restricted systems. These systems support parts, but not all of, the enterprise, and carry greater potential risk for abuse and misuse. Such systems, while used by large portions of the enterprise, rarely see a single individual with access to all of them.

The next layer of the pyramid covers regulatory-material, highly sensitive, and other mission important systems. These systems are used by fewer people than the previous layers. Abuse or incident in such systems often comes with regulatory obligations and appropriately painful audit requirements. And finally, the last layer of the pyramid are systems that deliver missions critical functions (a.k.a. production systems), systems that have life-and-limb implications, and the systems that protect and use the enterprise’s “secret sauce.” These are the most rigorously controlled systems because of the extreme business impact they represent.

Crucial Policy Types

With this analogy for enterprise systems in mind, the next thing to consider is what kind of policy describes the most important controls for those different types of systems. In the IAM world, there are three kinds of controls that differ based on the time they are applied. Controls can be applied:

before the person (or non-human/machine, or legal entity, etc) actually uses their user account in a system. These are admin-time controls.
as the person establishes a session in a system. These are run-time controls.
while the person has a session in a system. These are event-time controls.

It’s important to note that session is being used here in a broad sense to include both traditional sessions in applications as well as to include tokens that enable apps on behalf of the person (or non-human identity, or machine, or machine acting on behalf of the person, etc) to access resources.

For the bottom tier of the pyramid, those systems and apps that are used by everyone, the most common controls are described in admin-time policies. Such policies describe birthright access, which enables people to be generally productive. Note that admin-time policies will not be the only policies used; an enterprise would most likely also have accompanying run-time policies that enable single sign-on and enforce multi-factor authentication. Additionally, allowing an employee to remain persistently connected to the productivity suite requires more robust contextual information and event-time policies. But for this exercise we are focusing on which policies carry the most important and impactful controls. In this case, the binary nature of birthright policies are the most important controls without which access is not enabled to begin with.

As we move up the pyramid the most important controls start to be found increasingly in run-time and event-time policies. This is true in part because systems that have greater sensitivity and business impact have increased requirements for controls such as device security posture and user assurance. One shouldn’t be able to access financial systems with nothing more than a username and password. Nor should one be able to log into a production database from an unpatched laptop.

Additionally, run- and event-time controls are needed to help thwart privilege escalation and accidental abuse in that the policies that describe those controls can be evaluated continuously and thus can prevent misuse and abuse more quickly than admin-time controls waiting on joiner, mover, leaver events. Said differently, the tolerance for risk exposure and time of detection of incident( and risk) is lower at the top of the pyramid than the bottom; run- and event-time controls’ ability to be continually evaluated helps reduce both.

Considering Contextual Information

Policies come in all shapes and sizes. Some consider a wide array of conditions while some only look at a single user attribute. While the number of conditions in a given policy is a measure of a type of complexity, modern IAM expands what it means for a policy to be complex. Policies are shifting away from considering information from a single system, such as whether a person is active in Human Resource’s systems or a user is a member of a group. In today’s brave new world, policies must consider multiple pieces of information from multiple sources. For example, a policy might consider whether the person is a member of a group in a specific directory, as well as:

is their laptop up to date in terms of patching;
can they present a cryptographic secret bound to that device;
does a service ticket exist for the system the user is trying to access and is that ticket assigned to the person?

Each of those bullets is information that comes from a different source. Each addresses different parts of the overall requirement to protect the system commensurate to the impact the system represents.

To be clear, it is not strictly true that systems at the top of the pyramid require wildly complex policies, but they do often require multiple controls as defined by those policies. Instead of thinking about each control in a vacuum, modern IAM can consider them as each a piece of context (with their own information sources) that can be evaluated as a singular policy.

Standing Privileges

User accounts are assigned privileges that in turn enable those accounts to access specific resources, interact with services, and help people get their jobs done; this is not news. What is also not news is that enterprises struggle with over-privileged users who have more granted abilities than they need or should have. Furthermore, appropriately granted privileges can be abused by adversaries and mistakenly used by employees and contractors as well. This has given rise to the notion of zero standing privilege (ZSP), in which a user account is only granted specific privileges at the time the account is in use, based on robust policy. But like role-based access control, attribute-based access control, privileged access management, and many other things within the IAM world, ZSP should not be used everywhere for every use case.

ZSP should not be used for those commonly used systems that are the bottom tier of the pyramid. Although one could apply ZSP, it’s a waste of effort and should not be attempted until other more impactful applications of ZSP have been completed further up the stack. By removing standing access from user accounts in regulatory-sensitive and production systems, IAM teams can mitigate risks of abuse and misuse. Leaving risk aside, it is hard to justify that people should have access to production systems 24 by 7 “just in case” they need to use it.

There is an additional benefit to using ZSP for the top tier systems: simplification. Lacking other kinds of policy controls, enterprises can employ role management or similar techniques to encode organizational and business system context into policies. This leads to role explosion, multi-level nested groups, and all other manner of soon-to-become legacy controls which require constant maintenance lest they drift into inaccuracy. ZSP offers simplification by clearly expressing the conditions under which certain privileges can be used without the layers of abstraction upon which other mechanisms rely; further, ZSP can take advantage of externalized, fit-for-purpose policy administration tools.

I hope this was useful for you! Next week I will present a notional architecture… stay tuned true believers!