Incidents Happen: A real-life scenario (part 2 of 3)

DISCLAIMER

This series (and the following scenario) is a shortened and simplified account of incidents and incident response. It is not intended to be an exhaustive list of everything to complete. As every incident and organisation are different, your approach should be risk-based and fit your organisation. 

Welcome back to ‘Incidents Happen’: a 3-part blog series brought to you by NQA.

While this series focuses on information security, the principles apply to any context. A machine tool not behaving as expected, a release of waste, an accident at work… incidents like these can occur anywhere and at any time.


In Part 2 of the series, we cover:

• What happens when an incident gets reported.

• A real-life scenario to compare to and see where your organisation might be vulnerable.
   

After reading this blog, move on to Part 3: setting objectives and making improvements.

Refresh your memory on what an incident, event and a weakness is with Part 1.

Sometimes innocent error, sometimes deliberate

Unfortunately, some incidents are caused by a deliberate malicious act.

No matter whether the incident was accidental or not, someone responsible must be assigned to investigate the report.

This is sometimes the Information Security Manager (ISM) within your organisation. Depending on the size and scale of your organisation, establishing a dedicated multi-disciplinary Incident Response Team may be best practice.

Depending on how severe the incident is, it may require:

• Improvements made to the information security management system.

• Involvement from law enforcement agencies (such as if company laptops get stolen from the office)*.

• The organisation to invoke its Disaster Recovery or Business Continuity Plan.

*Evidence preservation is vital in crime scenes. Prosecution is only possible if the evidence is collected and stored properly, so make sure no one tampers with it.

Incidents can be a wake-up call, or they can cause lasting damage to an organisation's reputation.

A real-life incident scenario

Let’s dive into a very plausible incident scenario*.

*The examples, business names and incidents portrayed in this article are fictitious. No identification with actual businesses, products or services is intended or should be inferred.

The context

Henry works in sales for Speed29, a car parts manufacturer. He receives a job offer from a rival company and decides to take it.

During his notice period, Henry gathers contact and contract details of Speed29 clients. He emails this information to his work email, with plans to poach the clients once he settles into his new role.

However, a support analyst at Speed29 picks up on strange behaviour happening on Henry’s account. She reports it as an information security incident.

The report

• Incident no.: ID010

• Reported on: 05/06/2023

• Reported by: Lisa

• Classification: Potential incident

• Details: Suspicious behaviour was identified on Henry’s account. 

• Assigned to: Information Security Manager

• Investigation: 05/06/2023 – Confiscated Henry’s laptop. Looked through the sent emails and server access logs. Identified that Henry had been attempting to access details of customers he didn’t usually deal with. Found a spreadsheet of contacts and contracts, though it had not been sent outside the company. 06/06/23 – Henry was given a disciplinary hearing and dismissed on grounds of gross misconduct and breach of contract. Account suspended.

• Root cause: Henry was looking for confidential information to take to his new job.

• Action to address the root cause: The account was suspended, and the member of staff was dismissed. Consider data loss prevention tools to stop exfiltration in the future.

• Status: Closed

• Date closed: 07/06/2023

Actions going forward

• Action #1: The possibility of the incident happening again is added to the risk register. The incident is identified as being high enough (and therefore likely to re-occur).

• Action #2: A data loss prevention tool is introduced in the treatment plan.

• Action #3: The data loss prevention tool is added to the management system objectives.
   

Extra considerations to make

Alongside the data loss prevention tool, it would be valuable for Speedy29 to consider:

• Should Henry have been put on gardening leave?

• What more could Henry's activity logs have told us (i.e. was there any unusual or unexpected activity)?

• Should someone have looked through the logs before Henry handed in his notice?

• Do we need to review onboarding practices and staff screening?

• Is it worth rotating roles to develop different capabilities?

• How often do (and should) we review access and the level of access?

Take a minute to think...

...how easy it might be for someone like Henry to breach data security and take confidential details from your organisation to another.

Evaluate whether:

• Someone could achieve this (and how).

• If anyone would be able to catch them?.

• What could be done to prevent this happening.

Incidents dealt with early on can lead to great improvements in your management system.

 

Final thoughts from NQA

Incident management is a key part of any information security management system. It helps keep an organisation secure, alongside highlighting risks and areas of improvement.

Every incident is an opportunity to learn and improve. Post-incident reviews are a useful way to do this, which we will cover in another NQA blog post very soon.

Explore how to plan and measure the effectiveness of objectives with Part 3 of the series.

Get your business up to speed with ISO 27001 (Information Management)

Sign up for our mailing list to receive the latest on ISO 27001 – plus industry updates, expert content and more 👇