Sikre konfigurationsbaselines for NIS2 og DORA

Fredag eftermiddags fejlkonfiguration, der blev et bestyrelsesanliggende

Kl. 16.40 en fredag godkendte den tekniske ansvarlige for en fintech-platform det, der lignede en rutinemæssig firewallændring. En midlertidig regel blev åbnet for at fejlfinde en integration med en udbyder af betalingsanalyse. Sagen lød: “fjernes efter test.” Testen blev gennemført. Reglen blev stående.

Tre uger senere fandt en ekstern scanning en administrativ grænseflade, der var tilgængelig fra internettet. Serveren var patchet. MFA var aktiveret for almindelige brugere. Sårbarhedsscanneren markerede ingen kritisk CVE. Men systemet var stadig ikke sikkert, fordi konfigurationen var afveget fra organisationens godkendte hærdede tilstand.

Mandag morgen havde CISO’en fire samtaler kørende parallelt:

1. Tilsynsmyndigheden ville vide, om den operationelle robusthed var blevet påvirket.
2. Databeskyttelsesrådgiveren ville vide, om personoplysninger var blevet eksponeret.
3. Bestyrelsen ville vide, hvorfor “midlertidige” ændringer ikke blev detekteret.
4. Den interne ISO/IEC 27001:2022-revisor ville se revisionsbevis for, at sikre baselines var defineret, godkendt, implementeret og overvåget.

Det er her, mange sikkerhedsprogrammer opdager en ubehagelig sandhed. Sikker konfiguration er ikke blot en teknisk hærdningstjekliste. I 2026 er sikre konfigurationsbaselines et spørgsmål om governance, cyberhygiejne, IKT-risiko, revisionsbevis og bestyrelsens ansvarlighed.

En anden version af samme problem udspiller sig i mange regulerede organisationer. Maria, CISO hos en voksende B2B-betalingsformidler, har dygtige teknikere, patchede systemer og god cloudpraksis. Men en parathedsvurdering for NIS2 og DORA fremhæver én rød observation: manglende formaliserede sikre konfigurationsbaselines. Hendes team ved, hvordan servere skal hærdes, men meget af den viden ligger i teknikernes hoveder, ikke i godkendte standarder, automatiserede kontroller eller bevispakker.

Det hul kan ikke længere forsvares. NIS2 kræver, at ledelsesorganer godkender og fører tilsyn med foranstaltninger til styring af cybersikkerhedsrisici. DORA kræver en dokumenteret ramme for styring af IKT-risici og robust IKT-drift. GDPR kræver passende tekniske og organisatoriske foranstaltninger. ISO/IEC 27001:2022 kræver risikobaseret kontroludvælgelse, implementering, overvågning, revision og løbende forbedring.

Sikre konfigurationsbaselines samler alle disse forpligtelser i ét praktisk kontrolsystem: definér baseline, tildel ejerskab, håndhæv den ved provisionering og idriftsættelse, styr undtagelser, detektér baselineafvigelser, dokumentér revisionsbevis og forbedr efter revisioner eller hændelser.

Som Clarysecs Zenith Blueprint: en revisors 30-trins køreplan beskriver det i fasen Kontroller i praksis, trin 19, Teknologiske kontroller I:

“Mange brud skyldes ikke softwarefejl; de skyldes dårlige konfigurationsvalg. Standardadgangskoder, der ikke ændres, usikre tjenester, der er aktiveret, unødvendige åbne porte eller systemer, der eksponeres mod internettet uden begrundelse.”

Den sætning viser, hvorfor sikre konfigurationsbaselines nu er en central kontrol for robusthed. De definerer, hvad sikker konfiguration betyder, før en revisor, tilsynsmyndighed, kunde eller angriber spørger.

Hvad en sikker konfigurationsbaseline reelt er

En sikker konfigurationsbaseline er det godkendte, dokumenterede og gentagelige sæt af sikkerhedsindstillinger for en systemtype. Den kan gælde for Windows-servere, Linux-værter, netværksenheder, SaaS-tenants, cloudlagre, Kubernetes-klynger, databaser, firewalls, endpoint-enheder, identitetsplatforme, IoT-enheder og operationel teknologi (OT).

