Latest in Employment Law>Articles>Creating Cybersecurity Awareness and What to Do if an Incident Occurs
Creating Cybersecurity Awareness and What to Do if an Incident Occurs
Published on: 27/10/2023
Issues Covered: Data Protection and GDPR
Article Authors The main content of this article was provided by the following authors.
Seamus McGranaghan
Seamus McGranaghan

Seamus and Christine, in conversation with Keith Anderson from Vertical Structure Ltd...

Christine:  So Seamus, I'll bring you in now. If an incident occurs, so somebody has unfortunately clicked on the wrong link in the email in your organisation, what are the first things that people should be doing to keep themselves safe?

Seamus:  Well, from experience and from client work and things like that, I suppose the culture in the workplace has to be that if there is an incident that happens, and whether it's a data breach, whether it's a more severe ransomware situation, once there's been any kind of concern, the employee needs to be in a position where they're coming to report it internally.

You don't want to wait until your whole entire system or server is completely manipulated and it's too late to do anything about trying to salvage or to take those steps.

I always have a funny image in my head of people running around pulling the wires out of every socket in back of computer and every server that they can see in order to try to limit the damage when these things happen.

And I think we all try to be as aware as possible. If we're getting good training and we are getting the testing that happens and things like that, if that is all good, that's all very, very helpful. But there's always that little slip that has the potential to happen.

And at times, even from my own perspective, law firms feel like very much that we can be in the firing line of the target, I suspect, as much as any other business feels it. But it is something that you're living with on a daily basis.

You can come into work and you can be very comfortable about all your systems in place and everything that's happening in the background that you don't see, that you don't really want to see or want to know about, unless you're Keith and you're dealing with it on a daily basis. But there is the potential that a breach and that risk can happen at any stage.

I had taken a look through a lot of the ICO guidance and a lot of the other statutory guidance that is out there. And I have to say, in preparing for this, I've learnt a lot more than what I knew, and then I went back and listened to Keith's podcast and my mind was blown and my knees started to shake and quiver as well just at the thought of what could happen.

So starting point for it in ICO guidance is don't panic if something happens. What they say is not every breach is going to require reporting, not every breach is going to be as severe and as bad as what you think that it might be. But what you should have is your policies, your guidance, your steps in place that you can go quickly and know where to access that.

And hopefully maybe through your disaster recovery plan or your training that you've done, you've been through a sort of process before internally where there have been those tests and checks happening that everybody knows where to start.

If you don't have anything in guidance or if you're not familiar with your guidance, you're going to be starting from a really, really difficult point.

The other thing that the ICO talks about is we know that when it comes to reporting that you have to do that within 72 hours. That's what's in the regulations. And what they say is to start your clock from that point. A really helpful tip that they talk about is to start a log to record what has happened, who's involved, and what you're doing about it.

And then they talk about that as you progress through the different steps of risk assessment, you're keeping your log updated. It means that if you have intervention from ICO, or if ICO come and are looking to look at some sort of enforcement proceedings or fines and things like that, if you have a log that you can present to them, the information that you can provide to them will assist them in determining how well you might have handled it or how difficult the situation was and how it all unravelled.

So, at that point, start your timer. Look for your starting point. Your starting point will be not when the breach happened, but whenever you discovered the breach. So there could be panic around that as well.

The next thing on the risk assessment is really to find out what happened. Pull all your facts together as quickly as possible and keep updating your log. And that will involve getting to the bottom of whether it has been a phishing email that's come in that somebody has clicked on and you're open to a ransomware attack, or whether it has been a data breach because there has been information that has been either accidentally sent out, or if it's been more sinister in relation to it.

So the next step that they talk about is just finding out what happened and then moving on to try to contain the breach.

And I suppose, Keith, for me, that probably is that idea of running around and trying to stop the problem.

Keith:  Even in modern companies, some of the last-ditch scenarios could be unplugging things. We do see that. You get some very red-faced IT managers who have to sprint for the first time in about 20 years down the hall.

But yeah, containment would be definitely my number one priority. And I suppose, Seamus, from your side and my side, that'll always be the challenge within the business in terms of the compliance with legislation, and then also, "Let's get this locked down".

