What impact would this have on your business both internally and externally? Would you know how to respond to such an attack, and would you have the protocols and processes in place to ensure that your organisation could continue functioning as normal? 

Availability-related attacks can paralyse a business in an instant, but the threat is not just from cyber criminals looking to exploit your weaknesses (or, as we increasingly see, nation-states targeting the critical infrastructure or information assets of their rivals). Availability incidents can just as easily happen accidentally as a result of human error. Regardless, the impact on the business is often severe. 

But what do we actually mean by a system availability attack/incident? 

Defining system availability attacks: 

A system availability attack is anything that impedes your business from having access to the information systems and processes that are required to operate normally.

In most cases, an attack will result in entire systems being taken offline but in rare circumstances can affect a particular information asset that stops a business from functioning. For example, an online retail organisation might find that it can no longer access its pricing schedules and formulae.

Hard-hitting – the impact of a system availability attack: 

The pain felt from a system availability attack can vary significantly and can be anything from a few hours of inconvenience while the business recovers to days, weeks or even months of disruption depending on the type of attack the organisation has been subject to. 

With systems down, organisations can no longer operate and communicate internally and for those that are customer-facing, can prevent them from providing the products, solutions and services that allow them to generate revenues. In the most extreme cases, this can put a company out of business. 

The impact can continue long after systems are back online. Take a ransomware attack, for example. Even if the organisation pays the ransom, it can take weeks to recover data and get up and running again – the reputation damage caused during this time can be just as great as the financial impact suffered. 

The types of attack that can take systems offline: 

Distributed Denial of Service (DDoS) has historically been the most common availability-related threat, but ransomware is increasingly prevalent. While many consider ransomware to be an advanced cyber threat, it ultimately takes systems offline and makes vital information unavailable. 

Understanding the risk of systems being taken offline accidentally: 

Human error should be considered a cyber threat, and it is one of the most common causes of availability-related incidents for small, medium and enterprise-level organisations. User error can have wide-reaching impact and can relate to either back-end administration or the regular business use of a system. 

It is most likely to occur when the use of privileged user accounts is widespread and/or poorly controlled, and when systems require significant manual inputs or processing steps such as spreadsheet imports. While there is often no malicious intent, user error resulting in a system availability incident is just as harmful to an organisation as a well-planned cyber attack. 

How to respond to a system availability attack: 

How the organisation responds to its systems going offline is key to limiting the damage caused to the business. Access to specialist internal skills or external expertise that knows exactly what processes and activities should kick in is crucial to survival. 

Make sure you know what, when, how and who. This should be set out in an all-encompassing Cyber Security Policy with buy-in from the top down and all employees trained to be cyber security aware. 

The biggest mistakes we see businesses make: 

Failing to plan is planning to fail, and this is the biggest mistake the vast majority of organisations make when it comes to system availability incidents. We often see insufficient capacity planning as well as inadequate system/security testing to identify potential loopholes before an incident occurs. 

It’s also common for organisations to not patch quickly when updates become available and for them to have weak internal policies and processes in place which often leads to “headless chickens” syndrome when something does occur. 

How to be more resilient to system availability incidents: 

Having an effective plan and policy in place is the only way to improve resilience. In technical terms, this should focus on sufficient system capacity, security testing, frequent patching and strong cyber defences that are well-configured and with well-maintained firewalls. 

The organisation needs to have in place a mechanism that enables staff to report even the mildest signs that the business might be under attack – this requires regular staff training. 

Should systems go down, it’s vital for the organisation to have separate, up-to-date backups that have been tested. This, combined with a comprehensive business continuity plan so that everyone in the organisation knows what to do when an incident occurs, can significantly improve resilience, response and recovery. 

The Oversight Framework for ICT Third-Party Providers

Chapter 5 of the DORA Act is dedicated to the establishment of an oversight framework for critical ICT third-party service providers. These providers, which supply essential services to financial institutions, play a vital role in the sector’s digital infrastructure. Given their importance, the DORA Act mandates that these third-party providers are subject to strict oversight to ensure they adhere to the necessary security and resilience standards.

