Een pentestergids voor het testen van DORA-compliance en cyberbeveiliging

Inleiding

Hallo, ik ben Alix, een pentester bij Approach Cyber. Als je op deze blogpost hebt geklikt, is de kans groot dat je geïntrigeerd bent door de Digital Operational Resilience Act (DORA) [1], net als ik. Gezien het groeiende belang ervan, besloot ik me te verdiepen in wat het echt inhoudt. In deze blogpost zul je de reikwijdte van DORA ontdekken – in wezen het “wanneer”, “wat”, “wie” en “waarom” erachter. Bovendien belicht ik een onderwerp dat nauw aansluit bij mijn dagelijkse werk: Digitale operationele tests. In het bijzonder zal ik de gebieden verkennen die een pentester zoals ikzelf kan aanpakken binnen deze tests. Of je je nu afvraagt of DORA van toepassing is op jouw bedrijf, op welke tests je je moet voorbereiden of als je gewoon de basis van DORA wilt begrijpen, deze blog is voor jou gemaakt! Dus, zonder verder oponthoud, laten we er meteen in duiken.

Wat is DORA?

Noteer alvast uw agenda: Vanaf 17 januari 2025 staat de Europese financiële sector een grote verandering te wachten! Op deze datum wordt de Digital Operational Resilience Act (DORA) geïmplementeerd. Net als de General Data Protection Regulation (GDPR)[2] is DORA een Europese verordening[3]. Dit betekent dat deze vanaf het begin direct van toepassing is op een breed scala aan entiteiten zonder dat deze, in tegenstelling tot richtlijnen, hoeft te worden omgezet in nationale wetgeving.

DORA, voor wie?

Voordat we dieper ingaan, is het misschien handig om te bepalen of DORA op jou van toepassing is. Als we in artikel 2 van DORA duiken, is het duidelijk dat het veel verder reikt dan traditionele financiële instellingen. Inclusief kredietinstellingen, betalingsinstellingen en instellingen voor elektronisch geld, beleggingsondernemingen, leveranciers van crypto-activa en verzekeringsmaatschappijen, om er maar een paar te noemen [4]. Hoewel deze lijst al vrij uitgebreid lijkt, bevat DORA in het 4e artikel flexibiliteit voor micro-ondernemingen[5], kleine ondernemingen en kleine en middelgrote ondernemingen (MKB). Daarnaast is de DORA zonder uitzondering ook van toepassing op externe ICT-dienstverleners van financiële entiteiten.

Ja, je leest het goed. ICT-serviceproviders van derden staan zeker op de lijst en je vraagt je misschien af: “Waarom is dat?

Het is een strategische zet om externe ICT-dienstverleners binnen het toepassingsgebied van DORA te brengen. Het doel is om de risico’s te verminderen die gepaard gaan met aanvallen op de toeleveringsketen, zoals het beruchte SolarWinds incident[6]. Tijdens deze inbreuk op de cybersecurity slaagde een Advanced Persistent Threat (APT)-groep, bekend onder de naam APT29[7] erin het netwerk van SolarWinds te infiltreren. Ze implanteerden kwaadaardige code in een update van de Orion-software. Dit veroorzaakte een cascade van compromissen die tal van organisaties in gevaar brachten, waaronder belangrijke overheidsinstanties en grote bedrijven.

Het kader van DORA omvat externe ICT-dienstverleners vanwege deze dreiging.

De doelstellingen?

Waarom DORA? Het is opgericht om de veerkracht van de financiële sector in de EU te versterken. En er zo voor te zorgen dat alle spelers hun ICT-systemen en -diensten beschikbaar, intact en vertrouwelijk kunnen houden. Maar wat bedoelen we eigenlijk met veerkracht? De verordening beschouwt digitale operationele veerkracht als het vermogen om de essentiële ICT-voorzieningen te bouwen, te onderhouden en te evalueren die de netwerken en informatiesystemen waar financiële entiteiten van afhankelijk zijn, beschermen.

Simpel gezegd zorgt DORA voor een continue stroom en kwaliteit van financiële diensten, zelfs wanneer deze worden verstoord.

De gevolgen?

Nu we beter bekend zijn met deze nieuwe regelgeving, is het belangrijk om de gevolgen van niet-naleving te begrijpen.

DORA suggereert niet alleen, maar dringt erop aan om voorbereid te zijn op en in staat te zijn om snel te herstellen van ICT-verstoringen. De verordening geeft bevoegde autoriteiten de bevoegdheid om toezicht te houden, onderzoek te doen en sancties op te leggen om naleving te garanderen, zoals benadrukt in artikel 50 van de DORA[8]. Niet-naleving van de DORA-vereisten kan leiden tot ernstige sancties. Hieronder vallen de opschorting van activiteiten, de noodzaak van openbare bekendmakingen en aanzienlijke financiële sancties. Het volgen van de richtlijnen van DORA is niet alleen het afvinken van vakjes voor naleving. Het is een voortdurende toewijding aan het verbeteren van onze verdediging tegen de dynamische cyberdreigingen die de financiële sector bedreigen en het waarborgen van de veerkracht en integriteit van onze digitale activiteiten.

