CIS Benchmarks: wat ze zijn en waarom ze belangrijk zijn

Wat CIS Benchmarks precies zijn

Een CIS Benchmark is een document dat per instelling beschrijft hoe u een specifiek besturingssysteem, cloudplatform, softwarepakket of netwerkapparaat configureert zodat het moeilijker aan te vallen is. Ze worden gepubliceerd door het Center for Internet Security (CIS), een Amerikaanse non-profitorganisatie, en omvatten de platforms die organisaties daadwerkelijk gebruiken: Windows Server en desktopedities, de belangrijkste Linux-distributies, Amazon Web Services, Microsoft Azure, Google Cloud, Kubernetes en Docker, Microsoft 365, Google Workspace, veelgebruikte browsers en netwerkapparaten van leveranciers zoals Cisco en Palo Alto Networks. Er zijn in totaal meer dan 100 Benchmarks, verdeeld over 25+ productfamilies van leveranciers. CIS werkt elke Benchmark bij wanneer nieuwe platformversies verschijnen.

CIS Benchmark-aanbevelingen doorlopen vóór publicatie een consensusproces. Vakexperts uit de industrie, overheid en academische wereld stellen instellingen voor, beoordelen ze en stemmen erover. Daardoor leest de richtlijn als praktisch advies voor beheerders, in plaats van als documentatie voor hardening van één leverancier. Elke aanbeveling is gemarkeerd als "Scored", wat betekent dat naleving automatisch kan worden gemeten en verwerkt in een numerieke score, of als "Not Scored", wat betekent dat het een goede praktijk is die niet eenvoudig automatisch kan worden gecontroleerd.

De Benchmarks zelf zijn voor elk gedekt platform gratis als PDF te downloaden. Wat geld kost, zijn de tools eromheen: CIS-CAT Pro, een assessmenttool die een systeem tegen een Benchmark scant en een compliance-score en remediationrapport produceert, en CIS Hardened Images, vooraf geconfigureerde virtuele machine-images die direct compliant zijn met een Benchmark en via de AWS-, Azure- en GCP-marketplaces worden verkocht onder een CIS SecureSuite-lidmaatschap. Er bestaat ook een gratis, beperkte versie, CIS-CAT Lite, voor organisaties die geautomatiseerde scoring tegen één Benchmark willen uitproberen voordat ze een betaald abonnement nemen.

Anatomie van een aanbeveling

Een Benchmark is geen losse lijst met suggesties. Elke aanbeveling daarin, en één Benchmark kan er honderden bevatten, volgt dezelfde structuur uit vijf onderdelen. Daardoor kan een engineer de richtlijn daadwerkelijk gebruiken in plaats van hem alleen te lezen:

• Description: wat de instelling is en wat deze beheert.
• Rationale: waarom de wijziging belangrijk is en welke aanval of blootstelling ermee wordt beperkt.
• Audit procedure: de exacte stappen of controle via de command line om vast te stellen of een systeem momenteel aan de aanbeveling voldoet.
• Remediation procedure: de exacte stappen of opdrachten om het systeem compliant te maken als de audit mislukt.
• Default value: de instelling zoals die standaard is voordat iemand iets wijzigt.

Deze structuur komt voort uit CIS WorkBench, het samenwerkingsplatform waar het consensusproces daadwerkelijk plaatsvindt. Vrijwillige experts van leveranciers, overheidsinstanties, auditors en de industrie dienen aanbevelingen in, bespreken en testen ze en stemmen erover voordat ze worden gepubliceerd. Benchmarks worden voortdurend herzien wanneer platforms veranderen en nieuwe dreigingen ontstaan. Dit proces is langzamer dan wanneer één leverancier zijn eigen hardeninggids schrijft, en dat is juist de bedoeling: een aanbeveling die een beoordeling door mensen met verschillende belangen doorstaat, vormt een sterkere baseline dan een aanbeveling die uitsluitend door de bouwer van het product is opgesteld.

CIS Benchmarks versus CIS Controls: het onderscheid dat vaak verloren gaat

CIS publiceert ook de CIS Controls, en de twee worden in gesprekken vaak door elkaar gehaald, ook binnen IT-teams die beide gebruiken. De Controls bestaan uit 18 geprioriteerde beveiligingsmaatregelen, verdeeld over drie Implementation Groups naar organisatorische volwassenheid. Ze beschrijven wat een securityprogramma moet afdekken: asset-inventarisatie, toegangsbeheer, databescherming, incidentrespons enzovoort. Ze werken op het niveau van een strategisch document.

