A Security Policy needs to be abstract not specific

There’s much I don’t like about many of the published security policies an the ones I see in use at many sites I visit and audit.   But lets pick on ones that deal with passwords.

Firstly, the concept of passwords are limiting.
Are you going to add a “pass-card policy” and a “iris scan policy” and a “fingerprint policy” ?

Of course not. its all “Authentication“.

And it doesn’t matter where or how or even WHAT you are accessing – policy applies. So the policy has to be general.

The workshops I’ve run on policy writing open with an explanation of what makes good and bad policy and use this point as an illustration. Good policy is general and isn’t going to need to be revised as business
needs or technology – and hence risk and how its addressed – change.

Access to corporate Information System resources
will be restricted to authorized users in accordance
with their roles. Users will uniquely identify
themselves and will be accountable for the actions
carried out under this identification.

Simple language, very general.
You could say it even applies to the to the parking lot at the data centre.

It doesn’t address passwords or swipe cards or fingerprints directly for a simple reason.

THEY ARE NOT POLICY ISSUES.

Le me say that again.
Specific controls and specific control technology are not policy issues.

They are standards.
Refer to them. Refer to NIST, refer to the Microsoft documents.
They are not policy.

The _general_ example I gave above is POLICY.

Can you see the difference?

Now read that paragraph again.

Does it say anything about HOW you access corporate IS resources?

No.
So it doesn’t matter if you do it at the computer at your desk in the office; from your laptop when working at home over the VPN; from the airport using your smartphone over the Internet. It doesn’t matter if the ‘resource’ is a parking lot, the email server or in ‘The Cloud’ somewhere.

You don’t need separate policies for all of them.

I picked on ‘password policy‘ because its easy to illustrate how a specific like this is wrong-minded and can easily be invalidated by a shift in technology. But the principle applies to the whole of the proposed document.

Why does this matter?

A minimalist approach has much to recommend it.

Quite apart from making the document shorter an hence easier to communicate, it eliminates redundancy and with it the opportunity for sections that talk about what is essentially the same thing but end up
being contradictory.

The example I gave avoids there being questions like

Does remote access use passwords or certificates?

because its NOT a policy issue. A ‘remote access policy’ might or might not talk about passwords, about SSH, kerberos or X.509 depending on the the bias of a technical writer. In which case its about standards, not policy, and its about access controls, no policy.

Implementation details – controls – must not be embedded in policy.

There a lot more potential for conflict in the document structure as its laid out at the moment.

Why do I talk about it?
Lets leave a policy document aside or a moment and thing of our jobs as Information Security specialists. part of our roles is thinking about what can go wrong, the weaknesses in the configuration and management of the Information systems, management, communication and storage. We think about threats and vulnerabilities.

Now apply that same approach to the document. this one you are calling a “policy manual”. Don’t take a bottom-up approach, such as arguing over the length of a password or how often it should be changed. That isn’t policy. At best its a standard and a highly context sensitive one at that!

Identify what is in common and make it a policy.

I gave the example above of access control.
It doesn’t matter whether its access to the workstation, the server, that CRM database, the “pipe” out to the Internet, or the Citrix array inbound over the ‘Net from home or an Internet caf�.

It all access to corporate IS resources. It should have one and only one policy. It should not be spread over a number of policies with ifs and buts and different technologies and phases of the moon.

Remember: you have to write policy that can be followed and can be enforced. If users )or sysadmins for that matter) have to remember lots of different circumstances and special conditions then they are less
likely to conform. “Oh, I forgot“; “Oh, I was confused“; “Oh, I didn’t think it applied here“; “Oh, I didn’t think it applied to me“.

That’s a start.

Yes, I’ve picked on “access”, but I could equally well have picked on “virus” or “email” or “mobile”.