ISO 27001 & BS 25999

It’s been six years since the last revision of ISO/IEC 27002 (in 2005) – much has changed in information security since then, and this standard definitely needs some “facelifting”. Since ISO 27002 is closely tied to ISO 27001, this revision has to be done simultaneously for both standards, and is expected to happen in the latter half of 2012 or during 2013.

ISO 27001 and ISO 27002

What these two standards have in common are the 133 controls – they are offered as a kind of catalogue in Annex A of ISO 27001, with the idea that appropriate controls are selected based on the risk assessment. ISO 27002 lists all of these 133 controls again, but offers detailed explanation of best practices for their implementation. For a detailed explanation of the differences between ISO 27001 and ISO 27002, read ISO 27001 vs ISO 27002.

This relationship between the two standards is why ISO 27002 has changed its name in 2007 – it was previously called ISO/IEC 17799, but its name was changed to ISO/IEC 27002, making it part of ISO 27k series.

This most important link between ISO 27001 and ISO 27002 – identical structure of ISO 27001 Annex A and ISO 27002 controls – will most likely still be included in new revisions of both standards. However, the way it is structured and the individual controls will most probably change.

Expected changes

At the moment of writing this article (October 2011) it is impossible to predict all the changes in ISO 27002 because the final draft hasn’t been written yet. However, most likely changes can be judged by hearing what ISO 27001 experts have to say – here’s a summary of suggestions from ISO 27k Forum, the leading expert forum about ISO 27001/ISO 27002:

• Accountability – definition of what it means in relation to human resources management
• Authentication, identity management, identity theft – they need better description because of their criticality for web-based services
• Cloud computing – this model is becoming more and more dominant in real life, but hasn’t been covered in the standard
• Database security – the technical aspects haven’t been systematically laid down in the existing revision
• Ethics and trust – an important concept not covered at all in the existing revision
• Fraud, phishing, hacking, social engineering – these particular types of threats are gaining more and more importance, but aren’t covered systematically in the existing revision
• Governance of information – this concept is very important for the organizational aspect of information security and is not covered in the current revision
• IT auditing – needs to focus more on computer auditing
• Privacy – needs to go broader than existing data protection and legal compliance, especially because of cloud computing
• Resilience – this concept is completely missing in the existing revision
• Security testing, application testing, vulnerability assessments, pen tests etc. – these are essentially missing in the current revision

As Gary Hinson from the ISO27k Forum argues, several of these issues are already covered, but they were not given sufficient emphasis in the current revision of the standard – key terms widely used today are either completely missing or are only vaguely alluded to.

Also, the new ISO 27002 will refer more on other standards that define certain areas in more detail – for instance, Section 14 Business Continuity Management will refer to ISO 22301 (new standard dedicated to business continuity management) and ISO/IEC 27031 (focused on ICT aspect of business continuity).

All these changes mean that not only some of the controls will change or will be added, but it also means that the structure of the standard will change – instead of existing 11 sections of Annex A / ISO 27002, some new sections will probably have to be created, and others merged. And these structural issues are probably the toughest ones since the body in charge of the revision (JTC 1/SC 27 committee) will need to ensure compatibility with the existing revision. This is why we have no idea at the moment what these structural changes will look like.

ISO 27002 certification?

Many people still ask me whether it is possible to get certified against ISO 27002. The situation with the new revision will stay the same – currently it is not possible, nor will it be possible to get an ISO 27002 certificate because unlike ISO 27001, this is not a management standard.

This means ISO 27002 will remain a code of practice (or best practices) for implementation of security controls. It will not define the management system – e.g. the documentation management, internal audit, management review, corrective and preventive actions, risk management, etc.  – all these remain in the domain of ISO 27001. Therefore, ISO 27001 will remain the only certifiable standard in the ISO 27k series.

Implications for the ISMS

If you already have your Information Security Management System implemented, you don’t have to worry too much – no matter which changes the new revision will bring, you will have enough time (normally one year after both standards have been published) to implement the changes.

Once the revisions are published, you will need to align the structure of your controls in the Statement of Applicability with the new Annex A in the revised ISO 27001. And although the structure won’t change too much, this alignment will be the biggest job that’s ahead of you.

And this is where the new ISO 27002 will bring the most value – in the transition period you will have plenty of refreshed best practices to choose from. And since ISO 27002 is quite detailed, and you still have the freedom to choose only the appropriate stuff for your organization, it will definitely help you make such transition easier.

You probably knew that the first step in ISO 27001 implementation is defining the scope. What you probably didn’t know is that this step, although simple at first glance, can sometimes cause you quite a lot of trouble. Namely, a lot of companies are trying to decrease their implementation costs by narrowing the scope, but they often find themselves in a situation where such a scope gives them a headache.