En stærk baseline besvarer praktiske spørgsmål:

• Hvilke tjenester er deaktiveret som standard?
• Hvilke porte må eksponeres eksternt?
• Hvilke autentifikations- og MFA-indstillinger er obligatoriske?
• Hvilke logningsindstillinger skal være aktiveret?
• Hvilke krypteringsindstillinger kræves?
• Hvilke administrative grænseflader er begrænset?
• Hvilke cloudressourcer må være offentligt tilgængelige, og med hvis godkendelse?
• Hvilke afvigelser kræver risikoaccept?
• Hvor ofte kontrollerer vi for baselineafvigelser?
• Hvilket revisionsbevis dokumenterer, at baseline fungerer?

Den mest almindelige fejl er at behandle baselines som tekniske præferencer i stedet for styrede kontroller. En Linux-administrators tjekliste, en cloudarkitekts wikiside og en netværksingeniørs firewallkonvention kan alle være nyttige, men de bliver først reviderbare, når de er godkendt, kortlagt til risiko, anvendt ensartet og overvåget.

Derfor er ISO/IEC 27001:2022 et nyttigt anker. Pkt. 4.1 til 4.3 kræver, at organisationer forstår interne og eksterne forhold, interessenter og ISMS-omfang, herunder juridiske, regulatoriske, kontraktlige og tredjepartskrav. Pkt. 6.1.2 og 6.1.3 kræver risikovurdering af informationssikkerhed, risikobehandling, kontroludvælgelse, en Anvendelseserklæring og godkendelse fra risikoejer. Pkt. 8.2 og 8.3 kræver, at risikovurderinger og risikobehandling gentages med planlagte intervaller eller efter væsentlige ændringer.

Annex A gør derefter den tekniske forventning konkret gennem A.8.9 Konfigurationsstyring, understøttet af aktivfortegnelse, sårbarhedsstyring, ændringsstyring, logning, overvågning, adgangsstyring, kryptografi, brug af cloudtjenester og dokumenterede driftsprocedurer.

Resultatet er en enkel, men stærk governance-konklusion: Hvis organisationen ikke kan vise, hvad sikker konfiguration betyder for hver væsentlig systemtype, kan den ikke overbevisende dokumentere cyberhygiejne under NIS2, kontrol med IKT-risiko under DORA, ansvarlighed under GDPR eller kontroleffektivitet under ISO/IEC 27001:2022.

Hvorfor NIS2, DORA og GDPR gør baselines uundgåelige

NIS2, DORA og GDPR bruger forskelligt sprog, men de mødes om det samme driftsmæssige krav: systemer skal konfigureres sikkert, overvåges løbende og styres gennem ansvarlig risikostyring.

NIS2 Article 20 kræver, at ledelsesorganer i væsentlige og vigtige enheder godkender foranstaltninger til styring af cybersikkerhedsrisici, fører tilsyn med implementeringen og modtager cybersikkerhedstræning. Article 21 kræver passende og forholdsmæssige tekniske, driftsmæssige og organisatoriske foranstaltninger. Sikre konfigurationsbaselines understøtter Article 21(2)(a) om politikker for risikoanalyse og informationssystemsikkerhed, Article 21(2)(e) om sikkerhed ved anskaffelse, udvikling og vedligeholdelse af netværks- og informationssystemer, herunder håndtering af sårbarheder, Article 21(2)(f) om politikker og procedurer til vurdering af effektivitet, Article 21(2)(g) om grundlæggende cyberhygiejne og cybersikkerhedstræning, Article 21(2)(h) om kryptografi, Article 21(2)(i) om adgangsstyring og styring af aktiver samt Article 21(2)(j) om multifaktorgodkendelse og sikker kommunikation.

