Searching for the Perfect Fit: Security Systems Integration Testing

This is the second of a series of three articles on security system testing. Today's security systems are actually IT systems (computers, operating systems, software, databases, networks) coupled with intelligent sensors and control devices (like video cameras, card readers and motion sensors) brought together for security operations use. This puts security systems integrators in the position of providing IT systems without any formal training in testing them. Similarly, the average security practitioner tends to have little or no training in testing IT systems. This situation is changing for large corporate and government customers, who increasingly are getting their IT departments involved in security systems projects. Systems integrators and security practitioners must get up to speed on current good practices with regard to testing integrated computer-based systems.

The Evolution of “Integration”

The term “integrated” has been defined loosely and variously in the security marketplace for many years, so before this article goes further, some clarification is in order. As more and more IT folks begin to take part in security system projects, it is important as well for security and IT folks to be on the same page and for there to be a clear understanding of the scope of integrated security system testing.

Several years ago, the phrase “true integration” was popular, along with its related question, “Is it interfaced or integrated?” When the term was introduced, “true integration” meant that systems were integrated only if they used a single underlying database so that no data entry would have to be performed twice. In contrast, an “interfaced” system was composed of separate software applications with independent databases—usually provided by separate vendors—that were set up to communicate with each other by exchanging data.

In a short time, the definition of “true integration” was expanded to include having a single user interface for all functionality. This concept of integration resulted in monolithic software applications encompassing all of the requisite security system elements, such as access control, alarm monitoring, video monitoring, ID badge production and visitor management.

These integration terms were developed before the introduction of the World Wide Web and the Web browser interface, prior to the proliferation of high-speed Internet connections and global networking. Today even those systems first designed as “truly integrated” are now interfacing with IT department corporate directories and identity management systems. Today not all of the data can reside in the security system's database. Furthermore, wired and wireless networking has connected PDA phones and even building signage to security systems. The idea of a single user interface application no longer fits.

In place of the varied definitions of integration that the industry has employed over the years, I propose the following version from Dictionary.com:

combining or coordinating separate elements so as to provide a harmonious, interrelated whole

This is a much more general definition than “one database, one user interface,” and it has the advantage of not being made obsolete by advances in technology. It also has a subtle, but very important distinction: it is results-oriented. Having a single database or software application is no guarantee that the system will be set up in the way that it should be, or that it will be harmonious with an organization's security operations. How integration is technically accomplished is important for a number of reasons, including initial cost, flexibility, maintenance cost, compliance to standards and performance. But unless the end result is suitable to the security practitioner's purposes, standards compliance and even technical excellence are irrelevant.

An Eye to the Future

In the previous decade, the scope of security integrations has remained relatively static, and even the addition of identity management systems and corporate directories into the mix has not impacted security operations. However, security practitioners must now expand their thinking because information technology advances are broadening the scope of integration significantly, and in ways that definitely impact security operations. A case in point is the use of news feeds.

News feeds are information files provided by websites, to make information available automatically to other websites or computer applications. Pandemicflu.gov offers a news feed, and the Center for Disease Control and Prevention (CDC) has several news feeds. The National Weather Service has news feeds for each state plus tropical cyclone impact areas, as well as storm specific feeds. There are a number of cyber security websites with news feeds.

SAFE is security workflow automation software by Quantum Secure that includes the capability to monitor news feeds from multiple sources and recognize events that have a security impact (such as an approaching category 4 hurricane or a disease outbreak). In response to predefined security policies, SAFE can schedule a high-priority meeting through Microsoft Outlook or Lotus Notes; automatically send text messages to the cell phones of non-respondents; notify the security manager of meeting responses; and initiate warnings to employees at the threatened locations. It can initiate the assignment of tasks to security personnel based upon situation response scenarios.

Testing these kinds of integration capabilities requires more planning and preparation than previous types of security system integrations. As security integrations expand their technology scope, and also expand their security operations scope, testing approaches need to incorporate both technology verification and validation of operational elements.

Verification and Validation

These two factors—technology verification and operational validation—are captured in a system acceptance testing approach that is known as verification and validation, or V&V for short. When performed by an independent third party, it is referred to as independent verification and validation or IV&V. The term V&V developed in software project management and software engineering. It has been embraced by the FDA, NASA, the U.S. military and many other organizations as the approach for proving the acceptability of critical systems.

According to several dictionaries, the words verification and validation can be used interchangeably. In the context of V&V, however, they have very specific and non-interchangeable definitions, revised for this article for application to security systems.

Verification: Evaluating a security system or one of its components to ensure that it satisfies or matches the original specifications and equipment lists. Was it made from the correct parts (both hardware and software), and were these parts set up and connected correctly? Verification includes documentation reviews and inspections, as well as basic tests to ensure that the individual elements work (i.e. does presenting a valid card at the reader unlock the door, does motion in the field of the motion detector trigger an alarm).

Validation: Evaluating a security system or one of its components to ensure or confirm it satisfies the security department's needs and fulfills its intended use—in other words, that it will perform as it is expected to perform. Validation requires active testing, putting the system and its various parts through both typical and non-typical usage.

Verification addresses the first factor—that sound and correct technology is used. Validation addresses the second factor—that the system is suitable to the organization's needs.

V&V is not something simply tacked onto the end of a security project. It is performed at various points as the project progresses. During the factory acceptance test, the suitability of the system itself and its major sub-systems and components is validated. Can the system perform the way the security practitioner needs it to? At the final acceptance stages, validation is concerned with checking that the system and its components are set up correctly. Will the system perform the way the security practitioner needs it to? Figure 1 depicts the integration aspects of system design, installation, startup and operations.

V&V for Systems Integration

Today most security systems contain both built-in integration and interface integration. For built-in integration, verification has already been performed in-house by the vendor. Validation must still be performed at the facility to ensure that the built-in integration capabilities are set up and being used correctly. For interface integration, especially integration with corporate IT, HR or even external systems, detailed documentation is required and often must conform to HR or other documentation standards. For example, integrating a security system with a manufacturer's production line system that is subject to FDA regulation (such as for notifying security of a hazardous chemical release or other type of alarm) will require adherence to the FDA's formal validation process.

Documentation Is Vital

The only valid basis for all verification and validation steps is the documentation that the customer and the system provider contribute to the project. Better systems integration documentation means fewer mistakes, faster startups, and more maintainable systems.

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. Mr. 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 upon the upcoming book from Auerbach Publications titled Physical Security System Acceptance Testing, by Ray Bernard and Don Sturgis, scheduled for release in late 2007.