Choices When Integrating IAM with the NIST Framework

It has been said that there are 10 types of people in the world, those that understand binary and those that do not.  

Any number of binary choices can be created to help define distinctive groups and reveal contrast in their experiences and micro-cultures. I recently used a ‘bowlers vs. golfers’ analogy with my son, only to realize -- and regret -- the blank, blinking expression on his face which came from him having seen my performance in both activities. I would suggest that this is definitely not the expression that you want to receive from your upper management after running into challenges rolling out an identity and access management (IAM) program or wrestling with getting your identity house in order, in the context of the NIST Cybersecurity Framework. But here again we have yet another dichotomy; those that have successively rolled out a compliant IAM solution for the organization, and those that are seeking some sort of therapy for the effort.

While you may not be the one that gets into the bits and bytes, you may have felt that moment when a project of yours has been judged in a very binary way. These are just a few thoughts from my experience that may put you in to the ones and avoid the zeros when addressing IAM and the NIST Framework.

For those not familiar, the NIST Cybersecurity Framework has three main sections:

1) Core functions – identify, protect , detect, respond, recover  

2) Tiers – partial, risk-informed, repeatable, adaptive

3) Profiles – current vs. target.

It is in the process of balancing the efforts to roll out a comprehensive identity solution while anticipating the expectations of the Framework that we find our first hurdle in the core-identify step….the first one. The reality is that in many organizations an individual has more identities than Sybil. This is because most enterprises have evolved in a dissociative but coexistent way. Jack Doe has an identity in multiple AD domains, another in HR, and still others in other LDAP directories, mainframes, the infrastructure equipment, independent/isolated servers , and any number of applications which rely on their own identity repositories. He may be known as jdoe in one, jack_doe in another, jack.doe, jack.o.doe, doejack or some other variant depending on the naming convention used at that time and place of the system addition. The most that I have seen to date is seven hundred and twenty directory stores….in one organization.

Normalizing and integrating this” dissociative identity disorder” enterprise is generally handled by utilizing an abstraction layer that sits above all of the identity stores and arbitrates which one is authoritative over which part of the individual’s identity and metadata. This virtual directory service capability is important to the enterprise’s ability to consume the advanced capabilities of identity and access management solutions as well as the centralization and optimization of the effort of accounting for all individual’s identities. For Microsoft-centric environments, taking a further step of consolidating enterprise systems that run Linux, UNIX and MAC under AD and managing things like group-policy or SUDO centrally with a best-of-breed AD bridging technology can also aid in both efforts plus add significantly more security to the administration of user access.

In the core-detect and core-protect steps, removing the IT equivalent of the Bermuda triangle should also be considered. This business process triangle has contributed to more lost data and loss of visibility to access than almost all others combined. It happens when the data owners are not the ones that are opening access to a resource or data;only those administrators or help desk employees with a technical skill set have the authority to do so. The triangle is formed when 1) the person requesting access contacts 2) the help desk, opening a ticket requesting access to the 3) resource, application or data.  

The problem with this model, found in more than 90 percent of most organizations, is that the very capable and certified administrators enabling access do not always know the value of the data and may open more access than they should.   Second, the process and capability necessary to have a single source of truth about any one individual’s access is almost impossible. It is dependent on a string of help desk tickets, AD audits combined with an even worse, exhaustive manual audit of every host and application to verify authoritatively the level and scope of access any one individual may have.

Further, deprovisioning becomes comparable to putting all of the feathers back into the proverbial pillow. Each granting of access provisioned in a manual process has to be located, removed and documented, something completely unnecessary when using a fully integrated yet modular identity management solution.  

Many risk and identity managers may not be aware that the ability exists to enable the non-technical data owner to authorize access through simple automated workflows, have the provisioning journaled in a forensic and historical way so as to be able to track who granted access, when, and to what, while providing instant visibility and access to any one individual’s entitlements across the entire organization.

Being able to centralize identities and platform administration, automate the access of who and how access is provided, integrating non-IT access such as physical security/ door access data -- and any other entitlement, for that matter -- puts those wrestling with the above issues way ahead of the game. For those looking even further down the road, you would be nicely positioned to build upon these steps as foundational components of an insider threat program, which is becoming a rapidly increasing requirement for public and private sector leadership. With the right path and technology partner, it’s as easy as 01 10 11.

Anonymous