Digitaal operationeel testprogramma van DORA

En dan nu de technische dingen waar we allemaal van houden. Artikel 25[9] van DORA beschrijft de digitale operationele weerbaarheidstests die financiële entiteiten moeten uitvoeren. Deze tests variëren van ‘kwetsbaarheidsbeoordelingen en scans’ tot ‘penetratietests’. De reikwijdte is uitgebreid en omvat openbronanalyses, netwerkbeveiligingsbeoordelingen, gap-analyses, fysieke beveiligingsbeoordelingen en, waar mogelijk, broncodebeoordelingen. Het omvat ook op scenario’s gebaseerde en compatibiliteitstests, evenals prestatie- en end-to-end tests. Door elk aspect van de beveiliging van een informatiesysteem te behandelen, wil DORA de robuustheid en veerkracht ervan garanderen.

Het is echter belangrijk om te onthouden dat het 4e artikel[10] van de DORA een aspect van flexibiliteit en afweging in de aanpak introduceert. Het legt het evenredigheidsbeginsel vast, waarbij wordt benadrukt dat de implementatie van cyberbeveiligingsmaatregelen en veerkrachttests moet worden afgestemd op de omvang, het risicoprofiel en de operationele complexiteit van elke financiële entiteit. Kleinere entiteiten of entiteiten die te maken hebben met verschillende soorten risico’s, kunnen zo een cyberbeveiligingsstrategie aannemen die zowel effectief als beheersbaar is en die is afgestemd op hun specifieke omstandigheden zonder overweldigend te zijn.

In de volgende paragrafen zal ik alles ontkrachten wat door een ethisch hackingteam kan worden behandeld. Helaas zal dit niet gaan over ‘Gap analysis’, ‘compatibility testing’, ‘performance’ en ‘source code reviews’, omdat die buiten het bereik vallen van mijn huidige rol bij Approach Cyber.

Kwetsbaarheidsscans en beoordelingen

De “kwetsbaarheidsscans en -beoordelingen”, die niet alleen in artikel 25, maar ook in artikel 8[11] van het DORA worden genoemd, benadrukken het belang van het voortdurend identificeren van ICT-risico’s. Een kwetsbaarheidsscan is voornamelijk een geautomatiseerd proces dat erop gericht is bekende zwakke plekken in de beveiliging van systemen op te sporen. Een kwetsbaarheidsscan is in de eerste plaats een geautomatiseerd proces gericht op het opsporen van bekende zwakke plekken in de beveiliging van systemen. Het is een goed onderdeel van routinematig beveiligingsonderhoud en biedt een uitgebreid overzicht van potentiële kwetsbaarheden. Toch is het cruciaal om te begrijpen dat deze scans geen vervanging zijn voor handmatige penetratietests. Terwijl scans bekende kwetsbaarheden kunnen aanwijzen, gaan handmatige penetratietests veel dieper. Het houdt in dat een tester echte aanvallen nabootst en creatief denkt om complexe kwetsbaarheden en exploits te ontdekken die geautomatiseerde tools over het hoofd zien.

Open-source analyse?

Het volgende punt op de agenda van DORA is open-source analyse, wat naar mijn mening nauw verbonden is met open-source intelligence (OSINT)1. Voor de niet-ingewijden: OSINT omvat het verzamelen, opslaan en analyseren van gegevens die openbaar beschikbaar zijn. Dit kan van alles zijn, van gelekte wachtwoorden tot vertrouwelijke bedrijfsinformatie. Hoewel het regelmatig controleren van dergelijke informatie misschien niet de standaardpraktijk is voor veel organisaties, is het een must voor teams die red team (end-to-end) oefeningen uitvoeren. Over red teams gesproken, deze oefeningen zijn niet alleen routinematige beveiligingscontroles en ze gaan ook niet alleen over het testen van de beveiliging van systemen of applicaties. Ze gaan ook over het onderzoeken van organisatorisch beleid en het menselijke element om het meest kritieke pad van uitbuiting te identificeren. En de effectiviteit van de aanwezige verdedigingen en procedures te evalueren.

Netwerkbeveiligingsbeoordelingen

Om verder te gaan met het volgende punt: DORA bevat ook een netwerkbeveiligingsbeoordeling als een van de vereisten. In het jargon van een pentester verwijst dit meestal naar penetratietests van de interne infrastructuur en pentests van de gebruikersdirectory. Dit soort tests mag niet ontbreken in een volwassen organisatiebeoordeling. Het maakt het mogelijk om potentiële gaten in netwerkcomponenten te identificeren en niet alleen kwetsbaarheden te beoordelen, maar ook privilege-escalatie2 en post-executievectoren (stap 5 tot 7 van het onderstaande).

