Win the security numbers game

Lumping many sets of security requirements into fewer security bands leads to lower costs, better management, and higher security

I used to be a Certified Public Accountant (CPA) before I learned that computers and computer security were a better fit. Still, you would think that earning a college accounting degree, working at a CPA firm, and passing one of the hardest professional exams in the world would enable me to do my own taxes. But I'm too scared. The tax code is full of thousands of ever changing laws. There are exceptions to every exception. Believe me, when Congress passes a tax simplification act, CPA firms cheer. That means yet another year when taxes will be treated differently than all of the prior years.

There are so many tax laws that not even dedicated tax professionals, including IRS employees, can get it right. Each year around April 15, U.S. newspapers are loaded with stories of how frontline IRS tax agents could not correctly answer simple tax questions. Who can blame them? Have you seen the size and complexity of the tax code? Exactly how many different laws can one person be expected to know, understand, and enforce with any efficiency?

[ Is your organization moving to Windows 7? Then be prepared: Check out InfoWorld's essential guide. | Tune in to the InfoWorld Security Central channel for the latest IT security news and reviews. ]

Many companies have a similar problem with information security. I've consulted with a number of clients, all with good, intelligent, well-trained security teams, who are struggling to secure a growing number of security domains, each with a different set of increasing security requirements.

The challenge was recently epitomized when one of these clients stated, "I've got 186 different (internal and external) customers with 186 different sets of security requirements."

I sat back stunned. I could not imagine a more impossible scenario short of simply increasing the number. Unless you have a dedicated person or team per set of security requirements, you have no chance of addressing them. It's impossible to make customized, personalized guarantees on such a scale.

A modest proposal

If your team is asked to provide more than a handful or two of security requirements across your enterprise, in all likelihood they are probably not doing a bang-up job in meeting those requirements. If the different clients and applications share the same physical network, then it's highly likely some of the security boundaries are being mixed up and crossed. Who can blame the IT staff? They were given a nearly impossible job. Every additional set of security requirements increases the workload proportionally, if not exponentially. Every additional set of requirements means more configuring, more monitoring, more of everything -- except real security, of course.

The only way to improve the situation is to collapse the number of security domains into a broader range of "security bands" that meet the common requirements. Then classify all the security requirements into the smaller subset of bands.

For a simple example, suppose different clients and applications have different storage archive requirements. Client A says you must save all e-mails for seven years. Client B says e-mails containing company information must be saved for five years. Client C wants executive e-mails saved for seven years and all other company e-mails saved for three years. Client D wants all e-mails saved forever. Client E says all e-mails must be dumped after one year. All other clients, numbering in the dozens, have not yet defined an e-mail archive policy.

How many security bands do you make? Make two, maybe three at the most. Hard drive space is cheap. The biggest expense of any e-mail archive solution is the initial purchase. Cut out most of the different security requirements by making one big security band that keeps all e-mails forever. If you're not required to purge, don't. By keeping all e-mails, you meet the security requirements of all clients except Client E, who must be handled differently. You could even create a third category of e-mail archiving where you save e-mails for seven years and then delete, thus saving some money and hard drive space.

Me, I'd keep it to two and just tell management the cost of doing so. It might even mean charging clients for the additional storage or archival costs and surely will result in increased retrieval times when e-mails are requested. But by reducing the number of security requirements from five or more to just two, you've increased your ability to manage more efficiently and effectively. And this means decreased security risk.

Big targets are easier to hit

Some security leaders get caught up in the service professional's dream of delivering just the needed service at the bare minimum cost. That's a fool's dream when you have more than a handful of requirements. You'll end up nickel and diming your staff, straining budgets, and letting your customers dictate your priorities. Worse yet, every additional security requirement you try to tailor increases the chances of security failure.

I'm not saying you shouldn't deliver the service level the customer wants. I'm saying it's OK to meet that promise by overdelivering for some and just meeting it for others. By creating security bands, you become the leader again.

If you have an unmanageable number of security requirements, review the various requirements: response times, availability, security permissions, domain separation, backup storage, anti-malware, hardening, and so on. Find the components that are common to the various requirements and note the different values under each component. Then group the requirements into a handful of security bands. Each band should indicate the minimum level of security that will be delivered. Document each security band so that you can hand customers and managers a single page listing the bands and their service level agreements. Group every existing client or application you have into a security band. When new clients or applications come on board, ask the owners to pick a security band.

Try hard to avoid making one-off security bands for clients or applications that need just one change. You may think you're being accommodating, but you will just end up re-creating the structure you worked so hard to get away from.

This story, "Win the security numbers game," was originally published at InfoWorld.com. Follow the latest developments in information security, risk management, and regulatory compliance at InfoWorld.com.

Mobile Security Insider: iOS vs. Android vs. BlackBerry vs. Windows Phone
Join the discussion
Be the first to comment on this article. Our Commenting Policies