DORA gælder fra 17. januar 2025 og fungerer som den sektorspecifikke regelbog for operationel robusthed for omfattede finansielle enheder. Articles 5 og 6 kræver governance og en dokumenteret ramme for styring af IKT-risici. Article 8 kræver identifikation af IKT-aktiver, informationsaktiver, IKT-understøttede forretningsfunktioner og afhængigheder. Article 9 kræver beskyttelses- og forebyggelsesforanstaltninger, herunder sikkerhedspolitikker, procedurer, protokoller og værktøjer for IKT-systemer, sikker dataoverførsel, adgangsstyring, stærk autentifikation, beskyttelse af kryptografiske nøgler, ændringsstyring, patchning og opdateringer. Articles 10 til 14 udvider modellen til detektion, respons, genopretning, backup, genetablering, læring og kommunikation.

GDPR tilføjer databeskyttelsesperspektivet. Articles 5 og 32 kræver integritet, fortrolighed, behandlingssikkerhed og ansvarlighed gennem passende tekniske og organisatoriske foranstaltninger. Cloud buckets med offentlig adgang, overeksponerede databaser, usikre standardindstillinger og overdreven administratoradgang er ikke kun infrastruktursvagheder. De kan udvikle sig til svigt i beskyttelsen af personoplysninger.

Ét samlet program for sikre konfigurationsbaselines kan understøtte alle tre regelsæt uden at skabe parallelle bevisstrømme.

Clarysecs baselinemodel: politik, procedure og platformsbeviser

Clarysec behandler sikker konfiguration som et gentageligt kontrolsystem, ikke som et enkeltstående hærdningsprojekt. Baseline skal være autoriseret af politik, omsat til procedurer, implementeret gennem tekniske kontroller og dokumenteret med revisionsbevis.

Informationssikkerhedspolitik fastsætter denne forventning på organisationsniveau:

“Organisationen skal vedligeholde en minimumskontrolbaseline afledt af ISO/IEC 27001 Annex A, suppleret, hvor det er relevant, med kontroller fra ISO/IEC 27002, NIST SP 800-53 og COBIT 2019.”
Fra afsnittet “Risikobehandling og undtagelser”, politikklausul 7.2.1.

Denne klausul forhindrer, at konfigurationshærdning bliver en samling personlige præferencer. Den forankrer minimumskontrolbaselinen i anerkendte frameworks.

For cloudmiljøer præciserer Politik for brug af cloudtjenester kravet:

“Alle cloudmiljøer skal overholde en dokumenteret baselinekonfiguration godkendt af cloud-sikkerhedsarkitekten.”
Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.3.1.

Politik for audit og overvågning af efterlevelse gør derefter baseline til en overvåget kontrol:

“Automatiserede værktøjer skal implementeres til at overvåge efterlevelse af konfigurationskrav, sårbarhedsstyring, patchstatus og privilegeret adgang.”
Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.4.1.

Konfiguration kan heller ikke adskilles fra sårbarheds- og patchstyring. Politik for sårbarheds- og patchstyring fastslår:

“Afhjælpning af sårbarheder skal være i overensstemmelse med baselinekonfiguration og standarder for systemhærdning.”
Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.4.1.

Det er væsentligt. Et system kan være patchet og stadig være usikkert, hvis SMBv1 er aktiveret, administrative grænseflader er eksponeret, logning er deaktiveret, eller svage autentifikationsindstillinger fortsat er i brug. I Zenith Controls: vejledning til tværgående efterlevelse behandles konfigurationsstyring som en forebyggende kontrol, der beskytter fortrolighed, integritet og tilgængelighed, med driftsmæssig kapacitet inden for sikker konfiguration. Zenith Controls forklarer også afhængigheden mellem konfigurationsstyring og sårbarhedsstyring:

“Sårbarhedsstyring afhænger af kendte konfigurationer. Uden en defineret baseline er det umuligt at sikre, at patches anvendes ensartet.”

Det er den bevisfortælling, revisorer og tilsynsmyndigheder i stigende grad forventer: et kontrolsystem, ikke isolerede tekniske opgaver.

Kortlægning af ISO/IEC 27001:2022 A.8.9 til understøttende kontroller

