Akimbo’s Good Policy Guide

Writing IT Security Policies is a dull, but unfortunately critically important aspect of working in Cybersecurity. Our Governance Risk and Compliance brothers and sisters do not get enough respect for how much effort it takes to produce a useful and effective policy – and the truth is many of them don’t get read as often as they should. It’s also true, that a lot of policies are not well written.

In this article I want to give some generic guidance on what policies should contain and how they should be written, then we’ll give a couple of “deep dives” into specific policy considerations for things like Acceptable Use and AI tooling.

Version Control

Every policy document should have a version control table. This table should include the history of changes to the document. You should also consider how you clearly convey when a policy is in draft state and when it is ratified. You should also consider how you clearly convey when a document has been reviewed.

Some organisations choose to increment the version number on each review and have the change description set to “Document Reviewed”. That works, since it’s easy to check when the last document was reviewed and determine when it’s next due for a review. However, a lot of policies don’t change that often so, it’s not unusual for a review to result in no changes to the document – and yet the version number is incremented. This is okay, but an alternative approach is to have a table to track changes and a table to track reviews. That way, it’s more obvious when a review resulted in no changes to the document.

I often find documents with a wild selection of version numbers too. An approach that I recommend is to use minor numbers to show a draft version and major numbers to show ratification. For example, 2.3 would be the third draft version as it is passed around the reviewers, once it is accepted as complete it would become version 3.0.

For the version control table, you should at least include the following columns: version, date, author. A lot of policies also include a “Description” column to indicate what was changed in the document, but more often than not I find this column contains little more than “Amendments” – so it really adds little value. If you’ve decided on a different approach to managing reviews that the major/minor version number idea given above, then this column could indicate whether it was an amendment or a review version, which is better than nothing. In general, if a change description column is to be included, it should include more than a single word to describe the changes that were made.

Document Ownership

You should also consider having a clearly stated document ‘owner’. This is given generally to a specific role, rather than a person (to avoid having to amend the policy if a staff member leaves). The benefit of this is that it designates the person who is responsible for maintaining and updating the policy and gives a specific point of contact should someone have questions or issues with the policy.

Purpose

The benefit of including a ‘purpose’ section is to increase understanding and engagement by staff members. A lot of people out there have an easier time following rules if they understand why the rule exists. The purpose section can be beneficial in encouraging staff members to follow the policy as it allows you to clearly establish why it exists. The purpose doesn’t have to be legal or regulatory based, it could be simply to assist in achieving business goals or some moral good (such as minimising impact on the environment).

Additionally, a policy document should clearly state the potential outcomes for violating that policy. This should be stated early in the document, ideally in the purpose or scope section.

The purpose of this Acceptable Use Policy is to outline the appropriate use of company IT Assets in order to protect company systems and data from misuse, and to protect users from security risks. This is to ensure compliance with legal and regulatory requirements. Violation of this policy may result in disciplinary action, up to and including termination.

Scope

The scope section is generally “Who does this document apply to?” and it should clearly define which people the document relates to. For example, does it only apply to full time employees, or does it also apply to contractors?

However, in some instances (such as an Acceptable Use Policy) it should also clearly state the equipment,environments and situations it applies to. For example, does the policy only apply to company-issued laptops and desktops, or does it also apply to company-issued mobile phones?

This policy applies to all individuals who have access to the organisation’s IT systems, assets, or data. This includes employees (permanent, temporary, and part-time), as well as contractors, agency workers, interns, and volunteers.

The Policy Itself

The main body of the policy will of course vary greatly depending on whether you’re writing an Acceptable Use Policy, an Asset Management Policy, or any number of other options. However, there’s still some general guidance to follow.

The first thing is to be very clear with terms like “must”, “should”, and “can”. Many aspects of policy documents are trying to mandate things from people, in those instances you should use a clear term to show that it is a requirement, such as “must” or “shall”. Using “should” in these sentences may give the impression that the requirement is optional.

It is thought that the average person would interpret these statements as:

• Must – this is mandatory.
• Should – this is recommended.
• Can – this is optional.

There is a very important distinction between “User must not share passwords” and “Users should not share passwords”. The first is likely understood to mean that it is against the rules to share passwords under any circumstances, whereas the latter is likely understood to mean that they generally should not share passwords but may be allowed to under some unspecified circumstances.

Whilst we’re talking about terminology, it’s also important to understand that policies set the guidelines and rules, therefore they should be prescriptive not descriptive. For example:

“A review of user account privileges is performed once per year.”

The above statement isn’t useful within a policy because it simply describes previous actions but does not mandate what must be done. A better statement would be:

