OPINION: Moving Physical Access Control to the Cloud


About the Author: Joel Rader, a senior solutions architect at Radiant Logic, is an identity, credentialing, and access management professional with over ten years of experience solving identity challenges for enterprise, government, and defense sector clients.

Over the last decade, software that is “Enterprise Ready”, or built with large scale deployments in mind, has become more commonplace, if not an absolute requirement. The availability of cloud computing platforms, such as Azure and AWS, have enabled this transition by allowing highly flexible deployments with global communication abilities. This is in contrast to “on premise” deployments where resources are locally installed and managed, with only controlled external communications allowed. Physical Access Control Systems, or PACS, have largely followed the “on premise” model for security reasons. Providing a pathway for Internet access is seen as an unacceptable security risk for systems that control physical perimeters and therefore have life safety ramifications.

Is there a need for an Enterprise PACS (ePACS) that allows for large scale communication and cloud-friendly deployments where the benefits are worth the associated security challenges? I vote yes, with the caveat that you have to integrate such a PACS with the larger infrastructure of an enterprise to make the cost and security challenges worthwhile. I would also note that the term “ePACS” is not an industry-standard, and that my description of such a system already exists in fragments. Saving a deeper dive into the technical aspects for a later discussion, I’m describing overall themes here as to what defines the benefits of an ePACS. So, what are the benefits of a properly designed ePACS?

Improved Communication Enterprise Wide
Communication is absolutely essential to any enterprise system, specifically between different systems in the enterprise. For an ePACS, this is how you enable user on-boarding and off-boarding in an automated fashion. Often this is a manual process, and not having clarity on who has access to what is a critical concern and shouldn’t be left to manual audits. The primary integration component needed for ePACS is to an enterprise’s Identity Management System (IdMS). A common challenge in this space is that there isn’t a consistent integration model to follow. Identity information is often proprietary or obfuscated behind an API or SDK. Following standard communication protocols and formats to represent user data streamlines the process to truly combine identity and (physical) access control.

Another major communication platform for ePACS is to any Credential Management Systems (CMS) that are creating credentials. In the same sense that automatic detection of user on-boarding and off-boarding occurs, automatic detection of credential issuance or revocation is critical. In situations where multi-factor authentication (MFA) is desired, multiple connections to relevant CMSs will be required, unless an intermediary is available to broker the exchange.
Overall, it is important to keep in mind that communication needs to be open and that proprietary interfaces are kept to a minimum. This allows for long-term enhancement, improved troubleshooting, and prevents isolation of an important component to the enterprise.

Attribute, Policy & Rule Based Access Control
Establishing rules on physical access is typically done at the “head-end” of whichever software product is in use at a facility. This includes grouping access points, assigning cardholders to groups, and finally associating cardholder groups to access points. This approach, while functional, does not leverage any “upstream” intelligence from enterprise identity management systems. It also means that different facilities are managed independently, creating differences in naming conventions, access policies, and other types of fragmentation. Ideally, any resource whether logical or physical should be treated consistently across an enterprise with respect to access control policies.

Defining access control policies at the enterprise level can help to standardize the attributes and naming conventions in use, removing ambiguity from applying fine-grained access. This standardization is also helpful when properly applying technical controls to ensure an access zone meets Level of Assurance (LOA) requirements, which is important for federal agencies.
An example of this would be a facility access policy that requires cardholder authentication after normal business hours. Unless such a policy is defined at an enterprise level and implemented through automated communication methods, there is a high probability that each facility’s implementation would be slightly different. What exactly qualifies as “after hours”? The higher the criticality level of an access policy, the more importance uniformity would need to be across the enterprise. Setting standards for credential acceptance, security boundary designations, and threat escalation events are all examples of enterprise definitions that should be understood by an ePACS. These definitions can be part of a more advanced attribute, policy, and rule-based access control implementation.

Improved Security Through Device Integration
So far the focus has been on improving communication to an ePACS from upstream sources. But, what can an ePACS provide in return to benefit the enterprise? The simple answer is the ability to push important events back up the chain for processing and analysis. Low-level events, such as a standard door access event, may be reported locally only. However, security alarms triggered by a forced door, or a revoked credential in use, can provide important context which should be immediately reported upstream. Additionally, the ability to detect cloned credentials may only be able to be done effectively by evaluating activity across all enterprise facilities.

The credential readers themselves are potentially a maintenance challenge. Should a reader model and or software version have an update or replacement available, how long would it take to do a proper inventory check to determine the number of devices affected? Ideally, this type of check would be automated by having devices self-report when on-line. Facility and regional totals could be developed helping the accuracy of scheduling and cost estimates. This is a simple example of device integration improving security and maintenance, and certainly countless others exist.

Enterprise Physical Access – What’s Next?
What’s next is easy to describe, but complex to implement. From an enterprise architecture perspective, the responsibility lies upstream from an ePACS to provide the necessary attributes and resources required to implement improved identity and attribute information. For any existing PACS, the ability to consume external identities and attributes must be given priority along with making available internal information such as reader devices and event notification.

The classical treatment of a PACS is to keep it not as an IT system, but under a separate security and management silo. An ePACS, by comparison, would instead be more akin to other IT systems, and managed in lock-step with them. The challenge of course is that different skill sets are required to maintain network devices versus physical devices, especially as the security threats affecting each are drastically different. Blending the two in a cohesive manner likely requires changing of policy and management operations, neither of which happen quickly.

So what’s next? A slow integration of enterprise features into current PACS is my guess. Hopefully by defining the desirable end-state and how to overcome hurdles along the way, we can get to that end-point in a reasonable time-frame.