How Do You Mitigate Information Security Risk? – IT Governance UK Blog

Posted on by Admin
How Do You Mitigate Information Security Risk? – IT Governance UK Blog

Related Post


Modify, share, avoid or retain?

Risk management is fundamental to information security and the international standard for information security management, ISO 27001.

Previously, our head of GRC (governance, risk and compliance) consultancy, Damian Garcia, explained where to start with cyber security risk management: establishing a common vocabulary.

In other words, you must define what a ‘risk’ means to your organisation. You need to define what constitutes a ‘high’ impact, what constitutes an ‘unlikely’ risk, and so on.

By clearly defining such terms, you can ensure a consistent approach across your organisation, even when different people – with different experiences and backgrounds – are involved.

But once you’ve identified your ‘high’ information security or cyber security risks, how do you mitigate them?

In this interview

Risk appetite

What do you do after you’ve assessed and categorised your information security risks?

Define your risk tolerance or ‘risk appetite’. Most organisations haven’t thought about that, but you need to decide how much risk you’re willing to accept. This varies per organisation, depending on size, industry, and so on.

It can even vary from department to department – for example, my consultants and I are probably more risk averse than our sales colleagues. That’s just in the nature of our respective jobs – it doesn’t mean that someone is wrong in their attitude towards risk.

But you need a consistent approach across the organisation for information security risk.

That requires the board, or senior management, to formally define the organisation’s risk appetite, taking into account the context of the business. For example:

  • Business strategy
  • Financial situation
  • Organisational size and sector
  • Customer and other stakeholder expectations
  • Legal, regulatory and contractual requirements

Addressing high risks

What comes after establishing risk appetite?

Prioritise your risks, and address the high-level risks ASAP. These are the risks that, if they materialise, can be detrimental to your business.

But you need nuance. Organisations may choose to tolerate the risk – even a high risk – for a set period.

Under what circumstances would you tolerate a high risk for a limited time?

For busy periods of the year, for example. That’s when you might want to relax some of your controls to facilitate a period like Christmas.

For example, credit card providers have anti-fraud and identity checks in place. But for Christmas, they might choose to relax one or two – not all! – of those checks.

They might make that decision because they’ve weighed up the benefit of the additional revenue gains against the cost of the fraud that’ll occur as a result of those relaxed checks, and found that relaxation of controls to be worth it. Because it benefits their business.

That’s a part of risk tolerance, too. But it’s not a decision the risk manager or information security manager can make – it needs to come from the top of the organisation.

Risk responses

Let’s come back to addressing your risks. You’ve identified, assessed and prioritised them. How do you then address those risks?

You’ve got four broad risk responses:

  1. Implement a control to modify the risk.
  2. Outsource the activity to share the risk.
  3. Accept [or retain] the risk, but continue to monitor it.
  4. Stop the activity to avoid the risk.

Treating the risk by implementing a control is by far the most common response.

Modify the risk

How do you choose the correct control to modify a risk?

That could take all day to explain!

To keep it brief, existing controls sets, like Annex A in ISO 27001, can be a good place to start. ISO 27005 is another good one, which provides guidance on risk management in an ISMS [information security management system].

Bridget Kenyon’s excellent ISO 27001 Controls book, which gives implementation and auditing guidance on the Annex A controls, is another great resource. All my consultants have a copy!

After selecting their controls, what must organisations think about when implementing them?

Make sure the control is effective. You can’t just implement it and forget about it – you’ve got to check that the control is working as intended.

And if it isn’t, make changes such that it does work properly.

Could you give us an example? What sort of changes might someone make?

Suppose you’ve noticed that you’re falling foul of more malware attacks. That suggests something isn’t working properly, but what? What’s the root cause?

Is it, for example, that your free anti-malware software is no longer doing the job you want it to? Then you might need to purchase a more robust system.

Or perhaps your staff awareness training is ineffective in spite of your annual refreshers. That might be because your training isn’t clear or relevant enough, so you need to make changes to your awareness programme.

Share the risk

What must organisations consider if they choose to outsource?

The trap that organisations fall into is thinking: ‘We’ve outsourced this [website/database/etc.] to a third party, so we now don’t have to worry about the risk anymore.’

Yes, you do! You might have made someone else responsible for the security of that activity, but ultimately, you are accountable.

Interviewer note

