Access control is an essential part of both physical security and electronic information security. As security risks and regulatory compliance requirements continue to grow, strengthening access control continues to grow in importance. This article considers several ways that Role-Based Access Control — now in widespread corporate use for electronic information systems (i.e. IT security) — can be successfully applied to physical security, either by leveraging IT security efforts or by following applicable portions of the 2004 ANSI/INCITS standard for Role-Based Access Control (RBAC, commonly pronounced “are-back”).
According to a December 2010 report titled, “Economic Analysis of Role-Based Access Control”, (http://1.usa.gov/HtNI9B), RBAC has saved the U.S. economy more than $6 billion during the past 16 years. More than half of all organizations that have more than 500 employees use RBAC for at least some access control.
RBAC has become the predominant model for advanced access control in the IT world because it reduces the cost of access management. In contrast, RBAC is generally not applied to physical access control system (PACS) deployments. Because physical access control systems are often networked at the enterprise level, and many interface with HR and corporate directory systems, it is very feasible to utilize RBAC for strengthening physical access and reducing the effort required to keep access privileges up to date.
At ISC West 2012 one access control company demonstrated its role-based PACS product, and in this article we include a look at how RBAC appears in the product’s user interface. However, a role-based PACS is not necessarily required to adopt Role-Based Access Control for physical access management. RBAC can be used with many existing access control systems, and this article will present some ways that can be done.
Restoring Physical Access Integrity
In most but not all medium- and large-sized organizations, the state of physical access management is far from ideal. Many risks due to weaknesses in access management have been overlooked or downplayed, particularly in situations where available security resources and tools simply did not fully match up to the access management burden. This occurs for mechanical locks and keys as well as for card-based access.
A poor state of lock and key management is often tolerated. This is usually because bringing locks and keys back to a known good state would entail a gargantuan level of effort, an unacceptable financial cost, and a painful interruption to the business that would result from the wholesale rekeying of locks.
Even when starting from a clean slate for access card management and mechanical key management, the initially accurate privilege and key assignments do not last for long. Often, due to PACS product limitations in managing card access privileges, compromises are made in access level definitions, to the point where over time the access level names no longer accurately represent the scope of access privilege being provided. Thus, access management is no longer transparent, and the integrity of privilege management it too hard to maintain.
When mechanical keys are lost or unreturned by departing personnel, locks are often not rekeyed according to desired practice. Key record-keeping easily becomes outdated, and the integrity of the mechanical key program degrades.
However, technology has advanced to the point where any organizations can upgrade the caliber of their access management, and maintain its integrity going forward with considerably less effort than has been required in the past.
Full Spectrum Physical Access Control
Mechanical lock cores for more than 200 models of existing door locks plus many filing cabinet locks can now be replaced by battery-free electronic lock cores, which use a single electronic key type that can be programmed for any selection of locks. This brings lock and key management in line with access card management, enabling a unified approach to be taken for all of physical access management.
The Next Logical Step in Physical Access Management
RBAC has become the single-most effective approach to managing large-scale access control, and the American National Standards Institute (ANSI) adopted it as a standard in 2004. RBAC is actually the next step in the historical progression of physical access control management.
There is already a similarity between RBAC and conventional access control group mechanisms.
Figure 1 shows the historical development of physical access privilege management, culminating in the use of cardholder groups to help simplify the management of access privileges. There are of course a number of variations to access privilege schemes, but most systems have the elements show in in Figure 1 in common.
One purpose of RBAC is to allow access roles to align with an organization’s actual personnel roles and related job responsibilities, as shown in Figure 2.
In a PACS that supports groups of cardholders (which can play the part of Roles in an RBAC scheme) and groups of access levels(where an access level group can be created for each role), RBAC can be established and managed by established procedure even if the PACS product does not directly support RBAC.
Role-Based Access Control Specifics
In contrast to typical PACS group schemes, RBAC has the following features when properly implemented:
Privileges are assigned to roles. This contributes to scalability, since in most large organizations more than one person has the same role (sales person, accountant, auditor, receptionist and so on). Roles change less frequently than personnel; thus assigning and updating access privileges is simplified.
Roles are assigned to cardholders. Roles are designed to parallel actual organizational roles, which simplifies management and allows role assignment to be done as part of the personnel enrollment process. This lightens the security department’s burden in physical access management.
Roles are hierarchical, that is, they can inherit privileges from other roles. This is required in order to parallel real-world organizational functional roles and to simplify access management. See Figure 3.
It is possible to implement a one-role-per-person policy. Hierarchical inheritance makes it possible to restrict role assignment to one role per person. This is not a requirement of RBAC, but some IT security practitioners favor it as a simplification mechanism.
Make Access Control Simpler
RBAC provides ability to approve the access privileges that are assigned to a specific role, instead of having to individually approve them for each person who will be assigned to the role. This significantly reduces the number of approval workflows required, which at times can be burdensome and can result in delays in access privilege assignments. Such delays often translate into delays in getting individuals functioning in their assigned positions. RBAC can eliminate them.
The process of naming roles that reflect the various organizational positions is termed “Role Engineering.” The resulting roles are called a “Role Catalog,” and its contents reside in the corporate directory or HR management system. Roles engineering is significant work, but the results are incredibly valuable for both physical security and IT.
Company Roles, not IT Roles
Many IT departments, especially in large enterprises, are implementing or already have implemented an Identity and Access Management (IAM) program, to “once and for all” get a good handle on corporate identity management and information systems access management.
The program is called Identity and Credential Access Management (ICAM) in the U.S. government, because it uses a single smart card for both physical and logical security. Secure enrollment and card issuance processes are critical to the integrity of access management.
Because the IAM/ICAM programs and projects are run by IT departments, there is a tendency (especially for physical security practitioners) to think of the roles that are developed as “IT roles,” when in fact, they are the organization’s roles. There is every reason for physical security to use these roles in access management.
Physical access privilege assignments are generally simpler than IT permissions. For example, where an accounts payable department may have many sets of information access requirements, most of the Accounts Payable personnel will have common physical access requirements. The roles used stay the same. Thus, it is simpler work establishing RBAC for physical security than for IT security; it uses a subset of the roles that IT security uses.
Implementing RBAC
Here are three ways to implement RBAC for Physical Access:
- Procedural – the use of documented manual procedures to establish RBAC, as depicted in Figure 4.
- Directory-driven – the same as the Procedural approach except that the PACS obtains roles directly from the Role Catalog through an LDAP or other interface.
- System-based – the physical access control system enforces RBAC, with or without a directory interface, as described in the section that follows.
According to security practitioners who have implemented RBAC, about 75 or 80 percent of the requirements are covered with role-based privilege assignment, and the remainder is covered by individual privilege assignments. A physical security example of the individual privilege assignment is the card or electronic key for a manager’s own office door. Only the manager has access to her office door, except perhaps for emergency and cleaner access privileges. So while the majority of personnel have cubicles and or desks in common areas, office door management may be an individual privilege assignment per cardholder for a subset of personnel. This in no way lessens the value of the simplification RBAC provides in access management. The “one-off” and “individual assignment” cases are reduced by up to 80%. The confusion factor is practically eliminated and audit reviews are definitely streamlined.
System-Based RBAC for Physical Access
RedCloud Security’s Express and Enterprise appliances (www.RedCloudSecurity.com), demonstrated at ISC West, provide RBAC management in conformance with relevant portions of the ANSI/INCITS standard.
Figure 5 shows the creation of the Physician Role, which inherits the access privileges of the Resident role. (Creation can be automatic by import from the corporate directory’s Role Catalog), or manual if the system is a standalone (non-integrated) system.
Audit-Proof Physical Access
“Audit-proof physical access” requires a physical access control management process that is clearly defined, is easily managed, and by which access privileges are assigned and updated in a timely manner according to job positions, responsibilities and duties. If you don’t have that now, consider using RBAC to help you create that state for physical access management.
Ray Bernard, PSP, CHS-III is the principal consultant for Ray Bernard Consulting Services (RBCS), a firm that provides security consulting services for public and private facilities. He is founder and publisher of The Security Minute 60-second newsletter (www.TheSecurityMinute.com). For more information about Ray Bernard and RBCS go to www.go-rbcs.com or call 949-831-6788. Mr. Bernard is also a member of the Subject Matter Expert Faculty of the Security Executive Council (www.SecurityExecutiveCouncil.com).
