Baselines voor veilige configuratie voor NIS2 en DORA

De misconfiguratie op vrijdagmiddag die een bestuursprobleem werd

Om 16:40 uur op een vrijdag keurde de teamleider engineering van een fintechplatform goed wat een reguliere firewallwijziging leek. Er werd een tijdelijke regel geopend om problemen met een integratie met een aanbieder van betaalanalyses op te lossen. In het ticket stond: “verwijderen na testen.” De test slaagde. De regel bleef staan.

Drie weken later vond een externe scan een beheerinterface die vanaf internet bereikbaar was. De server was gepatcht. Multifactorauthenticatie (MFA) was ingericht voor reguliere gebruikers. De kwetsbaarheidsscanner markeerde geen kritieke CVE. Maar het systeem was nog steeds niet veilig, omdat de configuratie was afgedreven van de goedgekeurde geharde toestand van de organisatie.

Op maandagochtend voerde de CISO vier gesprekken parallel:

1. De toezichthouder wilde weten of de operationele weerbaarheid was geraakt.
2. De Functionaris voor gegevensbescherming (FG) wilde weten of persoonsgegevens waren blootgesteld.
3. Het bestuur wilde weten waarom “tijdelijke” wijzigingen niet werden gedetecteerd.
4. De interne auditor voor ISO/IEC 27001:2022 wilde bewijs dat veilige baselines waren gedefinieerd, goedgekeurd, geïmplementeerd en bewaakt.

Dit is het moment waarop veel beveiligingsprogramma’s een ongemakkelijke waarheid ontdekken. Veilige configuratie is niet alleen een technische hardeningchecklist. In 2026 zijn baselines voor veilige configuratie een governancevraagstuk, een vraagstuk van cyberhygiëne, een ICT-risicovraagstuk, een kwestie van auditbewijs en een onderwerp van bestuurlijke verantwoordingsplicht.

Een tweede versie van hetzelfde probleem speelt in veel gereguleerde organisaties. Maria, CISO van een groeiende B2B-betaalverwerker, heeft sterke engineers, gepatchte systemen en solide cloudpraktijken. Maar een gereedheidsbeoordeling voor NIS2 en DORA levert één rode bevinding op: het ontbreken van geformaliseerde baselines voor veilige configuratie. Haar team weet hoe servers moeten worden gehard, maar veel van die kennis zit in de hoofden van engineers, niet in goedgekeurde standaarden, geautomatiseerde controles of bewijsdossiers.

Die kloof is niet langer verdedigbaar. NIS2 vereist dat bestuursorganen cyberbeveiligingsrisicobeheersmaatregelen goedkeuren en daarop toezicht houden. DORA vereist een gedocumenteerd ICT-risicobeheerkader en weerbare ICT-operaties. GDPR vereist passende technische en organisatorische maatregelen. ISO/IEC 27001:2022 vereist risicogebaseerde selectie van beheersmaatregelen, implementatie, monitoring, audit en voortdurende verbetering.

Baselines voor veilige configuratie verbinden al deze verplichtingen in één praktisch stelsel van beheersing: definieer de baseline, wijs eigenaarschap toe, dwing deze af tijdens provisioning en inrichting, beheer uitzonderingen, detecteer configuratiedrift, lever bewijs en verbeter na audits of incidenten.

Zoals Clarysec’s Zenith Blueprint: de 30-stappenroadmap voor auditoren het formuleert in de fase Beheersmaatregelen in de praktijk, stap 19, Technological Controls I:

“Veel inbreuken ontstaan niet door softwarefouten, maar door slechte configuratiekeuzes. Standaardwachtwoorden die ongewijzigd blijven, onveilige diensten die zijn ingeschakeld, onnodige poorten die openstaan of systemen die zonder rechtvaardiging aan internet zijn blootgesteld.”

Die zin vat samen waarom baselines voor veilige configuratie nu een kernbeheersmaatregel voor weerbaarheid zijn. Zij definiëren wat veilig betekent voordat een auditor, toezichthouder, klant of aanvaller ernaar vraagt.

Wat een baseline voor veilige configuratie werkelijk is

Een baseline voor veilige configuratie is de goedgekeurde, gedocumenteerde en herhaalbare set beveiligingsinstellingen voor een systeemtype. Deze kan gelden voor Windows-servers, Linux-hosts, netwerkapparaten, SaaS-tenants, cloudopslag, Kubernetes-clusters, databases, firewalls, endpointapparaten, identiteitsplatformen, IoT-apparaten en operationele technologie.