This seems a common trap, even when talking about specific laws or contractual requirements:

  • For GDPR (General Data Protection Regulation) compliance, organisations often overlook their Article 28 requirements around processor contracts.
  • For the PCI DSS (Payment Card Industry Data Security Standard), SAQ A/e-commerce merchants expect compliance to be straightforward because they’ve implemented a website redirect or an iframe, then are surprised when problems arise.
  • Under DORA (Digital Operational Resilience Act), securing your ICT supply chain is an explicit requirement for the finance sector – likely because it’d otherwise be overlooked.

Can you give us a real-life example of how this might be a trap?

I was working with a pension provider, which had outsourced a part of its system.

In view of business continuity, I asked the IT manager how important the system was to the organisation. He responded: “We can’t afford to be without this system.” Meaning that the client couldn’t afford for the system to be down for more than one or two hours.

I then asked: “What does your SLA [service level agreement] say? If this system fails, how quickly will your provider get it back up?”

The IT manager didn’t know, so I got him to email the provider. The response? “It’s computers, mate. It’s complicated. It can take as long as it needs to.” Honestly, I’m not making this up!

The IT manager was going white. I asked him whether that response gave him confidence. Of course, he said ‘no’.

We phoned the procurement team to check the SLA – made sure that answer [in the email] was correct. Because if it was, that’s a massive risk to service availability – remember, security is about more than just stopping data from falling into the wrong hands.

[Damian elaborated in this previous interview.]

To cut a long story short, the client couldn’t afford to not get that system up and running within a reasonable time frame. That’s true for a critical system for any organisation. That hurts your business. It hurts your operations. It hurts your reputation.

What can an organisation do if it finds itself in a situation like this?

Assuming the service provider doesn’t improve its service, all you can do is either bring that activity back in-house or find a different provider.

If you’re facing that sort of catastrophic risk, you can’t just accept it! You’ve got to do something about it.

How a risk response can introduce a new risk

To generalise, this means that the act of implementing a control, or otherwise mitigating a risk, can in itself create a new risk, right?

Absolutely!

If you have, say, an application on just one machine, or in one server room, and determine you need some kind of DR [disaster recovery] site. What do you do?

You’ll probably set up another site – another server room. Or maybe you’ll go to a third party and use their data centre.

Well, that introduces a new risk, because now you’ve got some of your information assets on a different premises. Someone else’s premises, in fact, if you use a third party.

So, how is your information or machine protected? Are there environmental threats? And is the building secure? Can someone just walk in and take it [the information/machine], or do you have to – metaphorically speaking – go through War and Peace to enter the building?

To come back to your question: yes, implementing certain controls can definitely introduce new risks, which you must identify, categorise and address – much like any other risk.

I suppose the CrowdStrike outage showed us that.

Yes. You implement something intended to protect your environment, then it becomes a point of failure instead!

[Interviewer note: Information security manager Adam Seamons discussed the CrowdStrike outage, and the lessons we can learn from it, in much more detail in this interview.]

Retain a risk

Let’s come back to the risk responses. What does accepting or retaining a risk look like in practice?

The classic example is a bespoke application running on an old operating system that’s no longer supported – i.e. it can’t be updated.

And that application is so bespoke, but of minor importance, that it’s not worth investing in an upgrade.

What do you do instead?

You can put some controls in place. You can sandbox it. You can separate it from the network. But in spite of those controls, the residual risk* is still outside your risk appetite.

If you can’t justify the cost of an upgrade – the cost of a control should never exceed the cost of the risk materialising – and you can’t stop the activity yet, you’ve just got to accept it until that application reaches its end of life.

Again, this isn’t a decision a risk manager or an IT manager can make – the senior leadership team has to review and sign off that risk response.

You’ve also got to continue to monitor that risk – even more so than for risks that are within your tolerance levels.

[*Residual risk is the risk level after you’ve applied all controls (or other measures/responses). Inherent risk is what the risk looks like if you did absolutely nothing about it.

The current risk is your current risk level, where you’ve applied some but not all controls because, for example, the lead time for some controls is longer.]

Monitor and review risks

Why do you monitor information security risks?

Think about what a risk consists of: a threat exploiting a vulnerability, right?

Well, those change all the time. New tools [threats] are constantly being developed. New vulnerabilities are constantly being discovered. So, your risks are obviously going to change over time, too.

That means you need to monitor them:

  • Are the controls you implemented still effective?
  • Are the risks still within your risk appetite?

You’ve got to regularly review your risks. Ask these types of questions – make sure your defences are still adequate.

