Security
and intellectual property. DORA complements the NIS2 Directive as well as the General Data Protection Regulation (GDPR).
Regulation as a competitive advantage As every CISO knows, cybersecurity is a multi-aspect, multidisciplinary activity and no organisation will ever succeed in entirely preventing attacks and breaches. What businesses can do — and what the regulations require — is implement programmes to manage and minimise risk and demonstrate that they are effective. Rather than view regulation as an onerous task, achieving
compliance enables organisations to gain a competitive advantage. Indeed, as new regulations come into force, organisations are likely to find that many of their partners will require proof of compliance before doing business with them. Achieving compliance with NIS2 and DORA will be a lengthy
process, therefore getting started sooner rather than later is imperative. Additionally, the more resilient the organisation becomes against cybercriminals and risks, the easier it will be to pass regulatory audits.
The implications of DORA for API security DORA is a crucial legislative framework that mandates operational resilience for financial institutions such as banks, credit institutions, insurance companies or insurance intermediaries, pension funds, investment firms, payment service providers, and e-money institutions, within the EU. Our research indicated that 44% of financial services organisations received regulatory fines resulting from an API security incident in 2023. Coming into force in January 2025, it requires organisations
to prepare for and withstand operational disruptions, including cyberattacks and technology failures. In addition, DORA also applies to third-party IT providers, such as data centres or cloud service providers that deliver services into this sector. In total, more than 22,000 financial institutions and IT service providers in the EU are affected. DORA sets out several requirements that have implications for API security, namely:
Digital operational stability: Tis involves organisations implementing regular testing programmes that identify potential gaps, vulnerabilities and/or deficiencies with digital operational stability such as network security tests, penetration tests, web-app tests, and more. Conducting mandatory reviews based on threat-led penetration testing (TLPT), depending on the size, risk and business profile of the financial enterprise is important, as is regularly testing your APIs for vulnerabilities. DORA outlines examples of security testing which include
web-based application and API testing. Tis includes utilising public-facing resources such as the Open Web Application Security Project (OWASP) top 10 threats, which helps to identify errors in configuration, weaknesses, logic flaws, and code issues that may allow threat actors to gain access, manipulate, or otherwise control organisational resources.
Governance and strategy: Tere is now increased responsibility for management bodies with regard to IT risk management and
www.pcr-online.biz
compliance with security regulations. Tis includes increased audit plans and specialised training.
NIS2 a step forward for EU cyber resilience Coming into force in October 2024, the NIS2 Directive is the most comprehensive European cybersecurity directive to date. It has stricter requirements for risk management and incident reporting, covers a wider remit of industries, and features increasingly hard- hitting financial penalties for non-compliance.
While it does not specifically mention APIs, NIS2’s requirements
for enhanced cybersecurity, risk management, incident reporting, and supply chain security have significant implications for the security and management of APIs in organisations subject to the directive. For example:
• Increased Security Requirements: NIS2 imposes stricter security requirements on organisations, including those related to the protection of information systems. As APIs are integral to the functioning of many digital services, ensuring their security becomes crucial under NIS2.
• Risk Management: Organisations are required to adopt appropriate and proportionate technical and organisational measures to manage the risks posed to the security of network and information systems. Since APIs can be potential attack vectors, they need to be included in risk management strategies.
• Incident Reporting: NIS2 mandates the reporting of significant cybersecurity incidents. As APIs can be involved in or affected by such incidents, organisations need to have mechanisms in place to monitor, detect, and report API-related incidents.
• Supply Chain Security: Te directive emphasises the importance of securing the supply chain, which includes third-party services and soſtware. As APIs are oſten used to integrate external services, ensuring their security is essential for compliance.
• Critical Sectors: NIS2 extends its scope to cover more sectors, including digital infrastructure and digital services providers. For these sectors, where APIs are extensively used for integration and service delivery, ensuring API security becomes a priority.
APIs are critical to business transformation and lie at the heart
of corporate strategies for growth and innovation. However, they also represent a considerable security risk. Traditional controls like API gateways and web application firewalls (WAFs) leave APIs vulnerable to targeted attacks or malicious abuse, making them a top attack vector for web applications. Attacks that cause data breaches or compromise performance can lead to regulatory fines, reputational damage, and lost revenue. With the escalating regulation requirements, organisations
must also look at what they need to put in place through the lens of API security. API security should be a priority for every in-scope organisation if they are going to remain compliant with NIS2 and DORA.
March/April 2024 | 33
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52
