Identity lifecycle management for security and compliance

This tip is part of SearchSecurity.com's Compliance School lesson, Compliance-driven role management. Visit the Compliance-driven role management main page for related materials, or check out the Security School Course Catalog for more learning content.

It seems that every time we turn around, there is a new regulation requiring enterprises to control access to data, employ strong accountability measures and undergo regular audits. If there is a silver lining to the ever-growing list of regulations, contracts and laws, it is that they are beginning to show some commonality in their requirements.

It is clear that one of the key elements in data protection regulations like HIPAA, the Massachusetts identity theft law (201 CMR 17.00) and the Payment Card Industry Data Security Standard (PCI DSS) is the need for strict access controls for protected data and strong accountability regarding who can and does have access to sensitive information. Both access control and accountability are the main components of identity and access management (IAM).

Sources of identity
Identities -- accounts for applications, databases and systems for people, applications and services -- are assigned to individuals and applications in order to authorize and monitor their access to protected resources. But where do these identities come from? Who authorizes their creation? In short: multiple sources.

Human resources departments are one authoritative source of identities for employees; it is the department where employees are first registered by the organization. Employees are assigned identity numbers, then job titles, business roles and, eventually, are given identities that allow them to access resources and get paid.

However, HR is not the only source of identity. Most companies have multiple directories that store identities serving applications or platforms. Some may be maintained by HR, but others may be managed by MIS, accounting, or whichever business unit controls a particular system for which access demands a unique identity. Customer databases and a myriad of other systems can also be sources of identity. The important point is that for an organization to manage identities effectively, it must understand where identities originate and who is assigning them.

From identity to access
With sources of identity firmly in hand, the next step is to map out how the creation of identity flows to the creation of roles and, from roles, to permissions or entitlements. For example: People have identities; they also have jobs with one or more roles. Finally, roles require permissions or entitlements that allow access to resources necessary for those roles: resources such as applications, files, databases and, more conceptually, information.

More Security School lessons from Richard Mackey Richard Mackey is the guest instructor in a number of our Compliance School lessons, including How to meet HIPAA compliance requirements and Building a risk-based compliance program. Visit our Compliance School to view more lessons from other great contributors.

Identity and access management systems help by managing every phase of this process, from identity creation to resource access. IAM systems include databases of roles that aggregate entitlements. (Entitlements are privileges that have meaning in an application.) For example, there might be a specific entitlement to authorize payment in an accounts payable application. There might also be a separate entitlement to enter invoices and request authorization for payment. These entitlements or privileges would be grouped under appropriate roles and roles would be assigned to various people. The application would then check the entitlements associated with the user and determine whether the user had the required entitlement to execute a particular operation. The IAM system maps roles to their necessary entitlements and then delivers entitlements to applications so those applications can determine whether the user is authorized to access that particular application or resource, thereby streamlining the entire progression.

The roles (or groups of entitlements) may be assigned at hiring, when an employee's job changes or when a new application comes online. The assignment of roles is an authorization process in which business owners, supervisors and system owners (or custodians) should all be involved. In the most pedestrian of cases, roles that are common to all employees may not require explicit approval. However, when the resources to be accessed require regulatory protection, there must be an approval workflow. IAM systems manage this workflow.

Defining roles: Hard work, not magic
When considered abstractly, grouping together entitlements -- such as those that allow an employee to run accounting software, see personnel records and authorize payments -- seems like a simple concept. Unfortunately, the process of determining which roles should exist in the first place, which people should be assigned which roles, and which entitlements should be grouped within each role can be a complicated process of interviews and inspection of technologies.

This first step can be a long, steep one that organizations often underestimate. The challenge is bringing together a set of diverse applications and making sense of who should have access to what. In most organizations, the entitlements associated with users have accumulated over time and have never been analyzed for consistency. In order to work effectively, the role architecture needs to be as simple and consistent as possible, so it can be built on over time. A mistake in the entitlement and role model early on may be difficult to recover from, especially after many users and applications are provisioned.

When a company plans deployment of an IAM system, it must first budget significant time for the analysis of identity, roles and entitlements. This process requires the involvement of both business and technical representatives who understand job functions and, from there, how those functions map to technical access. This process provides the organization the opportunity not only to construct a mapping that can be implemented in technology, but also understand where duties need to be separated to meet regulatory requirements.

The key is to remember that although the definition process is difficult, there are long-lasting benefits. The implemented IAM system will provide a place to analyze roles, audit access to resources and ensure that the right people are involved in approving access. These are all critical elements of any compliance program.

The job never ends
An IAM environment requires ongoing commitment. Each year, the company will add technologies, reorganize the business and need to respond to new regulations. Every IAM system needs to adapt to these changes.

In all likelihood, the IAM technology will be capable of meeting the requirements, but the struggle will be to maintain the commitment necessary to periodically review the role definitions, approval workflow, entitlements and audit processes to ensure that they all meet these ever-changing regulations.

Keep in mind that access management is the perfect model for the entire compliance program: It requires commitment from both business and technology groups to be successful. IAM technology is a useful tool that, like compliance, requires care and feeding to be effective.

About the author:
Richard E. Mackey Jr. is vice president of consulting for SystemExperts Corp., He is a leading authority on enterprise security architecture and compliance. He has helped many organizations, from online retailers and application service providers to major manufactures assess and improve their security and compliance programs. He has advised leading Wall Street firms on governance and policy, security architecture, identity management, and intrusion detection and analysis. Prior to joining SystemExperts, Mackey was the director of collaborative development for The Open Group (the merger of the Open Software Foundation and X/Open). Prior to the merger, he was the Technical Lead of the OSF Distributed Computing Environment (DCE) project. Mackey has been a frequent speaker at conferences and a regular contributor to major publications on topics such as PCI, HIPAA, and GLB compliance, security standards, identity management, and service-oriented architecture security.

20 Nov 2009