What does IT want from security?
IT managers have three basic criteria for selecting the best products for the corporate information infrastructure. First, the system must use the latest technology, which extends the product life cycle and provides the best return on the company's investment. Second, it must be designed for scalability, which means it will be able to handle future growth without performance degradation.Third, it must integrate seamlessly with the corporate infrastructure, by making use of current industry standards in database technology, networking, and operating systems.
Latest technology. The security industry has traditionally fallen behind the technology curve. Many vendors of security management systems are still offering proprietary systems based on dated technology. They have limited networking capabilities. rely on old sixteen-bit application and operating software, and lack a robust client-server database architecture and flash memory. They also use sixteen-bit controllers with a proprietary interface protocol, making it difficult if not impossible to integrate such products into a corporate infrastructure. IT managers consider these types of systems dead-on-arrival and will insist that the new security system be based on the latest technology available so that the company does not buy an electronic system that is already obsolete. IT managers will focus on the system's software and its field hardware - the most important component being the system's intelligent controller.
Software. IT managers generally dislike application software that is designed as a monolithic program in which each line of computer code is unique to that particular software and is interconnected and dependent on all other lines of computer code in the program. Remove or change one section of code from the software and the entire program shuts down. These systems are rigid and difficult to maintain and enhance.
Instead, IT managers want software that has been developed as a set of small self-contained components, or objects - each of which performs a specific function. The objects (lines of computer code) can be "glued" together to run a large software application - such as an intrusion detection, access control, or alarm monitoring system - or individual objects can be copied and used in other applications, even those unrelated to security. For example, in object-based ID badging software, one object might interface with the camera, another might capture images, a third might compress and store the photographs, and a fourth might print employee pictures.
Together, the various lines of code would provide the company the ability to print photo ID cards for employees. However, individual objects from the video ID software could also be copied and used in object-based desktop publishing software - for example, to print employee photographs in the company newsletter. It doesn't matter whether both software packages are made by the same manufacturer, as long as they are both based on individual objects, which are written with standardized modules that allow each object to fit into other software applications like pieces of a puzzle.
This ability to "reuse" objects adds flexibility to the system. The result is that the software has a "plug-and-play" component architecture, meaning that each component can be quickly plugged into and accepted by the company's existing infrastructure. Such software also results in smaller program size, as many lines of repetitive code are replaced with a single line, making the system more efficient and faster. These programs generally have a shorter development cycle as well, which means that new features and capabilities are delivered faster to end-users. Furthermore, the cost of development is less, resulting in better prices.
Intelligent controllers. As part of the total security system, the field hardware must support the modern architecture and should be designed to have the same principal characteristics as the application software: power and flexibility, with an easily upgradable interface. One of the most important components of field hardware is the intelligent system controller (ISC), the field panel used to monitor and control card readers, alarms, and other field devices.
For IT managers to accept an ISC on a corporate network, it must meet the following minimum requirements: 32-bit CPU architecture; TCP/IP protocol support; flash memory for firmware; support for a large local cardholder database; and support for a large number of readers and alarm panels.
* Microprocessor. An ISC must have a 32-bit microprocessor to support the most demanding network applications with a large number of transactions. These systems are fast and can handle from dozens to thousands of transactions with little if any delay. For example, access control systems with 32-bit architecture respond almost instantaneously, even in a busy environment, when a card is swiped through a reader. Anything less could lead to performance degradation.
In addition, the security manager should ensure that the control panel's microprocessor contains 32-bit data and address buses - the paths in the microprocessor used to retrieve and direct information through the system. Data and address buses that are smaller than 32-bit are much slower and less efficient.
* TCP/IP protocol. Seamless support for the TCP protocol and IP addressing is essential for these controllers to be part of the corporate LAN or WAN infrastructure. Systems that lack these network capabilities will not be seriously considered for integration by IT groups.
* Flash memory. One of the most critical features of modern security systems is the use of flash memory in the controllers to store firmware. Firmware is the software embedded in the controller's computer chip that allows the controller to process data and interface with card readers and other field devices. As application software rapidly changes with technology, so must the capabilities and feature set of the firmware. Flash memory allows the new versions of firmware to be downloaded from the server or PC workstations to every controller in the system within minutes. Without these capabilities, the controllers would become obsolete, and the only way to upgrade them would be to physically replace the EPROMS - where the firmware is stored - a process that would be time consuming and costly.
* Cardholder database. Support for a large cardholder database is important for a truly distributed network system where the access decisions are made in the local controller database rather than at a host computer. An ISC with a full-capacity database allows all information on cardholders in the corporation, including contractors, to be downloaded into the controller so that access decisions can be made by the controller in real time.
In many systems, the cardholder database in the controller is limited, and to make an access decision, the request must be sent to the host computer. During peak traffic hours or when the host computer is being used for other purposes (such as printing a large report), individuals trying to gain access may have to wait an unreasonably long period of time before the system opens the door. Furthermore, the access control system will come to a complete standstill whenever the host computer is down. Therefore, IT managers insist that decision-making at the host be avoided at all costs. as it is incompatible with the modem concept of distributed architecture, where all access decisions are always made locally and in real time.
The actual size of the controller's database will depend on the number of employees and outside contractors who need access cards. When making this decision, however, IT managers want to ensure that the controller can handle future growth. The security manager should recommend an ISC with a database that can handle several thousand people more than actually work at the company.
* Card readers. The controllers should support 32 to 64 card readers and input/output alarm panels. Older panels can only support two to eight readers and alarm panels. By installing a panel with a larger capability, the company will simplify the security system installation, minimize the cost of installation and maintenance, and allow for some global functions to be performed at the controller level rather than at the host computer. Companies with only a few doors might opt for smaller capacity ISCs, but again, this can approach cause problems if the company grows or is purchased and expands into office suites with many more doors.
Scalability. IT managers will insist that the security system have properly designed scalable architecture to ensure that performance degradation will not occur as the system grows. Scalability is measured not by the number of doors or cardholders a system can support but by the number of transactions (events) the system can consistently and effectively process. A system with scalable architecture will perform the same way without any modification to the application code, regardless of whether it is supporting a few transactions per minute or several thousand.
It is also important to ensure that the security system's vendor can provide a seamless upgrade path as the security system grows beyond its initial installation. Such an upgrade usually entails, at most, changing only the database and operating system technologies or hardware platforms - to increase memory, for example. The application software should remain the same. Many vendors either do not provide an upgrade path beyond the maximum configuration of the installed system, or they require the customer to purchase new application software capable of supporting the expanded growth. Furthermore, the new application software often has a different look and feel, which requires complete retraining of end-users, a very expensive undertaking.
With properly designed architecture. scalability is distributed across several different system components rather than concentrated in one place. To assess system scalability, IT managers will look at the following: transaction-based application design, client/server database design, application support for symmetric multiprocessing, and distributed network and application partitioning.
Transaction-based design. Security applications are continually processing transactions by accessing the database. A properly designed application breaks these database accesses into small operations. Application code for dealing with transaction processing must be small and tight - meaning that the program is written with as few lines of computer code as possible. The fewer lines of code a computer must process, the more efficient (and faster) that computer becomes. For example, a tightly written access control program can respond to an alarm event in a second or less, while one that requires the computer to process many more lines of code may take three or four seconds before responding to an alarm. To help determine whether software is tightly written, the security manager should ask vendors about their system's response time - for example, how long it takes a system to display an alarm event on the monitoring screen. A tightly written computer program usually leads to minimum overhead during transaction processing and, consequently, the ability to process a large number of transactions quickly.
Client/server design. Robust client/server database architecture is essential for effective transaction processing. A database server and a powerful SQL engine are critical components of true client/server architecture. (SQL stands for Standard Query Language, which is a national standard for database languages.)
Many vendors use file server technology instead of a database server. In a properly designed client/server architecture, the client workstation sends a query, to the database server, which then processes the request and sends only the final result back to the client workstation. This guarantees database integrity up to the last transaction in the event of a database crash. It also significantly minimizes network traffic. As a result, significantly more clients can be added to client/server database systems versus file-oriented database systems.
Multiprocessing. Today's database servers use one or more microprocessors to process information. The more microprocessors a database server has, the more efficient and faster it becomes, because the work can be divided among several processors instead of just one. As companies grow, security managers may add processors to their database servers to ensure that, for example, the access control system continues to process information quickly. However, databases can only use multiple processors if their application software is designed to support more than one CPU. Even a system with six processors may be inefficient if the software is designed improperly and only allows one processor to be used.
To be truly scalable, therefore, security management software must be designed to support a multiprocessor-based database server. This feature allows the security software to take advantage of additional processors when they are added to the system. Security managers should test new software in the corporate environment for one or two months before finalizing a purchase. As additional processors are put online, the security manager should see a substantial improvement in the software's performance - for example, an access control system can handle more transactions more quickly. This is a clear indication that the additional processors are being used by the software.
Distributed network. Distributed networking is an integral part of scalable architecture. Every intelligent hardware component in the company's security system must be designed as a network-compatible module with its own processing and decision-making capabilities.
If the security manager wants to purchase an intelligent system controller for the corporate access control system, IT managers will insist not only that the ISC have its own cardholder database (as discussed earlier) but also that it can be plugged directly into the company's network. This allows the controller to communicate with the access control system's host computer much faster and from anywhere in the world without any degradation in signal transmission, making it much easier for the company to bring remote offices online.
Traditionally, an ISC had to be directly wired to its host to transmit alarms and report transactions to the host. That architecture limited the distance a controller could be from the host computer (wires only stretch so many feet) or forced the company to use dialup modems and telephone lines for remote transmissions - a slow process.
Integration. IT managers want to ensure that security systems can be integrated with existing hardware, databases, and networks, both local and wide area. One way to achieve this is through open architecture.
Open architecture. Open architecture is an important criterion for IT groups in selecting the right security system. Unfortunately, many vendors claim to have open systems without clearly understanding what the phrase "open system" means from an IT point of view. To clarify, an open system is one in which every communication protocol and every interface is designed according to industry standards that allow for easy integration with other systems and components.
Security management systems with open architecture should satisfy the following minimum requirements: The application software must be hardware-independent and should seamlessly interface with multiple intelligent system controllers from different vendors within the same systems. The application software must be peripheral-device-independent and seamlessly interface with digital/video cameras, badge printers, and scanners from different vendors.
Also, the most advanced systems should use universal input/output capabilities in which the security software application can interface with any external system - such as a fire or burglar alarm system - using a common communication protocol.
The software should also use universal data import and export, which is the ability to move data, including pictures, signature, fingerprints, voice, and video, to and from an external file or database system; and it should have an open interface protocol (a generic protocol) to interface with ISCs.
Most importantly, the application software must also be database-independent and seamlessly interface with multiple relational database management systems (RDMSs) from major vendors such as Microsoft, Oracle, Sybase, and Informix. And the software must be network independent and seamlessly interface with all major network protocols, including TCP/IP, IPX. and NetBios.
Database. An important issue for IT personnel who evaluate and select security systems is the ability to seamlessly integrate the application with external corporate databases such as human resources, payroll, accounting, and others. To gain acceptance by IT managers, the new security application and database design must comply with corporate standards and satisfy several requirements.
The application must be open database connectivity (ODBC) compliant; it often must support a bidirectional interface with an external database: it usually must download and distribute security-related data to every ISC in the system in real time: and it must guarantee the delivery of security data to each ISC in the system.
* ODBC compliance. IT managers will insist that new security application software be ODBC compliant - which means the software has an ODBC driver that allows the security manager to use the security software to access nonsecurity databases. For example, ODBC-compliant access control software would allow the security manager to access the human resources department database to see whether employees have been hired or terminated so that they could be added or deleted from the access control database.
When shopping for a system that is ODBC compliant, however, the security manager should be aware of a misleading but common claim made by vendors. Many vendors say that their security system supports the new ODBC database interface standard. What they mean is that the security system's database is ODBC compliant - not the application software itself. That means, for example, that an access control system's database could be accessed by other nonsecurity departments, st,cb as human resources, but the access control software could not be used to access the human resources department database. To avoid this pitfall, the security manager should ask the vendor whether the application software itself is ODBC compliant.
* Bidirectional interface. In addition to ODBC-compliant application software, the IT manager may require the security system to have a bidirectional interface. A bidirectional interface is a triggering mechanism in the software which ensures that any change to one database is automatically transmitted to another database. For example, the access control database would be automatically notified to terminate an employee's access privileges when the human resource manager deletes that employee's name from the human resource database. Without this interface, the security manager must periodically check the human resource database for new or terminated employees, then manually make the changes.
* Real-time download. When bidirectional interfaces are used, it's important that information be transmitted between databases in real time. For example, when changes occur in employee or badge status that could affect employee access, that information must be downloaded from the human resource database to the security database in real time and not in batch mode, which is typically performed once a day. This data must also be distributed in real time to every lSC in the system to prevent unauthorized access by the affected employee. The real-time component is necessary to maintain corporate security, since information is communicated to the security database and automatically distributed across the entire security system.
* Guaranteed data delivery. While distributing security data across the system, the application must be able to detect whether communication paths are unavailable or if transmission errors occur. The application must store the undelivered data and continuously monitor the communication lines for availability. As soon as a communication path is restored, the security data must be delivered to the target ISCs. This design will always guarantee data integrity across the entire system.
Network integration. For a security system to be seamlessly integrated within a corporate infrastructure, it must comply with corporate networking standards. In most environments, support for the TCP/IP protocol is sufficient to allow
integration with Windows NT, Unix, and even Novell networks. Database servers, workstation clients, and ISCs must be easily configurable as network nodes with IP addresses assigned to them, and they must be flexible enough to be plugged into a corporate LAN or WAN.
Security managers can and should play a vital role when a company is purchasing new security management systems. To stay in the loop, however, the security manager must understand how IT managers think and the criteria used to judge the worthiness of electronic systems.
Rudy D. Prokupets is the chief technology officer and executive vice president of research and development for Lenel Systems International, Pittsford, New York.
|Printer friendly Cite/link Email Feedback|
|Title Annotation:||information technology|
|Author:||Prokupets, Rudy D.|
|Date:||Mar 1, 1999|
|Previous Article:||Crafting a cohesive program.|
|Next Article:||Merger, they wrote.|