Een sterke baseline beantwoordt praktische vragen:

• Welke diensten zijn standaard uitgeschakeld?
• Welke poorten mogen extern worden blootgesteld?
• Welke instellingen voor authenticatie en MFA zijn verplicht?
• Welke logginginstellingen moeten zijn ingeschakeld?
• Welke encryptie-instellingen zijn vereist?
• Welke beheerinterfaces zijn beperkt toegankelijk?
• Welke cloudresources mogen publiek zijn, en met wiens goedkeuring?
• Welke afwijkingen vereisen risicoacceptatie?
• Hoe vaak controleren we op configuratiedrift?
• Welk bewijs toont aan dat de baseline werkt?

De meest voorkomende fout is dat baselines worden behandeld als engineeringvoorkeuren in plaats van als beheerde beheersmaatregelen. De checklist van een Linux-beheerder, de wikipagina van een cloudarchitect en de firewallconventie van een netwerkengineer kunnen allemaal nuttig zijn, maar zij worden pas auditbaar wanneer ze zijn goedgekeurd, aan risico’s zijn gekoppeld, consequent worden toegepast en worden bewaakt.

Daarom is ISO/IEC 27001:2022 zo’n nuttig anker. Clausules 4.1 tot en met 4.3 vereisen dat organisaties interne en externe kwesties, belanghebbenden en het ISMS-toepassingsgebied begrijpen, inclusief wettelijke, regelgevende, contractuele en derdepartijvereisten. Clausules 6.1.2 en 6.1.3 vereisen informatiebeveiligingsrisicobeoordeling, risicobehandeling, selectie van beheersmaatregelen, een Verklaring van Toepasselijkheid en goedkeuring door de risico-eigenaar. Clausules 8.2 en 8.3 vereisen dat risicobeoordelingen en risicobehandeling op geplande intervallen of na significante wijzigingen worden herhaald.

Annex A maakt de technische verwachting vervolgens concreet via A.8.9 Configuration management, ondersteund door inventaris van bedrijfsmiddelen, kwetsbaarhedenbeheer, wijzigingsbeheer, logging, monitoring, toegangscontrole, cryptografie, gebruik van cloudservices en gedocumenteerde operationele procedures.

Het resultaat is een eenvoudige maar krachtige governance-uitspraak: als uw organisatie niet kan aantonen wat veilig betekent voor elk belangrijk systeemtype, kan zij cyberhygiëne onder NIS2, ICT-risicobeheersing onder DORA, verantwoordingsplicht onder GDPR of doeltreffendheid van beheersmaatregelen onder ISO/IEC 27001:2022 niet overtuigend aantonen.

Waarom NIS2, DORA en GDPR baselines onvermijdelijk maken

NIS2, DORA en GDPR gebruiken verschillende taal, maar komen uit op dezelfde operationele eis: systemen moeten veilig zijn geconfigureerd, continu worden bewaakt en via verantwoord risicomanagement worden beheerd.

NIS2 Article 20 vereist dat bestuursorganen van essentiële en belangrijke entiteiten cyberbeveiligingsrisicobeheersmaatregelen goedkeuren, toezicht houden op de implementatie en cyberbeveiligingstraining ontvangen. Article 21 vereist passende en evenredige technische, operationele en organisatorische maatregelen. Baselines voor veilige configuratie ondersteunen Article 21(2)(a) beleid voor risicoanalyse en beveiliging van informatiesystemen, Article 21(2)(e) beveiliging bij verwerving, ontwikkeling en onderhoud van netwerk- en informatiesystemen, inclusief afhandeling van kwetsbaarheden, Article 21(2)(f) beleid en procedures om de doeltreffendheid te beoordelen, Article 21(2)(g) basisc yberhygiëne en cyberbeveiligingstraining, Article 21(2)(h) cryptografie, Article 21(2)(i) toegangscontrole en beheer van bedrijfsmiddelen, en Article 21(2)(j) multifactorauthenticatie en beveiligde communicatie.