There will be people in your company who'll be saying, "Who cares about the ICO right now? Everything is on fire. Can we just shut it down first?" So one of the things that I definitely recommend is you have people who are massively focussed on fixing the issue, and they don't need to worry about the ICO. You have other people in the business to do that, and then you coordinate some sort of leadership around that. That can be outlined in an incident management plan, potentially a disaster recovery plan as well.

But in terms of going a little bit before that and thinking about how you try and reduce the likelihood of a ransomware attack happening . . . And just to be clear, everyone should be familiar with a ransomware attack, but what that means is all your files on your computer and all the computers in your organisation, all the files have been encrypted. They've been locked up.

If you tried to click on any of the files in your My Documents or SharePoint, it asks for a password. You don't have the password, the attackers do, and they will give it to you in exchange for a ransom pay-out. So just to be clear, that is a ransomware attack.

So one of the things to try and reduce that . . . Well, one of the things that we know is the attackers will most likely come in through a phishing attack. So good awareness around how to spot phishing attacks. Good antivirus and good email filtering are the things that help reduce that down.

But then that's not always going to work. Ones will get through, and then what they're trying to do is install either remote access onto your device or the ransomware, the malware, that can automatically go around and start locking and encrypting everything.

The attackers, from what we know, could be in your system for up to a month before they do anything. Because what they're trying to do is they're trying to understand, "Well, what do these guys do?"

If it was Legal-Island, "What do Legal-Island do? Where are Legal-Island's crown jewels? What's the valuable data that they have?" And once they have that, that's when they pull the trigger on it.

So some of the things around that that you can do is have multifactor authentication on, strong passwords, unique passwords for all your different systems so that if they do get one of the passwords, they can't just use it everywhere else, good controls on your laptop, and things like that. All of those types of things can reduce the likelihood of that happening.

And then the next step is, "Oh, dear. Right. We've been hit with the . . ." It'll be a bit stronger than "oh, dear", but, "We've been hit with the ransomware attack", and that's when your incident management process kicks in, and that's where part of your business just focuses on fixing the ransomware attack. Maybe it doesn't affect everything, so the other thing is you're trying to do BAU as well.

One of the things I would definitely recommend is to have a printed copy of your incident management plan and all the contacts in your office, because if you get ransomware, it's more likely than not that all of that good planning is locked up as well. So there are just a few pointers.

Christine:  Yeah, that's a good point, Keith. We all have these lovely folders. Incident management folder is gone.

We're getting a few questions in, if I could just put a couple of those to you. And everyone, please do keep sending them. Somebody's asking about the IT manager running around unplugging everything. What if you're cloud-based and you don't have the plug to unplug?

Keith:  So the benefit of being cloud-based is it does offer you more protection. So say your SharePoint or your OneDrive or your office Google Drive is compromised. There are ways that you can go onto those as the admin and reverse back, restore back to a backup or an older version to recover the data. But that doesn't solve the issue of how the ransomware got onto devices.

So they're similar principles. Think about your devices and how that is potentially being shared across devices. So we would recommend everything is turned off, and then you identify the infected devices, you clean them up, you close everything back before even restoring your data.

The potential is you restore your data and then there's a device that is still infected and it syncs up all the encrypted files again to your SharePoint or things like that.

So one of the things, and it's always hard with business, especially with customer-facing business, is to slow down and contain it first. Identify the issue and then bring everything back in a very controlled manner.

That's where you might need to have customer comms, thinking about how you communicate with your customers, be it other businesses or the public as you bring things back. Do it right once and be confident that you've identified their entry route so that it can't happen again.

Christine:  Brilliant. And Seamus, that brings us in that when we're communicating with customers, that is when the problems are going to start happening. If O'Reilly Stewart's customer data was compromised, you're going to have a lot of very angry clients on your hands. And also potentially maybe if your payroll's been compromised, you're going to have a lot of potentially angry staff. So what legal issues is that going to throw up for us?

Seamus:  I mean, the key aspect for this is really assessing the risk and looking to see what the risk is. I suppose after you've dealt with those containment procedures . . . And there's a lot of stuff in the guidance, absolutely, of what Keith's talking about there in relation to backup systems and looking at all of your key protectors that you have within your business. But ultimately, if you have a breach, then you're looking at assessing that risk, and what does that mean?

