Identity and Access Management: The Quiet Disruption in Security Engineering

We are on the cusp of a revolution in information security engineering. Even a cursory glance at the security technoscape shows a shift away from perimeter-based defenses and their electronic ramparts, bastions, and moats, toward mechanisms that automatically regulate access to data resources and processing functionality in real time. This is consistent with and reflective of emerging resource-centric information architectures such as Named Data Networking (NDN) and Content-Centric Networking (CCN).

The result of this revolution will be a focus on the development and deployment of systems and applications that are secure by design, and a deprecation of models emphasizing the use of aftermarket security products to address inherent architectural vulnerabilities. At the core of this change are a group of technologies known collectively as Identity and Access Management, or IdAM.

According to research and advisory firm Gartner, IdAM is “the security discipline that enables the right individuals to access the right resources at the right times for the right reasons.”¹ This definition effectively segments IdAM’s key elements:

• The right individuals are human and system users that have been reliably identified (in a process called authentication) based on rigorous identity verification requirements, and who have been effectively described in terms of a set of attributes.
• The right resources are system resources such as data, services, processing power, and transformation capabilities, for which access requests are adjudicated by mechanisms that compare pre-defined access control policies (which are aligned with organizational concerns and objectives) to the identifying attributes of the human and system users making the requests. These resources are defined or “tagged” in such a manner as to integrate them with IdAM functionality.
• The right times and the right reasons are the access control policies that specify the criteria required for access to specific resources. Policies typically identify the resource to which access is being sought, the user or type of user permitted to access the resource, the specific action being governed, and the environmental factors that impact the access-granting decision. Collectively, these policies provide the authorization management functionality around which IdAM revolves.

IdAM is, in essence, an architectural integration of fine- grained access controls within a given system. If a user doesn’t satisfy a resource’s access policy requirements, that user is denied access to the resource. It’s that simple. If the policies and policy evaluation mechanisms are adequately defended (a significant but achievable requirement), it’s extremely difficult for bad actors to circumvent a properly implemented IdAM capability.

IdAM is agnostic to the system level at which it is applied. It’s just as applicable to a standalone, thick client note-taking application as it is to a distributed enterprise resource planning (ERP) program, or an industrial control system (ICS) that manages electricity production or the water supply. Moreover, IdAM principles can be applied at many levels, ranging from a user’s interactions with a single application to inter-process communications governing access to CPU processing cycles. The degree and level of IdAM integration are business decisions that should reflect, among other factors, the degree of system criticality and the costs of a realized risk.

If a user doesn’t satisfy a resource’s access policy requirements, that user is denied access.

It’s that simple.

IdAM in Action

There are many access control methodologies, chief among them being role-based access control (RBAC) and attribute- based access control (ABAC; also known as policy-based access control, or PBAC). (NIST Special Publication 800-162 provides an excellent introduction to ABAC).² At this time, it is widely agreed that RBAC is generally unsuited for the type of fine-grained access control required by a robust IdAM implementation. The eXtensible Access Control Markup Language (XACML), an OASIS standard, provides guidance for IdAM implementations.³ There are a number of commercially-available XACML implementations, both open source and proprietary. These include IBM’s Tivoli, Oracle’s Entitlements Server, and WSO2’s Identity Server.

IdAM begins at the engineering phase:

• Specification of user attributes necessary to support the IdAM regime.
• Resources subject to IdAM controls identified, categorized, and catalogued.
• Specification of basic access control policies for each resource or resource type.

Ideally, this is all done before a system is implemented. This is not to say that effective IdAM can’t be retrofitted to an existing system, but as with all software, it’s far easier and less expensive to make changes during the requirements phase than after implementation and/or deployment.

User Attributes

Effective IdAM requires that user account information be rich in context. The closer account details come to representing an ideal, ontological description of the user, the more flexible, adaptable, and capable the access control regime will be.

For example, if a user’s account information is limited to the user’s name and organizational unit or department, access control decisions will be limited to a binary evaluation of whether or not the user is part of that department. This limitation deprives the organization of the opportunity to differentiate between managers and line employees, between employees with special training and others, or between employees located within a particular country and those in other global locations.

In order to maximize the effectiveness of IdAM, user account information should include detailed information about the user’s organization and sub-organization, her roles, special training, location, seniority, and additional duties.

Resource Identification

Resources subject to IdAM controls must be identified in order for policies governing those resources to be generated, and for policy enforcement to take place. Generally, this is done by defining resource categories and allocating each resource to a particular category.

For example, data resources that contain personally identifiable information (PII) such as date and place   of birth, Social Security number, or address could be grouped within a PII resource category. Alternatively, data resources that contain financial information such as bank or credit card account numbers could be grouped into an Account Data category. Resources may be identified and categorized, or “tagged,” in many ways, including the addition of a discrete data field within a record or within a specialized lookup table.

Policy Specification

Once resources are categorized and user attributes defined, access control policies can be laid out. As noted above, policies govern who can perform what actions on a given resource within a given environment. It’s often easiest to specify the resource, user, and actions at the time of resource categorization. Environment variables may be subject to the conditions of a specific deployment.  Some examples:

• If the resource in question is a data record containing PII, a policy might limit read access users who:
  • Are employees and not contractors.
  • Are assigned to the Human Resources department.
  • Have taken PII security awareness training.
  • Are assigned to the same office location as the employee identified in the data record to which access is sought.