“A user account privilege review must be conducted at least annually.”

(It’s probably also a good idea to have a process document that states how those reviews are conducted and some templates to allow you to document when they were conducted and any pertinent findings)

Regulatory and Compliance Terms

If you follow all of this guidance the result may be a very terse and to the point policy full of “musts” and “must nots”. In many cases, this is appropriate since policies set rules. However, there is no problem in doubling back on your work and trying to write it in a more friendly and “plain English” way. However, be very careful with trying to simplify regulatory or compliance requirements. It’s very common that we come across policy documents that contains requirements that original in regulation (such as the requirements laid out in GDPR for example) that have been “simplified” to the point that they are no longer accurate.

 Terms such as “Special Category Data” and “Criminal Offence Data” are often seen thrown in together for example, although the requirements of handling these types of data do differ in some ways.

Also seen are “simple definitions” given within policy documents that are incomplete. For example, consider the following:

“Under GDPR, Special Category Data is a type of personal data that is more sensitive and needs extra protection. This includes information about a person’s health, race, religion, political views, genetics, biometrics, sex life, or sexual orientation.”

On the face of it, this seems like a decent “plain English” definition. Although some people might argue that “race” doesn’t cover the actual requirement, which is “race or ethnic origin” and “religion” doesn’t entirely cover the requirement which states “religious or philosophical beliefs”. However, potentially more importantly, this definition does not include anything regarding trade union membership. Personal data revealing trade union membership is Special Category Data. In attempting to simplify the definition this was entirely missed!

I’m not saying don’t try to use plain English, or to simplify complex legal terms into language everyone can understand – I’m just saying be very careful that what you wrote accurately and fully represents the actual requirements.

Ambiguity

Whilst writing in plain English is an acceptable goal, one should also be on the lookout for policy terms that are vague or ambiguous. A common term that encountered in policies is “regularly” which can mean frequently, but it can also mean at uniform intervals. For example, consider the following statement:

“Security updates must be installed regularly.”

The problem is, if all security updates are installed once per year, every year, then this is installing them regularly (as they are being installed at a defined interval). However, no doubt the author of that statement intended something very different. Perhaps their intention was something more like:

“Security updates must be installed no later than 14 days after release.”

Whilst we’re talking about security updates if your policy on security updates is covered in its entirety in 11 words (like the statement above), you should probably revisit it. If there was a new security update released today, which was to address a vulnerability that is actively being exploited by threat groups that are known to target organisations like yours…would you want the team to wait 14 days before installing it?

If not, then that statement above is incomplete, and you should probably add a little more detail on how the organisation should prioritise the installation of security updates. Perhaps it should take into account variables such as severity and likelihood of exploitation. Microsoft certainly publishes this information for their security updates, your update policy should probably take that information into account.

Exceptions

No matter how hard we try, there will always be exceptions. There are two ways to handle policy exceptions, the first is to try to make the policy cover all current requirements of the business and the other is to make a policy which applies well to most situations and have documented exceptions for the edge cases.

The important part here is documented exceptions. If you are unable to handle all edge cases within your policy then exceptions are perfectly acceptable, but you should make the process for requesting policy exceptions clear. This should include who is authorised to grant exceptions, the frequency in which those exceptions should be reviewed, and that all exceptions must be in writing.

A silly example of this: a company was once encountered that had the following statement in their Password Policy:

• Passwords must not contain an emoji

In discussion, the IT team revealed  they had a system which crashed if the user used a password with an emoji in it, but the problem was no one could remember which system it was…nor did they know if it was still in use.

My point is not that you should ban emoji from passwords, it’s that writing a policy to cover all possible edge cases may be difficult, and as such you should have a good process for handling and reviewing exceptions.

Violations

You should also consider having a clear statement on how people should approach policy violations. Whilst it’s likely that your main IT Security Policy states that staff members must report security incidents immediately, it might not be clear to staff that includes policy violations – so consider having a statement in there that violations should be reported, and to whom.

Policy Classifications

Once you’ve put all of your policy documents together, it’s worth reviewing their classification level. I see an awful lot of companies that mark all policies as confidential, when in actuality there’s little within them which truly requires the protections offered at that level. A lower classification will allow these documents to be shared more easily, which will simplify some processes such as completing supplier security requirements and onboarding new staff members. Whilst I understand the hesitancy in sharing information about how systems are secured, building systems that are secure even if the attacker is able to fully review your policies is more effective.

Hopefully that provides a good overview of common issues we find in policies, if you’re trying to put new policy documents together and finding it tough, or if you need a hand reviewing your existing documentation and tightening it up – we’re here to help.