Test, som en hacker tænker

"Jamen, de blev jo hjulpet indenfor." "Så er det jo lidt snyd, er det ikke?" En sætning vi indimellem hører, når vi har gennemgået resultatet af en teknisk sikkerhedstest – en hacker-test udført som "Assume Breach".

Når den IT-sikkerhedsansvarlige i en virksomhed står med en rapport, der er blodrød med angivelser af en mængde kritiske sårbarheder og fejlkonfigurationer, handler det om at finde en god forklaring overfor virksomhedsledelsen og andre interessenter, hvorfor det ser så skidt ud.

I dette blogindlæg gennemgår jeg vigtigheden af at lave en såkaldt Assume Breach-test – og sætter lup under, hvorfor du er bagud, hvis I ikke tester sikkerhedsforanstaltninger ud fra hvad en hacker (formentlig) tænker. Læs videre, hvis du er på udkig efter anbefalinger.

Assume Breach: Er det ikke bare snyd?

I en Assume Breach Test – som navnet antyder – tager man udgangspunkt i at en hacker kan komme uset inden for muren. Det vil sige, at testen tager udgangspunkt i, at hackeren har fået udleveret en standard laptop eller virtuel maskine sammen med en ganske almindelig brugerkonto.   
 
Derfra søger hackeren at bevæge sig rundt i infrastrukturen og finde de krummer, der kan flytte hackeren over på andre enheder eller forøge dennes rettigheder via en lateral og horisontal bevægelse i infrastrukturen.   
 
Målet vil ofte være fuld domæneovertagelse som eks. Domæne Administrator, muligheden for at udtrække følsomme data, ændre i data og lignende. Altså: Målet er at bryde fortroligheden, integriteten og/eller tilgængeligheden.   
 
Men er det ikke snyd, når hackeren bliver hjulpet indenfor? Det korte svar er nej.   
 
Det længere svar er, at vi gerne beviser, at man kan kompromittere en organisation via phishing e-mails, via fysisk kompromittering i en ”Black Team”-test eller ved at anvende en ekstern sårbarhed.   
 
Vi kan ikke garantere, at det på det konkrete tidspunkt lykkes inden for et rimeligt forbrug af konsulenttid. Hvis det var så enkelt, ville vi som samfund stå over for meget større udfordringer, end vi trods alt gør. Men er vi først inde, så vil jeg godt garantere, at vi lykkes. Før eller siden.

Supply Chain – den største cybertrussel 

Når vi ser på trusselsudviklingen de senere år – særligt de store cyberangreb som Mærsk, SolarWinds-sagen, Coop i Sverige, Move-IT, Odense Universitets Hospital og mange flere – så er der særligt ét fællestræk: at cyberangreb i dag ofte sker via et Supply Chain-angreb.   
 
Angreb via Supply Chain bør anses for den altoverskyggende største trussel virksomheder i relation til IT- og cybersikkerhed skal håndtere. For principperne om ”zero trust” og ”trust but verify” lever i overvejende del på et teoretisk niveau og alt for sjældent i praksis.   
 
Så når en underleverandør bliver hacket og dermed skaffede angriberen en uhindret adgang ind bag borgmuren, er man ofte prisgivet, hvis man ikke har arbejdet struktureret for at imødegå denne trussel.   
 
Det er den barske realitet, at vi ikke længere kan gemme os bag borgmure og voldgrave i forsvaret mod de cyberkriminelle. Hvis du ønsker et effektivt forsvar, både i forhold til økonomi og udbytte i form af læring, så bør du teste ud fra en Assume Breach-tilgang.   
 
Det er den bedste metode til at få indsigt i de nødvendige, mitigerende handlinger og til at forberede sig på den dag, hvor det ikke er en venligsindet konsulent, men en ondsindet hacker, der kommer på besøg. 

Flere år bagefter de cyberkriminelle

Opgaven med at forbedre sikkerheden kan for flere synes uoverskuelig. Særligt fordi mange virksomheder og organisationer er flere år bagefter de cyberkriminelle i forhold til evner og modenhed.   
 
Mange anvender stadig infrastruktur, der blev etableret for et årti eller mere siden. Maskinen har måske fået lidt olie undervejs, når det knirkede, men ellers har det overvejende fået lov at passe sig selv. Også selv om der på labels står historiske navne som “NT”, “XP” og “2012r2”. Den løbende rengøring og vedligehold har været stærkt begrænset.  
 
