ISO 27001 & ISO 22301

A few days ago I received the following question from one of our clients: “What is the difference between ISMS Risk Assessment and BCM Risk Assessment?” And, although the answer to this question might seem easy, in actuality it is not.

Here’s the rest of his question: “… Because on your blog I found that if I’ve done ISMS it should be fine for BCM. On the other hand, ISO 22301 recommends to use ISO 31000 standard.”

Why ISO 27001 risk management framework is a good solution

It is true that ISO 22301 refers to ISO 31000 regarding risk assessment, but ISO 31000 is written very generally since it covers all kinds of risks (not only business continuity, but information security, financial, market, credit, and other risks).

On the other hand, risk assessment framework is described much better in ISO 27001, and even more precisely in ISO 27005; the focus of information security risk assessment is on preserving confidentiality, integrity and availability. And availability is the key link between information security and business continuity – when performing ISMS risk assessment, all the business continuity risks will be taken into account.

And the good thing is, risk assessment as it is described in ISO 27001 and ISO 27005 is perfectly aligned with ISO 31000.

Possible differences in approach

But this is where it might get complicated – my client had another question because he wanted everything to be cleared out: “I think that another difference between those two Risk Assessment approaches is – with ISMS we deal with assets (both primary and supportive); however, with BCM we deal with critical activities and processes.”

And he was basically right – business continuity risk assessment does not have to be so detailed; it can be made high-level for activities and processes. But, although this approach is fine from the point of view of the standard itself, in my view the problem is in the implementation – how would you mitigate the risks if you don’t know exactly where the problems are?

This is where I think ISO 27001 risk assessment framework is better – it forces you to pinpoint where the weaknesses are, which assets should be protected better, etc. If you kept the risk assessment on the process level you probably wouldn’t get all this valuable information.

Risk mitigation compatibility

It is worth mentioning here – ISO 27001 risk treatment options are completely aligned with risk mitigation requirements in ISO 22301 and ISO 31000. Basically, business continuity mitigation comes down to 4 options described in ISO 27001: (1) applying appropriate controls, (2) accepting risks, (3) avoiding risks, and (4) transferring risks. There are no options listed in ISO 22301, while in ISO 31000 they are named a bit differently and organized a bit differently, but they are essentially the same:  changing the likelihood and the consequence, retaining the risk, avoiding the risk, and sharing the risk.

Further, ISO 22301 requires you to “plan actions to address these risks and opportunities,” while ISO 27001 asks for developing the Risk Treatment Plan – again, very similar requirement­ with a slightly different name.

And to finish with this: there is another good thing about ISO 27001 – in Annex A it gives you a catalogue of possible safeguards to choose from; this is something that neither ISO 22301 nor ISO 31000 has.

Hope I managed to persuade him. What do you think?

Click here to see a Risk Assessment and Treatment Methodology template.

Risk Treatment Plan is one of the key documents in ISO 27001, however it is very often confused with the documentation that is produced as the result of a risk treatment process. Here’s the difference:

Risk treatment process

Risk treatment is a step in the risk management process that follows the risk assessment step – in the risk assessment all the risks need to be identified, and risks that are not acceptable must be selected. The main task in the risk treatment step is to select one or more options for treating each unacceptable risk, i.e. decide how to mitigate all these risks. Four risk treatment options exist (for complete risk management process, please read  ISO 27001 risk assessment & treatment – 6 basic steps):

1. Apply security controls from Annex A to decrease the risks – see this article ISO 27001 Annex A controls.
2. Transfer the risk to another party – e.g. to an insurance company by buying an insurance policy.
3. Avoid the risk by stopping an activity that is too risky, or by doing it in a completely different fashion.
4. Accept the risk – if, for instance, the cost of mitigating that risk would be higher that the damage itself.

Risk treatment is usually done in a form of a simple sheet, where you link mitigation options and controls with each unacceptable risk; this can also be done with a risk management tool, if you use one.  According to ISO 27001, it is required to document the risk treatment results in the Risk assessment report, and those results are the main inputs for writing Statement of Applicability. This means that results of risk treatment are not directly documented in Risk Treatment Plan.