Benchmarks gaan één niveau lager en vertalen een van die maatregelen, veilige configuratie, naar exacte, testbare instellingen voor een specifiek platform. De twee zijn ontworpen om samen te werken, niet om elkaar te vervangen. CIS Control 4, Secure Configuration of Enterprise Assets and Software, behandelt veilige configuratie op programmaniveau. Safeguard 4.1 vraagt om het vaststellen en onderhouden van een gedocumenteerd proces voor veilige configuratie. CIS Benchmarks zijn de platformspecifieke richtlijnen die de meeste organisaties gebruiken om dat proces uit te voeren. De Control schrijft niet voor dat deze boven een gelijkwaardige eigen baseline moet worden gebruikt.

Voorbeelden van CIS Benchmarks per platform

"CIS Benchmark" is geen enkel document, maar een familie van documenten, elk gericht op een specifiek platform. Enkele veelgebruikte voorbeelden:

Elke Benchmark is gekoppeld aan een specifieke platformrelease. CIS werkt richtlijnen bij of trekt ze in wanneer leveranciers nieuwe versies uitbrengen. Controleer de eigen Benchmark-catalogus van CIS voor de actuele versie in plaats van te werken met een oude, lokaal opgeslagen kopie.

Wie hier daadwerkelijk aandacht aan moet besteden

Het concept van veilige configuratie is eenvoudig te onderschrijven en net zo eenvoudig om niets mee te doen. Het wordt concreet zodra u uw eigen situatie erin herkent. Een Benchmark is het overwegen waard wanneer u:

• Windows- of Linux-servers, virtuele machines of endpoints op enige schaal beheert
• Microsoft 365, Google Workspace of andere SaaS-platforms gebruikt die bedrijfsgegevens bevatten
• Workloads in AWS, Azure of Google Cloud draait en een baseline wilt die verder gaat dan de standaardinstellingen van de provider
• Betaalkaartgegevens of andere gereguleerde of gevoelige informatie verwerkt
• Gedocumenteerd bewijs nodig hebt dat auditors kunnen beoordelen voor ISO 27001, PCI DSS, NIST CSF of NIS2
• Infrastructuur via Terraform, Ansible of vergelijkbare tooling uitrolt en systemen standaard compliant wilt maken
• Genoeg systemen beheert dat configuratie niet langer afhankelijk kan zijn van degene die toevallig ieder systeem heeft gebouwd

Dit betekent niet dat u elke aanbeveling op elk systeem moet implementeren. De juiste baseline hangt af van het platform, de bedrijfsbehoefte en wat een bepaald systeem operationeel kan verdragen. Daarom is een gefaseerde uitrol belangrijk.

Waarom veilige configuratie zoveel aandacht verdient

Standaardconfiguraties zijn bedoeld om een systeem met zo weinig mogelijk supportvragen werkend te krijgen, niet om een aanvaller te weerstaan. Een vers geïnstalleerde server, een standaard cloud-storagebucket of een nieuwe Microsoft 365-tenant wordt geleverd met instellingen die gemak bevoordelen: ruimere rechten dan de meeste gebruikers nodig hebben, verouderde protocollen die voor compatibiliteit zijn ingeschakeld en logging die lager is ingesteld om ruis te beperken. Geen daarvan is een fout. Het is simpelweg niet de configuratie die een securityteam zou kiezen, en de meeste organisaties gaan later niet bewust terug om die keuze te maken.

Precies daar ontstaat een groot deel van de incidenten in de praktijk. Een storagebucket met standaard openbare toegang, een server die nog een verouderd protocol gebruikt waarvan niemand meer weet waarom het is ingeschakeld, een beheerconsole die vanaf internet bereikbaar blijft omdat een firewallregel na een migratie nooit is aangescherpt: dit zijn configuratiefouten, geen zero-day-exploits, en het zijn ook de fouten die het goedkoopst te voorkomen zijn. Verkeerde configuratie blijft een belangrijke hoofdoorzaak in rapporten over datalekken en beveiligingsincidenten, zowel in cloud- als on-premise-infrastructuur, omdat de onderliggende situatie niet is verdwenen: complexe platforms worden nog steeds met permissieve standaardinstellingen geleverd.

