Implementing and managing access control can be a nightmare, especially in extended enterprises encompassing partners,...
suppliers, contractors and remote users. Regulatory requirements and fear of being the next data breach headline increase the pressure.
The challenge is as complex as it gets. What permissions does each user actually need? How do you keep track of authorized and unauthorized access? How do you enforce access policies across heterogeneous systems and applications? And how do you make sure that provisioning procedures are administered uniformly across the enterprise?
Trying to keep up manually is inefficient, costly and error-prone. Too much access leaves you open to insider abuse, as well as hackers who have their pick of unused or poorly managed accounts that have direct access to company assets. And, your auditors probably won't like what they see.
But, identity management products, designed to unify and automate this complex task, do not roll out easily and cheaply. They must somehow integrate diverse components that comprise an enterprise's often heterogeneous identity and access management (IAM) environment. "Identity management" is a somewhat loaded term that covers a smorgasbord of components, including authoritative sources, identity repositories, virtual or meta-directories, database integration components, access control policy enforcers and more.
Almost everyone acknowledges that a finely developed role-based access control (RBAC) structure should be one of the first steps in architecting an enterprise access control infrastructure. A solid RBAC structure is the first step to constructing an enterprise access control infrastructure encompassing identification, authentication, authorization and auditing. RBAC simplifies the identification piece, which will feed into the authentication process.
However, real-world implementations are hamstrung by an often poor understanding of what RBAC is, and a lack of standardization that spawns proprietary solutions that are costly and difficult to integrate, maintain and scale.
We'll talk about these issues and examine the standards that are being developed to overcome them.
Groups are Just a Start
Most people in the industry incorrectly equate RBAC with only creating individual roles or groups and assigning users to those containers. Assign the necessary entitlements and permissions to the containers, and you have an access control model that is easier to manage, better for enforcing least privilege, and more scalable compared to user identity-based access control.
True, the use of groups allows organizations to better assign privileges, monitor how data is accessed, and meet statutory and regulatory requirements pertaining to privacy and confidentiality.
However, constructing effective roles and policies is labor intensive and complex. Managing static access rights through access control lists (ACLs) quickly gets overwhelming and does not provide enough flexibility in our dynamic environments.
Groups and ACLs are a step in the right direction, but they are not powerful enough tools to provide the type of detailed, dynamic control that companies require for the extended enterprise in a Web-based world.
The RBAC model is much more complex than just using groups and ACLs and allows for granular security context- and content-based access decisions.
A more robust implementation of RBAC will be essential to meet security and business needs as they become more entwined with each other. Managing thousands or millions of accounts securely requires automated applications that can interoperate easily. This would enable organizations to apply their RBAC schemes regardless of which HR, CRM, IAM, and/or database applications they have in place.
An Attractive Model
Understanding the limitations of ACL and group policies, NIST established an RBAC standard (http://csrc. nist.gov/rbac/draft-rbac-implementation-std-v01.pdf) as a guideline for vendors who construct role-based systems. It also gives companies direction for successful development and application of RBAC across their enterprise based on real-world functional needs.
Moving toward this standard approach requires vendors and administrators to become more familiar with the RBAC model and the types of security that it can provide for different environments. The model is made up of the following components:
- Core RBAC: This is the foundation of the model, and will be integrated in every RBAC implementation. Users, roles, permissions, operations and sessions are defined and mapped according to security policy. It defines many-to-many relationships among individual users and privileges; it describes how a session is a mapping between a user and a subset of assigned roles and accommodates traditional but robust group-based access control.
Here's how it works. Many users can belong to many groups with various privileges outlined for each group. When the user logs in (this is a session), the various rights assigned to roles and groups that he is a member of are available to him during this session. So if I am a member of the accounting, R&D and administrative groups, I can use any or all of the accumulated privileges assigned to each group.
- Hierarchical RBAC: This allows the administrator to set up an RBAC model that maps to the organizational structures and functional delineations required in a specific environment. This is very useful, since businesses are already set up in a personnel hierarchy. In most cases, the higher you are in the chain of command, the more access you will likely have.
For example, the nurse role can access certain files and the lab technician role can access another set of files. The doctor role inherits the permissions and access rights of these two roles and has more elevated rights already assigned to it.
- Static separation of duty: Constraining incompatible combinations of privileges is a critical concept to prevent abuse of authority, including fraud. An obvious example would be that an employee cannot be a member of both the cashier and accounts receivable groups.
- Dynamic separation of duties: Deter fraud/conflicts of interest by constraining the combination of privileges that can be activated in the same session (See Figure 1). For example, if I am in the groups cashier and cashier supervisor, I only have the access rights and work within the security context of the particular role I log in under. I do not have the aggregate privileges of both roles during one session.
Gears Don't Mesh
Where access control needs to become more granular, access control products need to become more flexible, less proprietary and more standardized.
But there's still a lot of work to do, because products that work at the enterprise identity management and access control level are proprietary, for the most part. This means that implementation is expensive because of the customized programming required to integrate the necessary components such as HR database, access control enforcer, identity stores, databases, directories and workflow. This would also mean a forklift replacement if a company decides to change products. (Some companies have decided to develop in-house customized and stove-piped access control solutions. This usually amounts to a never-ending, expensive software development project.)
We should learn from the bind that companies got themselves into when implementing proprietary electronic data interchange (EDI) solutions. Implementa-tion, upgrading and maintenance are all extremely expensive under this approach, and extending functionality or flexibility is cost-prohibitive.
Experience has taught us the benefits of a standard framework that allows for loose coupling of modular components that communicate using standardized protocols and provide standardized APIs.
While some access control products are moving toward the use of standards such as SOAP, XACML, SAML and Web services, as customers, we need to understand the benefits of these technologies and avoid getting stuck with proprietary solutions that could break existing systems, drain the bottom line and impede dynamic changes as our business needs evolve.
The Enterprise Dynamic Access Control (EDAC) model addresses many of these issues. EDAC is a metadata-based access control system that automates the complex and labor-intensive tasks of assigning users to roles. The model explains the different types of data that can be collected and how a rules engine can use these inputs to enforce dynamic access decisions. EDAC, which was developed within the U.S. Department of the Navy and is supported by NIST, offers the plumbing and algorithms to help corporations make secure and thoughtful authorization implementations.
An EDAC-compliant system makes dynamic access control decisions based on taking information typically gathered from HR databases, converting into a standardized metadata format and applying the following criteria at decision time:
User and corporate attribute changes: Group memberships, security clearance, job description.
Environmental time constraints and security threats: Time constraints (such as access only between 8 a.m. and 5 p.m.); security level (such as Homeland Security raising its security level, so users' permissions are changed accordingly).
Questionnaire: Permissions are dynamically assigned based on user responses.
Workflow: Demonstration that procedure has been followed (such as if a hospital patient's lab results have been reviewed and approved, the nurse can administer prescribed drugs).
Customizable business rules: Combines all of the above to make dynamic access control decisions. (If Homeland Security is at a low security level, the user has a clearance of secret, and it is between 8 a.m. and 5 p.m.)
The model leverages existing protocols such as SOAP, XACML, SAML and Web services, and further defines the payloads they process. Therefore, in order for assets to interface with an EDAC-compliant system, certain attributes and values would have to be transported by a SAML package, for example.
EDAC furnishes a comprehensive, extensible access control framework. It aims at providing a cost-effective way to seamlessly integrate components in a modular access control environment, in which each module contains a set of salient features and communication protocols. This approach would allow software vendors to focus on building high-performance rules engines, policies establishing graphical user interfaces and user and environmental profile generators.
So what do RBAC and EDAC have in common? The RBAC standard is made up of guidelines for vendors and organizations to follow to design robust structures that meet business, regulatory and security needs. EDAC builds upon the RBAC model by extending the variables that can be used for dynamic access control decisions, implementing a modular access control approach, and allowing for interoperability based on Web services technology.
Implementing RBAC and EDAC won't solve all of our access control issues, but they will help. Addressing all types of security solutions in a more standardized and modular manner will allow vendors to provide us with more secure and effective products, because they will no longer need to worry about developing the underlining foundations.