Risk Treatment Plan

So, where is the Risk Treatment Plan in this whole process? The answer is: it can be written only after Statement of Applicability is finished.

Why is this so? To start thinking about Risk Treatment Plan, it would be easier to think of it is an “Action plan” where you need to specify which security controls you need to implement, who is responsible for them, what are the deadlines, and which resources (i.e. financial and human) are required. But in order to write such a document, first you need to decide which controls need to be implemented, and this is done (in a very systematic way) through Statement of Applicability.

The question is – why didn’t ISO 27001 require the results from risk treatment process to be documented directly in the Risk Treatment Plan? Why was this step in between needed, in the form of Statement of Applicability? My opinion is that the authors of ISO 27001 wanted to encourage companies to get a comprehensive picture of information security – when deciding which controls are applicable in Statement of Applicability and which are not, the result of risk treatment is not the only input – other inputs are legal, regulatory and contractual requirements, other business needs, etc. In other words, SoA serves as a kind of a checklist that takes a global view of the organization, and Risk Treatment Plan wouldn’t be complete without such a check.

To conclude – Risk Treatment Plan is the point where theory stops, and real life begins according to ISO 27001. Good risk assessment and risk treatment process, as well as comprehensive Statement of Applicability, will produce very usable action plan for your information security implementation; skip some of these steps and Risk Treatment Plan will only confuse you.

Click here to see a sample Risk Treatment Plan.

Term ‘residual risk’ is mandatory in the risk management process according to ISO 27001, but is unfortunately very often used without appreciating the real meaning of the concept.

What is residual risk?

According to ISO 27001, residual risk is “the risk remaining after risk treatment”.

Here is how it works: first you have to identify the risks, and then you need to mitigate the risks you find unacceptable (i.e. treat them). Once you treat the risks, you won’t completely eliminate all the risks because it is simply not possible – therefore, some risks will remain at a certain level, and this is what residual risks are. The point is, the organization needs to know exactly whether the planned treatment is enough or not.

Residual risks are usually assessed in the same way as you perform the initial risk assessment – you use the same methodology, the same assessment scales, etc. What is different is that you need to take into account the influence of controls (and other mitigation methods), so the likelihood of an incident is usually decreased and sometimes even the impact is smaller.

For more information about the risk management process read ISO 27001 risk assessment & treatment – 6 basic steps.

How is it related to acceptable level of risk?

I mentioned that the purpose of residual risks is to find out whether the planned treatment is sufficient – the question is, how would you know what is sufficient? This is where the concept of acceptable level of risks comes into play – it is nothing else but deciding how much ‘risk appetite’ an organization has, or in other words whether the management thinks it is fine for a company to operate in a high-risk environment where it is much more likely that something will happen, or the management wants a higher level of security involving a lower level of risk.

Both approaches are allowed in ISO 27001 – each organization has to decide what is appropriate for its circumstances (and for its budget). The former approach is probably better for high-growth startup companies, while the letter is usually pursued by financial organizations.

Residual risk management

Once you find out what residual risks are, what do you do with them? Basically, you have these three options:

1. If the level of risks is below the acceptable level of risk, then you do nothing – the management needs to formally accept those risks.
2. If the level of risks is above the acceptable level of risk, then you need to find out some new (and better) ways to mitigate those risks – that also means you’ll need to reassess the residual risks.
3. If the level of risks is above the acceptable level of risk, and the costs of decreasing such risks would be higher than the impact itself, than you need to propose to the management to accept these high risks.

Such a systematic way ensures that management is involved in reaching the most important decisions, and that nothing is overlooked.

So the point is – top management needs to know which risks their company will face even after various mitigation methods have been applied. After all, top management is not only responsible for the bottom line of the company, but also for its viability.

You can also check out our Risk Assessment and Treatment Methodology which describes how to set an acceptable level of risk and how to manage residual risks (commercially sold document template).

“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 an information security or business continuity professional, then you’re probably aware of the most difficult part of your job: to convince your management that investment in information security/business continuity makes sense.

Traditionally, “making sense” for management means that the revenues that will result from the investment will be larger than the total cost of investment. (Of course, there are some other aspects the management will also consider – read Management’s view of information security).