Naarmate het bedrijf groeit en de infrastructuur evolueert, neemt de complexiteit van het up-to-date houden van apparaten, accounts en beleidsregels toe. Zelfs kleine misconfiguraties kunnen het algehele informatiesysteem (IS) aanzienlijk beïnvloeden[12].

Hoewel DORA specifiek jaarlijkse infrastructuur- en gebruikersdirectorytests vereist, wordt deze best practice aanbevolen voor alle organisaties, niet alleen die in de financiële sector. Het uitvoeren van deze tests is essentieel om een proactieve cyberbeveiligingshouding te handhaven en inbreuken te voorkomen.

Fysieke beveiliging en end-to-end testen

Bij het voorlaatste onderwerp van onze discussie staan fysieke beveiligingsbeoordelingen en end-to-end testen in de schijnwerpers. Deze reviews zijn een essentieel onderdeel van een uitgebreide beveiligingsstrategie. Ze richten zich op de fysieke aspecten van de beveiliging van een organisatie die vaak deel uitmaken van red team-oefeningen. Ze omvatten een breed scala aan tactieken, van het beoordelen van de beveiliging van Wi-Fi en bekabelde netwerken tot de bekende USB-drop tests. Een belangrijke factor in deze beoordelingen is het begrijpen en beperken van social engineering risico’s[13].

Dreigingsgestuurde penetratietests (TLPT)

Tot slot penetratietests op basis van scenario’s of penetratietests op basis van bedreigingen (TLPT). Bij TLPT worden live productieomgevingen gecontroleerd op basis van vooraf gedefinieerde scenario’s die door de financiële entiteit zijn gedefinieerd, maar door de bevoegde autoriteiten zijn gevalideerd. Het is verplicht om deze tests ten minste elke drie jaar door een externe entiteit te laten uitvoeren. Vooral als de financiële organisatie al een eigen intern team voor ethisch hacken heeft. Als gevolg hiervan moet de entiteit een samenvatting van relevante bevindingen, corrigerende actieplannen en documentatie over naleving aan de autoriteiten presenteren.

Hoewel de regelgevende technische normen, zoals criteria, methodologieën en processen, zijn gedefinieerd in het TIBER-EU-kader[14][15], waarvan de details buiten het bestek van deze blog vallen. Zoals beschreven in het 26e artikel van DORA[16], blijven de financiële entiteiten echter altijd volledig verantwoordelijk voor de naleving van de regelgeving voor ICT-diensten van derden die binnen het toepassingsgebied van dit soort tests vallen.

De penetratietestvereisten van DORA stimuleren een voortdurende en dynamische interactie tussen het rode team en het blauwe team. Voor de financiële sector is namelijk een cyberbeveiligingsstrategie nodig die zowel aanval als verdediging omvat. In deze context stellen penetratietests bedrijven in staat om te anticiperen op potentiële inbreuken en een staat van paraatheid en veerkracht te bereiken. Deze proactieve aanpak sluit aan bij DORA’s visie van operationele robuustheid, zodat organisaties niet alleen voorbereid zijn op de huidige bedreigingen, maar zich ook kunnen aanpassen aan toekomstige uitdagingen.

Blijf het spel voor met Approach Cyber’s ethische hackingdiensten.

En zorg ervoor dat je systeem klaar is voor updates.

Moge de balans tussen rood en blauw blijven bestaan bij het versterken van onze digitale verdediging.

Conclusie

En daar hebben we het dan, een uitgebreide (hoop ik) beschrijving van de Digital Operational Resilience Act, of DORA, zoals we die op deze blog hebben leren kennen. We begonnen met de basis – het ‘wat’, ‘wie’, ‘wanneer’ en ‘waarom’ – en doken diep in het domein van digitale operationele tests. Hier kon ik als pentester een stukje van mijn dagelijks leven delen op Approach Cyber. Van het begrijpen van de verstrekkende reikwijdte van DORA tot het doorgronden van de essentie van resiliëntietests, onze reis ging over het uitpakken van hoe deze regelgeving de ruggengraat van cybersecurity in de financiële sector kan vormen.

Ik hoop echt dat dit stuk wat licht heeft geworpen op DORA. Of je nu nieuwsgierig bent naar de toepassing ervan op jouw organisatie, naar de specifieke aspecten van het testen op naleving, of gewoon naar het veranderende landschap van cyberbeveiliging. Laat gerust een reactie achter of deel deze post op LinkedIn als je denkt dat anderen er iets aan hebben. Je kunt hier een andere blog van mij vinden.
En hartelijk dank dat je tot het einde van deze discussie hebt volgehouden.

1. Dit is mijn standpunt als ethisch hacker. Aangezien ‘open-source veiligheids- en risicoanalyse (OSSRA)’ onder ‘broncode-evaluatie’ valt, is er meer informatie: https: //www.synopsys.com/content/dam/synopsys/sig-assets/reports/rep-ossra-2023.pdf ↩︎
2. Zoals gedefinieerd in NIST SP 800-115, Section2.4.1, pagina 16, paragraaf 5. ↩︎