• Similarly, a policy might limit update (or write) access for a data record in the PII resource category to users who:
  • Are employees and not contractors.
  • Are assigned to the Human Resources department.
  • Are at the Manager, Director, or Vice President Level.
  • Have taken PII security awareness training.
  • Are assigned to the same office location as the employee identified in the data record to which access is sought.

Additionally, policies may be updated after deployment to include environment variables such as time, domain, or originating IP address, which further define the access control regime. For example, the read policy for the PII data category could include a time specification restricting access to requests from a specified series of IP addresses, within the company domain, and occurring between 8:30 AM and 5:00 PM EDT.

Deployment

Once user attributes are defined, resources tagged, and policies defined, the system is ready for deployment.

A typical IdAM interaction begins with a user’s authentication to the system. IdAM hinges on the positive identification of a unique user. If a bad actor can fool the system into thinking that she is a legitimate user through the use of stolen or otherwise compromised credentials, the trust basis that enables the IdAM security regime is fatally  damaged.

The average user logs on to about 25 password-protected resources (networks, applications, or sites) per day, putting them in a no-win situation. They either create different, complex passwords for each account (which are hard to remember when needed, leading to insecure password storage habits) or they create a few simple passwords that are easy to remember, which puts them at greater risk of having a single stolen or broken password that results in many breaches, account takeovers, identity theft, and fraud. Social engineering and phishing attacks that spoof online services’ identities exacerbate the password problem. These vulnerabilities exist because of the inherent characteristics of passwords as human-readable, human-machine shared knowledge.  Put another way, it makes no sense to design and implement an IdAM solution and then rely on single-factor authentication using password-based credentials.

If a bad actor can fool the system into thinking that she is a legitimate user through the use of stolen or otherwise compromised credentials, the trust basis that enables the IdAM security regime is fatally damaged.

Given the importance of robust authentication, it is recommended that IdAM implementations employ multifactor authentication that combines non-password knowledge factor tools in conjunction with other authentication factors such as tokens (the “have” authentication factor), biometrics (“are”), and geofencing tools (location-based authentication factors).

Once the user successfully authenticates to the system, she requests access to a resource. The request is stopped by an enforcement mechanism (called a Policy Enforcement Point, or PEP, in XACML), which redirects the request to an access control decision engine (the Policy Decision Point, or PDP). The PDP gathers required information about the user making the access request (from the user’s account attributes), the resource and the controlling policy (often assisted by a component called the Policy Information Point, or PIP). A comparison is made, in real time, between the user’s attributes, the environmental conditions under which the access request is made, and the policy requirements. If the requirements are met, access is granted. If not, access is denied.

It’s as simple as that.

OK, It’s Not Really That Simple

The descriptions of IdAM functionality in this article are, obviously, simplified and abbreviated. They’re intended to stimulate creative security engineering and to inspire readers to learn more about IdAM.   IdAM in  general and XACML in particular are complex and require non- trivial engineering, software development, and system administration expertise. That being said, there are, as mentioned above, a number of readily integrated implementations available today that significantly lower barriers to entry.

There’s another perspective that should also be taken when evaluating the benefits of an IdAM implementation. IdAM is not merely another security feature – it’s part of a broader shift in the Tao of system security engineering. The currently dominant philosophy (let’s call it Cyber 2.0, with Cyber 1.0 being the earlier “Information Assurance” regime) asserts that bad actors and malicious activity can and must be identified and stopped at the system perimeter, and that an application or capability’s concerns are limited to its own functional space (i.e., whether it performs the job for which it was built).

IdAM, while not new (version 1.0 of the XACML standard was ratified by OASIS in 2003), is an element of what can be called Cyber 3.0. In Cyber 3.0, there is    a growing realization that systems, networks, and applications are designed to operate within a distributed, free-flowing information environment and that as such, they are inherently porous. Cyber 3.0 recognizes that this information permeability is an architectural feature, not a vulnerability.

The result is that in Cyber 3.0, security is not defined by how well bad actors and malicious packets are prevented from getting inside the firewall, but rather by how well they are prevented from doing anything (i.e., accessing resources) once they are inside. In Cyber 3.0, services, applications, and capabilities are not considered suitable for release until they effectively blend both functional and non-functional capabilities (e.g., security, interoperability, performance, and scalability, etc.). Cyber 3.0 pushes the defenses inside the application and thus inside the enterprise, and robust IdAM capabilities are a key part of those defenses.

Sources

2. Gartner Research. “Identity Management – Access Management.” Gartner IT Glossary. February 07, 2012. http://blogs.gartner.com/it-glossary/identity-and-access-management-iam/.
3. Hu, Vincent C., David Ferraiolo, Rick Kuhn, Adam Schnitzer, Kenneth Sandlin, Robert Miller, and Karen Scarfone. “Guide to Attribute Based Access Control (ABAC) Definition and Considerations.” NIST Special Publication 800-162. Accessed July 12, 2016. doi:10.6028/nist.sp.800-162.
4. Parducci, Bill, Hal Lockhart, and Erik Rissanen. “EXtensible Access Control Markup Language (XACML) Version 3.0 | OASIS Standard.” EXtensible Access Control Markup Language (XACML) Version 3.0. January 22, 2013. http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html.