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.
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.
This was first published in November 2009