Penetration-test

Hærdningsstandarder og sikkerhedsbaselines: et fælles udgangspunkt

Hærdningsstandarder og sikkerhedsbaselines: et fælles udgangspunkt

Efter en penetrationstest kan IT-afdelingen stå med fund, der handler om opsætning: indstillinger, der aldrig blev ændret, tjenester, der ikke bruges, og servere, der er sat op forskelligt. Spørgsmålet er så, hvad den rigtige opsætning er. En hærdningsstandard, også kaldet en sikkerhedsbaseline, er et offentliggjort sæt anbefalede indstillinger for en bestemt type system, og den kan bruges som det fælles udgangspunkt. Svaret på, hvordan den bruges, hviler på tre led: I vælger en kendt baseline, tilpasser den til jeres drift med registrerede afvigelser, og måler løbende, om systemerne følger den.

Hvad en baseline er

En baseline beskriver, hvordan et styresystem, et program eller et stykke udstyr bør være sat op set ud fra sikkerhed. Den kan dække indstillinger for login, rettigheder, logning, netværkstjenester og funktioner, der bør slås fra.

Den amerikanske standardorganisation NIST beskriver sådanne tjeklister for sikker opsætning i sin vejledning om det nationale tjeklisteprogram. Ifølge vejledningen kan tjeklisterne bruges til at sætte et produkt op, kontrollere opsætningen og opdage ændringer, der ellers kunne gå upåagtet hen, og de kan mindske angrebsfladen og begrænse virkningen af et vellykket angreb.

Hvem udgiver baselines?

Der findes flere udgivere. To af dem, som IT-afdelinger med Windows-miljøer kan møde, er disse.

  • Producentens egne baselines · Microsoft udgiver sikkerhedsbaselines for Windows, Windows Server og egne programmer. Ifølge Microsoft er en baseline en samling anbefalede indstillinger med en forklaring af deres betydning for sikkerheden, og Microsoft anbefaler at bruge en kendt og afprøvet baseline frem for at skrive en selv.
  • Uafhængige konsensusstandarder · Center for Internet Security, en amerikansk nonprofitorganisation, udgiver CIS Benchmarks. Ifølge organisationen er de anbefalinger for opsætning, der er udarbejdet i et konsensusarbejde mellem fagfolk, og de dækker produktfamilier fra flere producenter, herunder styresystemer, cloudplatforme og netværksudstyr.

Valget afhænger af, hvad I har. Et miljø med mange forskellige producenter kan have gavn af en udgiver, der dækker dem alle. Et miljø, der næsten kun består af én producents produkter, kan tage udgangspunkt i producentens egen baseline. Det vigtigste er, at alle systemer af samme type følger den samme standard.

Nogle systemer har ingen offentliggjort baseline. Det kan gælde specialudstyr, ældre forretningssystemer eller små apparater på netværket. Her kan producentens egen vejledning om sikker opsætning være udgangspunktet. Findes den heller ikke, kan I skrive en kort minimumsstandard ud fra de samme principper: kun de nødvendige tjenester, ændrede standardadgangskoder, begrænset administrationsadgang og opdateret software. Skriv også ned, hvorfor der ikke findes en bedre kilde, så valget kan tages op igen. Drifter en leverandør systemerne, bør det fremgå af aftalen, hvilken baseline leverandøren følger.

Baseline og penetrationstest svarer på hver sit spørgsmål

En baseline spørger: er systemet sat op, som det bør være? En penetrationstest spørger: hvad kan en angriber faktisk nå med den opsætning, der er? De to supplerer hinanden. → Hærdning forklaret

En gennemgang mod en baseline kan finde mange afvigelser, uden at nogen af dem kan bruges til noget alvorligt i jeres miljø. En penetrationstest kan finde en alvorlig vej gennem netværket, som består af indstillinger, der hver for sig er i overensstemmelse med baselinen, men tilsammen åbner for misbrug. Testen viser også ting, en baseline ikke dækker, fx rettigheder i Active Directory, delte mapper og adgangskoder i scripts.

Brug derfor testens fund til at spørge, om baselinen dækker det, der blev fundet. Hvis ikke, skal standarden udvides. Hvis den gør, men systemet ikke fulgte den, er det et spørgsmål om udrulning og opfølgning.

Tilpasning og afvigelser

