When you're planning an enterprise access control deployment over multiple locations, of course you'll have much more to think about than just the technology. You will need to approach your design from management, technological and architectural perspectives.
In this article, we'll help you consider those aspects of project design and identify both the potential successes and the pitfalls that could be encountered along the way. The management section will discuss salesmanship, coordination, and the need to identify all the potential stakeholders. The technological discussion will provide guidance on selecting the appropriate equipment and manufacturers, the communications issues and the significance of a security system. The architectural discussion will not be from the typical building approach, but will be explored in terms of your system architecture.
In preparation for this article, I interviewed a number of individuals at Aggleton & Associates and also John Moss, one of the founders of Software House and the current CEO of S2 Security Corp. Thanks to each of you for your contributions.
Management Perspective
Perhaps the greatest failures I have seen in security implementations are due to a failure to develop a sound plan and to coordinate that plan with all of the involved stakeholders. Sometimes identifying the stakeholders is the biggest challenge. Failure to include a peer manager in the process, such as the procurement manager, has caused a number of large projects to come to a screeching halt. Let's first talk about the plan development and then move to a discussion of coordination.
Developing an implementation plan for an enterprise access system deployment involves first identifying the overall goals and objectives of the project. Is the goal merely to link up existing, like systems, or is the goal to establish a common system within which existing systems represent differing technologies and software? Having been involved in both types of projects, I can say that the easier of the two is the former. When systems are varied, there is a significant challenge in gaining consensus on the appropriate solution.
For instance, after one major installation, I saw problems develop because a site manager did not feel that he had been sufficiently involved in the selection of systems; his favored system was not the one deployed. In cases like this, the overlooked stakeholder becomes the proverbial snake in the grass. If you do not coordinate and sell this individual ahead of time on the merits of the selected system, any issues that develop—and there will be issues—will escalate and create significant hurdles for a long period.
Identifying stakeholders and making them part of the planning process is a major step that is often overlooked. We all have been guilty of saying something like, “I run this department and I know what's best from a security perspective.” An attitude like that will surely lead to disaster when implementing a complex system. I suggest that you pull together a team or committee responsible for the enterprise deployment. Make sure the committee includes representatives from all departments that may be impacted by the system, such as procurement, telecommunications, networking, information technology, risk management, facilities and human resources. I understand well the old story about an elephant being a mouse designed by committee, but I have seen the alternative first hand. A project not properly coordinated can come to a complete halt, never to be resurrected, because a particular entity wasn't properly consulted.
Another issue that should be reviewed at this point is the option of a one-credential solution. In organizations that don't communicate, there is often a conflict when it comes to credentialing and access devices. That's why you frequently hear of people having to carry multiple cards for the same facility. IT implements a credential for gaining access to data processing resources and Facilities implements a credential for purchasing food at the cafeteria, while Office Services implements a manual system of accountability at copy machines. And don't forget you still have the access control card that may vary from the ID card.
What's the answer? Pick a card, any card, then coordinate it and develop its multi-technology applications. (For more information about one-card initiative planning, see Ray Bernard's “One Card” series of articles in the August, September and October issues of ST&D. )
Technology Issues
The security system is mission critical; it demands continuous availability. This level of availability is the first technical hurdle to overcome. How do you configure the system to best take advantage of the network available within the company? I have seen expectations of network availability shattered when security field panels lose communications with the server for over an hour while the network is brought down for maintenance or upgrade.
Coordination with the IT and/or telecommunications department is essential the moment you conceive that your security system—or any portion of it—will exist on the company LAN or WAN. You must understand this new domain you are entering, and you must convey to the network provider the level of reliability a security system demands.
While most major access control systems manufactured today claim to be ready for network interconnect, your IT department may not be so convinced. I have seen networking groups demand that a system live successfully in an offline test environment for six months before it can be deployed on the corporate LAN or WAN. This is particularly true for video, but that's another conversation.
John Moss, CEO of S2 Security Corp., related to me his concern that few plans take into account the need for all elements of the security system to degrade gracefully during a communications failure. For example, degrading gracefully would imply that distributed field panels don't lose functionality upon communications failure, maintain a complete transaction history and continue to permit door openings to valid card holders. Some older filed panels operated in a degraded mode upon communications failure whereby persons were granted access based upon just a facility code on the card and not the full card identifier.
Ensuring automatic restoration after a communications failure is equally important. I have personally been involved with one project where existing field panels from a large access control provider needed to be manually reset after each communications failure, and the system locked personnel out of critical areas until such reset could occur.
Further, Moss said that there are still network conformance issues unaddressed by some providers of security equipment. These include:
• The ability to respond to traps and protocols in a Simple Network Management Protocol (SNMP) environment. SNMP is an application-layer protocol that is used by network management systems for monitoring network-attached devices for conditions that warrant administrative attention. An SNMP trap is used to report an alert or other asynchronous event about a managed subsystem.
• The ability to be seen and evaluated by standard network monitoring tools. These tools keep track of database activity, ensure that any intrusion attempts prompt alerts, and provide bandwidth use statistics to permit IT departments to effectively monitor, protect and manage their complex network environments.
• The ability to ensure that control communications can't be spoofed; that is, to ensure that someone can't mimic a data transfer to cause the system to react, thinking it has a proper communication. This could be someone recording a door opening signal and then playing it back into the system in such a fashion that the perpetrator now can control a door.
It is extremely important that IT and telecommunications department representatives participate in the selection and ultimate implementation of systems that will be deployed on the network. I have seen projects fail to meet their schedules when issues such as domain names and IP addresses weren't resolved prior to panel installation.
System Architecture
There are basically two types of system architecture currently deployed for security systems. For the purposes of this article, let's call them Client-Server and Host-Node. IT folks who read this article may take some exception to my loose definition for these two types of configurations, but they will certainly agree with the fundamentals.
Client-Server configurations typically offer data entry and display at the various connected workstations, while keeping the database itself on the server. Also, the field panels for the system don't connect to the client workstations but to the server. This means that loss of communications between the client and the server halts display and control of anything occurring at the panels. If the client workstation was in the security console, the security officer would be blinded to all alarms and system transactions until communications were restored. A significant number of enterprise security systems are deployed in this fashion.
Host-Node configurations can be deployed in a multi-server configuration on either a local or regional basis. Workstations and field panels connect locally to the server, and WAN communications failure does not impact local display. All that is disrupted in this configuration is central database update, which will occur immediately upon restoration of communications.
It is imperative that the security manager understand the differences between and potential impacts of these two configurations and the actual survivability statistics for the corporate WAN prior to selecting a system configuration. Serious alarms could remain unknown and unaddressed while WAN communications are down. There are work-arounds to address the vulnerabilities of both system configurations, but they need to be planned in advance.
When you're designing your access control system, the best advice is to research the topic, identify all the potential stakeholders, and consider carefully your alternatives. Your best friend is knowledge, and your worst enemy is the person you should have included but didn't.
James A. Francis, CPP, CFSO is senior vice president and COO of Aggleton & Associates Inc. Mr. Francis' more than 30 years of experience in the security profession spans both government and industry. Both in his current role and in his previous roles, he has been responsible for the development, planning and implementation of complete security programs. He has managed both a contract and proprietary guard force, developed and implemented security policies and procedures, developed and conducted security awareness training programs, and developed and implemented emergency procedures and evacuation plans.
