Unfortunately, physical security is often forgotten or ignored by information security professionals.
We know it's important and closely tied to information security, but not only is physical security largely unrelated to traditional infosec topics like incident response and malware analysis, it's also typically managed by an entirely separate team, so it's generally an afterthought. Not to mention that you can usually see an infosec analyst's eyes glaze over as you talk about fire detection, fence heights and CCTV.
Because physical access control systems (PACS) -- electronic systems that organizations use to restrict and audit physical access to campuses, buildings, rooms and often physical IT assets -- aren't usually deployed and managed by IT. That leaves them as islands unto themselves: a necessary control, but without any integration with other digital access control systems and little oversight by security teams, even when they're in scope for compliance initiatives such as PCI DSS and HIPAA. But is this really the best way to approach a system that can easily be the Achilles heel to the best security program?
In this tip, we'll discuss the circumstances in which information security teams may want to consider the integration of physical access control systems with IT or logical access management systems and how an organization can go about laying the groundwork for this integration.
Access control integration: Why it matters
In a perfect world, integration of physical and digital access control systems seems like the most efficient way to manage onboarding and offboarding of employees or contractors. This is a critical process that must be tightly controlled to limit the risk posed by overly broad access privileges within an enterprise. However, integration can pose its own risks, often resulting from vulnerabilities in the PACS software or an older or even unsupported operating system required by the vendor.
When integration works, smooth onboarding and offboarding eliminates a major pain point for security: unreliable privilege management processes that often result in overly broad or even unauthorized access. The U.S. government has already attempted to address this issue with Homeland Security Presidential Directive 12 (HSPD-12). The policy, issued in 2004, was an attempt by the federal government to centrally standardize identity and access for employees and contractors to government facilities and networks, thereby lowering risk to the infrastructure. The directive was a response to the overwhelming variety and inconsistency of controls used for physical and digital access. Unfortunately, as with many federal initiatives, in 2010, the DHS Office of Inspector General found that the implementation was behind schedule. It has been beset with "weak program management, insufficient funding and resources and a change in implementation strategy" -- demonstrating just how hard these kinds of projects can be.
But there are plenty of red flags that can detail a physical/logical access control project before it even begins.
Access control integration: Starting the process
If the technical hurdles can be overcome and all the stakeholders are on board with the physical/logical access control integration effort, it's time to find where to start.
Unified physical and digital access can only happen with a well-managed project that seeks to involve all the stakeholders in an organization. This should include human resources, facilities, physical and computer security. The assets to be protected must be inventoried and classified, with users properly categorized. Any good classification system should reflect the appropriate intersection of users and assets --physical or digital. You may not get the systems integration right up front, but it will be easier if you document your classification system. The technology should simply be able to implement access, while integrating with your identity management solution, with little customization or retrofitting of either.
Why not integrate your existing authoritative data source for identity within your organization, such as Active Directory, as well as the procedures that go with them? Often the barrier to this well-intentioned goal is due to the limitations imposed by the vendors of those physical access control products.
Typically, they're marketed and sold by companies who don't have expertise in secure application development or even information security. Often, their software interfaces are haphazard, a slapped on upgrade to an existing product. Application work isn't the primary purpose of their business, so the irony is that their own physical access control products usually fail security audits when deployed according to their documented procedures. The system requirements could include an older version of Windows, Linux or Java. This leads to infinite loops of disagreement between the physical and information security teams, as they try to determine how best to proceed with a safe deployment.
Next, consider how the physical components of the system work. Does it store card information in memory on the reader or controller in case it loses connectivity to the back end management system? Does it fail open or fail closed? This could impact any termination process you have in place. If you integrate the product with a central identity management system, how does it protect the PII? If you're retrofitting a product, which already exists in your environment and it has poor application security with no encryption of the communication protocols, then maybe you're better served having a manual onboarding/offboarding process in order to protect other systems.
A great example of this is with CCTV systems. These products have matured from simple cameras with a DVR to full-blown video over IP. What was previously a tool for physical intrusion detection now increases the attack surface of an enterprise with its own set of vulnerabilities that must be addressed and secured. Otherwise, the camera and everything it records could end up in a hacking tool such as Shodan, a computer search engine cataloging unsecured IP devices, exposing your organization's soft underbelly to black and grey hats globally.
Even if the product doesn't have glaring security issues, when application development, digital security and identity management isn't a vendor's primary concern, you're often speaking a foreign language when trying to communicate with PACS vendors. There are multiple horror stories of products, which invalidate support if you upgrade the OS, apply security patches or even install antivirus. It's no wonder these systems can become IT's worst nightmare! Don't create risk aggregation. If a PACS is running an unpatched version of Windows XP and it has access to your Active Directory server, it may create a bigger security problem than lack of integration between the digital and physical access control systems. Risk will be minimized if the information security team is included during the evaluation phase of a PACS.
Moreover, don't forget the monitoring component. Who will track the logs for violations and correlate with digital systems or cameras? Determine which parties will ultimately be responsible for the physical access control system and ensure that they will collaborate with the existing security operations center staff.
Don't buy the solution before identifying the problem. Even if you only have locks on your doors, you have to worry about how you distribute the keys and to whom. The same holds true of any access control system, whether physical or digital. You'll also need to ensure that you test the physical and digital security of the system itself. The security of your digital and physical assets should be complimentary and in alignment in order to provide a cohesive security strategy. While it makes sense to integrate identity systems in order to achieve this goal long-term, if the PACS could add weakness to the integrity of the whole, then it's better to keep it separate and isolated rather than rush an integration effort that doesn't have the right pieces in place to succeed.
About the author:
Michele Chubirka, aka Mrs. Y, writes, speaks and teaches on enterprise security architecture best practices, and is SearchSecurity's expert on identity and access management. Chubirka has more than 15 years of information security experience, with an emphasis on the design, implementation and support of enterprise application and network security products, including the maintenance and administration of multiple vendor technologies.