The Lure of Default Settings

The Lure of Default Settings

Print Friendly, PDF & Email

by Ray Bernard PSP, CHS-III

Feb-Mar 2015

When it comes to the installation of security systems and devices, some installers find it tempting to “turn it on, check it out, and run with factory settings” if everything seems to be working okay.

Q: Recently we signed off on an access control and video system installation because everything seemed to be working fine. Later we learned that all of the equipment was left at “factory default” settings. Some of these are not what we want. For example, communications encryption is turned off. Are we right to insist that the installer “make good” on providing us with secure security systems?

A: There is no question about the fact that you are right to insist on a secure systems configurations, and on whatever other requirements you provided. The only question is whether or not you end up paying extra because the system was already signed off as “accepted”.

Over the years, as well as recently, I have talked to a number of security dealers (resellers/installers of security equipment) that prefer to leave all equipment and software at its “out of the box” settings whenever they can. The reasons offered for doing this have included:

  • It simplifies tech support because you can tell the vendor that their product is configured to factory defaults. They can’t point the figure at you for any changes you made, since you didn’t make any.
  • Factory default settings are usually best. They represent that the vendors have found works well in most situations.
  • Our technicians don’t have to remember special configurations for specific customers. It standardizes service and support and gives us a high overall customer satisfaction rate.
  • It helps us to tell if problems are occurring because a customer has messed up the configuration, because their changes are obvious.
  • Allowing the customers to configure their own systems allows us to provide them with the lowest cost systems.
  • We provide the customers with training, and then they can adjust their systems over time, so that they can achieve an optimal system.

There is nothing wrong with using default settings if they accomplish exactly what is required for the intended security operations capability. The rationales listed above are faulty and inaccurate at best, and lame excuses at worst. In these particular cases, they really were false excuses for situations in which the installer didn’t really know how to properly deploy a security system. Follow-up discussions with the related customers revealed that (a) the customers did not know that they were being left on their own to perform the configuration of their systems, and (b) the training provided to the customers was minimal end-user training, not the kind of training and education required for systems configuration, commissioning and fine-tuning.

Some default settings leave system vulnerabilities in place, including those relating to passwords and encryption of communications.

When systems are installed leaving the security and network equipment at default settings, only a very low level of technical knowledge is required to perform the work. In fact, a novice installer with only minor networking knowledge could get the equipment connected together and powered up. After all, installation manuals and technical support and advice are available for free online. I have was astounded at the number of low-caliber security system installations I and my colleagues have found in 2010 and later among small businesses and small school districts. This is not a new problem. But it is an unacceptable one.

Don’t Get Stuck with Defaults

Of course engaging a high-end systems integrator and purchasing only the top-of-the-line brand of systems and equipment is one way to obtain two levels of assurance: a well-qualified installer and a vendor with strong technical support and professional services. But what if cost, size of system, location of project or other factors rule out the use of a top-tier integrator, big-name systems, and independent consultants? There is one proven successful approach that actually should be used on all projects of consequence.

Including a 30-day or 60-day Operations Acceptance Test in the deployment project provides the customer with a means to ensure that the system operates as required to support its security operations’ needs. It provides enough time for the customer to learn about the new technologies and get them adjusted to suite their particular requirements, whether or not written requirements were established at the start of the project. If the contract is written correctly, it can even account for situations where the customer-provided requirements were incomplete or incorrect. It allows for enhanced training and fine-tuning the system for best performance, which is especially important for outdoor perimeter intrusion detection systems and other technologies that involve analytics. When this approach is taken, there is usually no close-out punch list, as the installer has had plenty of time to address all items before final acceptance is given. A significant progress payment should be provided prior to starting the Operations Test Period, with the final payment being made upon successful completion of the Operations Test Period.

A single contract paragraph establishing an Operations Acceptance Test period is a highly affordable means of assuring that your security systems deployment project will meet its objectives.

Of course, having a well-qualified service provider install and configure your systems will help eliminate a multitude of other installation issues that shouldn’t happen.

Write to Ray about this column at ConvergenceQA@go-rbcs.com. 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. For more information about Ray Bernard and RBCS go to www.go-rbcs.com or call 949-831-6788. Mr. Bernard is also a member of the Content Expert Faculty of the Security Executive Council (www.SecurityExecutiveCouncil.com). Follow Ray on Twitter: @RayBernardRBCS

© 2014 Ray Bernard