TLS-certifikater er dukket op som et standardpunkt på revisionsagendaen — og ikke kun i ISO 27001-audits. NIS2-tilsyn, ISAE 3000-rapportering, interne revisioner og leverandørevalueringer begynder alle at stille specifikke spørgsmål om, hvordan organisationen styrer sine certifikater.
Mange IT-chefer og CISO'er opdager det sent: at det spørgsmål revisorerne stiller ikke er "har I TLS?" men "kan I dokumentere at I styrer jeres TLS systematisk?"
Hvad ISO 27001 kræver
ISO 27001:2022 Annex A kontrol 8.24 omhandler eksplicit brug af kryptografi og nøglestyring. Kontrol 8.20 dækker netværkssikkerhed inkl. TLS-konfiguration. Kontrol 5.9 og 5.10 handler om aktivfortegnelse og acceptable brug.
Revisor vil typisk spørge:
- Har I en politik for brug af kryptografi og certifikater?
- Er alle certifikater registreret — hvem ejer dem, hvornår udløber de?
- Er der en defineret proces for fornyelse og hvem der er ansvarlig?
- Kan I dokumentere at fornyelser gennemføres rettidigt?
- Hvad sker der med certifikater der ikke længere er i brug?
Hvad NIS2-tilsyn kigger efter
NIS2-tilsyn er mere procesorienteret end ISO 27001. Tilsynet vil undersøge om organisationen har et velfungerende risikostyringssystem — og certifikater er en målbar, konkret del af det.
Spørgsmål der typisk stilles:
- Har I et komplet aktivregister over jeres informationssystemer og de certifikater de bruger?
- Har I dokumenteret risiciene forbundet med certifikatudløb og TLS-konfiguration?
- Hvad er jeres kontroller for at sikre at certifikater fornys inden udløb?
- Kan I vise historik over hændelser og hvad der blev gjort?
- Hvad er jeres procedure for at rapportere en certifikatrelateret hændelse?
Hvad der er sværest at svare på
Baseret på revisionssamtaler er der typisk tre spørgsmål organisationer har sværest ved at besvare tilfredsstillende:
"Er I sikre på at jeres certifikatregister er komplet?" — Svaret "vi tror det er komplet" er ikke et godt svar. Revisor vil forstå processen: hvordan ved I at der ikke er certifikater I ikke kender til? Automatiseret scanning og CT-log overvågning er det eneste svar der holder.
"Hvad skete der senest en fornyelse fejlede eller trak ud?" — Hvis I ikke har et system der logger dette, kan I ikke svare. Et tomt svar signalerer at I ikke ved det — ikke at der ikke er sket noget.
"Hvem er ansvarlig for certifikat X?" — For certifikater på systemer hostet af leverandører eller oprettet af afdelinger uden for IT er svaret ofte uklart. Det er et rødt flag for revisor.
Hvad der faktisk imponerer revisorerne
Erfaringen fra organisationer der klarer revisioner godt på dette område er konsistent:
- De kan trække en aktuel rapport over alle certifikater med status og udløbsdatoer med få klik
- De kan vise en tidsserie der dokumenterer at monitoring har kørt kontinuerligt
- De har en dokumenteret, navngiven ansvarlig for hvert certifikat
- De kan vise at advarslerne fungerer — fx ved at vise de seneste alarmnotifikationer
- De har en skriftlig procedure for certifikathændelser — kort og operationel
Ingen af disse krav er svære at opfylde med det rigtige værktøj. Det er svært at opfylde med regneark og kalendernotater.
Forberedelse til revision: Tjekliste
- Komplet certifikatregister med udløbsdatoer, ejere og tilknyttede systemer
- Dokumenteret monitoringstatus — hvornår kørte sidste scanning?
- Alarmkonfiguration — hvem modtager advarsler og ved hvilke tærskler?
- Hændelsesprocedure for certifikatudløb og kompromittering
- Liste over leverandørers certifikater på jeres domæner
- Rapport over udløbte certifikater de seneste 12 måneder og hvad der skete
- Kryptografipolitik med reference til TLS-standarder og certifikatkrav