So what’s the problem? The problem is, even if you can calculate the total cost, there are no revenues to be made; OK, instead of revenues you might have cost savings, but the general opinion is that these are impossible to calculate.

However, I think there is a way to estimate the financial benefits (i.e. cost savings) of information security. Let’s take a deeper look of what it really means.

Is it really impossible?

First of all, you need to estimate the potential damage an incident could cause – it is also called the Single Lost Expectancy or SLE. But to calculate SLE you need to take into account several factors:

• The scope of the potential incident – which departments, locations, business units and processes would be affected.
• The cost of purchasing of equipment, goods and materials that were damaged by the incident.
• Employees – the cost of employees resolving the incident.
• Legal and/or contractual penalties – if you didn’t comply with legislation or contractual obligations.
• Lost revenues – both from your existing clients and from potential clients.

The next step is to estimate the likelihood – normally, you would have to consider threats and vulnerabilities, as well as existing security measures. The best way is to assess how often you think such an incident would occur – e.g. once every three months, once every three years or once every 30 years.

When you multiply Single Lost Expectancy and likelihood, you get the Annualized Lost Expectancy (ALE) – you could also consider this number to be the annual cost of that risk. For instance, the annualized risk of earthquake will cost you US$ 30000 if SLE is US$ 3 million and the likelihood is once in 100 years.

After that you would need to assess the frequency of the potential incident after you implement security measures – in the earthquake example, the frequency will stay the same; however, if you implement more effective anti-virus software, the likelihood of a successful malicious code attack will decrease.

Finally, you need to estimate how much your security measures will cost – to be accurate, you will again need to take into account various factors:

• Purchase value – cost of hardware, software, implementation services etc.
• Residual value of the security measure – its value after it is no more in use.
• External costs of maintenance – servicing, repairs etc.
• Internal costs of maintenance – mainly employees.

When you have all these inputs together, you will know whether your Return on Security Investment is positive or not – the point is that the decrease in your risk needs to be bigger than the total cost of security measures. It is best if you calculate both on an annualized level – this would mean that your Annualized Lost Expectancy has to be greater than the annual cost of security measures.

“Delusion or idiocy?”

When we have published our ROSI Calculator based on the abovementioned logic, one of the leading information security experts (whom I really do respect) has commented our tool on his Twitter account as follows: “delusion or idiocy? take your pick: http://bit.ly/lAeFZv – just enter ‘probability of incident occurrence’ :-( #ROSI #ROI”.

Why did he react this way? – Let’s be realistic, it is quite difficult to calculate all the costs related to the potential damage of an incident; however it is even more difficult to estimate precisely the likelihood of such an incident occurring. Especially if there are no statistics to support such an estimation.

But the question is – is it better to have nothing at all, or is it better to have at least some feeling about the financial consequences of the work you are doing? If you are a perfectionist, you will probably wait for another 10 or 20 years for a better methodology / statistics to evolve (by the way, the banking sector is now developing those under Basel II – Advanced Measurement Approach); or if you are a realist, you could use this logic to help you, keeping in mind that it is not perfect.

If you take the latter approach, you won’t be the only one in your company – just take a look what your marketing department is doing. They usually spend a lot of money on TV and radio commercials, but they cannot calculate exactly if that is profitable either, can they? What they sure are good at is presenting why this investment is needed, guessing along the way quite a lot of factors. Instead of making fun of them you should learn from them.

Something is better than nothing

So is it possible to calculate exactly what the Return on Security Investment will be? Unfortunately, the sceptics are right – it is impossible to calculate it precisely – mainly because it is difficult to estimate the likelihood of incident occurrence. But chances are you wouldn’t miss the probability that much – you wouldn’t assess the likelihood once in 100 years if it is more likely that an incident is going to happen every five years. That, together with taking into account all other relevant factors, will give you a much better picture of the risk your organization is exposed to.

And having that information in hand is much better than having nothing at all. More importantly, you will start speaking your management’s language (Profit & Loss language), which increases your chances of being heard.

To access the free Return on Security Investment (ROSI) Calculator, click here.