It talks about it at a high level certainly through some of the guidance in relation to consider the likelihood and severity of the risks to people's rights and to their freedoms. If you're looking at breaches that would result in safeguarding issues, identity theft, financial concerns, if there's significant distress going to arise, those are the real serious matters. And those were where you're going to have those difficult conversations with your client base or with your customers.

 What I think everything that I read is very clear about is that there shouldn't be a delay in notification if you're at a point where the risk is at that level.

And I read some interesting stuff where they said if you have accidentally sent an email in a hairdresser's to another client about an appointment, you're assessing the risk. What is the damage there in relation to that? Is it reportable? Is it something that needs to happen? That's that human error type aspect of it.

But if you have sent the same customer a receipt for their credit card that they've just paid on, and it contains financial information or names and addresses in the invoice, you can see how that is getting higher.

Right up to the level where your payroll has been compromised and there are details in respect of bank accounts and financial standing, and things in our office in relation to mortgage offers and medical notes and records, right up to sort of really high-level damage.

So it is about assessing that and it's looking at what has been compromised and what has been not compromised. The guidance is a bit woolly around when to report and when not to report, but there's definitely an undertone in the guidance that not everything is reportable. Don't panic too much. If it's something that isn't going to result in that aspect of a breach of freedom or safeguarding issues, then it can probably be dealt with. And if you can manage and contain it, then that's the way to go about doing it.

And not to jump ahead of things, but every day of the week we will get general inquiries in this office about breaches of data that are coming from banks, from clients of banks, from customers of banks, from telephone companies, from software companies, all of that sort of stuff. And we'll constantly be getting inquiries about, "Can I have a claim? Can I get compensation because there's been a breach of my data?" We have a different job to do in relation to that also then.

But if you think about the PSNI breach there, they have full expectation that that's going to be either a litigated matter or there's going to be some sort of reserve compensatory, maybe state compensatory scheme, or something like that set up in order to deal with that.

So it's very wide-ranging, Christine. And from a public perception, the public are very aware of their rights now in relation to their data. There's so much information out there and it tends to be . . . Even if you think back to some of the big employment cases, that Asda and Morrisons cases, where there was a big breach of 4,500 people, they all brought legal proceedings for recovery of compensation because of distress as a result of that.

So it's a big business all around, it sounds like to me, from the ransom, to the legal side, and compensational costs.

Keith:  And just to add to that, Seamus, just from being in the trenches on a few ransomware attacks, some of the things that we've learnt . . . One of the big takeaways was if you're reporting to the ICO, you can do an initial report to almost tick the box of the 72 hours and say, "Look, we're reporting what we believe is a breach and we will add more information to this as we get it". And they will see that as a good faith reporting.

The other thing that we have seen, especially for smaller companies who need clarification on a breach . . . This is a bit of a tip, and you might cringe and you might say, "No, this is awful". Please do if it's a bad one. But you can actually phone the ICO anonymously and give them a scenario and let them give you advice as to whether they believe that would meet the threshold for a breach.

I would only recommend this for micro and very small companies, but we've found that very useful where they can get a bit of guidance, a bit more than just the checklist on the website.

Christine:  What do you think of that, Seamus? Would that be something you would tell clients potentially?

Seamus:  I mean, certainly, I think where a client is worried about whether or not they're assessing that there's a reportable breach or not . . . Look, there are consequences for organisations that report a breach and there are consequences if they fail to report the breach as well. So absolutely, I think where you can get help . . .

I mean, look, the hope would be that if you are an organisation that has been impacted by a breach, that you will be contacting case organisation, or you'll be taking legal advice in relation to it, and there will be help and assistance in terms of being able to assess that.

There's a sort of general rule of thumb that they talk about in Article 20 of the Working Party and they say the risk exists when the breach may lead to physical material or non-material damage for the individuals whose data have been breached.

If you're the one doing the assessment or you're involved in the assessment, did you put your feet into the shoes of the individual and decide, "For me, would that be a breach if that was happening to me?" And that should give you the guidance. But it is very broad, I have to say, physical material or non-material damage.

Christine:  Anything.

Seamus:  Yeah. I think it is about making sure that you are taking advice, and I would assume that if anything like that happens at all, you're contacting your IT company straight away and getting them on board and the advice being learned in relation to that.

