ISO 27001 & ISO 22301

“Your ISO 27001 is nice in theory, but if our system administrator goes crazy, we’re dead.” – I hear this quite often when speaking to my clients about which security controls they should apply.

And it’s not only system administrators, it is also the line managers, engineers, top management, etc. – actually, anyone who has access to sensitive information or systems could be a potential threat. For instance, the biggest damage in banks is not done by robbers (with guns in their hands), but by inside jobs (with computers in their hands).

Of course, money theft is not the only purpose of these kinds of attacks – it can also be sabotage, theft of confidential corporate information, altering of data, theft of identities, etc.

Since this is such a complex issue, how can you deal with it?

Risk assessment

ISO 27001 is a standard which approaches security management mainly from the preventive point of view – the first step is to find out which incidents could happen regarding your employees (but also external partners with access to your systems), and then to choose appropriate security controls in order to avoid those incidents. In ISO 27001, this process is called risk assessment and risk treatment.

However, risk assessment shouldn’t be done superficially. If you didn’t think really hard about all the bad things that can happen, then you won’t mitigate those risks and someone could exploit those vulnerabilities.

Therefore, don’t rush through this step; do it systematically.

Preventive measures

Once you know how an insider can exploit your vulnerabilities, you can start planning your security controls in a comprehensive way. Again, ISO 27001 offers a catalogue of security controls in its Annex A – here are a few examples of the most common controls to mitigate the risk of insider threats:

• Access control (section A.11 in Annex A) – access to sensitive data can be approved on a need-to-know bases only. This way you decrease the number of people that can do harm, but also decrease the damage if someone’s identity is stolen.
• The access privileges must be regularly reviewed (control A.11.2.4) – very often quite a few employees have access to information they don’t really need.
• The accounts and access rights of former employees must be removed (A.8.3.3) – yes, sometimes there are open accounts a few years after an employee has left the company…
• Strong password policy (control A.11.2.3) or some other authentication method should be enforced to disable identity theft.
• Segregation of duties (control A.10.1.3) – you probably wouldn’t allow a single person to authorize large payments – the same goes for any other sensitive system.
• Backup (A.10.5.1) – of course, it should be regular; but also access to backup information cannot be allowed to employees who can harm your production systems the most.
• Document policies and procedures which clearly define the security roles and responsibilities (A.8.1.1; A.10.1.1) – you cannot expect your employees to observe the security rules if they don’t know what the rules are.
• Awareness & Training (A.8.2.2) – all of your employees need to know why it is necessary to protect sensitive data, as well as how to do it; for certain jobs (like monitoring logs) you may need to send your employees to special trainings.

Of course, there are other controls that are more technically oriented, like segregated network architecture (A.11.4.5), regular security patches (A.12.6.1), spyware scanning (A.12.5.4), anti-virus (A.10.4.1), firewall (A.10.6.1), physical entry controls (A.9.1.2), etc.

People issues

However, someone with high motivation and skills can bypass all of these security controls and achieve whatever agenda he or she has. Therefore, in my opinion, the most important thing is to develop some early warning indicators. And that requires a little bit more sophistication.

First of all, you need to know who you are employing – you probably wouldn’t allow some total stranger to access your sensitive data and/or systems only because he or she has a very nice diploma and a letter of recommendation. You need to dig deeper, or as ISO 27001 puts it – perform the background verification checks (A.8.1.2).

The second, and probably the most important control, is to constantly monitor what is going on – both on the “soft” side (most of the times you can observe if someone is starting to behave in a strange way) and on the “hard” side – by monitoring logs (A.10.10.2), i.e. monitoring whether there is anything suspicious in the use of information systems. Actually, the two can often be viewed together – whenever you conclude that someone’s behavior is peculiar, then this person’s logs need to be observed in more detail. And vice versa – if you spot some strange usage of information system, the soft side should be monitored more closely.

To conclude, insider threats will probably remain the biggest risk to the security of information – the complexity of information systems and amount of data will only increase this threat in time. And the best way to deal with them is to prevent them – once they happen, you can only hope they won’t go too far.

You can also check out our webinar ISO 27001 A.6 & A.8: Organization of information security; external parties; raising awareness, training and HR management (commercially sold training).