ISO/IEC 27001:2022 Annex A-kontrol A.8.9 Konfigurationsstyring er ankeret, men den bør ikke behandles som et lille selvstændigt dokument. Den afhænger af en bredere kontrolfamilie.

Denne relation på tværs af kontroller er grunden til, at Clarysec anbefaler at styre sikker konfiguration som en ISMS-kapacitet med ejere, revisionsbevis, metrikker og ledelsesrapportering.

En bredere krydskortlægning hjælper med at omsætte det samme baselineprogram til andre frameworks.

En praktisk baselinestruktur, som kan implementeres denne måned

Den mest almindelige fejl er at forsøge at skrive en perfekt 80-siders hærdningsstandard, før noget håndhæves. Start med en minimal, men reviderbar baseline for hver væsentlig teknologifamilie, og modn den derefter gennem automatisering og gennemgang.

For en baseline for cloudlagring kan første version omfatte, at offentlig adgang er deaktiveret som standard, kryptering i hvile er aktiveret, adgangslogning er aktiveret, administratoradgang er begrænset til godkendte grupper, MFA kræves for privilegeret konsoladgang, versionsstyring er aktiveret, hvor genopretningskrav kræver det, replikering er begrænset til godkendte regioner, og ændringer kun udføres via godkendte infrastructure-as-code-pipelines.

For en Windows Server 2022-baseline, der understøtter betalingsbehandling, kan første version omfatte deaktiveret SMBv1, deaktiverede ikke-væsentlige tjenester, RDP begrænset til en hærdet jump host, Windows Defender Firewall aktiveret med standard-deny-regler, kontrollerede lokale administratorkonti, videresendelse af hændelseslogfiler til SIEM, aktiveret endpoint protection og administrative ændringer knyttet til godkendte sager.

For hver baseline skal der etableres en lille bevispakke:

1. Det godkendte baselinedokument.
2. Et skærmbillede eller en eksporteret politik, der viser den anvendte konfiguration.
3. En liste over aktiver, der er omfattet af baseline.
4. En ændringssag, der viser, hvordan opdateringer godkendes.
5. En rapport om efterlevelse af konfigurationskrav eller en manuel gennemgangsregistrering.

Dette passer direkte til Zenith Blueprint, fasen Kontroller i praksis, trin 19, hvor Clarysec anbefaler organisationer at etablere konfigurationstjeklister for væsentlige systemtyper, anvende indstillinger konsekvent ved provisionering gennem automatisering, hvor det er muligt, og derefter løbende revidere implementerede systemer. Blueprint giver også en praktisk revisionsmetode:

“Vælg nogle få repræsentative systemer (f.eks. én server, én switch og én slutbruger-PC), og validér, at deres konfiguration matcher den sikre baseline. Dokumentér afvigelser og afhjælpning.”

For SMV’er er denne repræsentative stikprøvetilgang ofte den hurtigste vej fra uformel hærdning til revisionsklart revisionsbevis.

Eksempler på hærdning for SMV’er, der hurtigt reducerer risiko

Sikker konfiguration er ikke kun et cloudspørgsmål for store organisationer. SMV’er opnår ofte den største risikoreduktion gennem nogle få klare baselineregler.

Politik for netværkssikkerhed - SMV fastslår:

“Kun væsentlige porte (f.eks. HTTPS, VPN) må eksponeres mod det offentlige internet; alle andre skal lukkes eller filtreres”
Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.1.3.

Den kræver også ændringsdisciplin:

“Alle ændringer af netværkskonfigurationer (firewallregler, switch-ACL’er, routingtabeller) skal følge en dokumenteret ændringsstyringsproces”
Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.9.1.

Og den etablerer en gennemgangsfrekvens:

“IT-supportleverandøren skal gennemføre en årlig gennemgang af firewallregler, netværksarkitektur og trådløse konfigurationer”
Fra afsnittet “Styringskrav”, politikklausul 5.6.1.

Endpoint-baselines kræver samme opmærksomhed. Clarysecs Politik for malwarebeskyttelse af endpoints - SMV fastslår:

