Testing Today's Technology

Oct. 27, 2008
New Security Equipment Has Changed Traditional Testing Requirements

This is the final article of a three-part series on security system testing. The third installment examines recent security technology trends and the impact they have on the testing of security technology.

Three new dimensions in security system technology significantly change the testing requirements for today's security systems. These technology trends are listed below according to the degree that they impact security system testing requirements:

• Enterprise-wide system deployment;

• Intelligence at end-point devices; and

• Rules-based systems and dynamic integration.

Enterprise-wide System Deployment

Although enterprise-class card access control and alarm monitoring systems have been available for half a decade, most global and national corporations have systems that are not interconnected, and they operate them locally or, at best, regionally. Today, the security benefits of integration with global corporate directories, IT security systems and emergency notification systems prompt the enterprise-wide deployment of access control and alarm monitoring systems.

Increasingly, many companies are shifting from local site monitoring to regional monitoring in an effort to reduce overall security monitoring costs. This is made possible by the proliferation of global corporate networks and the networking capabilities of today's IP-based, enterprise-class security systems. Corporate networking has also made it possible for companies to monitor previously unmonitored sites, using IP-based systems over wide area corporate networks.

In recent years, a new driver has emerged for enterprise-wide deployment of access control systems: regulatory compliance for Sarbanes-Oxley (SOX) and the Health Insurance Portability and Accountability Act ( HIPAA) – which both have physical access control requirements. Manual auditing of disparate access control systems is error-prone and expensive. Central automated auditing of access control reduces costs, makes regular auditing at short intervals feasible and reduces vulnerability to lapses in compliance.

Testing requirements for globally-connected and regionally-monitored systems include ensuring that:

• Security systems on the corporate network meet IT department requirements for the type and configuration of networking equipment, and for computer and network security of the security systems (compliance cannot be assumed);

• Regionally-monitored systems have door and alarm descriptions that are unambiguous and identify alarm points for personnel not familiar with the local site (“lobby door,” for example, is almost meaningless in a multi-site system);

• Date and time issues are resolved at the active monitoring center so that event information is properly sorted regardless of the time zone in which it originates;

• System operator privilege assignments correctly limit local operator access to local system information;

• Local monitoring can be performed for critical locations locally or at an alternate monitoring center if wide area network connectivity to the primary monitoring center is lost;

• Both enterprise and local operations (including recording of video) are automatically restored if interrupted by a temporary loss of network connectivity;

• Integration connectivity that may have been interrupted by a temporary loss of network connectivity is automatically restored (or operators are automatically notified that manual procedures are required if that is the case); and

• Both government and corporate privacy requirements of monitored facilities are taken into account in global systems, where monitoring may be performed from a different city or country.

Intelligence at End-Point Devices

There is a wide array of intelligent end-point sensors, including container vibration sensors; smart gas, smoke and temperature sensors; chemical, biological and radiological warfare agent sensors; motion and non-motion sensors; and cameras with built-in object and behavior detection (such as detecting an object left behind in a crowd, graffiti and vandalism detection, slip-and-fall detection, team behavior, counting people in a crowd or line, and smoke or fire detection).

Prior to purchasing a smart sensor, device or intelligent camera, its effective operation should be verified in an environment that is identical or nearly so to the target environment and its range of environmental conditions. If the device cannot be observed in field operation in a similar environment, then a pilot test should be deployed to verify that the technology will work as needed.

Recently, a systems integrator accumulated $1 million in liquidated damages on a $3 million critical infrastructure project because one aspect of the technology did not work as expected. This should have been discovered in an early proof of concept or pilot test before the product was specified, or before the final contract was signed.

Testing requirements for intelligent end-point devices include:

• Verifying that each device is the correct type and model, and is correctly configured;

• Testing each device for all conditions or objects it is intended to detect, in as full a range of operating conditions as can be accomplished (seasonal testing may be required during the first year to verify correct operations under all environmental conditions);

• For configurable devices, verifying that the configuration is recorded or backed up and can be restored (either manually or via a system function);

• Verifying that intended device smart operation is restored automatically after power or network connectivity failures;

• Verifying correct system response when multiple intelligent devices report alarm or alert conditions; and

• Operational testing is performed for a period of 30 days or more to monitor for nuisance or false alarms, in addition to testing of system or device adjustments – to allow for fine tuning of alarm and alert priority settings and to ensure that intelligent device features are configured and performing as intended.

