Hvad der rent faktisk skete

Den rekonstruktion, der er kommet frem fra undersøgende journalistik, er enkel, hvilket er præcis det, der gør den urovækkende. En angriber fik kontrol over en e-mailkonto tilhørende et ægte myndighedskontor. Fra den konto sendte de anmodninger om kundeoplysninger til fintech-virksomheden, udformet som krav fra politiet. Anmodningerne kom fra et ægte myndighedsdomæne, så de bestod de tekniske kontroller, der normalt flager identitetstyveri, og blev dirigeret gennem virksomhedens normale proces for håndtering af forespørgsler fra myndigheder og politi.

Virksomheden behandlede anmodningerne som legitime og videregav oplysningerne. Den beskrev senere hændelsen som et eksternt identitetstyveri snarere end et brud på dens egne systemer, og den vinkling holder ved nærmere eftersyn: der er intet offentligt bevis på en indtrængen i netværket, og virksomheden har oplyst, at kunders midler og kernesystemer aldrig blev kompromitteret. Hvad der skete, var et brud på persondatasikkerheden, og under GDPR's egen definition er det sandt, uanset om en eneste server blev berørt. Uautoriseret videregivelse til den forkerte part er et brud, punktum.

En verificeret afsender er ikke det samme som en autoriseret anmodning

Den ubehagelige indsigt, der ligger under denne hændelse, er en, som de fleste organisationer ikke fuldt ud har indregnet: autentificering og autorisation er forskellige problemer, og de fleste videregivelsesprocesser tjekker kun det første.

SPF, DKIM og DMARC eksisterer for at besvare ét spørgsmål: kom denne besked rent faktisk fra det domæne, den påstår at komme fra? De er gode til det job. De siger intet om, hvorvidt den specifikke person, der sendte den, var autoriseret til at stille denne bestemte anmodning, om det juridiske grundlag, de henviser til, rent faktisk gælder, eller om omfanget og arten af det, de beder om, matcher en legitim forespørgsel. En kompromitteret konto i et ægte myndighedsdomæne stryger lige igennem alle tre kontroller. Domænet er ægte. Personen bag er det i dette tilfælde ikke.

Anmodninger fra myndigheder og politi bærer en specifik form for institutionel tillid, der gør dette 'gap' værre, ikke bedre. En anmodning, der ser officiel ud, har det med at blive behandlet hurtigere og draget mindre i tvivl, hvilket er præcis den antagelse, en angriber satser på.

Den del, der bør bekymre compliance-teams mere end selve datalækket

En enkelt svindele-mail, der slipper igennem, er en skidt dag. Hvad der forlydende skete her, er anderledes: det samme mønster af anmodninger fortsatte uopdaget over en længere periode. Det er ikke en historie om én e-mail, der slap forbi et filter. Det er en historie om en verifikationsproces, der ikke havde nogen mekanisme til at fange en velautentificeret forfalskning, selv efter at den allerede havde virket mere end én gang.

De fleste organisationer kan henvise til en politik, der siger, at anmodninger fra myndigheder behandles omhyggeligt. Langt færre kan vise, at politikken indeholder et specifikt, obligatorisk trin, såsom at bekræfte anmodningen via en uafhængigt fundet kontaktkanal – ikke en, der oplyses i selve anmodningen – før noget videregives. Uden det trin nedskrevet og faktisk håndhævet bliver "behandles omhyggeligt" støt og roligt til "behandles som enhver anden anmodning", og ingen opdager det, før det allerede er sket gentagne gange.

Hvad der er bekræftet, og hvad der stadig blot er påstande

En del af det at skrive ansvarligt om en igangværende hændelse er at være ærlig om, hvilke detaljer der er vished om, og hvilke der ikke er endnu. På nuværende tidspunkt:

Rimelig veldokumenteret: En angriber brugte en kompromitteret e-mailkonto fra en myndighed til at indsende falske anmodninger om kundedata. Virksomheden videregav data som svar i den tro, at anmodningerne var legitime. Virksomhedens egne systemer og kundemidler blev ikke kompromitteret. Myndighederne undersøger sagen.

Rapporteret af medierne, ikke officielt bekræftet: Det specifikke antal berørte kunder, og præcis hvilket myndighedskontors konto der var kompromitteret.

Alene påstået af angriberen, ubekræftet af enhver officiel myndighed: Den samlede datamængde, der hævdes at være opnået, varigheden af hvor længe den bagvedliggende myndighedskonto påstås at have været kompromitteret, og kravet om løsesum. Governance-praksis er klar på dette punkt: En trusselaktørs egne påstande om, hvad de ligger inde med, er markedsføring for afpresningsforsøget, ikke beviser, før noget uafhængigt bekræfter dem.

Hvad dette betyder, hvis din organisation nogensinde modtager en anmodning fra en myndighed

Næsten enhver reguleret organisation – finansielle tjenesteydelser, sundhedsvæsen, telekommunikation – har en eller anden proces til at besvare anmodninger om data fra politi og myndigheder, fordi loven generelt kræver det. Det spørgsmål, denne hændelse rejser, er ikke, om den proces eksisterer. Det er, om processen har en reel kontrol indbygget til præcis dette scenarie: en anmodning, der ser fuldstændig legitim ud, men måske ikke er det.

En rimelig kontrol her er specifik, ikke generel. Noget i retning af: Før du videregiver personoplysninger som svar på en anmodning fra en myndighed, domstol eller politimyndighed, skal du uafhængigt verificere rekvirentens identitet og bemyndigelse, det juridiske grundlag for anmodningen og dens omfang ved hjælp af kontaktoplysninger, der er fremskaffet uafhængigt, snarere end oplysninger, der er angivet i selve anmodningen. Anmodninger af stort omfang eller af usædvanlig karakter skal gennemgås en ekstra gang, før noget sendes ud.

Skrevet ned lyder det indlysende. Grunden til, at det svigter i praksis, er, at det sjældent findes et sted, hvor et modtageteam rent faktisk ser det i øjeblikket, og det bliver sjældent testet mod en anmodning, der ser helt rigtig ud.

Hvordan Formalize understøtter dette

Dette er et kontrolproblem, før det er et teknologiproblem, og Formalizes rolle er at sikre, at kontrollen rent faktisk eksisterer andre steder end i et politikdokument, som ingen åbner under pres. I praksis betyder det:

• En dokumenteret kontrol for videregivelse til myndigheder og politi, placeret sammen med dine øvrige kontroller i stedet for i en separat politikmappe, og med en navngiven ejer.

• Verifikationstrin indbygget i workflowet, så en anmodning bliver tjekket op imod definerede kriterier før videregivelse, ikke efter.

• En registrering af, hvem der godkendte en videregivelse og hvorfor, så begrundelsen allerede er der, i stedet for at skulle rekonstrueres fra hukommelsen, hvis en anmodning drages i tvivl senere.

• Den samme kontrol genanvendt på tværs af frameworks, da denne type videregivelsesrisiko berører GDPR og ofte også overlapper med forpligtelser under frameworks som DORA eller ISO 27001.

Intet af det erstatter sund fornuft. Det sikrer blot, at dømmekraften anvendes konsekvent, hver gang – inklusiv den ene gang, hvor det gælder mest.