DORA is van toepassing vanaf 17 januari 2025 en fungeert als het sectorspecifieke regelboek voor operationele weerbaarheid voor financiële entiteiten binnen het toepassingsgebied. Articles 5 en 6 vereisen governance en een gedocumenteerd ICT-risicobeheerkader. Article 8 vereist identificatie van ICT-activa, informatieactiva, door ICT ondersteunde bedrijfsfuncties en afhankelijkheden. Article 9 vereist beschermings- en preventiemaatregelen, waaronder beveiligingsbeleid, procedures, protocollen en hulpmiddelen voor ICT-systemen, veilige gegevensoverdracht, toegangscontrole, sterke authenticatie, bescherming van cryptografische sleutels, wijzigingsbeheer, patching en updates. Articles 10 tot en met 14 breiden het model uit naar detectie, respons, herstel, back-up, terugzetting, leren en communicatie.

GDPR voegt het privacyperspectief toe. Articles 5 en 32 vereisen integriteit, vertrouwelijkheid, beveiliging van de verwerking en verantwoordingsplicht door passende technische en organisatorische maatregelen. Publieke cloudopslagbuckets, te breed blootgestelde databases, onveilige standaardinstellingen en overmatige beheerstoegang zijn niet alleen zwaktes in de infrastructuur. Zij kunnen uitgroeien tot tekortkomingen in de bescherming van persoonsgegevens.

Eén programma voor baselines voor veilige configuratie kan alle drie regimes ondersteunen zonder dubbele bewijsstromen te creëren.

Het Clarysec-baselinemodel: beleid, procedure en platformbewijs

Clarysec behandelt veilige configuratie als een herhaalbaar stelsel van beheersing, niet als een eenmalig hardeningproject. De baseline moet door beleid zijn geautoriseerd, worden vertaald naar procedures, via technische beheersmaatregelen worden geïmplementeerd en met bewijs worden onderbouwd.

Het Informatiebeveiligingsbeleid legt deze verwachting op organisatieniveau vast:

“De organisatie moet een minimale baseline van beheersmaatregelen onderhouden die is afgeleid van ISO/IEC 27001 Annex A en, waar passend, is aangevuld met beheersmaatregelen uit ISO/IEC 27002, NIST SP 800-53 en COBIT 2019.”
Uit sectie “Risicobehandeling en uitzonderingen”, beleidsclausule 7.2.1.

Deze clausule voorkomt dat configuratiehardening een verzameling persoonlijke voorkeuren wordt. Zij verankert de minimale baseline van beheersmaatregelen in erkende raamwerken.

Voor cloudomgevingen verscherpt het Beleid voor gebruik van cloudservices de eis:

“Alle cloudomgevingen moeten voldoen aan een gedocumenteerde baselineconfiguratie die is goedgekeurd door de beveiligingsarchitect cloud.”
Uit sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.3.1.

Het Beleid voor audit en nalevingsmonitoring maakt van de baseline vervolgens een bewaakte beheersmaatregel:

“Geautomatiseerde tools moeten worden ingezet om configuratienaleving, kwetsbaarhedenbeheer, patchstatus en geprivilegieerde toegang te bewaken.”
Uit sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.4.1.

Configuratie is ook onlosmakelijk verbonden met kwetsbaarheden- en patchbeheer. Het Beleid voor kwetsbaarheden- en patchbeheer stelt:

“Herstel van kwetsbaarheden moet zijn afgestemd op baselineconfiguratie en standaarden voor systeemhardening.”
Uit sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.4.1.

Dat punt is belangrijk. Een systeem kan gepatcht zijn en toch onveilig blijven als SMBv1 is ingeschakeld, beheerinterfaces zijn blootgesteld, logging is uitgeschakeld of zwakke authenticatie-instellingen aanwezig blijven. In Zenith Controls: de gids voor naleving over meerdere raamwerken wordt configuratiebeheer behandeld als een preventieve beheersmaatregel die vertrouwelijkheid, integriteit en beschikbaarheid beschermt, met operationele capaciteit in veilige configuratie. Zenith Controls legt ook de afhankelijkheid uit tussen configuratiebeheer en kwetsbaarhedenbeheer:

“Kwetsbaarhedenbeheer is afhankelijk van bekende configuraties. Zonder gedefinieerde baseline is het onmogelijk om te waarborgen dat patches consequent worden toegepast.”

Dit is het bewijsverhaal dat auditoren en toezichthouders steeds vaker verwachten: een stelsel van beheersing, geen losse technische taken.

Mapping van ISO/IEC 27001:2022 A.8.9 naar ondersteunende beheersmaatregelen