Cyber- og informationssikkerhed handler basalt set om at have styr på mennesker, processer og teknologier. De tre fokusområders formål er at beskytte fortroligheden, integriteten og tilgængelighed for data, systemer og services i eller understøttet af IT.   
 
Det lyder jo umiddelbart enkelt. Ansæt de rette personer og uddan dem. Få styr på processer, procedurer og arbejdsinstruktioner, så man ved, hvem der gør hvad, hvordan og hvornår. Og anvend de relevante teknologier på den korrekte måde. 

Fortrolighed, integritet og tilgængelighed 

Der skal passes på data, systemer og services. Der skal holdes styr på fortroligheden, så kun de relevante personer og systemer har adgang. Dataintegriteten skal holdes intakt, så vi kan stole på, at indhold er korrekt. Og så skal der være tilgængelighed.  

Servicen skal være oppe, så den kan understøtte funktionen. Tænk eksempelvis på MitID, som kan medføre omfattende konsekvenser for borgerne og erhvervslivet, hvis servicen er nede.   
 
Det lyder jo egentlig simpelt nok, det der med at passe på data. Men hvad så med de tests, som både NIS2 og særligt DORA stiller krav om?  

Hvordan tester vi evnen til at imødegå cyberangreb mest effektivt – også ud fra et økonomisk perspektiv?  Og hvad sker der, hvis hackerne kommer ind i vores systemer? I disse tilfælde er alle de gode politikker nyttesløse. En politik nedfældet på papir har aldrig stoppet en hacker.   
 
Vi starter med at teste ud fra en hackers mindset. Den tankegang kan vi så bruge til at definere vores strategi, vores politikker og processer. Når vi kender det aktuelle niveau, kan vi lægge en strategi ud fra dette.  Du kan ikke starte omvendt med strategien, hvis du ikke ved, hvor slemt det står til. 

Antag det uundgåelige – test som en hacker arbejder 

Når det kommer til at definere virksomhedens tekniske teststrategi, er det en klar anbefaling at arbejde modulbaseret frem for at køre det hele i én stor og dyr sikkerhedstest.  Det involverer blandt andet følgende steps:

• Teknisk phishing test og awareness
• Assume Breach
• Test af Backup og Restore
• Test af kritiske applikationer

Penetrationstest og ”hacking” er sjældent som man ser det i amerikanske actionfilm. Det er i hvert fald ikke lige så nemt at hacke en virksomhed, som filmkulturen har det med at fremstille det. Det betyder dog ikke nødvendigvis, at der er tale om en høj modenhed.   
 
Overvej scenariet: En brandbombe eller Molotovcocktail kastes mod en husfacade. Skaden vil som udgangspunkt være begrænset med mindre særligt uheldige omstændigheder er til stede. Samme brandbombe detoneres i sofaen i stuen. Her er en større brandskade nærmest uundgåelig, og risikoen for total nedbrænding er overhængende. Samme brandbombe men forskellige steder for detonation. 

Ind skal de nok komme 

Det er almindeligt kendt, at en stor del af cyberangreb starter via e-mail phishing. Men hvis e-mail phishing skal anvendes i et målrettet angreb, er der risiko for, at det slår fejl.   
 
Der udsendes millioner af phishingmails på daglig basis. Blandt andet som del af opportunistiske angrebsforsøg via såkaldte ”Initial Access Brokers”. Organiserede grupper, der har gjort det til en sortbørsforretning at skaffe sig adgang til en hvilken som helst virksomhed eller organisation, og så sælge denne adgang på det sorte marked.   
 
Sagt med andre ord: Dét cyberangreb din virksomhed udsættes for, er højst sandsynligt ikke en del af et målrettet komplot. I var blot de uheldige, der var på det forkerte sted på det forkerte tidspunkt – og faldt i fælden.  
 
Det er ikke ualmindeligt, at initial adgang er 9-12 måneder undervejs, før det egentlige angreb som eks. ransomware eller datatyveri og efterfølgende afpresning igangsættes.  

Derfor bør I teste ud fra en antagelse om, at nogen kan komme ind ad hoveddøren – eller via et vindue på klem. Test og træning af medarbejderne i at spotte phishing e-mails er fortsat et vigtigt element. Men tag det som et selvstændigt modul, på samme måde som ”hacker-testen” bør være det.