Een Benchmark sluit die kloof met een specifiek, getest antwoord in plaats van een algemeen principe. "Harden uw servers" is advies waar niemand direct mee aan de slag kan. "Schakel SMBv1 uit, stel een minimale wachtwoordlengte van 14 tekens in, schakel het ingebouwde gastaccount uit en beperk anonieme SID- en naamvertaling" is iets wat een engineer kan implementeren en een auditor kan verifiëren. Die specificiteit, toegepast op iedere instelling die een platform beschikbaar stelt, is de werkelijke waarde van een Benchmark ten opzichte van algemene hardeningadviezen.

Level 1 en Level 2: twee niveaus van hardening

Elke CIS Benchmark verdeelt zijn aanbevelingen over twee profielniveaus. Level 1 omvat fundamentele hardening: instellingen die het aanvalsoppervlak betekenisvol verkleinen met een minimaal risico op verstoring van de normale werking. Het is bedoeld als baseline die geschikt is voor vrijwel elk systeem, inclusief systemen met algemene bedrijfsapplicaties waar beschikbaarheid belangrijker is dan defence-in-depth.

Level 2 gaat verder en omvat instellingen voor omgevingen met hogere beveiligingseisen, waar enige vermindering van functionaliteit of prestaties een aanvaardbare ruil is voor betere bescherming. Gereguleerde omgevingen, systemen met gevoelige gegevens en internetgerichte infrastructuur zijn gebruikelijke kandidaten voor Level 2.

Een Benchmark implementeren zonder productie te verstoren

De meest voorkomende fout is een Benchmark, vooral Level 2, rechtstreeks in productie toepassen zonder deze eerst te testen. Sommige aanbevelingen schakelen functionaliteit uit waarvan een specifieke applicatie ongemerkt afhankelijk is, zoals een verouderd protocol dat oude bedrijfssoftware nog gebruikt of een recht dat een monitoringagent nodig heeft om correct te werken. Alle aanbevelingen tegelijk uitrollen en vervolgens in productie ontdekken dat iets niet meer werkt, is de manier waarop hardeningprojecten de reputatie krijgen storingen te veroorzaken. Dat leidt er vaak toe dat een team de hele aanpak opgeeft.

Een gefaseerde uitrol voorkomt dit. Pilot de Benchmark eerst op een representatieve subset van systemen, bij voorkeur met minstens één systeem waarop elke kritieke applicatie draait, en controleer of alles blijft functioneren voordat u verder uitbreidt. Wanneer een aanbeveling echt botst met een bedrijfsvereiste, documenteer dan de uitzondering, de reden en eventuele compenserende maatregel in plaats van de aanbeveling stilzwijgend over te slaan. Een uitzonderingenregister dat een auditor kan beoordelen is een sterkere positie dan een Benchmark die ongelijkmatig is toegepast zonder vastlegging van de redenen.

Twee benaderingen werken beter op schaal dan iedere machine handmatig hardenen. De eerste is een Golden Image: harden één master-image volgens de Benchmark, valideer deze grondig en kloon hem vervolgens voor ieder nieuw systeem in plaats van dezelfde instellingen één voor één opnieuw toe te passen. CIS verkoopt hiervoor vooraf gebouwde Hardened Images via de belangrijkste cloudmarketplaces, hoewel veel organisaties hun eigen master-image bouwen en onderhouden, afgestemd op hun applicatiestack. De tweede is Infrastructure as Code. Provisioningscripts in Terraform of Ansible kunnen de instellingen van een Benchmark rechtstreeks vastleggen, zodat iedere server, container of cloudresource al compliant wordt aangemaakt, in plaats van pas compliant te worden nadat iemand eraan denkt een aparte hardeningstap uit te voeren.

Geen van beide benaderingen maakt voortdurende controles overbodig. Een systeem dat uit een Golden Image is opgebouwd of via compliant IaC is ingericht, wijkt binnen enkele weken van de baseline af door patches, software-installaties en goedbedoelde wijzigingen onder tijdsdruk. CIS-CAT-scans moeten daarom volgens een terugkerend schema worden uitgevoerd, niet alleen eenmaal vóór een audit, zodat drift wordt ontdekt en gecorrigeerd terwijl het nog een kleine afwijking is.