ISO/IEC 27001:2022 Annex A-beheersmaatregel A.8.9 Configuration management is het anker, maar moet niet worden behandeld als een klein losstaand document. Deze maatregel is afhankelijk van een bredere familie van beheersmaatregelen.

Deze relatie tussen beheersmaatregelen is waarom Clarysec aanbeveelt veilige configuratie te beheren als een ISMS-capability met eigenaren, bewijs, metrieken en managementrapportage.

Een bredere crosswalk helpt hetzelfde baselineprogramma te vertalen naar andere raamwerken.

Een praktische baselinestructuur die u deze maand kunt implementeren

De meest voorkomende fout is proberen een perfecte hardeningstandaard van 80 pagina’s te schrijven voordat iets wordt afgedwongen. Begin met een minimale maar auditbare baseline voor elke belangrijke technologiefamilie en laat deze daarna volwassen worden via automatisering en beoordeling.

Voor een cloudopslagbaseline kan de eerste versie omvatten: publieke toegang standaard uitgeschakeld, encryptie in rust ingeschakeld, access logging ingeschakeld, beheerstoegang beperkt tot goedgekeurde groepen, MFA verplicht voor geprivilegieerde consoletoegang, versiebeheer ingeschakeld waar herstelvereisten dit vereisen, replicatie beperkt tot goedgekeurde regio’s en wijzigingen uitsluitend via goedgekeurde infrastructure-as-code-pijplijnen.

Voor een Windows Server 2022-baseline ter ondersteuning van betalingsverwerking kan de eerste versie omvatten: SMBv1 uitgeschakeld, niet-essentiële diensten uitgeschakeld, RDP beperkt tot een geharde jump host, Windows Defender Firewall ingeschakeld met default-denybeleid, lokale beheerdersaccounts gecontroleerd, gebeurtenislogboeken doorgestuurd naar het SIEM, endpointbeveiliging ingeschakeld en beheerwijzigingen gekoppeld aan goedgekeurde tickets.

Bouw voor elke baseline een klein bewijsdossier:

1. Het goedgekeurde baselinedocument.
2. Een schermafbeelding of geëxporteerd beleid waaruit blijkt dat de configuratie is toegepast.
3. Een lijst met bedrijfsmiddelen die door de baseline worden gedekt.
4. Een wijzigingsticket waaruit blijkt hoe updates worden goedgekeurd.
5. Een rapportage over configuratienaleving of handmatige beoordelingsregistratie.

Dit sluit rechtstreeks aan op Zenith Blueprint, fase Beheersmaatregelen in de praktijk, stap 19, waar Clarysec organisaties adviseert configuratiechecklists voor belangrijke systeemtypen vast te stellen, instellingen bij provisioning waar mogelijk consequent via automatisering toe te passen en uitgerolde systemen vervolgens regelmatig te auditen. De Blueprint geeft ook een praktische auditmethode:

“Kies enkele representatieve systemen (bijvoorbeeld één server, één switch, één eindgebruikers-pc) en valideer dat hun configuratie overeenkomt met uw beveiligde baseline. Documenteer afwijkingen en remediatie.”

Voor mkb-organisaties is deze representatieve steekproefaanpak vaak de snelste route van informele hardening naar auditgereed bewijs.

Voorbeelden van mkb-hardening die risico snel verminderen

Veilige configuratie is niet alleen een enterprise-cloudvraagstuk. Mkb-organisaties behalen vaak de grootste risicoreductie met enkele duidelijke baselineregels.

Het Netwerkbeveiligingsbeleid - mkb stelt:

“Alleen essentiële poorten (bijvoorbeeld HTTPS, VPN) mogen aan het publieke internet worden blootgesteld; alle andere poorten moeten worden gesloten of gefilterd”
Uit sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.1.3.

Het vereist ook wijzigingsdiscipline:

“Alle wijzigingen in netwerkconfiguraties (firewallregels, switch-ACL’s, routingtabelen) moeten een gedocumenteerd wijzigingsbeheerproces volgen”
Uit sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.9.1.

En het creëert een beoordelingscadans:

“De IT-supportverlener moet jaarlijks een beoordeling uitvoeren van firewallregels, netwerkarchitectuur en draadloze configuraties”
Uit sectie “Governancevereisten”, beleidsclausule 5.6.1.

Endpointbaselines vereisen evenveel aandacht. Clarysec’s Endpointbeveiligingsbeleid - malwarebescherming - mkb stelt:

