Information security within organisations has to date, largely been driven by reactions to immediate, impending threats; breaches and other incidents. Other drivers can come from managers or executives beginning to understand the importance of information security but often only reacting tactically to perceived and / or “marketed” threats. The problem with these is the net negative operational impact they have on the organisation’s information asset environment. Individual issues get targeted rather than broad-spectrum mitigations with a better return on investment.

Indeed, the greatest preventer of strategic security outcomes within organisations is often executives and senior managers who have developed enthusiasms as a result of specific security incidents or as victims of well targeted marketing campaigns.

Information Technology solutions deployed within organisations have been notorious for not being driven by genuine operational needs. They are commonly deployed because a manager or executives are externally focused by something someone else is using, or something they were “sold”. This leads to a highly fractured solution set creating performance and usability issues for the rest of the “non-I.T.” business. Where this is the case for general I.T. it is orders of magnitude worse in the case of I.T. security solutions.

Any member of an organisation more than 10 years old need only look as far as their workstation IP address to see the legacy of this ad-hoc approach. They would see an IP address that is a legacy of the organisation deciding some time ago that it “needed” to connect two workstations to a shared printer, yet now causes numerous issues when attempting virtual private networking with business partners that happen to be using the same IP address ranges.

IT security solutions and / or services are normally selected due to a legitimate business need. The need is most often determined not by the business as a strategic decision, but instead is determined by well intentioned managers acting in the best interests of the organisation; commonly with little understanding of the strategic requirements of the organisation. This immediately raises the question, “why don’t the well intentioned managers understand the strategic requirements of the organisation?”

When a manager, or staff member, seeks strategic direction for the definition of any requirements there are only two places they can go. The manager can either refer to an executive for specific instruction, however this just shifts the ad-hoc decision making to the executive level, or they can seek instruction from organisational policy. If the manager is able to locate documented policy that articulates strategic requirements they are then faced with the prospect of determining what that policy is saying. This, in particular, is often where strategic direction for security falls down severely. If the organisation has a security policy at all it is often poorly written, poorly thought out and the manager is unable to practically comply with it due to its operational impacts.

Before discussing what common mistakes within security policies cause a complete breakdown in strategic direction for security and their consequences it is important to clearly articulate what a policy is and what a policy is not. A policy, whether for information security or any other matter, is a statement of requirements that the organisation has. A policy is not a document that articulates how those requirements are to be met and in fact should be mechanism agnostic.

A good, real world, example of policy is government legislation, such as road laws. Road laws, as described in government legislation, describes requirements that must be complied with, but does not articulate how those requirements are to be adhered to. For example, road laws (in Australia) mandate that when approaching an intersection with a traffic light any vehicle (car, truck, bus, bicycle, etc...) must stop if the traffic light is showing red and must wait until the light is showing green before proceeding. What the legislation, or policy, does not say is how that law is to be complied with, as long as you comply you can achieve it in any manner that complies with all laws. Organisational policy should be the same.

This brings us to the first critical error that is commonly made in defining IT security policies that render them practically non-implementable; blending policy, process and procedure.

Mistake #1 – Blending policy, process and procedure

By blending process and / or procedure elements in to policy, the organisation either becomes locked in to particular requirement solutions or is compelled to deliberately breach the policy requirements.

An example of this can be seen in a security policy recently reviewed by IPSec. The policy document was dealing with the issue of patch management and stated:

Windows patch management tools will be utilised to automatically download the latest Microsoft security patches. The patches will be reviewed and applied as appropriate.

Many IT workers would look at this statement and consider it to be entirely appropriate; however there are questions that arise as a result of this requirement:

1. What if the organisation doesn’t currently use Windows or currently has non-Windows systems?
2. What if the organisation wanted to start using non-Windows machines in the future?

The consequence of this requirement is that the organisation has no policy for patching non-Windows machines. This means the organisation’s IT staff have to just make it up as they go, or as soon as the organisation deploys non-Windows machines (e.g. VMWare vSphere virtualisation software) they have to amend the policy, and all that that should entail.

Describing how requirements are to be complied with within the policy itself condemns the organisation’s staff to ignoring the policy, and / or continually having to adjust the policy to the new environment.

Well written policy should not be impacted in any way by the mechanisms of compliance. When new solutions or methodologies are introduced it should not be necessary to adjust existing policy let alone write new policy.

Mistake #2 – Aligning policy to compliance requirements not operational practices

Many organisations find themselves creating security (or other) policies due to compliance requirements dictated by regulatory bodies, such as APRA or PCI-DSS, or by customers, such as AS/NZS 27001. When organisations find themselves tackling policy under such circumstances it means their principal motivation is to achieve the requirements dictated to them, with little time available to consider the broader strategic impacts that this may have.

When considering a policy set aligned closely to a compliance requirement, rather than being aligned to operational requirements, it is appropriate to consider scenarios to determine how successful the policy will be for the organisation. A good example would be to consider the average user's Contacts database associated with the organisation's email system.

