IAM – Basics – Policy

If there’s one thing that upsets me when I see articles and posting to forums about policy, its mention of a “Password Policy”. I have to step away from the keyboard, go outside and take some deep breaths to calm down.

I get upset because policy is important and developing — and more importantly communicating — policy has been an important part of my career and the professional service I offer. Policies need to be easy to understand and follow and need to be based on business needs.

If you begin with a list of policies, you end up adapting the the reality of your business – the operations – to the list. You are creating a false sense of security. You need to address what you need to control, and that is Identity and Access.

Lets face it, passwords, as Rick Smith points out in his book “Authentication“, are not only awkward, they are passée – even Microsoft thinks so. More to the point, using passwords can be bad for your financial health.

They should be used with care and not as a default.

And they should most certainly NOT be entombed in a corporate policy statement.

A policy is a high level statement on how the organization – not just IT – should be run. Passwords are not policy, the are controls. If you have a password policy then the people who use tokens, badges or swipe-cards are in violation because you have a Password Policy and not an Identity and Access Policy. So, are you going to add a Token Policy and a Swipe-Card Policy? Then you will need a SUPER Policy to determine which one to apply, and its not “Policy” any more.

Passwords, tokens swipe cards, biometrics and more are all implementations of controls. They are not Policy.

So what is a Identification and Access Policy?

The example I use in the workshops I give on Policy Development is this:

“Access to Corporate Information System resources will be restricted to
authorized users in accordance with their roles.

Users will uniquely identify themselves and be accountable for the
actions carried out under this identification.”

Now in my workshops I try to get people to structure the policies in a logical manner. The template I recommend is to have a hierarchy below the policy statement like this:

1. Justification – the reason for this policy
2. Who/where/when/what this applies to
3. Consequences of Non-compliance

That is the core. However we normally speak of “Policies and Procedures” so I recommend keeping them together. The “procedures” part I treat as three sections.

First, there are the “Guidelines for Interpretation“. While the policy core is very direct language and strong assertions, this is ‘gentler’ and more helpful. New situations are going to arise and the this second part of the policy will need to be “applied in context”. I usually recommend a Wiki for this as it is a living document.

Second, there are the relevant standards. By making use of standards, be they industry norms or “standard operating procedures” developed in house they don’t have to be part of the policy itself. These standards may be definitions, legal requirements or well established good practices.

Finally there are the actual procedures – the detailed instructions of what to do to fulfil the policy in various contexts. These may be extensive; they may be references to or copies of vendor instructions. Because they can be extensive and may be the most “living” part of the policy structure, again I recommend a Wiki or some kind of document management system.

Wikis usually incorporate search engines, cross reference capability, external links and the ability to attach or embed documents. Many also have good revision control and access control. All this makes them excellently suited for the management of Policies and Procedures.

Now, back to the policy statement I quoted.

It carefully avoids mentioning specifics. It talks of access to “Corporate Information System resources“. Not servers, not workstations, not routers. Not even backups. No the raised floor area. It could be referring to the photocopier or even the photocopy paper!

With a small change to simply “Corporate resources” it could even apply to reserved parking spaces, to say nothing of Internet bandwidth.

And under the relevant ‘standards’ and applicability it can cover tokens and swipe cards and biometrics without the need to get approval again from the Board, because the ‘standards’ and ‘procedures’ are under Operations. Oh, and it covers passwords too.

So there you have a fully functional, fully generic clearly understandable and technology/vendor agnostic Identity and Access Policy.

Policy Structure heirarchy
Policy Structure heirarchy
Enhanced by Zemanta

About the author

Security Evangelist

Leave a Reply