Also track your overall system:

  • Collectively, how are your risks changing over time?
  • Over time, is your exposure increasing or decreasing?
  • Do your systems and methods appear to be effective?

And if your results are trending in the wrong direction, you need to figure out why that is and do something about it.

When reviewing your risks, can bias creep in? Can people be unable to look at the same risks with fresh eyes?

That can happen. Removing bias and conflicts of interest is really important. I always get twitchy when I discover that, say, the information security manager is also the IT manager, and they’re responsible for internal audits. Because there’s no independence!

If the same person who implemented – maybe even selected – the controls is also measuring them, they’re less likely to report they’ve made a mistake. Or perhaps they’ll gloss over the mistake.

This is where I think bringing in an external consultant is very helpful. My consultants do a lot of internal audits, which has two major benefits to clients:

  1. Deep knowledge of information security and ISO 27001. We do this day in, day out. So, we understand the Standard and best practices very well.
  2. Complete independence. It doesn’t matter to us whether something is or isn’t working – we have no fear of retribution, so aren’t afraid to call anything out. And the client needs that peace of mind, because if you allow conflict of interest, you’re giving yourself a false sense of security or confidence.

When you conduct an audit, what kinds of issues do you often come across?

Organisations are great about getting their policies in order, especially when they’re implementing ISO 27001.

But you’d be surprised at how few enforce them.

I remember auditing one client’s physical security. Specifically, I was looking at their clear desk and clear screen policies.

I ask the office managers whether they’re aware of the policies. Yes, they are – good, tick in the box.

Then, I ask whether they ever go round the offices at the end of the day to check people are adhering to those policies? In other words, do you make sure they’ve turned off their computers, put confidential documents into a locked drawer, and so on.

It turned out they’ve never done that. So, I had to issue a nonconformity for that control.

You can’t just create a policy, then not enforce it. You need to make sure your measures – all measures, whether organisational or technical – are effective. That they’re doing the job you want them to do.

Do you have any final words of advice?

Risk never stops. Or rather, it only stops if your business stops, or you stop doing the activity giving rise to that risk.

Risk is something you need to constantly assess and evaluate. What controls do you have in place? Are they effective – both straight after implementation and over time? That’s a key challenge when setting up an ISMS – figuring out how often your risks change, and reviewing them accordingly.

Working out how often to review your risks is a fine balance. ISO 27001 simply says to perform information security risk assessments at “planned intervals or when significant changes are proposed or occur” [Clause 8.2].

So, what’s the correct interval? Wait too long, and you don’t pick up on changes in your risk environment quickly enough. Make it too frequent, and you might lack the resource to react to your findings – to make the necessary changes to your controls as part of that review process.

It comes down to understanding your own requirements, and that of your management system.

Accelerate your risk assessments

CyberComply makes conducting information security and ISO 27001 risk assessments simple:

  • Automate, review and repeat risk assessments, reducing the time spent on them by up to 80%.
  • Take advantage of CyberComply’s built-in library of threats, vulnerabilities and controls to treat risks.
  • Schedule tasks and reminders to review risks and stay on top of your implementation project.

Don’t take our word for it

Here’s what our customers say:

Stefano G:

CyberComply is very easy to use and easy to assign risks to risk owners and set up regular reviews – Great piece of software.

Yemi L:

I love everything about CyberComply. There is nothing that is not useful.

Steve Atkinson:

We required a simple solution to document our assets and complex data flow processes for compliance and risk analysis. CyberComply tools allow us to do this quickly and efficiently; the user interface is easy to understand and intuitive to use which is key here.

About Damian Garcia

Damian has worked in the IT sector in the UK and internationally, including for IBM and Microsoft. In his more than 30 years in the industry, he’s helped both private- and public-sector organisations reduce the risks to their on-site and Cloud-based IT environments.

He also has an MSc in cyber security risk management and maintains various professional certifications.

As our head of GRC consultancy, Damian remains deeply committed to safeguarding organisations’ information and IT infrastructures, providing clients with pragmatic advice and support around information security and risk management.

We’ve previously interviewed Damian about how to start managing risks, the insider threat and common cyber security and ISO 27001 myths.

We hope you enjoyed this edition of our ‘Expert Insight’ series. We’ll be back soon, chatting to another expert within GRC International Group.

If you’d like to get our latest interviews and resources straight to your inbox, subscribe to our free Security Spotlight newsletter.

Alternatively, explore our full index of interviews here.



Source link