Christine:  I mean, certainly at the forefront of my mind when I was planning for this webinar was the PSNI breach. It's very, very close to home. Initially, it was stated that it was human error, and then it seems to be that there was potentially more than one person involved in the decision-making process to send the offending information out. So what can we learn from the PSNI breach? What should others be doing that they maybe dropped the ball on slightly?

Keith:  The PSNI breach, it all came from what was a pretty innocuous FOI. The PSNI deal with hundreds of FOIs on a regular basis requesting all manner of data and information from them.

This one happened to be asking for a breakdown of staff numbers by rank, grades, location. Obviously, that goes into the FOI team, and then it makes its way through various organisational units until they find the right data source. We can surmise that that data source came from most likely an HR/payroll source potentially when you start looking at what was provided.

What it seems that happened, and I'm sure more will come out as time goes by, but what appears to have happened was there was a full export from one of those systems of more data than they needed to fulfil that FOI request, and it was surnames, initials, rank, grade, work location, and departments of PSNI staff.

It then went through, obviously, again, several organisational units back to the FOI team. And if anyone's familiar with Excel, it looks like they maybe took a sheet of all this data, turned it into a lovely pivot table of all the fantastic answers, and then forgot to delete or remote cleanse the master data. And then that was sent out to the recipient.

Because it was through an FOI website, it was out in the public domain. Within hours, it became apparent exactly what type of data had been given out. It was removed within four or five hours of being on the TheyWorkForYou website, which is what it is. But the genie was out of the bottle at that point. The data can be taken once and spread, and it was spread widely.

PSNI came out initially saying it was an unfortunate human error. And I think that's what you were getting at there. Actually, when you take a step back and you look at just how many different departments within the PSNI, different people who would've needed to be involved in that, it can't be human error. It has to be down to processes and procedures.

And then to add to the pain, there was another breach disclosed where a laptop containing a PSNI spreadsheet of 200 officers was stolen from a car. And then to add insult injury, a PSNI officer drove off on a motorway with a laptop and a notepad with the 42 named officers and staff members in the notepad.

So I know things come in twos, but for the PSNI, it really feels like it came in three this time. They've obviously had a pretty devastating time of it the last month.

Christine:  Yeah. And I suppose that's the argument, that every single layer of person that saw that document needed to be properly trained in cyber security awareness and properly trained in data protection. That's really the argument there, isn't it?

Keith:  Yeah, there is that argument, but I actually think it goes further. No one person should have been able to get that data out of whatever system it was in into a spreadsheet.

If we're looking at . . . Seamus, what did you call it? The material and non-material damages. If you look at the data that they have access to there, there's very clear risk, incredibly high risk for that data.

And I know it didn't have first names, it didn't have home addresses, but there were very unique names on there. And through jigsaw identification, all you would need is the electoral list to start identifying officers' home addresses. The worrying thing in there was . . . I think there were 40 officers attached to MI5 that were identified in the data breach as well.

Christine:  Yeah. And Seamus, if we come back to the ransomware, say the worst has happened, all your files are locked, and you just think, "This is too much. Our business has ground to a halt. I'm going to pay these guys". Can you pay them? Is it legal to pay them? What type of hot water can you get into if you do pay them, I suppose?

Seamus:  Well, I think Keith had sort of touched on it earlier on. I mean, there's a very practical side to the operation of a business and there is that aspect that . . . When we talk about the immediate steps to try to maintain and curtail to an extent you are setting aside all of the precise things that you should be doing because you're immediately trying to salvage the situation, and for all the right reasons that you're trying to salvage it, if you look at the legal perspective of it and what the guidance has to say, whether it's from enforcement, government agencies, ICO, none of them recommend, encourage, or require that there would be ransom paid.

But I think there's a reality of it. We were talking earlier on there's a very high percentage of organisations that do pay ransom. There's no illegality per se, and there's nothing in law that says you shouldn't pay it.

I think Keith made a really good point earlier on. We were chatting just about there are certain restrictions for ransomware where organised crime unit and money laundering and all those sorts of things that go on, and having to be very careful about specific types of payments that would maybe put you into difficulties when it comes to more statutory based and those concerns, that government has said you should not make payments to certain organisations and things like that.

