Simovits

DORA – När det röda laget knackar på

Under mitten av år 2022 antogs Digital Operation Resilience Act, även känt som DORA.
Kortfattat är DORA en EU-förordning ämnat att stärka den operativa säkerheten för verksamheter inom finansiella sektorn. Dessa kan summeras på 6 områden[1]:

  1. Riskhantering inom information- och kommunikationsteknik (IKT).
  2. Rapportering av allvarliga IKT-relaterade incidenter.
  3. Rapportering av allvarliga operativa, eller säkerhetsrelaterade incidenter relaterade till betalningar.
  4. Testning av det digitala försvaret.
  5. Utbyte av information och underrättelser vid cyberhot och cybersårbarheter.
  6. Åtgärdshantering för tredjepartsrelaterade IKT-risker.

I den här bloggposten presenteras en överblick och tolkning av kraven som ställs på s.k. hotbildsstyrda penetrationstester, motsvarande punkt 4, (Threat Led Penetration Testing (TLPT) och hur detta kommer ändra behovet på regelbundna säkerhetstester.

Vad är TLPT?

Begreppet TLPT är ett nytt begrepp som inte använts i branschen tidigare. Kollar vi närmare på G-7 Fundamental Elements of Cybersecurity for the Financial Sector[2] så kan vi utläsa att TLPT är en övning ämnad att under kontrollerade former kompromettera det digitala försvaret för en entitet genom att simulera de taktiker, tekniker och procedurer som används av verkliga hotaktörer[3]. Utövarna ska inför övningen tilldelas den minsta möjliga mängd dokumentation och annan relevant information om nätverket, personal och annan information som skulle kunna nyttjas för att formulera angrepp. I stället ska det angripande laget, som en del av övningen, samla in relevanta data från offentliga källor som därefter nyttjas för att formulera en angreppsplan.

De aspekter som definierar TLPT är att jämställa med Red Team-övningar, vilket är ett begrepp som mer bekant på den svenska marknaden.

Vem får utföra övningen?

När det kommer till vem som ska utföra övningen så är DORA flexibel. Sammanfattningsvis ställs följande krav på utövarna av testet[4]:

DORA ställer inte krav på externa utövare. Däremot tillkommer följande krav om utövarna är anställda inom samma entitet som testerna ska utföras mot[5].

Hur ska testerna vara strukturerade?

Medan DORA inte ställer krav på hur testerna ska vara strukturerade så kan vi fortfarande utläsa att testerna ska täcka flera, eller alla kritiska och viktiga funktioner och system inom den finansiella entitetens nätverk och följa riskbaserad metodik[7]. Kombinerar vi det med upplägget för en ordinarie red team-övning så kan vi landa i en struktur som ser ut enligt följande:

  1. Planeringsfasen: Under den här fasen diskuterar ledningen på den finansiella entiteten och utövarna hur omfattningen av testerna ska se ut och vilka system som ska, respektive inte ska inkluderas i övningen. Under planeringsfasen presenterar representanter för den finansiella entiteten de risker som framarbetas och vilka system som bedömts vara verksamhetskritiska. Denna information ligger till grund för utövarnas testplan.
  2. Rekognosering: Den här fasen kännetecknar det första steget i de faktiska testerna. Under fasen samlar utövarna in information om den finansiella entiteten och dess anställda från publika källor, så som LinkedIn och företagshemsidor.
  3. Initialt fotfäste: Utövarna erhåller ett fotfäste på den finansiella entitetens nätverk. Vanligtvis erhålls det genom att exploatera servrar exponerade mot internet eller än mer vanligt- genom phishing-mail. Vidare bör det tilläggas att vissa red team-övningar hoppar över steg 2 och börjar här under ett s.k. “assumed breach”-scenario.
  4. Lateral förflyttning: Utövarna samlar in resurser från det interna nätverket eller enheten de fått det initiala fotfästet på för att förflytta sig på nätverket. Syftet är att komma åt en mer förmånlig resurs, exempelvis i form av hoppservrar eller enheter med svagare skydd.
  5. Exploatering: Utövarna utnyttjar konfigurationsbrister eller tidigare insamlad information för att eskalera sina behörigheter till den grad att de kan uppnå sitt mål. I kontext av DORA kan detta handla om att uppvisa kontroll över de kritiska funktionerna och systemen.

Vad händer efter testerna?

DORA kommer inte med några överraskningar när det kommer till de förväntade slutprodukterna av ett test. Kort sammanfattat förväntas följande av de finansiella entiteterna:

Kollar vi slutligen på den efterfrågade frekvensen på tester så hittar vi ett minimumkrav på åtminstone var tredje år och den tillhörande klausulen att en behörig myndighet vid behov kan begära att den finansiella entiteten minskar eller ökar frekvensen på testerna givet riskprofilen.

Vägen framåt

Införandet av DORA kommer för vissa verksamheter innebära en stor förändring i hur man arbetar med den digitala operativa motståndskraften och hur man bemöter cyberhot. Givet utvecklingen, där vi ser fler och mer påkostade cyberangrepp riktade mot just finansiella entiteter så finns det stora fördelar med att kontinuerligt testa sin motståndskraft mot hotaktörer.


[1] https://eur-lex.europa.eu/eli/reg/2022/2554/oj  Kapitel 1 Artikel 1

[2] https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/1134064/2018-10-24-g7-fundamental-elements-led-penetration-testing-data.pdf

[3] Exempelvis statssponsrade hackergrupper eller en grupp antagonister som utför angrepp i syfte att uppnå monetär vinst.

[4] https://eur-lex.europa.eu/eli/reg/2022/2554/oj Kapitel 2 art 27

[5] https://eur-lex.europa.eu/eli/reg/2022/2554/oj Kapitel 2 art 27

[6] https://eur-lex.europa.eu/eli/reg/2022/2554/oj Kapitel 2 art 26

[7] https://eur-lex.europa.eu/eli/reg/2022/2554/oj Kapitel 4 art 24

[8] https://eur-lex.europa.eu/eli/reg/2022/2554/oj Kapitel 2 art 26