Tuesday, 02 January 2018 16:03

How to mitigate the risks of cyber security through contingency planning

Written by Angelos Christidis

Cyber security has become one of the hottest topics for leadership teams – both in terms of the risks from breaches and the skills needed to manage and address cyber security, which few leaders have.  Rumi Contractor, in his blog Cyber Security – getting it right in the boardroom sets out the issues that boardrooms face.  As we start the New Year, I want to help executives understand how they can mitigate against threats that put their company assets at risk.

Where do you start?  Once you have identified the risks and threats, you need to put controls in place to mitigate against impacts on tangible and non-tangible assets. As examples, your assets will range from hardware – hosting servers – to customer PII (Personable Identifiable Information).   The key is to assume and plan for the worst and set up controls in advance to counter cyber breaches. This highlights the need for strong Incident Response Plans, Disaster Recovery Plans and Business Continuity Plans.

In these plans, you need to differentiate between an incident and a breach. Quoting Verizon’s 2017 Data Breach Investigations Report:

Incident: A security event that compromises the integrity, confidentiality or availability of an information asset.”

Breach: An incident that results in the confirmed disclosure—not just potential exposure—of data to an unauthorized party.”

To summarize,

Breach - successful attempt and full access to systems

Incident - active attempt that might fail in gaining access to systems

The three plans mentioned earlier all contribute to what is referred to as ‘Contingency Planning’. Given the frequency of breaches nowadays in multiple sectors/industries (financial, automotive, retail, healthcare), let’s first consider how companies should react on the identification of a breach. Take a moment to study the diagram below, which paints a picture of the whole Contingency Planning Timeline.

 timeline

Creating an Incident Response Plan

To kick-start creating an Incident Response Plan (IRP), we must cover the identification of, the classification of and the response to an incident. Companies need to develop guidelines for how they will react to and recover from an active threat. This can only be made possible if the company has an Incident Response (IR) team in place that is able to actually detect incidents in the first place. This team should include individuals who confidently hold the expertise to handle critical company systems in real-time as incidents unfold. Evidence of an attack should be documented at all stages - in case the company ends up prosecuting the perpetrator.

To give you a better idea of realistic indicators, I have compiled the table below. It should be read from the perspective of a member of the IR team.

We might be getting attacked

We are probably being attacked

We are definitely being attacked

Presence of unfamiliar files on systems

Unexpected activities taking place at unusual times

Changes to logs indicating the use of dormant accounts

Presence of unknown programs & processes on systems

Unauthorized accounts now present in systems

Notification by partners/peers of the presence of known hacker tools

Unusual number of system crashes

User-base reporting attacks against accounts

Notification by hackers (randsomware?)

Unusual consumption of system resources

Notifications from Intrusion Detection and Prevention Systems (IDPS)

Evidence against the -Availability (resources down), Integrity (corrupted data), Confidentiality (leaked data) - of data

Whilst still in the Incident Stage, we could also briefly consider certain techniques a company could follow to stop an incident and regain full control of systems before it is too late. Methods include

  • Disconnecting affected systems from the global company network
  • Revoking access rights/permissions from unauthorized accounts
  • Disabling compromised accounts
  • Block incoming malicious traffic by temporarily reconfiguring firewalls
  • Temporarily disable a compromised service
  • Final resort: shut down all company systems and networks to reduce impacts

All decisions should be made according to the IR plan - with full approval by the IR Manager.

Although at this point a successful breach may not have occurred, you may still need to recover from the effects of an attempted incident. Once the incident has been contained and insiders have re-gained full access to all systems, we move to the recovery stage.

Before even attempting recovery, the appropriate individuals must be identified. These should include employees who have special training that enables them to assess the full extent of the damage on company assets and systems. Following this,they’ or ‘this team’ should re-draft a full risk assessment which needs to be presented to and have the approval of the leadership team.

This enables the company to revaluate threats and vulnerabilities in its systems thus re-implementing updated/improved controls.

Sources of information on damage

System logs

Intrusion Detection Logs

Configuration Logs and Documents

Documentation from the IR (Incidence Response)

Results from a detailed assessment of the system and its data storage

Below are the steps for creating a useful Incident Response Plan - ‘useful’ meaning the process has been tested and proven to work

