Et regelsæt gennemgås regel for regel med tre spørgsmål: Er reglen stadig nødvendig, giver den kun den adgang, der skal til, og står den det rigtige sted i rækkefølgen? Fundene ligger typisk i regler, der er for brede, ikke bliver brugt mere, eller som ingen kan forklare.
Gennemgangen læser regelsættet. Den sender ikke trafik gennem firewallen for at se, hvad der slipper igennem.
Målestokken: NIST’s punkter for regelsæt
NIST SP 800-115 fra 2008 beskriver gennemgang af regelsæt som en passiv teknik. Formålet er at sikre, at regelsættet er fuldstændigt, og at finde huller og svagheder, fx brud på politikken eller kommunikationsveje, som ingen har tilsigtet. Læsningen kan også afsløre regler, der gør filtreringen ineffektiv.
For firewalls nævner NIST fem typiske kontroller:
- Hver regel er stadig nødvendig.
- Reglerne håndhæver mindste adgang, altså kun de IP-adresser og porte, der skal bruges.
- Specifikke regler udløses før generelle.
- Ingen porte står unødigt åbne.
- Regelsættet lader ikke trafik gå uden om andre forsvar.
For routeres adgangslister tilføjer NIST, at midlertidige regler fjernes, når de ikke bruges mere, og at alt, der ikke er godkendt efter politikken, afvises som standard.
Bilaget til forordning (EU) 2024/2690 peger samme vej. Adgang og kommunikation, som driften ikke har brug for, skal forhindres (punkt 6.7.2, litra c), og unødvendige forbindelser og tjenester skal forbydes eller slås fra udtrykkeligt (litra f). Det bilag er kun bindende for en lille kreds af udbydere af digitale tjenester. At andre virksomheder holder deres regelsæt op mod det, er vores tolkning.
Regeltyperne, der oftest giver fund
Inden for fagområdet går nogle regeltyper igen, når regelsæt bliver læst. Listen er praksis og ikke hentet fra en kilde:
- Regler med “any” i kilde, destination eller tjeneste, hvor en snævrere angivelse ville have været nok.
- Regler uden beskrivelse, ejer eller sagsnummer, så ingen kan sige, hvorfor de findes.
- Midlertidige åbninger til et projekt eller en leverandør, som aldrig blev lukket igen.
- Regler, der ifølge firewallens egne tællere ikke har ramt trafik i lang tid.
- Regler, der skygges af en bredere regel højere oppe og derfor aldrig rammes.
- Objekter og grupper, der peger på adresser, som ikke længere hører til jer.
Rækkefølgen er værd at læse for sig. En firewall stopper som regel ved den første regel, der passer. Står en bred tilladelse før en specifik blokering, virker blokeringen ikke.
Udtrækket, driften trækker
Grundlaget er et fuldt eksport af regelsættet med objekter, grupper, adresseoversættelse og kommentarer, taget fra den aktive konfiguration. Har firewallen tællere for, hvornår en regel sidst blev ramt, skal de med. Det er dem, der skiller den ubrugte regel fra den sjældne, men nødvendige.
Til hver regel hører et svar på, hvem der bad om den, og hvad den bruges til. Står det ikke i kommentarfeltet, kan ændringsloggen eller sagssystemet give svaret. Kan ingen svare, er reglen et fund, uanset om den er farlig.
Loggen hører også med. SAMSIK anbefaler at logge både tilladt og blokeret trafik med tid i UTC, afsender og modtager med IP og port, beslutning og datamængde. Den log viser, hvad en bred regel faktisk lukker ind, og gør det muligt at erstatte den med en smal uden at gætte.
Hvor ofte, og hvem der godkender
DORA’s tekniske standard, delegeret forordning (EU) 2024/1774, er den eneste læste kilde med et fast interval. Hvor systemerne bærer kritiske eller vigtige funktioner, efterprøver en finansiel enhed mindst hver sjette måned, at firewallreglerne er tilstrækkelige (artikel 13, sidste afsnit). Standarden kræver også, at politikken for netsikkerhed fastlægger roller, ansvar og trin for at specificere, gennemføre, godkende, ændre og revidere firewallregler og forbindelsesfiltre (artikel 13, litra h). Begge krav gælder finansielle enheder under DORA.
Bilaget til 2024/2690 nøjes med “med planlagte mellemrum” (punkt 6.7.3). Uden for DORA er det derfor jeres egen beslutning, hvor tit regelsættet læses. Gennemgangen kan efterprøve, at beslutningen findes, og at den bliver fulgt.
Et regelsæt i kanten er sjældent sidste lag. Filtreringen på selve maskinerne har sin egen artikel: den lokale firewall.
Det kan driften selv
Før nogen udefra ser på regelsættet, kan driften lave tre ting. Sorter reglerne efter, hvornår de sidst blev ramt, og læg de ældste øverst på en liste. Tilføj en kolonne til ejer og en til formål, og send listen rundt til systemejerne med en frist for svar. Regler, ingen svarer for, sættes til at logge i en periode, så det kan ses, om de bærer trafik.
Gentag øvelsen, når regelsættet er ryddet. Næste gang er listen kort, fordi kun nye regler mangler ejer. Det gør også gennemgangen udefra mindre, fordi de lette fund allerede er væk.
Hvad det kræver, og hvad det koster at lade være
Det kræver et eksport, adgang til tællere og log og en person, der kan svare for de vigtigste regler. Det tunge arbejde er at finde ejerne til gamle regler, og det kan driften klare selv, før gennemgangen begynder.
Vokser regelsættet uden oprydning, bliver det sværere at se, hvad firewallen egentlig tillader. En regel, ingen kan forklare, bliver stående, fordi ingen tør fjerne den. Med tiden er det netop de regler, der bestemmer, hvad der kan nå jeres servere.
Det skal I lade være med
- At slette regler alene ud fra tællerne · en regel til årsafslutning eller gendannelse kan være nødvendig uden at være ramt i flere måneder.
- At åbne “midlertidigt” uden slutdato · skriv datoen i kommentaren, og følg op på den.
- At lade leverandøren være eneste vej til regelsættet · I skal selv kunne trække eksportet.
Det skal gennemgangen kunne vise
- ☐ Et dateret eksport af det aktive regelsæt.
- ☐ En ejer og et formål for hver regel, der tillader trafik.
- ☐ En liste over regler uden træf i en periode, med en beslutning om hver.
- ☐ Den fastlagte frekvens for gennemgang af regelsættet og spor af den seneste.
- ☐ Logning af tilladt og blokeret trafik.
Kilder
- NIST SP 800-115, Technical Guide to Information Security Testing and Assessment (2008), afsnit 3.3, læst 13. november 2026.
- Gennemførelsesforordning (EU) 2024/2690, bilaget, punkt 6.7.2 og 6.7.3, læst 13. november 2026.
- Delegeret forordning (EU) 2024/1774, artikel 13, læst 13. november 2026.
- SAMSIK, Logning, en del af et godt cyberforsvar (januar 2023), læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Træk et eksport af regelsættet med tællere, og markér de regler, der mangler en ejer.
Læs også: Udgående trafik: hvad må serverne tale med? · Ændringsloggen som bevis
→ Kontakt · Tlf. 70 13 63 23 · Teknisk sikkerhedsgennemgang hos Nielco IT
