OxCERT's blog

In July 2012 the University Council officially approved a new information security policy but what does this mean in practical terms?  Well, for a start, it means that each University department must formulate their own information security policy and it is the responsibility of the head of department to make sure this happens.  So, what is an information security policy anyway and why do departments need their own?

Different goals

It’s not just to make work for people, that is for sure, and the infosec team are here to help with any questions and (where possible) practical advice.  Of course resources are an issue which is why we’re putting our guidance and helpful tools into an information security toolkit.  This is currently being re-drafted and converted to fit the new IT Services web pages but in the meantime you can find it via the OUCS site.  There is, of course, a simple reason why each department should have its own policy and that is that one size does not fit all.  It would be great to be able to write one “policy” that tells every member of the University what they need to do to be “secure”, but the fact is that that just doesn’t work – especially in an environment as devolved and diverse as the University of Oxford.  That is because each department (or equivalent) has their own management structure, their own operational goals and objectives and hence their own security requirements.  Information security isn’t just about locking down data and IT systems so that bad guys can’t get in.  It is about assessing assets, requirements and risk and then making informed decisions.  Requirements for confidentiality, integrity and availability will vary hugely depending on what you are doing. Confidentiality, for example, is likely to be a much higher priority for those carrying out research using patient identifiable data than it would for, say, the University’s main webpage where availability is probably the most important thing.

This brings us back to the question of what is an information security policy anyway.  Well, the terminology can be argued about (there are specific definitions of “rule”, “regulation” or “policy” within the University) but it doesn’t matter what you call it.  In this context an information security policy simply means something that is approved at the highest level of seniority within the department, that states your goals for information security, your commitment to achieving those goals and the framework within which you will manage information security.  To that end we’ve provided a very simple template to work from which can be found in the toolkit.  This may well be accompanied by other policies and procedures but this is the bare minimum that is required.

What is the point of that you may ask?  Well for any information security programme to be effective and successful you need to know what it is you are trying to achieve and have a plan for how you are going to achieve it.  Visible support from senior management is essential as is officially identifying roles and responsibilities.  Ultimately information security is about measuring risk and making informed decisions so it is important to know who is responsible for making those decisions.  And that is why having a local policy is important.  It provides the framework from which everything else will happen and defines where the buck stops!  What it doesn’t do is tell you how those objectives will be met and, although the further down the hierarchy you go the closer to methodology you get, I prefer to keep policy and procedure separate.  That might not fit all departments and examples of staff “procedures” will be provided via the toolkit shortly.  However, I find that assigning responsibility for writing and authorising procedures to meet the policy means that you can have a concise and robust policy that will not need to be frequently changed, and procedures that can be altered, added to or scrapped as the threat landscape and technologies change.

Speed limit policy

One of the main arguments I hear against this approach is that you can’t have a policy in place that you can’t enforce .  I can see why people say this and understand what they mean.   But I don’t think it is necessarily true.  Certainly policies may be less effective if you can’t actively enforce them but, to me, a security policy is simply a security control like any other.  It is just one layer of the onion.  Regardless of where you are in terms of being able to actively monitor and enforce policy, without knowing what you are trying achieve how will you ever get there?  A policy that is communicated to all makes people aware of their responsibilities and also that there may be a consequence to their actions.  Take speed limits on motorways for example.  Everyone knows the limit is 70 mph but that it is impossible for the police to enforce this for every road user.  But does that mean that we shouldn’t have speed limits?  No.  Instead some road users stick to the limit anyway (or at least to a speed they don’t think they’ll be punished for doing)  and the police implement other controls to encourage people to comply varying from speed traps to cardboard cutouts of police cars.  Everyone who uses the roads however is aware of the legal limit, is aware that there is a consequence of breaking the limit, and that the consequence may be worse if the impact of you speeding is worse (e.g. you have an accident).

Security policies are no different.  Start with the policy which says where you want to be and build your other controls and practices around that to help give you assurance that you are doing the right things.  Some things will be more of a priority and will require more assurance than others.  However just because a “keep out” sign and a lock might be better doesn’t mean that a “keep out” sign on its own is pointless.