1.      Planning

  1. Distribute the Incident Response Plan to each team member
  2. Allow time for each member to perform an evaluation of the plan based on their role
  3. Walk-through each member’s steps at a joint conference following a ‘round-table’ style of discussion of actions at each juncture.

2.      Testing (a) - Simulation

  1. Put team members in isolation and allow them to simulate their own steps.
  2. Stop testing in places where testing would affect normal business operations (for example take down server X)

3.      Testing (b) - Parallel

  1. Team members simulate their steps in tandem as if a real incident is on-going
  2. Stop testing in places where testing would affect normal business operations (for example take down server X)

4.      Testing (c) - Full Interruption

  1. Team members simulate their steps in tandem as if a real incident is on-going
  2. Keep testing and simulate all procedures including those with denial/interruption of service
  3. Attempt to restore data from previous backups

Clearly the third method of testing is the most realistic and effective approach. However, this may be too risky of a method for some businesses or testing time may be a deciding factor.

Creating a disaster recovery plan (DRP)

Looking back at the Contingency Plan timeline, we can see a second layer that deals with ‘disasters’. Although the contingency planning team decides where exactly to draw the line between an incident and a disaster, a disaster, an incident declared as a disaster is typically one where

  • The organisation cannot mitigate the impact of an incident on company assets in real-time
  • The level of damage is extremely severe and swift recovery is impossible

When dealing with a disaster, the response from the team shifts from a focus on countering the attack to securing the most valuable company assets - thus preserving value in the long run. I will also later talk about the BCP (Business Continuity Plan). The difference between that and the current Disaster Recovery Plan (DRP), is that the BCP also focuses on re-establishing primary business operations at a different site.

The execution of a DRP closely follows that of the IRP described above. There are some differences which include key decisions on where to prioritise recovery efforts during/after a disaster.

  • Prioritization - human life preservation to securing customer database
  • Assign different roles / responsibilities to DR team members based on the incident rather than following a template
  • Notify key personnel immediately - CEO/CIO/CISO
  • Assign a role that focuses solely on documenting every step of the disaster - with sufficient legal detail

Business Continuity Plan (BCP)

The inevitable has happened - key assets for the running of your business network have been attacked and business operations at your primary site have come to a halt. This is where a strong Business Continuity Plan (BCP) can save the day.

The BCP outlines how a business can re-establish critical business operations - at a second backup site - during a disaster that impacts operations at a primary site, thus enabling the continuation of service providing. A BCP should be added to and “piggy-back” onto the IRP/DRP - since it is so simple to implement. It consists mainly of continuity/recovery strategies to follow and how/where to integrate off-site equipment (data storage, servers and offices).

Many companies may choose to not implement a BCP for one or more of the following reasons

  • The company is too small to afford a BCP
  • The company is asset/cash-rich enough and accepts they can simply ‘wait it out’ if operations are halted at their primary site
  • The company may not physically be able to shift operations elsewhere, such as in the manufacturing industry

How should business continuity sites be configured? The main deciding factor is cost of implementation and trust. There are three main choices

1.      Hot Site

A facility which mirrors all services offered by the primary site. It is fully configured and ready to go at any given time

2.      Warm Site

Very similar to the hot site but it does not have all necessary equipment installed. Applications and latest back-ups are already in place with some minimal time needed to reach full operation

3.      Cold Site

Rudimentary site which needs equipment, applications and data to be installed and configured before it is ready

 Other options that are less-favourable but cheaper could include

  • Service Bureaux - outsourcing continuity sites to a service provider
  • Time-sharing / Mutual Agreement - sharing hot/warm/cold sites with other companies and agreeing to help each other

Example of a consolidated Contingency Plan

Rather than implementing IRP, DRP and BCPs as separate documents, companies should aim to produce a single document. It should support concise planning by developing, testing and using Contingency Planning.

This single document should include the six concrete steps of the Contingency Planning process as shown here

steps

“Plan for the worst - hope for the best”

Leave a comment

Make sure you enter all the required information, indicated by an asterisk (*). HTML code is not allowed.

Read more

To read more of Metin Mitchell’s insights on leadership, leave your email here:

Categories

Elsewhere online

Popular Posts

Recent Posts

Tweets