“Apparaten moeten verouderde protocollen uitschakelen (bijvoorbeeld SMBv1) die door malware kunnen worden misbruikt”
Uit sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.2.1.3.

Voor IoT- en OT-omgevingen blijven onveilige standaardinstellingen een terugkerende blootstelling. Het IoT-/OT-beveiligingsbeleid - mkb stelt:

“Standaard- of hardgecodeerde wachtwoorden moeten worden gewijzigd voordat apparaten worden geactiveerd”
Uit sectie “Governancevereisten”, beleidsclausule 5.3.2.

Deze beleidsclausules zijn geen abstracte uitspraken. Het zijn baselinevereisten die kunnen worden getest, aangetoond en gevolgd. Voor een mkb-organisatie die zich voorbereidt op due diligence door klanten, NIS2-leveranciersbeoordelingen, cyberverzekering of ISO/IEC 27001:2022-certificering, leveren zij direct waarde op.

Afhandeling van uitzonderingen: de beheersmaatregel die volwassenheid onderscheidt van papierwerk

Elke baseline zal uitzonderingen hebben. Een legacy-applicatie kan een oud protocol vereisen. Een leveranciersappliance ondersteunt mogelijk niet de voorkeursinstelling voor encryptie. Een tijdelijke firewallopening kan nodig zijn voor migratie. De vraag is niet of uitzonderingen bestaan. De vraag is of zij worden beheerd.

Een volwassen uitzonderingsregister bevat:

• De baselinevereiste waarop inbreuk wordt gemaakt.
• De zakelijke rechtvaardiging.
• Het betrokken bedrijfsmiddel en de eigenaar.
• De risicobeoordeling.
• De compenserende beheersmaatregelen.
• De goedkeuringsbevoegdheid.
• De vervaldatum.
• De monitoringvereiste.
• Het remediatieplan.

Hier komen ISO/IEC 27001:2022-risicobehandeling en DORA-proportionaliteit samen. ISO/IEC 27001:2022 vereist dat besluiten over beheersmaatregelen worden gerechtvaardigd via risicobeoordeling, risicobehandeling, de Verklaring van Toepasselijkheid en goedkeuring door de risico-eigenaar. DORA staat proportionele implementatie toe op basis van omvang, risicoprofiel en de aard, schaal en complexiteit van diensten, maar verwacht nog steeds gedocumenteerde ICT-risicogovernance, monitoring, continuïteit, testen en bewustwording.

Proportionaliteit is geen toestemming om baselines over te slaan. Het is een eis om ze verstandig te schalen.

Voor een micro- of kleinere financiële entiteit onder een vereenvoudigd ICT-risicokader kan de baseline beknopt zijn en worden ondersteund door handmatige steekproeven. Voor een grotere financiële entiteit zal hetzelfde domein waarschijnlijk geautomatiseerde configuratiecontroles, betrokkenheid van interne audit, jaarlijkse testen en rapportage aan het bestuursorgaan vereisen.

Het Wijzigingsbeheerbeleid herinnert organisaties er ook aan te letten op:

“Configuratiedrift of manipulatie na goedgekeurde wijzigingen”
Uit sectie “Handhaving en naleving”, beleidsclausule 8.1.2.3.

Die formulering verbindt wijzigingsbeheer met driftdetectie. Een wijziging kan zijn goedgekeurd en toch risico creëren als de geïmplementeerde toestand afwijkt van de goedgekeurde toestand, of als een tijdelijke instelling blijft bestaan nadat het wijzigingsvenster is gesloten.

Eén audittrail bouwen voor meerdere nalevingsverplichtingen

Een baseline voor veilige configuratie mag geen vijf afzonderlijke nalevingswerkstromen creëren. Het model van Clarysec gebruikt één audittrail die aan meerdere verplichtingen is gekoppeld.

De sleutel is traceerbaarheid. Zenith Blueprint, fase Audit, beoordeling en verbetering, stap 24, instrueert organisaties de Verklaring van Toepasselijkheid bij te werken en deze te kruisen met het risicobehandelingsplan. Als een beheersmaatregel van toepassing is, hebt u een rationale nodig. Die rationale moet gekoppeld zijn aan risico, wettelijke verplichting, contractuele eis of bedrijfsbehoefte.

