En teknisk gennemgang viser, hvor opsætningen afviger fra en valgt målestok, på den dag udtrækkene blev trukket. Den viser ikke, om en afvigelse kan udnyttes, hvordan flere afvigelser virker sammen, eller hvad der sker i systemer, der ikke var med.
Grænserne er tekniske. De handler om, hvad en læsning af opsætningen kan bære som bevis, og hvad der kræver en anden teknik. Kender driften dem, kan den læse rapporten rigtigt og supplere, hvor det er nødvendigt.
Afvigelse er ikke det samme som udnyttelse
En konfigurationsgennemgang sammenligner indstillinger med en tjekliste og markerer afvigelserne. Sådan beskriver NIST metoden i sin vejledning fra 2008. Resultatet er en liste over steder, hvor opsætningen ikke svarer til målestokken.
Om en afvigelse kan bruges af en angriber, er et andet spørgsmål. En svag indstilling på en server, ingen kan nå, vejer anderledes end den samme indstilling på en server, der står mod internettet. Gennemgangen kan pege på eksponeringen, men den afprøver ikke vejen ind.
NIST skriver, at sårbarheder sjældent står alene, og at flere svagheder med lav risiko tilsammen kan give høj risiko. Ifølge vejledningen vurderes den samlede risiko mere pålideligt ved en penetrationstest. Den hører ikke til en teknisk gennemgang.
Kun det, målestokken spørger om
En gennemgang finder afvigelser fra de punkter, målestokken har. Har den valgte baseline ikke et punkt om en bestemt indstilling, bliver indstillingen ikke målt. Det gælder også punkter, som målestokken bevidst har udeladt.
Derfor er valget af målestok en del af resultatet. To gennemgange af samme miljø mod to forskellige målestokke giver to forskellige lister, og begge kan være korrekte. Rapporten skal sige, hvilken målestok der er brugt, og i hvilken version.
Kun det, der var med
Systemer uden for omfanget bliver ikke set. Står en server ikke på systemlisten, er den heller ikke i udtrækket. Det samme gælder en lejer, ingen kendte, et regelsæt på en filial eller et udstyr, en leverandør driver.
Bruges en stikprøve, gælder fundene de maskiner, der blev trukket. NIST skriver, at en lille stikprøve kan være næsten lige så effektiv, når maskinerne er ens opsat og styret centralt. Er de ikke det, kan afvigelserne gemme sig på de maskiner, der ikke var med. Hvordan stikprøven vælges, står i stikprøve af servere og klienter.
Kun det, rettighederne viser
Efter NIST kræver det rettigheder som administrator eller root at læse visse sikkerhedsindstillinger, også med automatiske værktøjer. Får den, der gennemgår, en læserolle, der ikke rækker hele vejen, bliver nogle indstillinger aldrig set. Det samme sker, når driften trækker et udtræk med en konto, der selv mangler rettigheder til dele af kataloget eller lejeren.
Det giver et hul, der ligner et rent resultat. En indstilling, der ikke kunne læses, er hverken i orden eller i uorden. Rapporten bør derfor skille de punkter, der er kontrolleret, fra dem, der ikke kunne kontrolleres med den givne adgang.
Kun dagen for udtrækket
NIST kalder en vurdering et øjebliksbillede af sikkerheden på et bestemt tidspunkt. En regel, der blev åbnet ugen efter, eller en konto, der blev oprettet dagen efter, findes ikke i rapporten.
Logs kan give lidt historik. De viser ændringer bagud i den periode, logningen dækker. Men en gennemgang ser fremad med udgangspunkt i den opsætning, der var, og siger ikke noget om opsætningen næste måned.
Kun det, papiret og systemet viser
En dokumentgennemgang viser hensigten. NIST skriver, at den ikke sikrer, at kontrollerne er gennemført korrekt, kun at retningen findes. Derfor holdes dokumenterne op imod udtræk.
Men også udtrækket har en grænse. Det viser, hvad der er sat op, ikke hvordan folk arbejder med det. Om administratorerne faktisk bruger deres særskilte konti, eller om en backup bliver kontrolleret, kræver historik, logs eller samtaler at belyse.
Det, der ligger helt udenfor
Grænsen er trukket teknisk. Ledelsens styring, risikovurderingen, ansvarsfordelingen og uddannelsen af medarbejdere hører ikke til en teknisk gennemgang. Det gør heller ikke undersøgelsen af, om nogen allerede har været inde i miljøet, eller hvordan en hændelse forløb.
Spørgsmålet om, hvad en audit af hele sikkerhedsarbejdet kan og ikke kan bevise, er beskrevet under den almene sikkerhedsaudit. Den tekniske gennemgang leverer bevis for opsætningen, og det bevis kan indgå dér.
Sådan supplerer driften
Mange af hullerne kan driften selv dække. Systemlisten kan afstemmes mod det, der faktisk svarer på nettet. Scanninger kan køres mellem to gennemgange. Ændringsloggen kan vise, hvad der er sket siden udtrækket. Og målestokken kan genbruges som tjekliste ved nye systemer.
Hvad det kræver, og hvad det koster at lade være
Det kræver, at rapportens begrænsninger står i rapporten: omfang, målestok, stikprøve og dato. Det kræver også, at den, der læser rapporten, ved, hvad den ikke dækker.
Læses en ren rapport som et bevis for, at miljøet er sikkert, bliver tilliden større end beviset. Det mærkes først, når en svaghed uden for omfanget bliver brugt.
Det skal I lade være med
- At læse “ingen fund” som “ingen risiko” · fundene gælder målestok, omfang og dato.
- At udelade systemer, I ikke har styr på · netop dér er afvigelserne sandsynlige.
- At bruge rapporten som bevis for hele sikkerhedsarbejdet · den dækker teknikken.
Det skal gennemgangen kunne vise
- ☐ Omfanget, med de systemer der var med, og dem der ikke var.
- ☐ Målestokken pr. platform med version.
- ☐ Dato for hvert udtræk.
- ☐ Stikprøvens størrelse og udvælgelse, hvor der er brugt stikprøve.
Kilder
- NIST, SP 800-115 Technical Guide to Information Security Testing and Assessment, september 2008, afsnit 3.1, 3.4, 4.3 og 6.2, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Skriv omfang, målestok og dato øverst i jeres næste gennemgangsrapport, så læseren kender grænserne.
Læs også: Gennemgang, scanning eller penetrationstest · Er kontrollen der, eller har den virket?
→ Kontakt · Tlf. 70 13 63 23 · Teknisk sikkerhedsgennemgang hos Nielco IT