So, where is the problem?

The problem when the ISO 27001 scope is not the whole organization is that the Information Security Management System (ISMS) must have interfaces to the “outside” world – in that context, the outside world are not only the clients, partners, suppliers etc., but also the organization’s departments that are not within the scope. It may seem funny, but a department which is not within the scope should be treated in the same way as an external supplier.

For instance, if you choose that only your IT department is within your scope, and this department is using the services of the purchasing department, the IT department should perform risk assessment of your purchasing department to identify if there are any risks for the information for which the IT department is responsible; moreover, those two departments should sign terms and conditions for the services provided.

Why is such an overhead necessary? You have to put yourself in the certification body’s shoes – it must certify that within your scope you are able to handle the information in a secure way, while it cannot check any of your departments outside the scope. The only way to handle such a situation is to treat such departments as if they were external companies. (Please note: certification auditors never like a narrow scope.)

This is not where the trouble stops. Sometimes, a narrow scope is simply not possible, because there is no interface with the outside world. For instance, if employees from both within the scope and outside the scope are sitting in the same room, such a scope is hardly feasible; if both the employees within and outside the scope use the same local network (with no segregation) and have the access to various network services, such a scope is definitely not possible – there is no way you would be able to control the information flow only inside the scope.

The point here is – narrowing your ISMS scope is sometimes impossible, and in most cases it will bring you unnecessary overhead. Therefore, what initially didn’t seem like a good solution, might be the optimal one after all – try to extend your scope to the whole organization. The rule of the thumb is: if your organization has no more than a few hundred employees, and one or just a few locations, the best thing would be for the ISMS to cover the whole organization.

On the other hand, if you really cannot cover the whole organization with your ISMS scope, try to set it in an organizational unit which is sufficiently independent; try to solve the relationships with other organizational units outside the scope by determining their service through internal documents (policies, procedures etc.) that would serve as “agreements” – in such a way you could document those organizational unit’s obligations in a manner that is usable in daily operations.

There you go – you have solved the first step in your ISO 27001 implementation.

Quite often I see information security policies written in too much detail, trying to cover everything from strategic objectives to how many numerical digits a password should contain. The only problem with such policies is that they contain 50 or more pages, and – no one is really taking them seriously. They usually end up serving as artificial documents whose sole purpose is to satisfy the auditor.

But why are such policies extremely difficult to implement? Because they are too ambitious – they try to cover too many issues, and are intended for a wide circle of people.

This is why ISO 27001, the leading information security standard, defines different levels of information security policies:

• High-level policies, such as the Information Security Management System Policy – such high level policies usually define strategic intention, objectives etc.
• Detailed policies – this kind of policy usually describes a selected area of information security in more detail, with precise responsibilities, etc.

ISO 27001 requires that Information Security Management System (ISMS) Policy, as the highest-ranking document contains the following: the framework for setting objectives, taking into account various requirements and obligations, aligns with the organization’s strategic risk management context, and establishes risk evaluation criteria. Such a policy should be actually very short (maybe one or two pages) because it’s main purpose is for top management to be able to control their ISMS.

On the other hand, detailed policies should be intended for operational use, and focused on a narrower field of security activities. Examples of such policies are: Classification policy, Policy on acceptable use of information assets, Backup policy, Access control policy, Password policy, Clear desk and clear screen policy, Policy on use of network services, Policy for mobile computing, Policy on the use of cryptographic controls, etc. Note: ISO 27001 does not require all these policies to be implemented and/or documented, because the decision whether such controls are applicable, and to what extent, depends on the results of risk assessment.

Because such policies should prescribe more details, they are usually longer – up to ten pages. If they were much longer than that, it would be very difficult to implement and maintain them.

In other words, information security is too complex an issue to be defined in a single policy – for different aspects of ISMS and different “target groups” there should be different policies. Middle-sized organizations usually build up to fifteen policies for their ISMS.

One could argue that this number of policies is nothing but overhead for a company. I would certainly agree if such policies are written only with the certification audit in mind – such policies will bring nothing but more bureaucracy. However, if a policy is written with the intention of decreasing the risks, then it will most probably show its value – if not right away, then probably in two or three years, by decreasing the number of incidents.

If this is the first time you have come across the notion of internal auditor, you are probably puzzled – Why would I need another control? Who is going to pay for it? Who should I employ to do it? It is such a waste of time…

Well, it doesn’t have to be so bad – besides complying with ISO 27001 & BS 25999-2 standards, internal audits could be quite useful for your other business affairs (whether related to information security & business continuity or not).

