Penetrationstest, Assume Breach, scanning eller sikkerhedsanalyse?

Ordene bruges ofte i flæng. Det burde de ikke.

En sårbarhedsscanning, en penetrationstest, et Assume Breach-forløb og en sikkerhedsanalyse kan alle afdække sikkerhedsproblemer — men de starter forskellige steder og besvarer forskellige spørgsmål.

Vælger I den forkerte metode, risikerer I at få en teknisk korrekt rapport, der ikke svarer på det, organisationen reelt har brug for at vide.

Hvad er forskellen på de fire metoder?

Metode	Det centrale spørgsmål	Typisk fremgangsmåde	Primært resultat
Sårbarhedsscanning	Har vi kendte tekniske sårbarheder?	Overvejende automatiseret scanning	Liste over mulige sårbarheder og fejlkonfigurationer
Sikkerhedsanalyse	Hvor er vores væsentligste sikkerhedsrisici?	Dataindsamling, konfigurationsgennemgang og manuel vurdering	Prioriteret risikobillede og handlingsplan
Penetrationstest	Kan de aftalte systemer kompromitteres i praksis?	Kontrolleret manuel test og udnyttelse	Dokumenterede angrebsveje og reproducerbare fund
Assume Breach	Hvad sker der, hvis en angriber allerede er inde?	Kontrolleret angrebsforløb fra en standardkonto eller almindelig arbejdsstation	Angrebskæde, konsekvens og vurdering af detektionsevnen

Hvad er en sårbarhedsscanning?

En sårbarhedsscanning undersøger systemer, services og software for kendte sårbarheder, manglende opdateringer og almindelige fejlkonfigurationer.

Scanningen udføres typisk med automatiserede værktøjer, der sammenholder det fundne miljø med databaser over kendte sårbarheder. NIST beskriver i SP 800-115 blandt andet, at sårbarhedsscanning kan identificere forældet software, manglende patches og afvigelser fra sikkerhedspolitikker.

En scanning er især nyttig, når I vil:

• skabe et hurtigt overblik over mange systemer
• finde kendte sårbarheder og manglende opdateringer
• følge udviklingen løbende
• kontrollere, om tidligere fund er blevet håndteret
• supplere organisationens patch- og sårbarhedsstyring

Begrænsningen er, at scanneren ikke forstår forretningskonteksten. Den kan levere falske positiver eller overvurdere et fund, som ikke kan udnyttes i den konkrete opsætning — og omvendt overse risici, der slet ikke er tekniske sårbarheder, men farlige konfigurationsvalg.

Et rent scanningsresultat er derfor ikke dokumentation for, at miljøet er sikkert. Det betyder primært, at værktøjet ikke fandt kendte problemer inden for det undersøgte scope.

Hvad er en sikkerhedsanalyse?

En sikkerhedsanalyse — ofte kaldet et security assessment — undersøger et miljø bredere end en traditionel sårbarhedsscanning.

Her gennemgås eksempelvis identiteter, rettigheder, konfigurationer, sikkerhedskontroller, logning, administratorroller og tekniske afhængigheder. Automatiseret dataindsamling kan indgå, men resultaterne vurderes manuelt og sættes ind i organisationens konkrete kontekst.

I et Microsoft 365-miljø kan analysen blandt andet omfatte:

• MFA og Conditional Access
• administrative roller og PIM
• gæster, partneradgang og B2B-samarbejde
• mailregler og ekstern videresendelse
• OAuth-tilladelser og Enterprise Apps
• SharePoint- og OneDrive-deling
• Intune, Defender, Secure Score og logning

I Active Directory kan analysen eksempelvis omfatte privilegerede konti, servicekonti, delegationer, trusts, GPO’er, LDAP-sikkerhed og adgangskodepolitikker. Det er præcis den type gennemgang, vores Microsoft 365 Security Assessment og Active Directory Security Assessment dækker.

En sikkerhedsanalyse passer især, når I spørger:

Hvor er vores væsentligste risici, og hvad bør vi gøre først?

Resultatet er normalt ikke alene en liste over tekniske fund, men en prioriteret handlingsplan, som både ledelsen og det tekniske team kan bruge.

En sikkerhedsanalyse forsøger derimod ikke aktivt at kompromittere miljøet — hos os er den altid read-only og uden driftspåvirkning (selve password-testen i AD-analysen foregår offline på en beskyttet kopi og sender ingen loginforsøg mod produktionsmiljøet). Den kan vise, at en konfiguration skaber risiko, uden at demonstrere hele angrebskæden i praksis.

Hvad er en penetrationstest?

En penetrationstest efterprøver, om aftalte systemer eller sikkerhedskontroller kan omgås eller kompromitteres i praksis.

Testen udføres inden for et skriftligt aftalt scope med klare regler for, hvilke systemer der må testes, hvornår testen må udføres, og hvor langt specialisterne må gå.

NIST beskriver penetrationstest som sikkerhedstest, hvor testeren efterligner realistiske angreb for at afdække, hvordan sikkerheden i et system, en applikation eller et netværk kan omgås. Testen leder ofte efter kombinationer af svagheder, som tilsammen giver større adgang end det enkelte fund.

En penetrationstest er relevant, når I vil:

• efterprøve en interneteksponeret flade
• teste en webapplikation eller et API før lancering
• dokumentere, om konkrete sårbarheder kan udnyttes
• efterprøve et miljø, som jeres egen leverandør har etableret
• få reproducerbare beviser og konkrete angrebsveje
• opfylde et kunde-, revisions- eller kontraktkrav

Bemærk i øvrigt forskellen: Vores kortlægning af eksponerede Exchange-servere identificerede angrebsfladen passivt — den var netop ikke en penetrationstest.

