Eight Rules

Origin

These rules originate from over two decades of experience in trouble-shooting and solving project problems with IP-based security technology deployments. For every troublesome deployment, at least one of these rules was not followed. In most cases, several rules were ignored. Following these rules does not guarantee success (for example, you still have to manage a project well, you have to select sound products, and so on). But ignoring them practically guarantees trouble.

Manufacturers take note: How easy do you make it for these rules to be followed?

Eight Rules for Deploying IP-Based Systems

Security vulnerabilities and deployment problems (as opposed to product problems) consistently result from violating one or more of the sound practices below. Thus these practices constitute rules for sound deployment.

1. Design and Deploy a Sound and Secure Network

The term design means developing a documented design that is subject to a documented change management process. According to observed practice, the concept for "deploy" doesn't always include "design", which is why design is specifcally called out. Similarly a sound network doesn't always mean secure in some minds, and so that is specifcally spelled out as well. If the design isn't documented, there is no sound basis for validating what was deployed. Thus countless torubleshooting hours have been needlessly wasted on many projects because the network configuration wasn't designed in writing, and its configuration wasn't documented, resulting in unverified assumptions or past problem experience becoming the starting point for troubleshooting. Hit or miss approach, in other words.

2. Identify and Test the Secure Deployment Configuration
for Each Product and System

Secure product configuration instructions are not always clearly provided by manufacturers. Documentation does not always keep up with product changes. Configurations don't always work the same way in all environments. This is why configurations must be tested in the target environment, not just in the lab, for each product and system.

3. Develop Appropriate Countermeasures for Known or Discovered Vulnerabilities

Hopefully the vulnerabilities that the manufacturer knows about are documented in release notes. But again, documentation does not always keep up with product changes. And manufacturers can't possibly test products and systems in a series of environments that represent all possible deployment environments. Nor can they feasibly test all possible configuration combinations. So it stands to reason that some vulnerabilities might escape them—especially if they are not testing for them. Whatever vulnerabilities are found in the actual deployment must have appropriate countermeasures applied.

4. Document the Secure Configurations and Countermeasures
in a Deployment Security Plan

If you don't have a deployment security plan, what basis is there for testing the security of the deployment? No combination of experience, expertise, training and intuition can make up for a lack of accurate documentation. The deployment itself must be subject to change management, and the security plan is one of the documents that is required for a sound change management process. This is independent of the change management process for the network.

5. Deploy According to Security Plan and the Manufacturer's Instructions

The security plan is listed first in this rule, because sometimes manufacturer's instructions have to be overridden for the sake of security. Where that is the case, the instructions themselves are a vulnerability factor, and should be reported per Rule 8. However, deploying according to the manufacturer's instructions is usually required to maintain warranty and support status. Thus not deploying according to manufacturer's instructions can create a system or product vulnerability, in that the product or system may not be supported when a problem arises. This is why it is important to disclose the matter to the manufacturer to put the manufacturer on notice, and to request confirmation that the manufacturer's warranty and support policies will continue to be applied.

6. Validate the Security of the Deployment

It is amazing how many times the human error element is ignored. It is almost always assumed that the work was done correctly, without checking it. What's more, sometimes instructions are followed to the letter—but instructions can be wrong. There are plenty of reasons to validate the security of the deployment at this point, before moving on to Rule 7.

7. Test and Document the Product, System and Network Performance

This rule is also rarely followed, except for some security video systems where the likelihood of the customer finding something wrong with a video image is very high. However, industry shoddy practices leave most deployments without documentation (see Rule 1 through Rule 4) and so often there is little to no criteria for performance validation.

8. Perform Appropriate Disclosure of Any Newly Discovered Vulnerabilities

Unfortunately, given the current state of the physical security industry, it is likely that one or more vulnerabilities will be discovered on a deployment project. When reporting them to the manufacturer, follow your organization's disclosure policy if one exists. If there is no disclosure policy, try to make the creation of a corporate or departmental disclosure policy a sufficiently prioritized follow-up action to your project.

After reporting to the manufacturer, you can also submit a Rant to this website. If you didn't find any new vulnerabilities, and you are very happy with the manufacturer's deployment support, you can submit a Rave instead.

Achieving Success

Don't risk failure by ignoring the rules above. As one website visitor commented, "Gee, if I can find these rules online, that means my boss can, too." Why leave it to chance? Actually, there is a better motivation to be embraced than fear of failure, and that is dedication to success. Print this page and get it to all the deployment stakeholders and appropriate project team members. It's easier to obtain stakeholder support for the actions required when they are presented in the context of a success plan. Applying these eight rules will require some time and effort, which pays off in project efficiency and effectiveness, not to mention overall success. Build them into your overall deployment planning and live up to your stakeholders' expectations.