The point with internal audits is that they should discover problems that would otherwise stay hidden and would therefore harm the business. Let’s be realistic – it is human to make mistakes, so it‘s impossible to have a system with no mistakes; it is however possible to have a system which improves itself and learns from its mistakes. Internal audits are a crucial part of such a system.

There are a few ways to perform internal audit:

a) Employ a full time internal auditor – this is suitable only for larger organizations who would have enough work for such a person (some types of organizations – e.g. banks – are obliged by law to employ such functions)

b) Employ part time internal auditors – this is the most common situation – the organizations use their own employees to perform internal audits alongside their regular job functions. One important thing to pay attention to: in order to avoid conflict of interest (the auditors cannot audit their own work), there should be at least two internal auditors so that one could audit the regular job of the other.

c) Employ internal auditor from outside of the organization – although this is not a person employed in the organization, it is still considered internal audit because the audit is performed by the organization itself, according to its own rules. Usually this is done by a person who is knowledgeable in this field (independent consultant etc.).

However, from my experience as an auditor, the sad truth is that most of the organizations perform internal audits just to satisfy the certification body. The result of such internal audits are a few non-conformities which do not get deep into the real problems of information security management system (ISMS) or business continuity management system (BCMS). This is a waste of time – if the companies have invested time of their internal auditors to perform such jobs, they should gain some benefits out of it.

But how then to approach internal audits in the right way – here are some thoughts:

1. The management should view the internal audit as one of the best tools to improve the system, not only as a means to get certified.
2. The internal auditor should be qualified – this means he/she must have experience in information security, information technology and auditing techniques. It does not mean that the auditor must be an expert in those fields.
3. The internal audit should be performed in a positive way – the aim should be to improve your system, not to blame the employees for their mistakes.

On the positive side, as a certification auditor I did see some organizations performing internal audits in a right way. Although their employees did feel a little uncomfortable about someone checking their activities, very soon they saw the benefits of such approach – problems became transparent, and were resolved rather soon.

You have been implementing ISO 27001 for quite a long time, invested quite a lot in education, consultancy and implementation of various controls. Now comes the auditor from a certification body – will you pass the certification?

This kind of anxiety is normal – you can never know whether your ISMS (information security management system) has everything the certification body is asking for. But what is it exactly the auditor will be looking for?

First, the auditor will perform the Stage 1 audit, also called the “Document review” – in this audit, the auditor will look for the documented scope, ISMS policy and objectives, description of the risk assessment methodology, Risk Assessment Report, Statement of Applicability, Risk Treatment Plan, procedures for document control, corrective and preventive actions, and for internal audit. You will also have to document some of the controls from Annex A (only if you found them applicable in the Statement of Applicability) – inventory of assets (A.7.1.1), acceptable use of assets (A.7.1.3), roles and responsibilities of employees, contractors and third party users (A.8.1.1), terms and conditions of employment (A.8.1.3), procedures for the operation of information processing facilities (A.10.1.1), access control policy (A.11.1.1), and identification of applicable legislation (A.15.1.1). Also, you will need records of at least one internal audit and management review.

If any of these elements are missing, this means that you are not ready for Stage 2 audit. Of course, you could have many more documents if you find it necessary – the above list is the minimum requirement.

Stage 2 audit is also called the “Main audit”, and it usually follows a few weeks after Stage 1 audit. In this audit the focus will not be on the documentation, but if your organization is really doing what your documentation and ISO 27001 say you have to do. In other words, the auditor will check whether your ISMS has really materialized in your organization, or is it only a dead letter. The auditor will check this through observation, interviewing your employees, but mainly by checking your records. The mandatory records include education, training, skills, experience and qualifications (5.2.2), internal audit (6), management review (7.1), corrective (8.2) and preventive (8.3) actions; however, the auditor will be expecting to see many more records as a result of carrying out your procedures.

Please, be careful here – any experienced auditor will notice right away if any part of your ISMS is artificial, and is being made for the purpose of audit only.

OK, you knew all this, but it still happened – the auditor found major non-conformity and told you that ISO 27001 certificate will not be issued. Is this the end of the world?

Certainly not. The process goes like this – the auditor will state the findings (including the major non-conformity) in the audit report, and give you the deadline until which the non-conformity must be resolved (usually 90 days). Your job is to take appropriate corrective action; but you have to be careful – this action must resolve the cause of the non-conformity, otherwise the auditor might not accept what you have done. Once you are sure the right action is taken, you have to notify the auditor and send him/her the evidence of what you have done. In the majority of cases, if you have done your job thoroughly, the auditor will accept your corrective action and activate the process of issuing the certificate.

There you go – it took some time, but now you are a proud owner of the ISO/IEC 27001 certificate. (Be careful though – the certificate is valid for three years only, and can be suspended during that period if the certification body identifies another major non-conformity on the surveillance visits.)