When considering the impact of a prospective policy structure on the organisation by role-playing the impact on a user's Contacts database it is appropriate to consider all of the places that the Contacts database is used, and how the Contacts database gets to a location from which it can be used. A fairly standard (in today's business environment) set of uses for the average person's Contacts database may include email and mobile phone; it may also include a VoIP handset.

The ability to use the Contacts database for sending emails requires that it is available where ever email may be written from. Hence the Contacts database must be available on the staff member's workstation, smart phone, tablet computer, email server for web based access, and anywhere else they may type emails.

The ability to use the Contacts database for mobile or VoIP telephony also requires that the contacts list is located on the staff member's mobile phone, desktop phone and VoIP server.

When considering the alignment of policies to compliance requirements and how this impacts achieving policy compliance with a user's Contacts database, we find that it is now a requirement that at any point in time the use of the Contacts database requires compliance with multiple policy elements at the same time. Additionally we find ourselves in the circumstance that if the author of the compliance requirements changes those requirements, the Contacts database may suddenly be required to comply with an entirely new set of requirements; and with little relationship to existing policies.

When assessing the use of the Contacts database against a commonly available standards compliant policy set, we find that the user's Contacts database, and the user's use of that Contacts database, must comply with no less than 13 policy elements. For example:

• Telecommuting and Mobile Computer Security Policy
• External Communications Security Policy
• Personal Computer Security Policy
• Electronic Mail Policy
• Computer Network Security Policy
• Internet Security Policy for User
• Intranet Security Policy
• Privacy Policy - Stringent
• Privacy Policy - Lenient
• Data Classification Policy
• External Party Information Disclosure Policy
• Information Ownership Policy
• Email Security Including Phishing
• And many others

One widely used security policy template set states that it has "1400 pre-written information security policies covering over 200 security topics". Even if only 10% of these had to be complied with it would be 140 policies to be complied with just to the Contacts database.

The simple fact is that organisations do not exist or operate to comply with particular regulatory requirements. Organisations exist to deliver services or goods to their customers, and from time to time they have compliance requirements to achieve. This means that policy sets should be closely aligned to the operational practices of the organisation. They should also be universally applicable, rather than chasing a particular standard that is dictated by others.

When applying the example of the Contacts database to a well structured security policy set the user's Contacts database, and the user's use of the Contacts database, will need to comply with policy elements based on the action they are performing. For example the following policies would require compliance:

• Asset Acquisition - When the user is acquiring a new Contacts database or new contact to enter in to the database.
• Asset Disposal - When the user is deleting an old Contacts database or deleting a contact from the database.
• Exchange and Transportation - When the user is transporting the Contacts database. Whether it is being transported on a mobile phone, a laptop computer or a tablet computer the requirements are the same.
• Change Control - When the user is changing the Contacts database. The requirements for change control on a Contacts database would be kept very low by ensuring an appropriate classification of the level of importance that specific Contacts database has to the organisation.
• Access Control - When the user is accessing the Contacts database. As with change control the requirements are set according to how important that individual Contacts database is. Also, as with the exchange and transportation requirements, requirements for access control are consistent no matter where the Contacts database is used.
• Storage - Impacting any device upon which the Contacts database is stored, in the same manner for all locations.

Rather than having to comply with potentially hundreds of policy elements for a single organisational asset, a well structured policy set will ensure a minimum number of consistent policies that are universally applicable. This should be regardless of asset, technology, medium, operational use, or compliance requirement, and that is able to remain consistent regardless of changes to any of those.

Whilst a well written policy set must be able to demonstrate compliance with governance, regulatory or standards requirements, it should not be so closely structured as to potentially impede the organisation's staff's ability to comply with the policy requirements.

Mistake #3 – Cut-and-Pasting standards elements

Achieving the requirements of standards through policy requires that the policy author understands the role of standards and how to appropriately use them. Standards are guidance documents intended to create a common language amongst industry professionals. They seek to allow complying organisations to achieve a pre-defined level of service or product specification, and / or design, to ensure products, services and systems are safe, reliable and perform in a consistent manner in a way intended by the organisation. Standards are not items of legislation mandated by a government; they are freely interpretable by implementing organisations that allow the organisation to achieve compliance in any manner they see fit.

When a policy author does not understand the role standards play, and is being pressured to rapidly develop policies that comply with those standards, they can become tempted to use the parameters defined by the standard directly. To create the required organisational policy the tasked staff member will run through the list of standards requirements, and will derive a policy line-item per standard element; for example:

AS/NZS 17799:2006 requirement 11.3.1 for “Password use” requires:

Control

Users should be required to follow good security practices in the selection and use of passwords.

Implementation guidance

All users should be advised to:

1. Keep passwords confidential;
2. Avoid keeping a record (e.g. paper, software file or hand-held device) of passwords, unless this can be stored securely and the method of storing has been approved;
3. Change passwords whenever there is any indication of possible system or password compromise;

4. Select quality passwords with sufficient minimum length which are:

   1. Easy to remember;
   2. Not based on anything somebody else could easily guess or obtain using person related information, e.g. names, telephone numbers, and dates of birth, etc.;
   3. Not vulnerable to dictionary attacks (i.e. do not consist of words included in dictionaries);
   4. Free of consecutive identical, all-numeric or all-alphabetical characters;