Voor veilige configuratie moet de SoA-vermelding voor A.8.9 verwijzen naar de baselinestandaard voor veilige configuratie, gedekte categorieën bedrijfsmiddelen, baseline-eigenaren, wijzigingsbeheerprocedure, monitoringmethode, uitzonderingsproces, beoordelingscadans en cross-complianceverplichtingen zoals NIS2 Article 21, DORA Articles 6, 8 en 9, GDPR Article 32 en klantverplichtingen.

Hoe auditoren baselines voor veilige configuratie testen

Veilige configuratie is aantrekkelijk voor auditoren omdat deze veel bewijs oplevert. Zij kan worden getest via documenten, interviews, steekproeven en technische inspectie.

De praktische vragen zijn voorspelbaar:

• Gebruikt u een hardeningchecklist bij het installeren van nieuwe servers?
• Hoe voorkomt u dat onveilige diensten zoals Telnet op routers draaien?
• Zijn cloudopslagresources standaard privé?
• Wie mag een afwijking van de baseline goedkeuren?
• Hoe detecteert u configuratiedrift na een wijziging?
• Kunt u een recente configuratiebeoordeling tonen?
• Kunt u aantonen dat een gedetecteerde afwijking is gecorrigeerd?
• Worden netwerk- en cloudconfiguraties geback-upt en onder versiebeheer geplaatst?
• Zijn rollbackprocedures gedocumenteerd en getest?

De sterkste organisaties onderhouden een baselinebewijsdossier voor elke belangrijke systeemcategorie. Dit verkort audits, verbetert antwoorden op due diligence door klanten en helpt het management de werkelijke prestatie van beheersmaatregelen te begrijpen.

Maak configuratiedrift een bestuursmetriek voor cyberhygiëne

Besturen hebben niet elke firewallregel nodig. Ze moeten wel weten of de cyberhygiëne verbetert of verslechtert.

Een bruikbaar dashboard voor veilige configuratie bevat:

• Percentage bedrijfsmiddelen dat aan een goedgekeurde baseline is gekoppeld.
• Percentage bedrijfsmiddelen dat baselinecontroles doorstaat.
• Aantal kritieke baselineafwijkingen.
• Gemiddelde ouderdom van openstaande afwijkingen.
• Aantal verlopen uitzonderingen.
• Aantal gedetecteerde ongeautoriseerde configuratiewijzigingen.
• Percentage geprivilegieerde configuratiewijzigingen met goedgekeurde tickets.
• Uitzonderingen voor publieke cloudblootstelling.
• Status van baselinebeoordelingen per technologiefamilie.

Deze metrieken ondersteunen de prestatie-evaluatie van ISO/IEC 27001:2022, managementtoezicht onder NIS2 en DORA ICT-risicorapportage. Zij sluiten ook natuurlijk aan op governance-uitkomsten van NIST CSF 2.0 en de monitoring- en nalevingsdoelstellingen van COBIT 2019.

Een eenvoudige regel voor het uitvoerend management helpt: geen kritisch systeem gaat live zonder baselinebewijs. Dit kan worden afgedwongen via wijzigingsbeheer, afdwingingsmomenten in CI/CD, controles van cloudbeleid, beoordeling van infrastructure-as-code, MDM-naleving, GPO-afdwinging of beoordeling van netwerkconfiguratie. Het volwassenheidsniveau kan verschillen, maar de beheersingslogica niet.

Het 90-dagen-draaiboek voor baselines voor veilige configuratie

Als u vanaf nul begint, probeer dan niet elk configuratievraagstuk tegelijk op te lossen. Gebruik een 90-dagenplan.

Dagen 1 tot 30: definieer de minimale baseline

Identificeer kritieke categorieën bedrijfsmiddelen. Wijs voor elke categorie een technische eigenaar, risico-eigenaar en goedkeuringsbevoegdheid toe. Maak een eerste baseline voor de instellingen die het meest relevant zijn voor ransomwareweerbaarheid, cloudblootstelling, geprivilegieerde toegang, logging, encryptie en gegevensbescherming.

Maak het baselineregister en koppel dit aan het ISMS-toepassingsgebied, het risicoregister en de Verklaring van Toepasselijkheid. Als u onder NIS2 valt, bepaal dan of u een essentiële of belangrijke entiteit bent, of dat klanten NIS2-gealigneerde cyberhygiëne verwachten. Als u een financiële entiteit onder DORA bent, identificeer dan welke ICT-activa kritieke of belangrijke functies ondersteunen. Als u persoonsgegevens verwerkt, koppel systemen dan aan GDPR-verwerkingsactiviteiten en gegevenscategorieën.

