Over the past four years at leading companies, the physical/corporate security departments and IT departments have been collaborating to improve security in both domains. This article presents three key lessons learned in those collaborative efforts, and provides a list of potential collaboration points between physical security and IT.
Lesson One: Integrate Processes, Not Systems
For many physical/IT collaborations, the initial thinking revolved around the systems integration tasks.
Data had to flow out of one system and into another. As the systems integration work was defined, more and more questions came up — such as where specific data comes from, who is responsible for the data, and so on. The process owners at the systems level were consulted. After quite a few iterations, enough questions were answered that the systems integration could be accomplished. The connections worked, so the project was considered successful.
However, for these projects, only systems-level documentation existed. What about the high-level impact on the business? That wasn't considered, but the common assumption was that it had to be better after the project. That's not necessarily a good assumption. When you automate an error-prone process, the errors simply happen faster. Additionally, the automation may provide opportunities to refine or improve the process at the business level.
Today's Integration Perspective
Collaboration benefits are available at all levels of security management and technology implementation, especially when security processes are examined within the context of the business processes. According to Wikipedia, the term Business Process Management (or BPM) refers to a set of activities which organizations can perform to either optimize their business processes or adapt them to new organizational needs. That's a very interesting description, because security executives and managers must optimize security processes to be aligned with the business, and adapt them to new business needs, including the changing risk picture of the business.
Additionally, the job of security is to reduce risks to acceptable levels at an acceptable cost. That means operational efficiency (i.e. process efficiency) comes into play as well when considering the total cost of security, especially for large organizations.
This is today's perspective for security practitioners. As Dr. Gerald L. Kovacich and Edward P. Halibozek have stated on page 14 of the book Security Metrics Management : “Security professionals who understand the corporate and global environment have a better chance of personal and professional success than those who do not.”
This is true for two reasons. First, security is about enabling and protecting business assets, operations and growth. Second, security must perform within the context of the business. Security must be planned and executed in harmony with business objectives. If you do not understand the business, you cannot align your security with it.
An additional benefit of being business-aware and process-aware is that many of the tools and approaches that make business management successful can make security management successful as well. One of these approaches is the automation of the workflow (i.e. the processes) of security operations. Security practitioners in both physical and IT security domains can learn from how the other business functions document and implement workflow optimization and management via BPM. One good reason to get educated in this area is that manual processes are less secure than automated ones, and that includes security operations processes. Another way of looking at this is to say that manual processes cost more to secure and monitor than automated ones.
Finally, consider this: your thinking will be more aligned with the business if you take the approach that you are integrating the processes of security, IT and the business as opposed to integrating their individual systems.
Integrated Security Management
One of the best introductions to Integrated Security Management, now more commonly referred to as Enterprise Security Risk Management, can be found in the first 8 pages of the Physbits 1.0 specification published by the Open Security Exchange (www.opensecurityexchange.org).
The Physical Security Bridge to IT Security (PHYSBITS) specification is a vendor-neutral approach for enabling collaboration between physical and IT security to support overall enterprise risk management needs. The technical portion of the document presents a data model for exchanging information between physical security and IT security systems. The introduction provides the organizational context for the collaboration about the technology integration. The high-level concept is simple, as shown in Figure 1.
To delve deeper, take a closer look at the business processes. Some key Business Security Management processes are shown in Figure 2.
All of the processes shown require collaboration between physical security and IT management in one or more aspects. For example: when a laptop is stolen, who responds? When a computer has been hacked, who takes physical custody of the computer hard drives that are evidence?
Lesson Two: Clarify Terminology
Although this may seem like a minor issue, it is not. Not having a correct and complete definition for terms relating to security processes results in foggy concepts and keeps security practitioners from moving forward. With regard to the physical and IT security domains, practitioners can be inadvertently separated by a common language. The potential for this phenomenon is illustrated in Figure 3, also taken from the Physbits 1.0 introduction.
The User Provisioning process shown in Figure 2 is expanded in Figure 3 to show some of its key sub-processes. What is the difference between Card Management and Credential Management shown in Figure 3? Here is a clue: the document was authored primarily by practitioners from the IT domain.
Thus, “card management” refers to the issuance of cards, such as the smart cards used for both physical and IT access control. “Credential management” refers to managing electronic credentials, which commonly consist of electronic digital certificates. “Key management” refers not to locks and keys, but to the means of managing data encryption keys more commonly known as PKI (Public Key Infrastructure).
For more information on these and other terms see the Security Industry Association's Quarterly Technical Update of December 2005, “The Roles of Authentication, Authorization and Cryptography in Expanding Security Industry Technology.”
These concepts are difficult or impossible to understand if you do not have clear definitions of the terms being used to describe or define the concepts.
Lesson Three: Cross Functional Teams Require Cross-Functional Training and Education
This involves getting all of the project or team members onto the same page with regard to the central issues. For a small team or project, the members may be able to educate each other. A key factor is that time must be allotted — both in terms of the individual task assignments and the overall schedule for any initiative.
One recent, highly publicized one-card initiative implemented Role Based Access Control (RBAC) for its information systems access control, but not for physical access control.
Why? Because consideration was not given to the education of the physical security project members with regard to RBAC. When the time came to begin collaborating to define the roles, the physical security project members were not prepared to participate.
Unfortunately, due to schedule pressures, RBAC for physical access control was not implemented. The ROI for that project was less than it should have been.
When considering initiatives that involve physical security, IT security, IT services, HR, Legal and other business functions, be sure to determine the appropriate approach and schedule for training and education. This can mean the difference between partial success and complete success.
Collaboration
The “Points of Collaboration” sidebar (left) presents 11 potential collaborations for physical security and IT. If you or your company are involved in a collaboration effort that's not on the list, please send me a note about it. We will collect the additional items and update the list for a future issue.