Key Provisions:

1. Oversight Authority: Chapter 5 empowers designated oversight authorities to monitor and assess the activities of critical ICT third-party providers. These authorities are responsible for ensuring that these providers comply with the same operational resilience standards required of financial entities.
2. Risk Management Requirements: Third-party providers must implement robust risk management practices. This includes identifying and mitigating potential risks that could impact the services they provide to financial entities. The providers are expected to have security measures that are at least equivalent to those of the financial entities they serve.
3. Right to Audit: Financial entities are granted the right to audit their critical ICT third-party providers. This provision ensures that financial entities can verify that the third-party providers are meeting the required standards. The audits can include reviewing security controls, resilience measures, and any incidents that may have affected service delivery.
4. Self-Assessments: ICT third-party providers are required to conduct regular self-assessments of their security and resilience measures. These self-assessments help in identifying any gaps or weaknesses in their systems, allowing them to take proactive steps to address these issues.
5. Audit Reports: Financial entities can request audit reports from their ICT third-party providers, including SOC II Type 2 reports and Information Security Management System (ISMS) Statements of Applicability (SoA). These reports provide an in-depth look at the provider’s controls and practices, giving financial entities greater assurance of their reliability.
6. Enforcement and Penalties: The oversight authorities are empowered to take enforcement actions if third-party providers fail to meet the required standards. This can include penalties, restrictions on services, or other measures designed to protect the integrity of the financial sector.

Practical Implications for Businesses: Managing Third-Party ICT Risk

The requirements outlined in Chapter 5 have far-reaching implications for both financial entities and their ICT third-party providers. The chapter’s focus on third-party risk management underscores the importance of ensuring that external service providers are as secure and resilient as the financial institutions they support.

1. Strengthening Third-Party Risk Management:

Financial institutions must enhance their third-party risk management strategies to comply with Chapter 5. This involves not only selecting ICT service providers that meet high standards of security and resilience but also continuously monitoring and assessing these providers. Regular audits and assessments become essential tools in this process, allowing financial entities to verify that their providers are maintaining the required standards.

2. Ensuring Compliance through Audits:

The right to audit, as granted under Chapter 5, is a powerful tool for financial entities. By conducting audits, financial institutions can gain direct insights into the security and operational practices of their ICT third-party providers. These audits should be thorough, covering all aspects of the provider’s operations that could impact the financial entity. This includes reviewing security controls, incident response plans, and business continuity measures.

3. Leveraging Self-Assessments and Audit Reports:

ICT third-party providers are expected to conduct regular self-assessments and provide detailed audit reports upon request. Financial entities should actively seek these reports, as they offer valuable information on the provider’s adherence to security and resilience standards. Specifically, SOC II Type 2 reports and ISMS SoA documents are crucial as they outline the provider’s control environment and how it aligns with industry standards.

4. Enhancing Governance and Oversight:

For financial entities, Chapter 5 emphasises the need for strong governance over third-party relationships. Senior management and boards of directors must be involved in overseeing third-party risk management activities. This includes reviewing audit findings, assessing the effectiveness of third-party controls, and ensuring that any identified risks are promptly addressed.

5. Preparing for Regulatory Scrutiny:

Given the oversight powers granted to regulatory authorities under Chapter 5, both financial entities and their ICT third-party providers must be prepared for potential scrutiny. This includes having all necessary documentation and evidence of compliance readily available. Providers should be ready to demonstrate their adherence to the required standards, while financial entities must ensure they have conducted sufficient due diligence on their providers.

Steps to Ensure Compliance with Chapter 5

To effectively meet the requirements of Chapter 5, financial entities should consider the following steps:

