Assume breach: test, der starter bag forsvaret

Hvad sker der, hvis en angriber først er kommet ind? Det er spørgsmålet bag en assume breach-test, hvor testeren fra starten får en adgang, der svarer til det, en angriber kunne have opnået, fx en almindelig medarbejders computer og konto.

Udgangspunktet bygger på en nøgtern antagelse: før eller siden kan nogen komme forbi det yderste forsvar. En medarbejder kan klikke på en mail, en adgangskode kan blive kendt, eller en leverandørs adgang kan blive misbrugt. I stedet for at bruge testtiden på at bevise, at det kan ske, springer testen det skridt over og undersøger, hvad der følger efter.

Hvorfor springe indgangen over?

En test, der starter udefra, bruger en del af sin tid på at finde en vej ind. Hvis vejen ikke findes inden for den afsatte tid, siger rapporten meget om det ydre forsvar, men intet om resten. Det er en fin oplysning, men den kan give et skævt billede af sikkerheden som helhed.

En assume breach-test bruger i stedet tiden på det, der ligger bag. Kan en almindelig medarbejder nå servere og data, de ikke har brug for? Kan adgangen udvides til flere rettigheder? Kan man fra kontornettet nå ERP-systemet, backup eller produktionen? Opdager overvågningen noget undervejs?

Svarene er relevante, fordi de beskriver, hvor stor skaden kan blive, når en indgang først er fundet. → Ekstern eller intern penetrationstest

Forskellen fra en almindelig intern test

En intern test tager også udgangspunkt inde på nettet, men ofte med en tilsluttet testmaskine og uden en bestemt brugers rettigheder. Den undersøger nettet bredt fra en placering.

En assume breach-test er mere specifik. Den efterligner en bestemt situation: en bestemt type medarbejder, på en almindelig arbejdscomputer, med de rettigheder og programmer, den medarbejder har. Udgangspunktet er dermed tættere på det, en angriber faktisk ville have efter en vellykket indgang. → Klienttest i en penetrationstest

Grænsen mellem de to er ikke skarp, og betegnelserne bliver brugt forskelligt. Spørg derfor altid, hvad udgangspunktet konkret er, frem for at nøjes med navnet.

Vælg udgangspunktet med omtanke

Det vigtigste valg er, hvilken adgang testeren skal starte med. Valget bør afspejle en situation, I faktisk er bekymrede for.

En almindelig kontormedarbejder · en standardcomputer og en konto med almindelige rettigheder. Det svarer til situationen efter en vellykket mail mod en vilkårlig medarbejder. → Phishing-test
En medarbejder med særlig adgang · fx en person i økonomi med adgang til ERP-systemet eller en i kundeservice med adgang til kundeoplysninger.
En hjemmearbejdsplads · en computer, der forbinder sig via fjernadgang. → Hjemmearbejde og penetrationstest
En leverandøradgang · den adgang, driftsleverandøren eller en anden leverandør har til jeres systemer.

Udgangspunktet skal stå i aftalen med konto, maskine og rettigheder. Det er det, rapportens konklusioner skal læses ud fra.

Hvad testen kan fortælle om adskillelse og rettigheder

En assume breach-test er især god til at vise, om interne grænser holder. Et net kan være fladt, så alle maskiner kan tale med hinanden, og rettigheder kan være vokset over tid uden at blive ryddet op. Testen kan vise, om en almindelig konto kan bruges til at nå systemer, der burde være adskilt. → Segmentering og penetrationstest

Den kan også vise, om centrale systemer som brugeradministrationen er sat op, så en almindelig konto ikke kan bruges til at få flere rettigheder. Den tekniske dybde i den del hører til specialister i netop de platforme. → Active Directory set fra køberen

Resultatet giver et grundlag for at prioritere. Hvis testen viser, at en almindelig konto kan nå backup eller ERP-systemets database, er det en tydelig besked om, hvad der skal adskilles først.

Overvågningen kan følge med

En assume breach-test kan kombineres med en afprøvning af overvågningen. Hvis driftsleverandøren eller et overvågningscenter skal opdage usædvanlig aktivitet, kan testen vise, om testerens handlinger blev set, og hvornår.

Det kræver en beslutning om, hvem der kender til testen. Skal overvågningen afprøves, må den ikke vide alt på forhånd. Men nogen hos virksomheden og hos leverandøren skal kunne skelne testen fra en reel hændelse. Når overvågning og reaktion bliver hovedformålet, nærmer opgaven sig red teaming. → Red teaming eller penetrationstest

Drift og data under testen

Testeren arbejder inde i den daglige drift, på en maskine der ligner medarbejdernes og med adgang til de samme systemer. Det stiller krav til aftalerne. Skriv, hvilke systemer testeren må forsøge at nå, og hvilke der skal lades i fred, fx produktionsanlæg eller betalingssystemer, hvor en forstyrrelse kan få direkte følger.

Aftal også, hvad der sker, hvis testeren når frem til følsomme oplysninger som løndata eller kundeoplysninger. Det er ofte nok at påvise, at adgangen findes, uden at åbne flere oplysninger end nødvendigt. Testeren bør melde med det samme, hvis et fund har så stor betydning, at det ikke kan vente til rapporten.

Testmaskinen og kontoen skal oprettes, så de ikke ved en fejl giver testeren mere end det aftalte. Hvis IT-afdelingen giver kontoen ekstra rettigheder for at få den til at virke, er udgangspunktet ikke længere det, I bestilte. Kontrollér derfor kontoen, før testen begynder, og notér eventuelle afvigelser, så de kan nævnes i rapporten.

Det skal I lade være med

At vælge udgangspunktet tilfældigt · Det skal afspejle en situation, I faktisk er bekymrede for.
At udlevere en administratorkonto som start · Så er spørgsmålet om udvidelse af rettigheder allerede besvaret.
At læse resultatet som en test af det ydre forsvar · Indgangen var givet på forhånd og blev ikke afprøvet.
At glemme at fortælle kontaktpersonen hos driftsleverandøren · Nogen skal kunne skelne testen fra en reel hændelse.
At lade testmaskine og konto stå efter testen · Fjern dem som en del af oprydningen.

Hvad kan og ikke kan konkluderes

En assume breach-test kan vise, hvad der kunne opnås fra det aftalte udgangspunkt på testtidspunktet, og om interne grænser og rettigheder holdt. Den kan også vise, om overvågningen opdagede noget, hvis det var en del af opgaven.

Den kan ikke vise, hvor let det er at komme ind i første omgang, fordi den adgang blev givet. Den kan heller ikke tale for andre udgangspunkter end det valgte. En almindelig medarbejders adgang siger ikke noget om, hvad en leverandøradgang kan bruges til.