Interview: Semperis’ Simon Hodgkinson - “Make sure you focus on recovery”

Cyber Daily: Let’s start with the basics, as I imagine many of our readers may be unaware of what this form of tabletop exercise is all about and how it works. Can you run us through the basics?

Simon Hodgkinson: The first thing to say is a tabletop usually starts with scenario development, something that's, contextually, really relevant to an organisation within which you kind of run the exercise, and it somewhat depends on the audience.

So this week, we ran an exercise in Sydney, with the guys from McGrath Nicol, and because we had a variety of different organisations in the session, it was more of a generic situation. But often, when you craft a tabletop exercise, it’s something very specific to your industry. So instead, for instance, I'm the former CISO at BP in oil and gas, we would be doing tabletop exercises for things like oil spills, safety incidents like fires, or in one of our facility’s financial liquidity issues. So anything that could impact the business operations, we would actually tabletop equally.

Every business now is becoming a digital business, so we had to include tabletop exercises for things like a cyber incident but also, equally, a prolonged loss of technology. We focus a lot on malicious cyber incidents, but often, the cause of major outages is internal human error. So you know, non-malicious insider activity, if you like.

VIEW ALL

So at BP, we ran numerous exercises at the executive level, at each individual business and also with the technical response teams. And why is that? You know, I get a little bit frustrated. We focus on cyber, but actually, a cyber incident is just a trigger for a business-impacting event. So you have to engage the executive team in understanding what their roles and responsibilities are in a cyber incident.

The one we ran this week was a more generic one because we had multiple customers in there. It was something along the lines of a data breach that was advertised on X for a certain organisation, and we crafted an organisation that was responsible for critical national infrastructure. So, under SOCI regulation in Australia. The first thing that the team is then expected to do, people around different tables, is we ask the question “What would you do?”

All you've got now is a post on Twitter/X, and it could be valid, or it might not be valid. What would you do? What would your communications approach be? What would your technology approach be? In these exercises you’re simulating a real world event, often in a very short space of time when the event would be multiple days, if not weeks, if it's a cyber incident, so within a period of time, we amp up the situation – so the response team have identified malicious activity in the environment, and then the incident commander and the incident team around the table are debating this.

What decision would you make? Many organizations would jump right to cutting the networks – let's isolate everything. But that's often the wrong decision. You need to remember what your role is: to make sure that we are here for the operational resilience of the business. And the right thing could be to keep the business running, knowing you've got a malicious actor in your environment, but then take appropriate actions to contain that person, and then work out how to eradicate them in a sensible way.

It's not an easy decision, and we put time pressure on people; then we get another inject into the situation where they get a communication saying, “Hey, send us some ransom payment,” usually from Proton Mail, etc, the usual playbook from such actors. So, what would you do in that situation? Would you pay?

Lots of government organisations now are leaning towards don't pay. Some are trying to make that a legal obligation. But actually, if your business is potentially going to go out of business as a result of a cyber incident, then maybe that's not the right answer. Maybe the right answer is to pay to re-establish your minimum viable business and make sure that it's not an existential issue in the end.

That's broadly the way that it runs, and one really critical bit at the end, then, is to do a post-incident review like you would do in a normal incident. So what do we learn from that and then capture those learnings so that people can take them away and make sure they go and reflect those learnings in their own organisations.

Cyber Daily: I think a lot of people would imagine that tabletops like what you've just described really belong at the high end of town, for big businesses. But do you think they're relevant to anybody who holds data?

Simon Hodgkinson: Absolutely, absolutely.

I think in the US and the UK, 50 per cent of GDP is generated by small to medium enterprises; in Australia, I think it's about 30 per cent. Small organisations often don't have the resources to respond, and therefore, it's a real existential threat for those organisations. They need to understand how they respond – it's all about operational resilience. It's not necessarily about cyber – if you think back to the old days of business continuity plans, when I run these cyber exercises, what I often find is people's business continuity plans have not been sufficiently updated to reflect the new digitisation of their business. They’re more traditional: my data centre’s gone down, or my network's gone down, and how do I run my business off paper for 24 hours? Well, nowadays, if you get impacted by a major outage from either a malicious or a non-malicious actor, you can be out for days, if not weeks, if not months. And for those smaller organisations, that means quite a few of them go out of business.