“Enheder skal deaktivere forældede protokoller (f.eks. SMBv1), som kan udnyttes af malware”
Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.2.1.3.

For IoT- og OT-miljøer er usikre standardindstillinger fortsat en tilbagevendende eksponering. Politik for sikkerhed i Internet of Things (IoT) og operationel teknologi (OT) - SMV fastslår:

“Standard- eller hardkodede adgangskoder skal ændres, før enheder aktiveres”
Fra afsnittet “Styringskrav”, politikklausul 5.3.2.

Disse politikklausuler er ikke abstrakte udsagn. De er baselinekrav, der kan testes, dokumenteres og spores. For en SMV, der forbereder kunders due diligence, NIS2-leverandørgennemgange, cyberforsikring eller ISO/IEC 27001:2022-certificering, skaber de værdi med det samme.

Undtagelseshåndtering: kontrollen, der adskiller modenhed fra papirarbejde

Alle baselines vil have undtagelser. En ældre applikation kan kræve en gammel protokol. En leverandørappliance understøtter måske ikke den foretrukne krypteringsindstilling. En midlertidig firewallåbning kan være nødvendig ved migrering. Spørgsmålet er ikke, om undtagelser findes. Spørgsmålet er, om de styres.

En moden undtagelsesregistrering omfatter:

• Det baselinekrav, der fraviges.
• Den forretningsmæssige begrundelse.
• Det berørte aktiv og dets ejer.
• Risikovurderingen.
• De kompenserende kontroller.
• Godkendelsesmyndigheden.
• Udløbsdatoen.
• Overvågningskravet.
• Afhjælpningsplanen.

Det er her, ISO/IEC 27001:2022-risikobehandling og DORA-proportionalitet supplerer hinanden. ISO/IEC 27001:2022 kræver, at kontrolbeslutninger begrundes gennem risikovurdering, risikobehandling, Anvendelseserklæringen og godkendelse fra risikoejer. DORA tillader forholdsmæssig implementering baseret på størrelse, risikoprofil samt tjenesternes art, omfang og kompleksitet, men forventer fortsat dokumenteret styring af IKT-risici, overvågning, forretningskontinuitet, test og awareness.

Proportionalitet er ikke en tilladelse til at springe baselines over. Det er et krav om at skalere dem intelligent.

For en mikroenhed eller mindre finansiel enhed under en forenklet IKT-risikostyringsramme kan baseline være kortfattet og understøttet af manuel stikprøvekontrol. For en større finansiel enhed vil samme område sandsynligvis kræve automatiserede konfigurationskontroller, involvering af intern revision, årlig test og rapportering til ledelsesorganet.

Politik for ændringsstyring minder også organisationer om at holde øje med:

“Afvigelser fra baselinekonfigurationen eller manipulation efter godkendte ændringer”
Fra afsnittet “Håndhævelse og efterlevelse”, politikklausul 8.1.2.3.

Den formulering forbinder ændringsstyring med detektion af baselineafvigelser. En ændring kan være godkendt og stadig skabe risiko, hvis den implementerede tilstand adskiller sig fra den godkendte tilstand, eller hvis en midlertidig indstilling bliver stående, efter ændringsvinduet er lukket.

Opbyg ét revisionsspor for mange efterlevelsesforpligtelser

En sikker konfigurationsbaseline bør ikke skabe fem separate efterlevelsesspor. Clarysecs model anvender ét revisionsspor, der kortlægges til flere forpligtelser.

Nøglen er sporbarhed. Zenith Blueprint, fasen Revision, gennemgang og forbedring, trin 24, instruerer organisationer i at opdatere Anvendelseserklæringen og krydsverificere den med risikobehandlingsplanen. Hvis en kontrol er anvendelig, skal der være en begrundelse. Den begrundelse bør knyttes til risiko, retlig forpligtelse, kontraktligt krav eller forretningsbehov.

For sikker konfiguration bør SoA-posten for A.8.9 henvise til standarden for sikker konfigurationsbaseline, omfattede aktivkategorier, baselineejere, ændringsstyringsprocedure, overvågningsmetode, undtagelsesproces, gennemgangsfrekvens og tværgående efterlevelsesforpligtelser såsom NIS2 Article 21, DORA Articles 6, 8 og 9, GDPR Article 32 og kundetilsagn.