The risk and what the ICO highlight in relation to this is that just because you pay a ransom doesn't mean that everything is solved and that it's a magic wand resolve the whole situation. You still have to take a view that your data has been compromised.

There are issues around if you pay the ransom, does it leave you vulnerable in the future? Those companies and those organisations know that you've paid previously, so are you likely to pay again?

And from a legal perspective, there are no guarantees, I suppose. We were talking earlier on about this, but there are no guarantees that you will pay the ransom and that you will get full access to your data and that it won't then be disseminated out in the public in any event.

Keith was very interestingly saying almost around that you have to sort of due diligence the credibility of these organisations.

Keith:  Yeah, it's interesting. From a moral point of view, in an ideal world, you should never pay a ransom. It's funding organised crime in some cases. In some cases, it's potentially funding terrorism. And that's where you have to be very careful as a business.

There is now an entire industry of ransomware gangs and then ransomware negotiators that your insurance company bring in. And the negotiators almost do a fit-and-proper check on the ransomware gang to say, "Oh, this gang is trustworthy. They have a history of paying up and doing what they say. But oh, no, this one doesn't", or, "You can't because this one is in Syria", or Russia or something like that.

We had a great example of where a company were bang to rights. They had been ransomwared and their data was completely locked up. The ransomware gang had got in and corrupted their backups as well. They had nothing. And they basically said, "Okay, we are going to pay you a six-figure sum to get our data back".

The ransomware negotiators started asking, "So tell us about yourselves. Who are you as a ransom gang?" And they said, "Oh, we are such and such. We are supporting the People's Republic of Syria", and the ransomware negotiator went, "I cannot believe you said that. If you said you'd been in Switzerland, you would've been getting the money. Now the fact is we can't even pay you. It would be illegal to".

So yeah, it's a funny world. I just don't like the stat that if you get a ransomware attack in the UK, you're more likely to pay it than not, which I think everyone should take on board. We need to look as businesses about why that is tipped in their favour and what we can do to tip it back in terms of physical controls, in terms of technological controls. Staff awareness is key. The vast majority of these attacks come through phishing, social engineering, things like that. So that's our first line of defence.

Christine:  We got a question in here, and I'm assuming it's for Keith because I don't understand it. It says, "Do you recommend pen testing?" I'm not sure what that is.

Keith:  So, for everyone on the call, pen testing is penetration testing. So it's not testing a pen. Basically, if you have a system, if you're a company that has either a network or you have a software platform or something like that where all your data is held onto, you would get companies like us and we have . . . I don't want to call them hackers. Let's call them pen testers. But basically, what they do is they will try and hack into your system. We will always get in, and then we will provide you with a useful report on what you can do to harden your systems.

So that's a very common thing. It's part of the proactive defences that you can have, is have someone have a go at trying to get into your system, and then give you a report to tell you what you need to do to fix.

But again, in terms of your users, can you pen test a person? Not really. But what we can do is we can do phishing simulations. We can simulate trying to get in and see if your staff, through the awareness that you've given them, are spotting these, are reporting these to the right people, and all that type of stuff.

Legal Island Training Resources for Your Staff

Cyber Security in the Workplace | eLearning Course

Are you responsible for overseeing the implementation of cybersecurity training for all employees in your organisation?
It is vital that your employees understand the importance of cyber security and the dangers that may be present in your workplace.
Legal Island’s Cyber Security in the Workplace eLearning course is tailored specifically to the law in your jurisdiction and provides comprehensive compliance training for all employees on cyber security practices in the workplace.

Click here to view our course on cyber security in the workplace.

Continue reading

We help hundreds of people like you understand how the latest changes in employment law impact your business.

Already a subscriber?

Please log in to view the full article.

What you'll get:

  • Help understand the ramifications of each important case from NI, GB and Europe
  • Ensure your organisation's policies and procedures are fully compliant with NI law
  • 24/7 access to all the content in the Legal Island Vault for research case law and HR issues
  • Receive free preliminary advice on workplace issues from the employment team

Already a subscriber? Log in now or start a free trial

Disclaimer The information in this article is provided as part of Legal Island's Employment Law Hub. We regret we are not able to respond to requests for specific legal or HR queries and recommend that professional advice is obtained before relying on information supplied anywhere within this article. This article is correct at 27/10/2023