Critical infrastructure: The five biggest technology mistakes

Recent shifts in the viability of many emerging security technologies are stirring action by critical infrastructure security professionals.

Some of the more creative technology innovations introduced in recent years have worked out their initial kinks and are starting to justify some of their previous hype. At the same time, these products are becoming more reasonably priced. As a result, security managers are rightfully considering and deploying more advanced security technology as important components of their security programs.

It makes perfect sense that planning and implementing modern security systems requires special attention be paid to every detail - ensuring that the totality of equipment and systems function as intended, does not over-burden administration, operations or maintenance staff and maximizes their intended benefits. Individual technologies must also integrate to provide greater situational awareness, thereby amplifying any "force multiplier" potentials to quicken return on investment.

The old axiom of "Good news travels fast and bad news is waiting when it gets there" does not seem to apply as much to security technology mistakes made by critical infrastructures. Many clients are uncomfortable sharing details from their technology implementation failures and political pressure is sometimes applied to lower the profile and embarrassment of dollars wasted on technology missteps.

The benefits of sharing these lessons learned, however, far outweigh any short-term perceptions. To help critical infrastructure end-users get maximum benefit from security technology systems, let's review five of the most common security technology deployment mistakes made by critical infrastructure protectors, along with tips for how to avoid them.

Mistake #1: Believing what you read and hear.

The security industry does not oversee or regulate what manufacturers print or say about their products. This is not to say that some manufacturers don't strive to provide honest information, but laypeople (and professionals) do not have the ability to determine the difference between real-world data and manipulated results.

Finding unbiased information about products is annoyingly difficult. Trying to learn a company's strategic vision for their products and a particular product line is harder. Forecasting which companies may purchase competitors, absorb and otherwise eliminate products is impossible.

The flood of proprietary specialty products amplifies the problems faced by decision-makers. For critical infrastructures especially, there can be pressure to hurry along technology deployments and expedite implementations.

How do you address these challenges? First, be skeptical of everything. Focus less on technical data like pixel counts and error rates and more on head-to-head evaluations in real-world conditions like your own.

Seek unbiased and experienced evaluations and advice. If you belong to an industry group or other peer network, use its membership to solicit feedback on what works and what does not. If you are relying on a peer with an identical system, visit them directly rather than take anyone's word for the effectiveness of their systems.

Before you commit to implementing any particular technology, conduct "proof of concept" testing at your facility to replicate how the proposed technologies will perform, and, more importantly, whether the technology meets your real needs.

This is different from "Beta" testing that lets others use you as a guinea pig for their product development while learning how their products perform at your expense. Too many users accept these test systems to cheaply augment their existing security to the detriment of the overall program.

Mistake #2: Technology will solve all your security problems.

Every security technology is only as good as the complete security program that supports it. History has demonstrated time and again that the simplest breakdowns can render the most sophisticated security systems useless. This is especially true with critical infrastructures - where an abundance of territorial stakeholders increases the odds of operational and procedural breakdowns.

Protectors of our nation's assets should remain constantly mindful that security technology is only one aspect of a security program, and, in fact, depends on the success of the other parts in order to be effective. For example, some technology proponents automatically believe that video surveillance cameras outfitted with analytics can replace the need for roving guards. In reality, however, depending on the particulars of the situation, more monitoring staff might be needed to receive, assess and respond to increased alerts that might be generated by advanced video systems - offsetting the fewer field personnel.

It is important to keep expectations reasonable about technology's role in your overall security program and thoroughly understand exactly the impacts of each proposed system. Ultimately, your security programs success may hinge on the perception of how effectively and appropriately security technologies are understood and have been deployed at your facility. In addition, technology's role in the overall program should be well thought-out and clearly communicated to everyone involved.

Mistake #3: Poor planning.

Security breaches can be a stressful time for everyone. Natural instinct dictates that the sooner something is done to address an incident, the less likely something like it will occur again.

Security technology such as cameras, access control and intrusion detection can seem like obviously good tools to deploy or upgrade; however, rushed incident response-driven deployments without appropriate planning are not always best for the overall security program - and in some cases, can create unnecessary liability.

A thorough understanding of the real vs. perceived needs for security technology is necessary prior to deploying any equipment. Planning for any critical infrastructure enhancement involves knowing the real security needs and which technologies are most appropriate to deploy.

This process must also addresses "low tech" and "no tech" supporting features essential to program success. For example, wherever cameras are deployed, a lighting plan should support their use.

When IP-based security systems are considered, the IT infrastructure plans should be updated to account for current and future bandwidth and resource demands.

When facilities are designed or renovated, minimum security technology standards should be in place. Prior to making any product standards decisions, a thorough competitive evaluation should be performed, including identifying a pool of competent, factory-certified installing companies to provide options and ongoing support.

When security systems costs are estimated, make sure that product lifespan and five-year service needs are anticipated in addition to the ongoing personnel and operational costs of maintaining the systems.

Mistake #4: Leaving out lynchpin stakeholders.

Critical infrastructures, like many organizations, can be politically charged environments with competing interests, agendas and legacy attitudes.

We have seen a trend among some organizations that in order to obtain consensus on issues and complete the project, the pool of stakeholders must be as small as possible. Security projects that kick-off without involvement from important stakeholders invites second-guessing, criticism and can create hurdles and project roadblocks that could be avoided.

Ultimately, the security program may suffer from less credibility and support, due to what is viewed by some as a program forced on them by an elite group that is out-of-touch with organizational needs.

Commonly overlooked stakeholders include service staff who maintain the systems, field personnel who respond to system alarms, operators who will be manning the equipment on a regular basis and information technology personnel whose network may be supporting the systems. Other departments appropriate for process inclusion are legal, local law enforcement, human resources and procurement.

Not every stakeholder needs to be integral to every security technology discussion; however, inviting these stakeholders to the table from the outset and keeping them informed in some manner throughout the process can smooth the implementation and acceptance path and remove much of the potential resistance to your security technology program.

Mistake #5: Deploying more technology than you need.

Just because it can be done does not mean it should be. In recent years, security mandates and grant funding opportunities have driven facilities to acquire significant amounts of security equipment.

I've had critical infrastructure clients call me and say they need to come up with some proposed security projects quickly so they can stake their claim to funds and get "their share" of a grant award. Unfortunately, we have repeatedly seen that funding processes and rushes to deploy technology at critical infrastructures sometimes do not consider the real vs. perceived needs for this equipment, nor the impacts these deployments will have on the overall security program.

Whether incident-driven or not, many well-meaning facilities have deployed more technology than they need. Ultimately, shortsighted technology deployments often become expensive boat anchors dragging down the security program without adequate operating or maintenance funding.

How much of which technology is enough? Try to match every technology deployment to a specific documented priority need. Make sure that these needs cannot be addressed by simpler and easier to implement and manage "low tech" or "no tech" solutions.

One test to evaluate whether you have deployed too much technology is to find the person within your organization who is most familiar with the proposed work. Ask that person to explain to a small group of non-security employees (representing various skill and authority levels), what need the proposed equipment will address, how it will accomplish this and how using this technology is appropriate when compared to other alternatives. Then, interview these employees and ask them these simple questions: Did the technology advocate's explanations make sense? Is it clear from the session that we need this equipment? Do you think our security program will be better with this equipment?