Hvordan revisorer tester sikre konfigurationsbaselines

Sikker konfiguration er attraktivt for revisorer, fordi området er rigt på revisionsbevis. Det kan testes gennem dokumenter, interviews, stikprøver og teknisk inspektion.

De praktiske spørgsmål er forudsigelige:

• Bruger I en hærdningstjekliste ved installation af nye servere?
• Hvordan forhindrer I usikre tjenester såsom Telnet i at køre på routere?
• Er cloudlagringsressourcer private som standard?
• Hvem kan godkende en afvigelse fra baseline?
• Hvordan detekterer I baselineafvigelser efter en ændring?
• Kan I fremvise en nylig konfigurationsgennemgang?
• Kan I dokumentere, at en detekteret afvigelse blev rettet?
• Bliver netværks- og cloudkonfigurationer sikkerhedskopieret og versionsstyret?
• Er tilbagerulningsprocedurer dokumenteret og testet?

De stærkeste organisationer vedligeholder en baselinebevispakke for hver væsentlig systemkategori. Det forkorter revisioner, forbedrer svar på kunders due diligence og hjælper ledelsen med at forstå den faktiske kontroludførelse.

Gør baselineafvigelser til en cyberhygiejnemetrik på bestyrelsesniveau

Bestyrelser har ikke brug for hver enkelt firewallregel. De har brug for at vide, om cyberhygiejnen forbedres eller forværres.

Et nyttigt dashboard for sikker konfiguration omfatter:

• Procentdel af aktiver kortlagt til en godkendt baseline.
• Procentdel af aktiver, der består baselinekontroller.
• Antal kritiske baselineafvigelser.
• Gennemsnitlig alder for åbne afvigelser.
• Antal udløbne undtagelser.
• Antal detekterede uautoriserede konfigurationsændringer.
• Procentdel af privilegerede konfigurationsændringer med godkendte sager.
• Undtagelser for offentlig eksponering i cloud.
• Status for baselinegennemgang pr. teknologifamilie.

Disse metrikker understøtter ISO/IEC 27001:2022-performanceevaluering, ledelsestilsyn under NIS2 og DORA-rapportering af IKT-risiko. De kan også naturligt kortlægges til styringsresultater i NIST CSF 2.0 og overvågnings- og efterlevelsesmål i COBIT 2019.

En enkel ledelsesregel hjælper: intet kritisk system sættes i drift uden baselinebevis. Dette kan håndhæves gennem ændringsstyring, CI/CD-gates, cloudpolitikkontroller, gennemgang af infrastructure-as-code, MDM-efterlevelse, GPO-håndhævelse eller gennemgang af netværkskonfiguration. Modenhedsniveauet kan variere, men kontrollogikken bør ikke.

90-dages playbook for sikre konfigurationsbaselines

Hvis I starter fra bunden, skal I ikke forsøge at løse alle konfigurationsproblemer på én gang. Brug en 90-dages plan.

Dag 1 til 30: definér minimumsbaseline

Identificér kritiske aktivkategorier. For hver kategori tildeles en teknisk ejer, risikoejer og godkendelsesmyndighed. Opret en første baseline for de indstillinger, der er mest relevante for robusthed mod ransomware, cloudeksponering, privilegeret adgang, logning, kryptering og databeskyttelse.

Opret baselineregisteret, og kortlæg det til ISMS-omfang, risikoregister og Anvendelseserklæring. Hvis I er omfattet af NIS2, skal I identificere, om I er en væsentlig eller vigtig enhed, eller om kunder forventer NIS2-tilpasset cyberhygiejne. Hvis I er en finansiel enhed under DORA, skal I identificere, hvilke IKT-aktiver der understøtter kritiske eller vigtige funktioner. Hvis I behandler personoplysninger, skal I kortlægge systemer til GDPR-behandlingsaktiviteter og datakategorier.

