Most organisations have two types of security policy: one type is a word document that follows a standard like ISO 27001, and the other is a set of access control lists (ACLs) that control a system. The first I call a management policy, the second a machine policy.
Management policies matter because they express what the management wants (or rather, what the CISO thinks they want); machine policies matter because they control what the IT actually does.
In theory, the machine policies should implement the management policy. But any experienced security person can tell you that management policies aren’t intended to be implemented, they’re intended to be audited. In particular, they don’t usually say what’s forbidden and what’s permitted - they state everything that’s forbidden and then tell you who to ask to get an exception. Management policies are more to do with security governance than security policy.
So, what do you really want in a machine security policy? Machine policies will generally derive from some business relationship or technical driver. Here are some things I might want to say in a machine policy:
Personal data can be accessed by the data subject, or his/her manager, or the police with a court order.
'This server is hardened according to vendor standards for an Internet-facing system’.
Of course, that’s very different from the machine policies we see in reality, which are usually just lists of users/resources to which access is permitted or forbidden. The problem is that machine policies are infrastructure oriented, not business oriented.
Why does this matter?
Machine policies are very difficult to set correctly, and very difficult to check.
It’s difficult to demonstrate that your machine policies are right.
When the environment changes (new threats, new laws, mergers and demergers), it’s very difficult to keep the machine policies in step.
As more business process are accessible over the Internet, and as more security decisions are automated, inaccurate machine policies will less and less tolerable.
There’s another issue with security policies, and it relates to how they are governed. Most organisations like to think that they operate top down, and that the senior management can force their policies on their employees and partners as they please. In reality, this is not practical, or even legal. In the world of intellectual property, nothing is owned; everything is licensed, with many stakeholders having complex and hard-to-define rights to ‘organisational’ information.
Think of the HR database, with all its personal information that really belongs to the employees. Increasingly, information stakeholders are coming out of the woodwork and pushing the government for legislation to protect their rights. How is the fragmented world of machine policies going to cope with this?
So, here’s what I think users (and vendors) need to move towards:
Most organisations don’t develop their own CPU chips, and they shouldn’t try to develop their own machine policies. Machine policies should be developed by specialised groups as a central service.
Machine policies need to be expressed in rich languages that can take account of real-world business relationships.
Organisations need to allow information stakeholders to influence their machine policies so that their legitimate interests are taken into account.
Most organisations are a million miles from being able to do this, but the technology isn’t that far off at all. New standards like XACML (eXtensible Access Control Markup Language) make all this very possible. Interesting times lie ahead.
Author: John Arnold, Jericho Forum board member