If you are starting to implement ISO 27001, you are probably looking for an easy way to implement it. Let me disappoint you: there is no easy way to do it. However, I’ll try to make your job easier – here is the list of sixteen steps you have to go through if you want to achieve ISO 27001 certification:

1. Obtain management support

This one may seem rather obvious, and it is usually not taken seriously enough. But in my experience, this is the main reason why ISO 27001 projects fail – management is not providing enough people to work on the project or not enough money. (Read Four key benefits of ISO 27001 implementation for ideas how to present the case to management.)

2. Treat it as a project

As already said, ISO 27001 implementation is a complex issue involving various activities, lots of people, lasting several months (or more than a year). If you do not define clearly what is to be done, who is going to do it and in what time frame (i.e. apply project management), you might as well never finish the job.

3. Define the scope

If you are a larger organization, it probably makes sense to implement ISO 27001 only in one part of your organization, thus significantly lowering your project risk. (Problems with defining the scope in ISO 27001)

4. Write an ISMS Policy

ISMS Policy is the highest-level document in your ISMS – it shouldn’t be very detailed, but it should define some basic issues for information security in your organization. But what is its purpose if it is not detailed? The purpose is for management to define what it wants to achieve, and how to control it. (Information security policy – how detailed should it be?)

5. Define the Risk Assessment methodology

Risk assessment is the most complex task in the ISO 27001 project – the point is to define the rules for identifying the assets, vulnerabilities, threats, impacts and likelihood, and to define the acceptable level of risk. If those rules were not clearly defined, you might find yourself in a situation where you get unusable results. (Risk assessment tips for smaller companies)

6. Perform the risk assessment & risk treatment

Here you have to implement what you defined in the previous step – it might take several months for larger organizations, so you should coordinate such an effort with great care. The point is to get a comprehensive picture of the dangers for your organization’s information.

The purpose of the risk treatment process is to decrease the risks which are not acceptable – this is usually done by planning to use the controls from Annex A.

In this step a Risk Assessment Report has to be written, which documents all the steps taken during risk assessment and risk treatment process. Also an approval of residual risks must be obtained – either as a separate document, or as part of the Statement of Applicability.

7. Write the Statement of Applicability

Once you finished your risk treatment process, you will know exactly which controls from Annex you need (there are a total of 133 controls but you probably wouldn’t need them all). The purpose of this document (frequently referred to as SoA) is to list all controls and to define which are applicable and which are not, and the reasons for such a decision, the objectives to be achieved with the controls and a description of how they are implemented.

The Statement of Applicability is also the most suitable document to obtain management authorization for the implementation of ISMS.

8. Write the Risk Treatment Plan

Just when you thought you resolved all the risk-related documents, here comes another one – the purpose of the Risk Treatment Plan is to define exactly how the controls from SoA are to be implemented – who is going to do it, when, with what budget etc. This document is actually an implementation plan focused on your controls, without which you wouldn’t be able to coordinate further steps in the project.

9. Define how to measure the effectiveness of controls

Another task that is usually underestimated. The point here is – if you can’t measure what you’ve done, how can you be sure you have fulfilled the purpose? Therefore, be sure to define how you are going to measure the fulfilment of objectives you have set both for the whole ISMS, and for each applicable control in the Statement of Applicability.

10. Implement the controls & mandatory procedures

Easier said than done. This is where you have to implement the four mandatory procedures and the applicable controls from Annex A.

This is usually the most risky task in your project – it usually means the application of new technology, but above all – implementation of new behaviour in your organization. Often new policies and procedures are needed (meaning that change is needed), and people usually resist change – this is why the next task (training and awareness) is crucial for avoiding that risk.

11. Implement training and awareness programs

If you want your personnel to implement all the new policies and procedures, first you have to explain to them why they are necessary, and train your people to be able to perform as expected. The absence of these activities is the second most common reason for ISO 27001 project failure.

12. Operate the ISMS

This is the part where ISO 27001 becomes an everyday routine in your organization. The crucial word here is: “records”. Auditors love records – without records you will find it very hard to prove that some activity has really been done. But records should help you in the first place – using them you can monitor what is happening – you will actually know with certainty whether your employees (and suppliers) are performing their tasks as required.

13. Monitor the ISMS

What is happening in your ISMS? How many incidents do you have, of what type? Are all the procedures carried out properly?