Cyber Daily: How often do you include media contact as part of your tabletops? We talk to a lot of people who have been impacted by ransomware attacks, for instance, and I imagine they would never expect to get a call from a journalist like myself asking them about an incident. Is that something you ever model into these tabletops?

Simon Hodgkinson: We absolutely do, and everybody should do that.

I like to separate the business response and the technical response and do tabletops for both, but not all organisations have the resources to do that. But exercise in both parts of that is really, really important. And in the business response, you've got to think about what your business leadership is going to do; what decisions are they going to make to keep that business running while the restoration team is restoring things.

Decisions like: what's the priority? If you think about a reasonably substantial digital ecosystem, it can take days, if not weeks, to recover. So what is that minimum viable business we need? What reporting have you got to do? Lots of organisations, even if they're based in Australia, are handling data from numerous jurisdictions. So what reporting obligations have they got across the world as a result of that?

In terms of communications, what's your holding statement? What are you going to say if something breaks, just just to calm down the market, or your clients, to avoid them creating a denial of service attack on you with so many requests for more and more information? Then you have to put in place things like rotas. So these incidents are typically not measured in hours, they're in the days, weeks, and months. Have you got a communications function that runs 24 by seven? Because for sure, if you're a global organization, somebody's going to be pinging things all of the time on social media or calling you for commentary as that event occurs, so you need those playbooks for pretty much all parts of your organisation.

The trouble is, what ends up happening is they become very fragmented, certainly in larger organizations. So the comms team will go and develop theirs, the legal team will develop theirs, the IT team will develop theirs. They're all in separate repositories, and they don't necessarily all link back together in a seamless way. So the tabletop exercise can really kind of help identify where those integration points may break down.

Cyber Daily: How do people respond when they're going through these exercises? I imagine there's going to be a lot of people that you run these tabletops for who have their eyes opened by the whole process and realise they really do need to do more work. Is that often the case?

Simon Hodgkinson: It's pretty much always the case.

Depending, again, on the maturity of the organisation. It can be anything from an organization where their cyber security process is awful, and the executive team have never actually been in the conversation about a cyber incident.

You know, the technical issue is bad, but the fact that the executive team – and potentially, if you're a publicly listed company, the board – have not actually been included in the conversation is frankly shocking, but it happens quite a lot.

One of the things that organisations need to do, first and foremost, is to get the executive team engaged. They manage risk every day of the week, operational risk if you're running manufacturing, uptime, safety, financial risks… They're very used to managing that, but for some reason, cyber has always been something we're going to delegate to the CISO – but the CISO isn't accountable for business operations, and it's just a trigger for an operational resilience issue.

Getting the CIO, CEO, the CFO, all engaged – really actively engaged – in the conversation through a tabletop allows them to ask who's going to be the incident commander? I did one for a privately held company last year, just for that company and what was really interesting is they chose the chief legal counsel as the incident commander. And I said to the CEO, you recognise at that point whatever he says you are going to do, because we're in command and control mode now, and it's sort of just getting them embedded in that and starting to turn up the heat.

Do you pay a ransom? In some cases, they'd never had that conversation. Of course, nobody wants to pay a ransom because the money is going to fund more and more criminal activity. But the reality is, if their business was down for a week or a month or what have you; would that change your decision-making and maybe negotiate with the actors? And when do you pull your insurance team in? Do you really know your insurance policy, so that you've got them in at the right point?

There are so many different aspects that are nontechnical, but I would always start with that sort of executive and business leadership level. And in parallel to that, having the technology teams going through a similar event.