Security policy - making it palatable

Ever since I've been aware of IT security, I have been told it is not, fundamentally, a technology issue. There's lots of really good stuff we can do with very sensible and worthwhile technology, installing systems, guarding perimeters, repulsing attackers and identifying users as they log on. But that is not what matters. What matters is the kind of policies we set up to ensure that the technology actually gets used.

If you don't have a thought-out policy, you may spend thousands blocking up a "gap" in your security -- when that gap does not actually exist, or is very unlikely to cause problems. You may leave other gaps wide open. Worse still, without a policy, your staff won't understand the reasons for the security measures and may, accidentally or deliberately, break them or side-step them.

Everybody knows this. Security is not fundamentally about technology. But how have we responded? With technology. With interminable discussions about technology -- this year, the merits of "intrusion-detection" versus "intrusion prevention". With endless new products designed to fill some security niche that got missed out by the last product, or combine the last three security product types into one super-duper appliance.

Despite being continually told that security is a matter of policy, 99 percent of my conversations about on the subject have been about products and technologies.

Security policy, like so many other important things, is not pleasant or easy to talk about. After a few minutes, our eyes tend to glaze and we start to look round for something "concrete" to install or configure. This is basically because the conversation is hard work, it is on subjects that do not come naturally to technologists, and we want to avoid it.

It's like those relationship-shaking conversations when one partner needs to talk about "What are we doing together? Where are we going?" and the other partner feels a sudden urge to tidy the cellar.

To determine security policies, you need to think about the business and examine the risks. You need to place a value -- and a probability -- on them. You need to budget, to find the best way to spread the available money across the security options -- and accept the unpalatable fact that it ain't going to be perfect. You need to plan the implementation, and (most important and irksome for the uber-geek) make sure that the rest of the company -- management and users -- understand as well as they are able, and agree with you.

This stuff is not fun. And efforts to make a structure to do it in are not light reading. But there have been several efforts to formalise it and make it palatable to the rest of us. And I think it's time to give them a look.

One of the best established is the International Standard on best practices in security, IS17799. This was developed in Britain as BS7799, first published in 1995. The document was just an advisory one, but the UK Government's Department of Trade and Industry (DTI) backed efforts to create a specification under which people might eventually get certified -- this was produced as BS7799 part 2. This part of the standard is not yet approved as an international standard, but should be one within a year or so.

"BS7799 part 2 is fully business-oriented," says Steven Hill, of Logica CMG Security, one of those involved in BS7799 almost from the start. "It is based in security risk assessment, and tells you how to consider threats." Only once the business decisions are made does the security policy start to consider product types.

Hill encourages users to evaluate themselves against the Capability Maturity Model (CMM) of Carnegie Mellon University. BS7799 categorises stages of maturity from Chaos through Piecemeal, Managed to Best Practice.

For many people's taste this may be like a foreign language. This why I like an approach I met at the RSA Conference in San Francisco: the GAISP or "generally accepted information security principles".

GAISP, created by ISSA, a US IT security group, is an effort to make security policy more acceptable by a comparison with accountancy policy.

Every US company has to file accounts that are created according to "generally accepted accountancy principles" (GAAP). Companies are happy to do this because it is a condition of doing business. What ISSA wants to do is to establish a similar level of acceptance for security practices -- and they want this one to be worldwide (GAAP is showing signs of becoming global but is not there yet).

GAISP has three advantages over IS17799, according to ISSA spokespeople. Firstly, it is more concrete: it starts from the same risk assessment ideas, but goes further in specifying ways to implement the policies derived. It does talk about actual technologies.

Secondly, it has the GAAP analogy to lend it weight, make it sound like something that your company has gone through before. This comfort-fact is worth having.

The third advantage is that the ISSA people are not wheel-inventors. They claim to have mapped IS17799 to GAISP, so that compliance with GAISP will automatically mean you have complied with IS17799. Follow GAISP, they tell me, and you have the best of both worlds.

GAISP is still at the stage of "good idea" rather than "fundamental necessity for the switched-on business." It is never going to be as interesting as a bunch of horror stories and product descriptions. Its very objectivity makes it difficult for security vendors to enlist it as a marketing tool, so you may not hear much about it from vendor channels.

But it has a concrete set of documents that should be finished by the end of the year. And, by the way, the documents will be updated regularly. So GAISP is potentially going to function as a set of updates to IS17799, which has to stick to an international standards publication schedule.

You will be hearing about it -- and IS17799 -- from analysts and consultants of course. This kind of thing is right up their alley, and they will sell a thousand projects launched where they come in as third parties to audit you under IS17799 or GAISP.

The biggest test of GAISP will be if it can survive this sort of attention without becoming the kind of consultants' gravy-train that the ISO 9000 "quality" standard did in the 1990s. That was an absolute fiasco, where governments required certification under a woolly document. Every white van on the streets had a BSI kite mark, proclaiming it was a "quality" company. But all it meant was that some part of the company -- say, the catering department -- had been passed ISO 9000-compliant, by a bunch of new graduates in suits, who knew nothing about the business.

If GAISP and IS17799 go this way, it will be a tragedy. But we are at a stage where it could turn out to be something real and useful.

The European launch of GAISP is next week, at the Infosec show in London. Its public leader, Mike Rasmussen of Forrester Research, will be there. And so will I, cheering GAISP on.

Let the editors know what you think in the Mailroom.