Dagen 31 tot 60: dwing af en verzamel bewijs

Pas de baseline toe op een steekproef van hoogrisicosystemen. Gebruik automatisering waar mogelijk, maar wacht niet op perfecte tooling. Exporteer configuraties, maak schermafbeeldingen, sla beleidsinstellingen op en registreer wijzigingstickets.

Maak voor elke uitzondering een risicoregistratie met vervaldatum. Maak voor elke afwijking een remediatieticket.

Dagen 61 tot 90: bewaak, rapporteer en verbeter

Voer een configuratiebeoordeling uit. Neem een steekproef van één server, één endpoint, één netwerkapparaat en één cloudomgeving. Vergelijk feitelijke instellingen met de goedgekeurde baseline. Documenteer afwijkingen en corrigerende maatregelen.

Rapporteer baselinenaleving aan het management. Werk de Verklaring van Toepasselijkheid en het risicobehandelingsplan bij. Neem terugkerende afwijkingen op in oorzaakanalyse. Als een misconfiguratie een incident heeft veroorzaakt of daaraan heeft bijgedragen, werk dan de relevante baseline bij als onderdeel van de geleerde lessen.

Dit geeft auditoren iets toetsbaars, toezichthouders iets begrijpelijks en management iets bestuurbaar.

Slotgedachte: veilige configuratie is cyberhygiëne met bewijs

NIS2 gebruikt de taal van cyberbeveiligingsrisicobeheersmaatregelen en basiscyberhygiëne. DORA gebruikt de taal van ICT-risico, weerbaarheid, monitoring, continuïteit en testen. GDPR gebruikt de taal van passende maatregelen en verantwoordingsplicht. ISO/IEC 27001:2022 gebruikt de taal van risicobehandeling, beheersmaatregelen, gedocumenteerde informatie, prestatie-evaluatie en voortdurende verbetering.

Baselines voor veilige configuratie verbinden dit alles.

Zij tonen aan dat systemen niet met onveilige standaardinstellingen worden uitgerold. Zij tonen aan dat wijzigingen worden beheerst. Zij tonen aan dat configuratiedrift wordt gedetecteerd. Zij tonen aan dat uitzonderingen op basis van risico worden geaccepteerd. Zij tonen aan dat bewijs bestaat voordat de auditor erom vraagt.

Belangrijker nog: zij verminderen reëel operationeel risico. De firewallregel op vrijdagmiddag, de publieke cloudopslagbucket, de vergeten SMBv1-instelling, het standaardwachtwoord op een IoT-apparaat en de niet-gelogde beheerconsole zijn geen theoretische auditbevindingen. Het zijn praktische faalpunten.

Clarysec helpt organisaties deze faalpunten om te zetten in gecontroleerde, bewaakte en auditbare baselines.

Volgende stappen

Als uw organisatie veilige configuratie moet aantonen voor ISO/IEC 27001:2022, NIS2-cyberhygiëne, DORA ICT-risicobeheer, GDPR-verantwoordingsplicht of assurance richting klanten, begin dan met Clarysec’s toolkit:

• Gebruik Zenith Blueprint: de 30-stappenroadmap voor auditoren om configuratiebeheer te implementeren in de fase Beheersmaatregelen in de praktijk, stap 19, en te valideren via de fase Audit, beoordeling en verbetering, stap 24.
• Gebruik Zenith Controls: de gids voor naleving over meerdere raamwerken om configuratiebeheer te mappen naar ondersteunende beheersmaatregelen uit ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST SP 800-53, COBIT 2019 en auditmethodologieën.
• Gebruik Clarysec-beleid zoals Informatiebeveiligingsbeleid, Beleid voor gebruik van cloudservices, Beleid voor audit en nalevingsmonitoring, Beleid voor kwetsbaarheden- en patchbeheer, Netwerkbeveiligingsbeleid - mkb, Endpointbeveiligingsbeleid - malwarebescherming - mkb en IoT-/OT-beveiligingsbeleid - mkb om uw baselinevereisten te definiëren, af te dwingen en aantoonbaar te maken.

Een veilige baseline is niet alleen een hardeningchecklist. Het is bewijs dat uw organisatie weet hoe veilig eruitziet, dit consequent toepast en het kan aantonen wanneer het ertoe doet.