This is where the objectives for your controls and measurement methodology come together – you have to check whether the results you obtain are achieving what you have set in your objectives. If not, you know something is wrong – you have to perform corrective and/or preventive actions.

14. Internal audit

Very often people are not aware they are doing something wrong (on the other hand they sometimes are, but they don’t want anyone to find out about it). But being unaware of existing or potential problems can hurt your organization – you have to perform internal audit in order to find out such things. The point here is not to initiate disciplinary actions, but to take corrective and/or preventive actions. (Dilemmas with ISO 27001 & BS 25999-2 internal auditors)

15. Management review

Management does not have to configure your firewall, but it must know what is going on in the ISMS, i.e. if everyone performed his or her duties, if the ISMS is achieving desired results etc. Based on that, the management must make some crucial decisions.

16. Corrective and preventive actions

The purpose of the management system is to ensure that everything that is wrong (so-called “non-conformities”) is corrected, or hopefully prevented. Therefore, ISO 27001 requires that corrective and preventive actions are done systematically, which means that the root cause of a non-conformity must be identified, and then resolved and verified.

Hopefully this article clarified what needs to be done – although ISO 27001 is not an easy task, it is not necessarily a complicated one. You just have to plan each step carefully, and don’t worry – you’ll get your certificate.

Here you can download the diagram of ISO 27001 implementation process showing all these steps together with the required documentation.

I have seen quite a lot of smaller companies (up to 50 employees) trying to apply risk assessment tools as part of their ISO 27001 implementation project. The result is that it usually takes too much time and money with too little effect.

First of all, what is actually risk assessment, and what is its purpose? Risk assessment is a process during which an organization should identify information security risks determining their likelihood and impact. Plainly speaking, the organization should recognize all the potential problems with their information, how likely they are to occur and what the consequences might be. The purpose of risk assessment is to find out which controls are needed in order to decrease the risk – selection of controls is called the risk treatment process, and in ISO 27001 they are chosen from Annex A which specifies 133 controls.

Risk assessment is carried out by identifying and evaluating assets, vulnerabilities and threats. An asset is anything that has value to the organization – hardware, software, people, infrastructure, data (in various forms and media), suppliers and partners, etc. A vulnerability is a weakness in an asset, process, control,etc., which could be exploited by a threat; a threat is any cause that can inflict damage on a system or organisation. An example of a vulnerability is the lack of anti-virus software; a related threat is the computer virus.

Knowing all this, if your organization is small, you don’t really need a sophisticated tool to perform the risk assessment. All you need are an Excel spreadsheet, good catalogues of vulnerabilities and threats, and a good risk assessment methodology. The main job is really to evaluate likelihood and impact, and that cannot be done by any tool – it is something your asset owners, with their knowledge of their assets, have to think about.

So, where do you get the catalogues and methodology? If you are using the services of a consultant, he/she should provide those; if not, there are a few free catalogues available on the Internet, you just have to do a search on Google. The methodology is not available for free, but you could use ISO 27005 standard (it describes risk assessment & treatment into detail), or you could use some other websites selling the methodology. All this should take considerably less time and money than buying a risk assessment tool and learning how to use it.

A good methodology should contain a method for identifying assets, threats and vulnerabilities, tables for marking the likelihood and impacts, a method for calculating the risk, and define the acceptable level of risk. Catalogues should contain at least 30 vulnerabilities and 30 threats; some contain even a few hundred of each, but that is probably too much for a small company.

The process is really not complicated – here are the basic steps for assessment & treatment:

1. define and document the methodology (including the catalogues), distribute it to all asset owners in the organization
2. organize interviews with all the asset owners during which they should identify their assets, and related vulnerabilities and threats; in the second step ask them to evaluate the likelihood and impact if particular risks should occur
3. consolidate the data in a single spreadsheet, calculate the risks and indicate which risks are not acceptable
4. for each risk that is not acceptable, choose one or more controls from Annex A of ISO 27001 – calculate what the new level of risk would be after those controls are implemented

To conclude: risk assessment and treatment really are the foundation of information security / ISO 27001, but it does not mean they have to be complicated. You can do it in a simple way, and your common sense is what really counts.

You can also check out our video tutorial How to Implement Risk Assessment According to ISO 27001 (commercially sold video).