Rules-Based Systems and Dynamic Integration

From an alarm and event monitoring perspective, traditional security systems integration generally ties an alarm or event occurrence in one system to a specific response by another system. This could be referred to as fixed integration, because it remains the same until the systems integrator or other authorized technician makes a change to the integration scheme.

In such integrations, alarm and event information generally travels automatically in one direction, from one system to another. For example, an access control system alarm from a particular door can trigger the display of a specific camera's video on an overhead display monitor. This traditional level of integration can automate some steps that a security officer would perform to determine if an actual security incident is occurring. It can save precious seconds, and in this example, could mean the difference between observing a security violation as it happens, and having to search recorded video to determine what has happened, while further security violations continue to occur and the monitoring security officer plays “catch-up.”

The Surveillint system from Proximex ( www.proximex.com ) goes beyond traditional fixed integration to provide situational awareness in two ways: by combining information from multiple systems and sensors (called data fusion) to identify situations that are occurring or are about to occur; and by assembling information from multiple sources (such as ID badge photos from recent access into an area, and images from nearby cameras) to facilitate response. Situations are identified and information is presented based on one or more rules defining how to interpret multiple sensor data, and what information to gather and present under certain conditions.

The Situator system from Orsus Solutions ( www.orsus.com ) uses its Incident Logic Workflow and Rules Engine to integrate end-point device, GIS and other real-time data with pre-defined response plans and rules so that it can drive the entire situation management process. For example, in response to a fence sensor alarm, it can identify the three closest patrolling officers and send a map of the perimeter alarm area to their PDAs, along with the following instructions:

• Go to Perimeter Zone 5

• Scan scene


If the first officer to arrive at the perimeter presses the “yes” button on the PDA screen to indicate a breach in progress, the system automatically activates the perimeter breach procedure and updates the task lists on the patrolling officers PDAs. As officers answer further questions such as

• Number of Intruders?

• Firearms Visible?

and so on, the system can push information and instructions back out to nearby officers, instructs other officers to take specific backup positions, locks down nearby buildings, and takes other actions defined in the response plan. In this manner, real-time incident data coupled with individual officer instructions can be provided to multiple officers and the command center simultaneously – something that cannot be accomplished by radio-based response management. Additionally, silent operation can keep intruders from hearing instructions or identifying the locations of responding officers by sound – definite tactical and safety advantages. The occurrence of certain overriding conditions such as gunfire, a hazmat incident or a medical emergency or fire can be taken into account in response planning to provide alternate or additional response actions and instructions.

Rules-based systems use dynamic integration , which means that interactions between systems, devices and personnel are determined in real time, based on predefined rule sets and response plans. The testing of such systems requires a much more significant planning and execution effort than for systems using fixed integration. The Situator system facilitates testing through the use of alarm emulation and device failure emulation (see graphic), to provide a means of testing rules and response plans without having to initiate actual alarm conditions at one or more end-point devices.

Testing requirements for rules-based systems with dynamic integration include ensuring that:

• Each individual end-point device (or system alarm or alert condition) is properly evaluated by the rules that apply;

• Representative samplings of multiple alarm or alert conditions are properly evaluated by the rules that apply;

• The correct response rule or plan is activated as a result of specific triggers or conditions;

• Response plans can actually be executed by personnel as expected (time factors and the effects of physical facility features may call for adjustment of rules and response plans);

• Rules and priority assignments resolve or interpret multiple alarm situations in the ways intended; and

• Operators are alerted when alarms or conditions have no rules or response plans that apply (operator situation evaluation may be required).

With fixed integrations whose technology impacts security operations, changes to security operations must be made all at once when the system is commissioned. In contrast, rules-based systems allow the users to define rules and response plans on an ongoing basis to allow for phased changes to security operations and to account for new threats and response needs as they are identified over time. The deployment of rules-based systems can be optimized in consideration of training and testing requirements. In fact, training and testing can usually be combined for maximum efficiency and cost-effectiveness.

Testing today's technology can require significantly more planning and execution work than previous generations of technology. A point to remember is that the greater the testing effort required, the greater the operational benefits are that the technology is providing.

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. Bernard has also provided pivotal strategic and technical advice in the security and building automation industries for more than 18 years. 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. This article is based on the upcoming book from Auerbach Publications titled Physical Security System Acceptance Testing, by Ray Bernard and Don Sturgis, scheduled for release in late 2007.