Sir Isaac Newton taught us force is equal to mass times acceleration, the keystone of most modern engineering. The Borg from Star Trek cautioned: "Resistance is futile. You will be assimilated." Both lessons are helpful guides for those traveling the road of convergence between the security industry and the information technology marketplace. This article shares a few observations learned firsthand along that road from an independent security integrator of 32 years.
The security electronics industry leveraged the same electrical engineering advances as the computer industry using first relays, then tubes, transistors, integrated circuits, and microprocessors to power ever more sophisticated systems. Each industry grew largely independent from one another using proprietary designs optimized for the unique requirements of each marketplace. The computer marketplace has always dwarfed that of the security industry in both size and influence.
Two trends changed things forever: the growth of networks and a steady increase in the power of microprocessors. Ethernet and Internet Protocols became standards allowing computers to be more easily interconnected. Local area networks (LANs) and wide area networks (WANs), including the Internet, flourished. Over the past 30 years microprocessors have grown ever faster, doubling in power approximately every 18 months, allowing products to become smaller, cheaper and faster. The IT industry experienced spectacular growth and with it came common standards, economies of scale and a commoditization that allows desktop computers to be sold for under $500.
When networks became ubiquitous, these digital pathways became a logical choice to connect security systems together. Access control panels were the first security systems to be widely connected through computer networks. It was simply easier and more cost effective than running separate security cabling, especially when connecting geographically disparate buildings.
Security system manufacturers jettisoned older proprietary designs for more cost- effective solutions that employed standard computer industry components and which promised a quicker path to market. Client-server architectures were embraced and standard operating systems like Windows were employed. As processor speeds increased, it gradually became feasible for the analog signals of both video (CCTV) and audio (Intercom) to be "digitized," allowing network compatibility. Security systems are now being pulled into the IT vortex, eventually becoming just another application running on the enterprise network.
When security began using the enterprise network and leveraging IT standards like SQL databases, operating systems, and computer servers, the IT department took a prominent seat at the table to help decide which solution should be selected and to insure adherence to its rules and regulations. Security integrators, accustomed to working with directors of security, have been making the painful transition from knowing more about IT than their client to now knowing less. Along the way a few lessons are being learned about working with IT departments.
Lesson One: First Impressions are lasting. When meeting with IT personnel, the perception of your overall expertise will be strongly discounted if you are unknowledgeable or poorly versed in IT terminologies and techniques. Right or wrong, your security expertise will likely be judged through the prism of your demonstrated IT understanding.
Lesson Two: Expect ironclad adherence to rules. IT resources have become the lifeblood of our enterprises. They are mission critical. When IT systems stop working everything comes to a grinding halt. As you can imagine, when this happens IT managers get yelled at by the big bosses. Over the years they have vigorously invested to increase system reliability and have created strict policies to prevent failures. Don't expect these rules and standards to be changed to accommodate security eccentricities.
Lesson Three: Get accustomed to arrogance. For a lot of reasons, arrogance seems commonplace in the IT domain. Some of this is a natural consequence of the confidence that comes when you are good at what you do. Some of it is a defense mechanism when you are better dealing with things like systems than things like people. Some of that arrogance is an expedient for dealing with too much change and too much complexity. Whatever the cause, arrogance seems to be found in abundance in the IT environment. Don't take it personally.
Lesson Four: Size matters. Typical IT projects are much larger than typical security projects. Many IT departments have in-house staffs to handle the tasks that security departments traditionally outsource to integrators. The IT business model often involves direct purchases from manufacturers, a current anathema for our industry. As security comes under closer IT control, there will be a tendency to adopt the paradigms of their industry, particularly for larger projects. This could require radical changes to our traditional business models.
Lesson Five: Who's the daddy? Just because security has adopted the use of IT building blocks doesn't mean the IT department automatically becomes the system's parent. Sometimes the house IT rules place untenable burdens on the security project. Sometimes creating separate infrastructure exclusively for security or virtual boundaries within the IT infrastructure to allow security centric rules without jeopardizing IT reliability. This approach requires either a high level of expertise on the integrators part or an open minded IT manager and often both.
Lesson Six: When things stop working. Getting security systems to work over networks is one thing...keeping them working is a second challenge. Is the problem in the security equipment or in the network? One experience involved a new network firewall being installed. The security equipment used a port address excluded by the firewall. Everything else in the building except the security system worked fine. Demonstrating that the security equipment worked fine when bypassing the network held little sway with the IT technicians. Getting to the root problem required a detailed explanation of the process the security system uses to authenticate a connection, something not usually covered in the installation manuals. Effective troubleshooting requires the ability of the security technician describing the problem in IT terms.
Lesson Seven: Shop Standards. Every IT shop has developed standards. Some use only Windows, others only UNIX; some use only a certain brand of computer or database or network switch. Limiting the number of "approved" products keeps things more manageable. In a similar manner, many security integrators limit the number of products they sell and service. Each client seems to develop their own standards. It requires the security integrator to gain a working knowledge of each client's standards. No one ever said the future was going to be easier!
Lesson Eight: Patches. IT security has become a big issue. Viruses and other security challenges cause the software companies to issue patches and revisions at increasingly frequent intervals. Some IT policies require installing a patch within a short time window after it is released. Conflicts with these policies have been encountered because many security equipment manufactures have not been as responsive as the general IT community when it comes to certifying their software will work with an operating system upgrade. Some IT departments have policies to set up their computers for automatic upgrades online. The recent Windows XP Service Pack upgrade from Microsoft caused a firewall to be automatically created, causing a rash of service phone calls when security connections suddenly stopped working.
Lesson Nine: Maintenance costs. Who pays for a service call when the source of the problem is something in the network? How do you estimate a maintenance budget when the number of responses is outside your control? When security systems utilize enterprise networks, issues of maintenance cost become more complicated. Some integrators exempt network issues from their maintenance agreements, other use historical records as a guide.
Lesson Ten: Splitting the pie. Often a customer, working within their IT policies, will provide the computer server, operating system and database for a security project with the security integrator responsible for providing and configuring the application software. The IT departments' database administrator is tasked with doing periodic backups and general housekeeping. When something goes wrong, who gets the first call? Like networking issues, someone is needed who knows enough about both sides to decide. Too often it requires both parties to coordinate a site visit. You guessed it... the language spoken needs to be database administrator.
About the Author: Jim Coleman is president of Operational Security Systems in Atlanta, Ga., and can be reached at [email protected]. Jim is the 2004-2005 president of SecurityNet, a national affiliation of independent security integrators. He welcomes your comments on his articles and hopes that you will share your own integration lessons. His column will appear monthly with SecurityInfoWatch.com's Security Markets & Systems eNewsletter.