Dag 31 til 60: håndhæv og indsaml revisionsbevis

Anvend baseline på en stikprøve af højrisikosystemer. Brug automatisering, hvor det er muligt, men vent ikke på perfekte værktøjer. Eksportér konfigurationer, tag skærmbilleder, gem politikindstillinger og registrér ændringssager.

For hver undtagelse oprettes en risikoregistrering med udløbsdato. For hver afvigelse oprettes en afhjælpningssag.

Dag 61 til 90: overvåg, rapportér og forbedr

Gennemfør en konfigurationsgennemgang. Udtag stikprøver af én server, ét endpoint, én netværksenhed og ét cloudmiljø. Sammenlign faktiske indstillinger med den godkendte baseline. Dokumentér afvigelser og korrigerende handlinger.

Rapportér baselineefterlevelse til ledelsen. Opdatér Anvendelseserklæringen og risikobehandlingsplanen. Send tilbagevendende afvigelser til rodårsagsanalyse. Hvis en fejlkonfiguration forårsagede eller bidrog til en hændelse, opdateres den relevante baseline som led i lessons learned.

Det giver revisorer noget testbart, tilsynsmyndigheder noget forståeligt og ledelsen noget, der kan styres.

Afsluttende pointe: sikker konfiguration er cyberhygiejne med beviser

NIS2 bruger sproget om foranstaltninger til styring af cybersikkerhedsrisici og grundlæggende cyberhygiejne. DORA bruger sproget om IKT-risiko, robusthed, overvågning, forretningskontinuitet og test. GDPR bruger sproget om passende foranstaltninger og ansvarlighed. ISO/IEC 27001:2022 bruger sproget om risikobehandling, kontroller, dokumenterede oplysninger, performanceevaluering og løbende forbedring.

Sikre konfigurationsbaselines forbinder dem alle.

De viser, at systemer ikke idriftsættes med usikre standardindstillinger. De viser, at ændringer er kontrollerede. De viser, at baselineafvigelser detekteres. De viser, at undtagelser er risikoaccepteret. De viser, at revisionsbevis findes, før revisoren spørger.

Vigtigst er det, at de reducerer reel driftsrisiko. Fredag eftermiddags firewallregel, den offentlige cloud bucket, den glemte SMBv1-indstilling, standardadgangskoden på IoT-enheden og den uloggede administratorkonsol er ikke teoretiske revisionskonstateringer. De er praktiske fejlpunkter.

Clarysec hjælper organisationer med at omsætte disse fejlpunkter til kontrollerede, overvågede og reviderbare baselines.

Næste skridt

Hvis organisationen skal dokumentere sikker konfiguration for ISO/IEC 27001:2022, NIS2-cyberhygiejne, DORA-styring af IKT-risici, GDPR-ansvarlighed eller kundesikkerhedsdokumentation, kan I starte med Clarysecs værktøjssæt:

• Brug Zenith Blueprint: en revisors 30-trins køreplan til at implementere konfigurationsstyring i fasen Kontroller i praksis, trin 19, og validere den gennem fasen Revision, gennemgang og forbedring, trin 24.
• Brug Zenith Controls: vejledning til tværgående efterlevelse til at kortlægge konfigurationsstyring til understøttende ISO/IEC 27001:2022-kontroller, NIS2, DORA, GDPR, NIST SP 800-53, COBIT 2019 og revisionsmetodikker.
• Brug Clarysec-politikker såsom Informationssikkerhedspolitik, Politik for brug af cloudtjenester, Politik for audit og overvågning af efterlevelse, Politik for sårbarheds- og patchstyring, Politik for netværkssikkerhed - SMV, Politik for malwarebeskyttelse af endpoints - SMV og Politik for sikkerhed i Internet of Things (IoT) og operationel teknologi (OT) - SMV til at definere, håndhæve og dokumentere jeres baselinekrav.

En sikker baseline er ikke blot en hærdningstjekliste. Den er beviset for, at organisationen ved, hvordan sikker konfiguration ser ud, anvender den ensartet og kan dokumentere det, når det gælder.