Best security practices don't exist. If they did, the company implementing them would be spending too much money trying to secure its information, and worse, more than likely stopping the business from operating. The best practice for any organization is to evaluate its risk, comply with applicable standards at the minimum level required, and implement just enough control to achieve that state.

There are organizations, such as certain three-letter government agencies, or R&D aspects of companies with high-value intellectual property, transactional or money transfer systems, that require best and state-of-the-art security. For most of the IT world, however, successful IT professionals balance the cost and complexity surrounding security controls, and IT costs in general, to obtain an appropriate and acceptable level of risk.

In the US, the Food and Drug Administration's Web page on information security states that GxP is the current standard for various regulatory compliance areas for pharmaceutical companies. GxP represents Good Practices, not best practices. That is, Good Manufacturing Practice or Good Clinical Practice. This is a bit odd: good enough was the plan of the day for manufacturing life-saving drugs.

Looking further, building codes define "minimal acceptable standards" that homes, lots and structures have to meet. Similarly, in the legal community, there is the standard of the reasonably prudent person. Doctors and other professionals are typically only held to a standard of reasonable or ordinary care, not excellent or the best possible care.

So IT and business professionals should not be asking for best practices, they should determine appropriate and reasonable controls to protect information and maintain compliance with federal regulations. Interestingly, even the regulatory guidelines allow flexibility in approach to controls, as long as the information is adequately protected and based on the use of a documented risk assessment to determine this reasonableness and appropriateness.

To determine if you're spending the appropriate amount on security controls, perform risk assessments for every significant technology decision. Documenting the outcome and how you arrived at your decision helps your organization meet regulatory and legal requirements, and earns you the respect and admiration of the business units and bean counters.

Take, for example, a network architecture migration. Engineers presented a fully redundant, resilient design for a branch office. The design specifications were based on what the engineers termed "best practice" and on input from the remote workers who said they had to be on the network, or their work would grind to a halt.

A risk assessment was performed. Although important, the remote site could be down for several hours before a significant effect would be felt by the overall organization.

Too much of a good thing

The office and network staff overestimated the importance of the operation to the business and built a design almost four times as expensive as it needed to be, based on the cost to buy highly available equipment and twice as much of it. The security-risk team suggested a lower level of availability equipment and saved the organization money. The best practice was too much for the job.

There is a simple, facilitated procedure to do this, normally at one of the meetings that is already a part of the design and decision-making process. The National Institute of Standards and Technology 800-30 process says to identify threats and vulnerabilities and identify controls mitigating those risks already deployed ("current controls"). Keeping those in mind, estimate the likelihood of the threat and the impact of the exploit of the vulnerability. This defines the "risk".

The easiest way to do this is to make a list of all the threats and vulnerabilities. Most people who aren't accustomed to abstract risk concept tend to group threats together as a "bad thing that could happen".

Listing threats as one makes the procedure easier for IT and business to follow and provide valid input. Then, group similar things together and gain consensus on the final list.

What gets top billing?

The goal should be to have a reasonably sized list -- 10 to 50 is a good amount. For example "unauthorized access to a Web application" can catch all the hacking, exceeding authorized access, and looking at other information risks to a company. From this list, rate each one as high, medium or low for probability and impact. This should be fairly simple to do: most people intuitively know viruses occur frequently, and that natural disasters don't.

Use this list to gauge the amount of control you need. Obviously a high probability/high impact risk needs more control to bring it to a medium/medium, or a low/medium. Something that reduces a high/high to a low/low has normally reduced too much risk and cost too much. Use a simple chart to map the risk-reduction to the cost of the controls. A high-risk reduction impact that has a low cost should be implemented immediately.

For example, an internal firewall to control access to payroll and finance is critical for Sarbanes-Oxley Act compliance. However, a high cost/low reduction control, such as using similar firewalls to segment every server in the company, is probably a waste of money.

A successful IT professional leader should focus on how much risk needs to be alleviated, and how much will the various controls needed to do that cost. When you really do need to implement an additional control, this process will help you pick the least-expensive one.

As David Lynas, executive director of security organization The SABSA Institute, says, "Spend absolutely every penny you need to on security. . . but not a penny more."

David Lawson is VP and a director of the global security practice and facility security officer at Greenwich Technology Partners