Det gjorde vi, da itb.dk blev hacket

IT-Branchens hjemmeside forsvandt i nogle formiddagstimer d. 23. april, da siden blev ramt af sårbarheden Drupalgeddon 2. Hvad gjorde vi – og kan gode råd gives videre?

Selvom det naturligvis aldrig er rart, at ens hjemmeside går ned pga. en sårbarhed, som hackere udnytter, er det en god anledning til at få testet, om din organisation nu også er klar til at overholde de krav, der træder i kraft med den nye persondataforordning 25. maj.

Når (ikke hvis) jeres systemer bliver hacket eller på anden måde kompromitteret, stilles der f.eks. krav om, at I evt. skal indberette hændelsen til Datatilsynet og til evt. berørte personer.

Det skal du vide ved et databrud

Først og fremmest skal I dog finde ud af, hvad der er sket og vurdere risikoen for de registreredes rettigheder som følge af databruddet.

Da vi blev ramt, kontaktede vi derfor den virksomhed, der hoster vores hjemmeside for at få mere information om:

  • Hvornår bruddet er sket
  • Årsagen til bruddet
  • Om der er personoplysninger, der er berørt (og i så fald hvilke, og for hvor mange)
  • Hvilke konsekvenser bruddet vil have for de berørte personer
  • Og hvad der er sket for at lukke hullet

De meldte hurtigt tilbage, at der var tale om en Drupalgeddon 2 sårbarhed, og at de var i gang med at patche, undersøge og sikre hjemmesiden for fremtidige angreb.

Vi fik med leverandøren hurtigt afklaret at der ikke var persondata, der var blevet kompromitteret, og konkluderede at der ikke var grund til at kontakte Datatilsynet eller berørte personer.

Havde der været læk af persondata, skulle vi have kontaktet Datatilsynet indenfor 72 timer.

Det lærte vi

Som led i IT-Branchens egen GDPR forberedelse til d. 25. Maj havde vi en skabelon vedr. Databrud klar som vi kunne sende til vores hostingudbyder, der svarede tilbage indenfor 72 timer.

Så fint at vi havde dokument og proces klar. Det hjalp på en hektisk formiddag. Du er velkommen til at hente vores egen interne skabelon her.

Hvis der havde været tale om persondatalæk, så må vi desværre også konstatere, at vores kommunikation med udbyderen tog for lang tid – bl.a. fordi vi ikke havde en SLA mht. reaktionstid og proces på sådanne ting.

Vi strammer af den grund op og sikrer, at der ligger en beskrevet og klar proces i forhold til, hvem vi skal kontakte hos vores udbydere af forskellige it-systemer, så vi kan nå at indsamle de rette data og få sendt dem videre i god tid.

En anden læring er, at du som kunde skal prioritere den løbende patching, også på systemer du er ved at migrere væk fra.

Så ja, IT-Branchen kan ligesom andre også hackes. Men forberedelse, reaktion og evaluering af de konkrete hændelsesforløb gør din organisation klogere. Og kan mindske både konkrete sårbarheder og tiden der går til du er i normal drift igen.

Hvad er det sværeste hos jer?

Vi håber, I kan bruge vores erfaringer til selv at blive skarpere på it-sikkerheden. Vi står selv frem med vores case, da vi mener, det gavner det fælles forsvar at dele viden herom.