Waar CIS Benchmarks passen binnen een audit

De meeste complianceframeworks vereisen een veilige configuratiebaseline zonder specifiek CIS te noemen. Daarom zijn CIS Benchmarks een van de meest gebruikte bronnen voor bewijs voor deze eis. ISO 27001 Annex A control 8.9, Configuration Management, vereist gedocumenteerde en gemonitorde veilige configuraties voor hardware, software, services en netwerken. Een CIS Benchmark in combinatie met een CIS-CAT-compliancerapport levert sterk technisch bewijs voor die control. De configuratiestandaard die een auditor beoordeelt moet echter uw eigen gedocumenteerde standaard zijn, niet een ongewijzigde kopie van de CIS-PDF die als beleid is opgeslagen.

PCI DSS Requirement 2 vereist gedocumenteerde configuratiestandaarden voor alle systeemcomponenten en noemt door de sector geaccepteerde hardeningstandaarden, waaronder CIS, als een acceptabele basis. Ook hier geldt dat de standaard moet worden afgestemd op uw eigen omgeving in plaats van alleen te worden aangehaald. NIST CSF's Protect-functie verwacht dat veilige baselineconfiguraties worden vastgesteld en onderhouden, en de technische maatregelen in artikel 21 van NIS2 omvatten systeembeveiliging en kwetsbaarheidsbeheer op een manier die auditors doorgaans op dezelfde wijze onderbouwen.

Onze ISO 27001-gids en NIST CSF- en NIS2-mappinggids behandelen waar veilige configuratie past binnen die bredere frameworks.

Veelgemaakte fouten die u moet vermijden

• Hardening behandelen als een project met een einddatum: een Benchmark die eenmaal wordt toegepast en nooit opnieuw wordt gescand, verandert binnen maanden in ongedocumenteerde drift.
• Level 2 standaard overal toepassen: de operationele kosten zijn zelden de moeite waard op systemen die het niet nodig hebben, en mislukte uitrol kan de bereidheid voor systemen die het wel nodig hebben aantasten.
• Het uitzonderingenproces overslaan: aanbevelingen die in strijd zijn met een bedrijfsbehoefte stilzwijgend negeren laat geen auditspoor achter en biedt de volgende engineer geen context.
• Aannemen dat de Benchmark van één versie ook op de volgende versie van toepassing blijft: CIS publiceert afzonderlijke Benchmarks voor specifieke platformversies en een gids voor een oudere release kan instellingen missen die later zijn geïntroduceerd.
• Benchmarks en Controls door elkaar halen tijdens een audit: ze beantwoorden verschillende vragen en het verwarren ervan kan het verzamelen van bewijs volledig de verkeerde kant op sturen.

Dit vervangt geen gedocumenteerde hardeningstandaard of bredere secure-by-designaanpak. Het is de specifieke, uitvoerbare laag daaronder en meestal de snelste kloof om te dichten zodra u weet dat deze bestaat.

Hoe Cyvra helpt

De diensten Cybersecurity Consultancy, Cybersecurity Assessment en Audits & Compliance van Cyvra bouwen veilige configuratiebaselines die ook tijdens een audit standhouden, niet alleen op de dag waarop ze worden opgesteld.

• Benchmark-gebaseerde hardening: Level 1- en Level 2-uitrol afgestemd op uw werkelijke omgeving en eerst getest voordat bredere implementatie plaatsvindt
• Uitzonderingenregister: gedocumenteerde, auditklare vastlegging van aanbevelingen die niet kunnen worden toegepast, inclusief de reden en waar nodig compenserende maatregelen
• Driftmonitoring: terugkerende compliancescans zodat een geharde baseline ook gehard blijft, niet alleen rond audittijd
• Compliance mapping: bewijs voor veilige configuratie rechtstreeks gekoppeld aan vereisten van ISO 27001, PCI DSS, NIST CSF en NIS2

We beoordelen uw huidige configuratie tegen de passende CIS Benchmarks, documenteren gerechtvaardigde uitzonderingen, prioriteren remediation en leveren bewijs dat u kunt gebruiken voor ISO 27001, PCI DSS of andere complianceprogramma's. Neem contact op met ons team voor Cybersecurity Consultancy of Audits & Compliance om te starten met een review van uw configuratiebaseline.