A DORA Regulation overview – part 2: incident management
Cliff Martin is the head of the cyber incident response within GRCI Law. He joined the Group in April 2021, bringing experience from the defence industry, where he dealt with both operational technology and IT complexities. Before that, he taught computer systems and network technologies in further and higher education.
Now, Cliff supports clients with their cyber security requirements, helping them prevent and manage cyber incidents. We sat down to talk to him about the second core requirement of DORA [Digital Operational Resilience Act]: incident management.
For more details on the first core requirement, risk management, see our interview with Andrew Pattison, head of GRC [governance, risk and compliance] consultancy Europe, from two weeks ago.
What is your view on DORA as a whole? How necessary is this regulation, and how hopeful are you about its effectiveness?
Like any regulation, I think it can only be a good thing, as long as the finalised requirements don’t make it too arduous for organisations to achieve compliance. But I see setting a minimum baseline that organisations must meet as a definite positive.
Besides, we’re not just talking about any organisations, but financial entities. Organisations that clearly hold a lot of sensitive data, and that are vital to our critical infrastructure, yet are not necessarily doing better than your average organisation when it comes to security – the statistics you presented last week clearly show that.
For me, the bottom line is that DORA sets at least a baseline. It outlines the fundamental requirements – a minimum standard – that these organisations must meet. That can only be a good thing.
Why do you think we’re seeing this problem of financial entities, and other organisations, not being secure on their own? Why does it take legal pressure for them to take action?
In my experience, it’s previously always come down to cyber security taking a back seat within these types of organisations, because they didn’t see it as essential for the sake of doing business – their understandable priority. However, because of this stance, these organisations often lacked even basic security.
This isn’t helped by the more recent trend of threat actors targeting such organisations. Such trends are also what drives regulations like DORA, of course.
Could you share some statistics on this trend?
Only a couple of weeks ago, I saw the NCSC Annual Review 2023, which showed a 64% increase of the number of incident reports on last year. There were also four incidents that “were among the most severe incidents the NCSC has had to manage (compared with one last year) due to the sustained disruption they caused and the victims’ links to critical infrastructure via supply chains”.
ENISA’s latest threat landscape report, published in October this year, also shows that the finance sector is targeted more. For DDoS [distributed denial-of-service] attacks, for example, it faced over 30% of attacks, making it the second-most attacked sector. Banking and finance also faced 12% of malware attacks.
But to sound a little more optimistic regarding what I was saying earlier: I do think we’re starting to see improvement in organisations taking security more seriously, recognising that keeping their ICT and data secure is essential to being able to do business. However, I don’t think we’re yet where we need to be, which, again, makes DORA a good thing in my book.
Speaking of which, let’s take a proper look at DORA’s incident management requirements. Articles 17–23 [Chapter III] are dedicated to this topic. Are there any other articles or chapters in DORA we need to keep in mind in terms of incident management?
I think incident management starts right at risk management. As you’re conducting your risk assessments, you want to be thinking about how you’ll be able to detect an incident when one occurs despite your best efforts, and what you need to put in place to be able to get the evidence you need to establish root causes, the extent of the damage, etc.
Don’t forget: when you put measures in place as part of your risk treatment plan, those shouldn’t just be preventive, but detective and responsive too. DORA is about achieving resilience – the clue is in the name – which requires a defence-in-depth approach.
With that in mind, Chapter IV’s digital operational resilience testing is also really important for the purposes of preparing for incidents. As Article 24(1) says, “For the purpose of assessing preparedness for handling ICT-related incidents, […] establish, maintain and review a sound and comprehensive digital operational resilience testing programme”. These might be tabletop exercises or red/blue team assessments, which basically test whether the organisation can actually respond to an incident, should one occur.
Information sharing – so gathering threat intelligence – can also be another key area to help inform your monitoring and incident management activities, and generally feed back into your controls. To gather that intelligence, you may be looking at organisations within the industry – and having a more sector-specific regulation like DORA can help with this. That said, every organisation is different, and should take the time to find the sources most likely to provide information relevant to its specific ICT solutions and business areas.
As you can see, incident reporting and management may only be one of many pillars in DORA, but it’s a core requirement that has links to practically all the other pillars too.
What sorts of ICT incidents must be reported under DORA?
At the moment, the requirements aren’t clear – DORA just states that “major” ICT incidents must be reported to the competent authority. This is something that the technical requirements set by the three ESAs [European Supervisory Authorities] should be clarifying, which are due to be submitted to the European Commission by 17 January 2024.
What this means for organisations is that they must define different incident types – like ‘major’ – so they can classify one accordingly if an incident occurs. This is really important, as that classification then determines the rest of the response, both in terms of its urgency and the concrete steps to take.
DORA aside, these classifications will vary per organisation and industry, but what I always say is to classify anything with a big impact – affecting your critical servers or services, for example – as ‘major’.
But in terms of DORA, obviously, the ideal situation is for the technical requirements to provide quantifiable parameters on what constitutes a ‘major’ ICT incident. We do already know DORA’s definition for a ‘major ICT-related incident’: “an ICT-related incident that has a high adverse impact on the network and information systems that support critical or important functions of the financial entity”.
However, we have to be prepared for the possibility that the definition won’t become much clearer than this, in much the same way that the GDPR [General Data Protection Regulation] is a little vague on what constitutes a reportable personal data breach. This is for the simple reason that what is ‘major’ will vary per organisation. Most obviously, it’ll depend on the organisation’s size, but its specific areas of business will also affect this.
Another possibility is that some member states will issue state-specific guidance on this. That may help clarify these parameters, but also create some variation across the EU, which can make things trickier for organisations operating across borders.
What information must incident reports include?
We don’t know this for sure yet, as the ESAs are yet to publish the relevant technical standards and templates referred to in Article 20 of DORA. However, once published, those templates in particular will be really helpful for organisations.
The fact of the matter is that when you’re in the middle of an incident, you’re faced with a really stressful situation. This type of template or checklist helps guide the organisation through the steps they must take and information they must gather.
I expect the template will include fundamentals like:
- What the incident was;
- When, how and by whom it was discovered; and
- The nature and extent of its impact.
I suppose some organisations may feel worried at the cost of all these measures. Ultimately, resources are – of course – limited. What would you say to organisations with a tight security budget?
I can’t deny that security is a cost. However, it’s far better to have something in place now, than to have to deal with the inevitable incident, which will cost you a heck of a lot more. It may be a bit cliché to say so, but security breaches really are a matter of when, not if, and organisations have to recognise this and act accordingly.
Related to this, I get a lot of questions from organisations that say things like: ‘We’re not of interest – why would anyone attack us?’ The problem is that people and organisations get attacked simply because they exist. That’s unfortunately just the way it is.
If you’ve got a vulnerability, someone will discover it and try to exploit it to fulfil whatever their objective is. It might be for financial or political gain, or even just to ‘get kicks out of it’, but criminal hackers often target vulnerabilities, not organisations. This is something that more organisations need to recognise, as EU lawmakers clearly are, and protect themselves accordingly.
Also, security needn’t be expensive. Basic measures like passwords and MFA [multifactor authentication], anti-malware software, firewalls, regularly installing patches, secure configuration, and others all cost very little, yet can help prevent most common attacks.
We hope you enjoyed this week’s edition of our ‘Expert Insight’ series – the second of a multi-part interview with our experts about the three core DORA Regulation requirements.
If you missed it, check out part 1, where Andrew Pattison, head of GRC consultancy Europe, talked us through the general cyber landscape and the risk management requirements. Part 3 will be with Alan Calder, founder and executive chairman of IT Governance, on supply chain security.
Please do leave a comment below to let us know what you think, and if you have any questions you’d like our experts to answer.
The post Expert Insight: Cliff Martin appeared first on IT Governance UK Blog.