En penetrationstest er imidlertid afgrænset af tid og scope. Hvis testen kun omfatter en webapplikation, siger resultatet ikke nødvendigvis noget om sikkerheden i Microsoft 365, Active Directory eller resten af organisationens infrastruktur.

En penetrationstest er derfor ikke et generelt sikkerhedsstempel. Den besvarer et mere præcist spørgsmål:

Kan en kompetent angriber kompromittere det, vi har aftalt at teste?

Hvad er Assume Breach?

Assume Breach simulerer situationen efter det første sikkerhedsbrud.

I stedet for først at forsøge at komme gennem organisationens ydre forsvar får testeren et aftalt udgangspunkt — typisk en kompromitteret standardkonto eller en almindelig arbejdsstation.

Herfra undersøges det kontrolleret:

• om angriberen kan bevæge sig mellem systemer
• om rettigheder kan eskaleres
• om privilegerede konti kan kompromitteres
• om kritiske data og systemer kan nås
• hvor stor den mulige konsekvens er
• hvad organisationens sikkerhedsløsninger opdager undervejs
• hvor hurtigt der reageres på aktiviteten

Microsoft beskriver »assume breach« som et af de grundlæggende Zero Trust-principper: Sikkerhedskontroller skal designes ud fra en forventning om, at en angriber allerede kan befinde sig i miljøet. Fokus bliver derfor at begrænse konsekvensen og forbedre detektion og respons.

Et Assume Breach-forløb er især relevant for organisationer, der allerede har etableret et vist sikkerhedsniveau og nu vil kende svaret på:

Hvad kan en angriber reelt opnå efter ét vellykket phishing-klik?

Forløbet tester ikke nødvendigvis hele perimeteren. Til gengæld giver det et mere direkte billede af organisationens modstandsdygtighed, segmentering og detektionsevne efter den første kompromittering.

Hvilken metode skal I vælge?

Vælg en sårbarhedsscanning, når:

• I vil finde kendte tekniske sårbarheder på mange systemer
• I har brug for løbende og gentagelig kontrol
• I allerede har en proces til at validere og prioritere resultaterne
• målet primært er patch- og sårbarhedsstyring

Vælg en sikkerhedsanalyse, når:

• I mangler et samlet billede af jeres sikkerhed
• I ikke ved, hvor den største risiko ligger
• I vil have konfigurationer og kontroller vurderet i deres sammenhæng
• ledelsen har brug for et prioriteret beslutningsgrundlag
• I skal beslutte, hvad der efterfølgende bør testes mere aktivt

Vælg en penetrationstest, når:

• I har en konkret applikation, flade eller infrastruktur, der skal efterprøves
• I vil vide, om svagheder kan udnyttes i praksis
• I har brug for reproducerbare beviser
• I vil have en uvildig tredjepart til at teste en leverandørs løsning

Vælg Assume Breach, når:

• I vil kende konsekvensen af en kompromitteret bruger eller maskine
• I vil teste lateral bevægelse og eskalering af rettigheder
• I vil efterprøve segmentering og adgang til kritiske systemer
• I vil vide, om jeres overvågning faktisk opdager et aktivt angreb

Hvad er den rigtige rækkefølge?

For mange organisationer er den mest værdifulde rækkefølge:

1. Sikkerhedsanalyse for at skabe et bredt og prioriteret risikobillede
2. Udbedring af de vigtigste fund
3. Penetrationstest af de mest kritiske eller eksponerede flader
4. Assume Breach for at undersøge konsekvens og detektion efter kompromittering
5. Løbende sårbarhedsscanning til at opdage nye kendte problemer

Rækkefølgen er ikke teori. Den digitale kommunikations- og læringsvirksomhed Cadpeople havde oprindeligt planlagt endnu en traditionel penetrationstest, men valgte efter vores anbefaling at starte med en sikkerhedsanalyse. Deres egen konklusion: »Det viste sig at være den rigtige beslutning« — og analysen bruges i dag direkte i deres ISAE 3000-arbejde. Læs deres og andres vurdering under cases & anbefalinger.

Rækkefølgen er heller ikke universel. En ny internetvendt webapplikation kan have brug for en penetrationstest før lancering, selv om organisationen endnu ikke har gennemført en bred sikkerhedsanalyse. En moden organisation med løbende scanning og stærke baselines kan være klar til Assume Breach uden først at gennemgå alle tidligere trin.

Det afgørende er, at metoden vælges ud fra den beslutning, resultatet skal understøtte.

Fem spørgsmål, I bør stille før testen

Før I bestiller en scanning, analyse eller test, bør leverandøren kunne svare klart på:

1. Hvilket spørgsmål skal forløbet besvare?
2. Hvilke systemer, brugere og miljøer indgår i scopet?
3. Er undersøgelsen automatiseret, manuel eller en kombination?
4. Må fundne svagheder udnyttes — og i hvilket omfang?
5. Får vi en prioriteret handlingsplan og mulighed for efterfølgende validering?

Hvis svarene er uklare, er det også uklart, hvad I reelt køber.

Ingen enkelt test kan stå alene

Sårbarhedsscanning, sikkerhedsanalyse, penetrationstest og Assume Breach er ikke konkurrerende betegnelser for det samme produkt. De er forskellige metoder, som supplerer hinanden.

Scanningen giver bredde. Analysen giver kontekst. Penetrationstesten giver praktisk efterprøvning. Assume Breach viser konsekvensen, når det første forsvar allerede er passeret.

Er I i tvivl om, hvor I skal begynde, er en bred, uvildig sikkerhedsanalyse ofte det bedste udgangspunkt. Den viser, hvor en efterfølgende penetrationstest eller et Assume Breach-forløb vil skabe størst værdi — og skal spørgsmålet først afklares, hjælper vi gerne. Uvildigt, og med en gratis foranalyse som første skridt.