5. Change passwords at regular intervals or based on the number of accesses (passwords for privileged accounts should be changed more frequently than normal passwords), and avoid re-using or cycling old passwords;
6. Change temporary passwords at the first log-on;
7. Not include passwords in any automated log-on process, e.g. stored in a macro or function key;
8. Not share individual user passwords;
9. Not use the same password for business and non-business purposes.

If users need access to multiple services, systems or platforms, and are required to maintain multiple separate passwords, they should be advised that they may use a single, quality password (see d) above)(sic) for all services where the user is assured that a reasonable level of protection has been established for the storage of the password within teach service, system or platform.

Other information

Management of the help desk system dealing with lost or forgotten passwords needs (sic) special care as this may also be a means of attach to the password system.

A bad creation of policy that is using cut-and-paste from the standard to derive organisation policies would then result in a policy similar to:

ACME Security Policy for Password Use

ACME users are required to follow good security practices in the selection and use of passwords.

The ACME users shall:

1. Keep passwords confidential;
2. Avoid keeping a record (e.g. paper, software file or hand-held device) of passwords, unless this can be stored securely and the method of storing has been approved;
3. Change passwords whenever there is any indication of possible system or password compromise;

4. Select quality passwords with sufficient minimum length which are:

   1. Easy to remember;
   2. Not based on anything somebody else could easily guess or obtain using person related information, e.g. names, telephone numbers, and dates of birth, etc.;
   3. Not vulnerable to dictionary attacks (i.e. do not consist of words included in dictionaries);
   4. Free of consecutive identical, all-numeric or all-alphabetical characters;
5. Change passwords at regular intervals or based on the number of accesses (passwords for privileged accounts should be changed more frequently than normal passwords), and avoid re-using or cycling old passwords;
6. Change temporary passwords at the first log-on;
7. Not include passwords in any automated log-on process, e.g. stored in a macro or function key;
8. Not share individual user passwords;
9. Not use the same password for business and non-business purposes.

If users need access to multiple services, systems or platforms, and are required to maintain multiple separate passwords, they should be advised that they may use a single, quality password (see d) above)(sic) for all services where the user is assured that a reasonable level of protection has been established for the storage of the password within teach service, system or platform.

As can be seen in the above example, the policy author has taken the articulated requirements of the standard, in verbatim format, and has defined them as a requirement of the organisation.

The issue with this is that the author has not actually described any specific requirements. In relation to passwords, specifically the author has failed to:

1. Describe what “good security practices” means;
2. Describe what “confidential” means;
3. Describe what “stored securely” means;
4. Describe how an “indication of possible system or password compromise” is to be detected or managed;
5. Describe what a “minimum length” for the passwords are, and under what circumstances;
6. Describe under what circumstances password characteristics, such as character combinations, should change;

Additionally, by adopting the standard’s requirements in a verbatim style the author has tied procedural elements in to the policy set, for example:

1. Changing passwords at the first log-on;
2. Requiring passwords to not be used in macro or function keys.

By directly using the standard to define the policy, a very common mistake by inexperienced policy authors, the organisation’s staff are left with a confusing set of policy requirements. With such a policy they either can not comply with it, or have to mandate compliance requirements that materially impact their ability to operate efficiently within the organisation.

Mistake #4 – Not considering the target audience

IT Security is most often left to the organisation’s IT department. What most organisations fail to consider is that the assets being protected by the IT security policy do not belong exclusively to the IT department; they in fact belong to the whole organisation. This means that it should not be an IT Security Policy, but should be an Organisation Security Policy. Such a policy impacts all assets, environments, staff, systems and processes within the organisation regardless of their location or form (electronic or physical).

When IT staff are allowed, in isolation, to create policy for the organisation they do so from their perspective. What this most often means is that the authors of the policy have little understanding of the broader organisation, and what impact their policies could have on the efficient and profitable operation of the organisation.

Further, when IT personnel develop policy they often do so in a manner that is only focused on their environment. IT staff authoring policies will define requirements for IT personnel to comply with in delivering IT solutions to the business. As soon as an attempt is made to apply those policies to an individual, environment, asset, system or process that is not IT oriented (e.g. the reception desk) the policy is very commonly not able to be practically applied and must either be rewritten or ignored.

The largest single inhibitor, however, of good policy coming from IT departments is their lack of ability to understand how people behave in the face of policies; and how to craft policy in a manner that encourages broader staff engagement and compliance. In most cases, where an IT department has been tasked to develop an IT security policy, the policy is being authored by someone who does not interact (beyond as a technical support resource) with others within the organisation outside of IT. This means they have a potentially limited ability to understand how non-IT staff think, react or behave and often only have negative interactions with non-IT staff.

These mistakes ensure that the vast majority of information security policies in place in organisations today, or produced by 3rd parties on organisation’s behalves, have fundamental mistakes of design within them. These fundamental mistakes ensure that when policies are published and staff are required to comply with them the organisation faces significant conflicts, large operational impediments, and broad-spectrum non-compliance from the very top of the organisation to the very bottom.