The InfoSec Blog

IAM – Basics – Policy

Posted by Anton Aylward

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.

You don’t need a Firewall Security Policy

Posted by Anton Aylward

A member of a discussion list I subscribe asked for a Firewall Policy template.

A usual, I was alarmed enough by this to want to comment and drag it back to the discussion on "assets".

I don't think you should have a "Firewall Security policy".
This is why.

A great book on firewalls once described the firewall as

The network's response to poor host security

You can occasionally see articles on host-centric security drifting by ...

A firewall is a "network PERIMETER protection device".

Do you have a well defined perimeter to which you can apply enforcement policies, or is your 'perimeter' like so many businesses these days, a vague and nebulous concept that is weakly defined? One thing that is "in" these days is "De-perimiterization". See "The Jericho Forum".

The firewall model is inherently one of a 'hard outer shell and soft vulnerable centre'. As I said, its based on the idea of poor host security. Good host security will mean that the hosts don't have any un-necessary open ports. Scan you network. If there are no open ports why do you need a firewall?

Oh, right: port 80. And all the hundreds of services behind it.
In effect those are your 'open ports'. Yes, there are firewalls that claim to do 'deep packet inspection'.  Check what they actually do.

There are other uses for a firewall?   Well some people use it as a NAT device. Some people use it to control outbound connections - "data leakage".   What they are really saying is that they haven't built their information architecture in a robust and secure manner.  Back to the 'poor host security'.  Perhaps you should be doing this sort of thing in your switch or router with ACLs.  Partition your network.

So why did I start by saying "assets"?
Some people think that the assets are the hardware.
Focusing on the hardware as opposed to the services, the information and the processes leads you to think in terms of things like 'firewalls' rather than in abstracts like "perimeters" and "access controls".

By addressing a "Firewall policy" you are focusing on equipment rather than fundamentals.

Enhanced by Zemanta

A Security Policy needs to be abstract not specific

Posted by Anton Aylward

The Information Security triad: CIA. Second ve...
Image via Wikipedia

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.


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?

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".

Enhanced by Zemanta

Encyclopedia of IT terms

Posted by Anton Aylward

CMP ChannelWeb have an on-line encyclopaedia of IT terms. This is a useful addition to my toolbar for composition, along with a more conventional dictionary.

ChannelWeb Logo

The definition of 'information security' seems limited to access control, which is very disappointing. The definition for 'computer security' is more comprehensive. Never the less, to a security professional both these definitions are lacking.

What screams out to me, and this is very obviously my bias, is the lack of any mention of INTEGRITY in these definitions. As I keep pointing out, if you don't have integrity, any other efforts at security, be it information security, or "Gates, Guards, Guns and Dogs" physical security, be it backup and disaster recovery, be it access control, be it 1024-bit SSL, are all going to be pointless.

Its not until we follow a few links at the Encyclopaedia do we come to a mention of Donn Parker's six fundamental and orthogonal attributes of security is there mention of 'integrity'. Even so, that definition has only a like to 'data integrity'. There is a separate definition for 'message integrity'. While these specific items are important, they are details. What is lacking is a general definition of "Integrity". Once again, Fred Cohen's seminal 1997 article on the importance of Integrity comes to mind.

No, a much better reference is Rob Slade's "Dictionary of Information Security", which, of necessity, encompasses many IT terms.

Enhanced by Zemanta