En baseline er skrevet til et generelt miljø. Microsoft skriver om sine baselines, at de er designet til velstyrede organisationer, hvor almindelige brugere ikke har administratorrettigheder. Hvis jeres miljø ikke ser sådan ud, vil nogle indstillinger give problemer, og andre vil ikke give den forventede beskyttelse. → Brugere med administratorrettigheder

Tilpasning er derfor normal, men den skal ske åbent.

  1. Start med baselinen som den er · og afprøv den på en lille gruppe systemer.
  2. Notér hver afvigelse · hvilken indstilling, hvorfor den er ændret, og hvem der har godkendt det.
  3. Begræns afvigelsen · gælder den alle systemer eller kun dem, der har brug for den?
  4. Sæt en dato for ny vurdering · afvigelser, der skyldes et gammelt system, kan forsvinde, når systemet udskiftes.

En afvigelse uden begrundelse er en svaghed, som ingen har taget stilling til. En afvigelse med begrundelse er en beslutning, der kan forklares over for en tester, en revisor eller en ny kollega.

Udrulning og vedligehold

En baseline, der kun ligger som dokument, ændrer intet. Den skal udrulles gennem den centrale styring, I allerede bruger, fx gruppepolitikker for maskiner i Active Directory eller enhedspolitikker for administrerede enheder. → Gruppepolitikker som testområde · → Administrerede enheder i Intune

Udrul trinvis som ved andre ændringer, og hold øje med, hvad der holder op med at virke. Når en ny udgave af styresystemet eller baselinen kommer, skal I tage stilling til forskellene, ikke blot overtage den nye udgave i blinde.

Mål løbende, hvor mange systemer der følger baselinen, og hvilke der afviger uden registreret grund. Et system, der afviger, kan være sat op i hånden, flyttet uden for den centrale styring eller ændret under fejlfinding og aldrig sat tilbage. Hver af de forklaringer peger på en lille rettelse i processen. Det er en kontrol, IT kan lave mellem testene uden en ekstern tester. → Sårbarhedsscanning mellem testene

Det skal I lade være med

  • At skrive jeres egen standard fra bunden. Begynd med en kendt baseline.
  • At udrulle baselinen på hele miljøet på én gang. Afprøv først.
  • At tilpasse uden at notere hvorfor. Så kan ingen se forskel på et valg og en fejl.
  • At tro, at en baseline erstatter testen. Den måler opsætning, ikke hvad en angriber kan nå.
  • At lade baselinen stå uændret i årevis. Nye udgaver kræver ny vurdering.

Hvad kan og ikke kan konkluderes

At systemerne følger en kendt baseline, viser, at opsætningen svarer til et anerkendt udgangspunkt med de afvigelser, I har valgt. Det viser ikke, at miljøet er sikkert som helhed, fordi en baseline ikke dækker rettigheder, sammenhænge mellem systemer og jeres egne data. En penetrationstest kan vise, hvor baselinen ikke rækker. Overholdelse af en baseline er heller ikke en certificering eller et bevis på, at bestemte krav fra kunder eller myndigheder er opfyldt.

Tjekliste til baselinen

  • ☐ Er der valgt en baseline for hver type system?
  • ☐ Er baselinen afprøvet på en lille gruppe før bred udrulning?
  • ☐ Er hver afvigelse begrundet, godkendt og registreret?
  • ☐ Rulles baselinen ud gennem central styring?
  • ☐ Måles det løbende, hvilke systemer der afviger?
  • ☐ Er testens fund holdt op mod baselinen?
  • ☐ Har baselinen en ejer, der følger nye udgaver?

Kilder

  • CIS Benchmarks: Center for Internet Security beskriver sig som en uafhængig nonprofitorganisation og CIS Benchmarks som konsensusbaserede anbefalinger for opsætning, der dækker produktfamilier fra flere producenter.
  • Microsoft Learn: Security baselines guide: definition af en baseline, anbefalingen om at bruge en kendt og afprøvet baseline og forudsætningen om velstyrede organisationer uden administratorrettigheder til almindelige brugere.
  • SP 800-70 Rev. 5: tjeklister for sikker opsætning kan bruges til opsætning, kontrol og opdagelse af ændringer og kan mindske angrebsfladen.

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Artikler til IT-afdelingen

Læs også: Servere som testområde · Klienttest for IT-afdelingen

→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Skal jeres miljø testes?

Fortæl kort, hvilke dele af jeres miljø der skal testes, og hvornår I skal bruge resultatet. Så vender jeg tilbage. Testen og rådgivningen er uvildige og uafhængige, og Nielco IT har ikke indgået forhandleraftaler med leverandører.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.