1. Understand the Criteria: The European Supervisory Authorities (ESAs) have specified criteria for designating ICT third-party service providers as critical, which includes: systemic impact of a failure; the importance of the functions supported; and the number of important institutions relying on the provider.
2. Gain assurance from ICT third-party providers: Financial entities must ensure that their ICT third-party providers comply with DORA’s requirements. This includes managing ICT risks, ensuring continuity and recovery, and reporting incidents2.
3. Consider Oversight Fees: The ESAs have also proposed oversight fees for critical ICT third-party providers, which are calculated based on the turnover of the critical ICT third-party service provider. These fees cover the costs of monitoring and ensuring compliance.

Overview

Chapter 4 of DORA mandates that financial entities establish and maintain robust ICT risk management frameworks. These frameworks should be integrated into the overall risk management system of the entity and should address all ICT-related risks comprehensively. The chapter outlines several key components that these frameworks must encompass:

1. Governance and Organisational Structure
2. ICT Risk Management Process
3. Information Security Requirements
4. ICT Incident Management, Classification, and Reporting
5. Digital Operational Resilience Testing
6. Management of ICT Third-Party Risk

Each of these components is designed to ensure a comprehensive approach to managing ICT risks, emphasising both preventative and reactive measures.

Governance and Organisational Structure

Implication: Financial entities must have a clear governance and organisational framework where ICT risk management is integrated at all levels in the organisation. This includes assigning specific roles and responsibilities for ICT risk management.

CRMG Recommendation: Effective governance and organisational structure are interdependent. A well-defined organisational structure supports good governance by providing assurance that roles and responsibilities have been clarified, ensuring accountability, and providing the most effective environment for effective decision-making.

ICT Risk Management Process

Implication: Entities need to identify, assess, monitor, and manage ICT risks continuously. This requires a systematic process that is well-documented and regularly reviewed.

CRMG Recommendation: Implementing a consistent approach to ICT risk management throughout the organisation, especially one that directly links threats to controls, will enable the organisation to understand, prioritise and address the relevant ICT risks.

Information Security Requirements

Implication: Ensuring the confidentiality, integrity, and availability of information and ICT systems is crucial. This includes implementing robust cyber security measures and maintaining a secure ICT environment.

CRMG Recommendation:  By focusing on these three attributes of information when implementing cyber security measures, organisations are in a better position to protect their data from unauthorised access, fraud, and also ensure it is available when required.

ICT Incident Management, Classification, and Reporting

Implication: Financial entities must have procedures to detect, manage, and report ICT incidents promptly. This includes classifying incidents based on their severity and impact.

CRMG Recommendation: Detecting potential incidents early, and prioritising responses so that the most critical incidents receive immediate attention are techniques that will help organisations utilise their resources to deal with ICT incidents as efficiently as possible.

Digital Operational Resilience Testing

Implication: Entities are required to perform regular resilience testing to ensure their ICT systems can survive various types of disruptions. This includes vulnerability assessments, penetration testing, and other forms of resilience testing.

CRMG Recommendation:  Regular resilience testing includes a wide range of techniques such as Disaster Recovery Testing, Load Testing, Failover Testing and Incident Response Testing. Threat-Led Penetration Testing (TLPT) is a particular area of focus under DORA as certain financial entities are required to conduct TLPT at least every three years to ensure their ICT systems can withstand sophisticated cyber threats.

Management of ICT Third-Party Risk

Implication: Managing risks associated with third-party ICT service providers is critical. Financial entities must ensure that their third-party providers adhere to the same high standards of ICT risk management as their own.

CRMG Recommendation: Third parties and the contracting financial entity must work very closely together to ensure the requirements of DORA are met and that all information for the Lead Overseer is available when they conduct off-site investigations, on-site inspections, and continuous monitoring.

By mandating standardised procedures and regular assessments, DORA aims to enhance the overall resilience of the financial sector against digital threats. Chapter 4 of DORA provides a comprehensive framework for managing ICT risks in the financial sector.

The practical implications and recommendations discussed in this article aim to guide financial entities in implementing effective ICT risk management frameworks, ensuring not only compliance with DORA but also the security and stability of their operations in an increasingly digital world.