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 wordt beoordeeld als "Automated", wat betekent dat een tool zoals CIS-CAT de naleving kan controleren, of als "Manual", wat betekent dat een persoon dit moet verifiëren omdat de instelling niet op betrouwbare wijze door een tool kan worden gecontroleerd. Manual betekent niet dat de aanbeveling minder belangrijk is. Deze labels hebben de oudere termen "Scored" en "Not Scored" vervangen, die u wellicht nog steeds tegenkomt in oudere versies van de Benchmarks.

De Benchmarks zelf kunnen gratis als PDF worden gedownload voor niet-commercieel gebruik, conform de gebruiksvoorwaarden van CIS. Wat wel geld kost, zijn de tools die hieromheen zijn ontwikkeld. CIS-CAT Pro, onderdeel van het CIS SecureSuite-lidmaatschap, is een beoordelingstool die een systeem toetst aan een Benchmark en een nalevingsscore en een herstelrapport genereert. CIS Hardened Images zijn een afzonderlijk product: images van virtuele machines die vooraf zijn geconfigureerd volgens een Benchmark en worden verkocht via de marktplaatsen van AWS, Azure, Google Cloud en Oracle Cloud. Een 'hardened image' biedt u een veilig uitgangspunt voor het besturingssysteem; het beveiligt echter niet de applicaties en gegevens die u erop uitvoert. Een gratis versie, CIS-CAT Lite, biedt beperkte functionaliteit en dekt een geselecteerde reeks Benchmarks, voor organisaties die geautomatiseerde beoordeling willen uitproberen alvorens zich te verbinden aan een betaald abonnement.

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 tevens de CIS Controls, en deze twee worden in gesprekken vaak door elkaar gehaald, ook binnen IT-teams die beide gebruiken. De Controls bestaan uit 18 geprioriteerde maatregelen, die elk zijn onderverdeeld in specifieke beveiligingsmaatregelen (153 in versie 8.1), waarbij de beveiligingsmaatregelen op basis van de maturiteit van de organisatie zijn ingedeeld in drie Implementation Groups (IG1 tot en met IG3). Ze beschrijven wat een beveiligingsprogramma moet omvatten: inventarisatie van bedrijfsmiddelen, toegangscontrole, gegevensbescherming, incidentrespons, enzovoort. De beveiligingsmaatregelen zijn concreet en operationeel, maar blijven platformonafhankelijk.

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 vanaf het begin volgens een goedgekeurde baseline wilt configureren
• 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 draaiende te houden met zo min mogelijk supportverzoeken, niet om weerstand te bieden aan een aanvaller. Aanbieders hebben sommige standaardinstellingen aangescherpt: Amazon S3 heeft sinds april 2023 de openbare toegang tot nieuwe buckets standaard geblokkeerd, en Microsoft schakelt beveiligingsstandaardinstellingen in, waaronder MFA en het blokkeren van verouderde authenticatiemethoden, voor nieuwe Entra ID-tenants. Bij een pas geïnstalleerde server of een langdurige tenant kan het gemak nog steeds voorrang krijgen: ruimere machtigingen dan de meeste gebruikers nodig hebben, verouderde protocollen die omwille van de compatibiliteit ingeschakeld blijven, en logboekregistratie die is teruggeschroefd om ruis te verminderen. Dat is geen fout. Het is simpelweg niet de configuratie die een beveiligingsteam zou kiezen, en veel organisaties komen daar nooit op terug om bewust een andere keuze te maken.

Juist in die kloof ontstaat een groot deel van de incidenten in de praktijk, en de oorzaak ligt meestal in wat er na de standaardinstellingen gebeurt: toegangsrechten die voor een project zijn toegekend, uitzonderingen die door niemand meer worden gecontroleerd, integraties die in stand worden gehouden voor verouderde systemen, en wijzigingen die later worden doorgevoerd. Een opslagbucket waarvan de blokkering voor openbare toegang tijdens een migratie is uitgeschakeld, een serviceaccount met veel meer rechten dan het nodig heeft, een tijdelijke firewallregel die nooit is verwijderd: dit zijn configuratiefouten, geen zero-day-exploits, en het zijn ook de fouten die het goedkoopst te voorkomen zijn. Verkeerde configuratie duikt steeds weer op als een van de belangrijkste hoofdoorzaken in rapporten over inbreuken, zowel in de cloud als in zelfgehoste infrastructuren, omdat complexe platforms voortdurend configuratiewijzigingen opstapelen die niemand toetst aan een baseline.

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 een stap verder en omvat instellingen die bedoeld zijn voor omgevingen met hogere beveiligingseisen, waar een zekere beperking van de functionaliteit of prestaties een aanvaardbare afweging is in ruil voor een betere bescherming. Level 2 is het overwegen waard voor gereguleerde omgevingen, systemen die gevoelige gegevens verwerken en infrastructuur met een hoog risico op blootstelling, maar uitsluitend na een risicobeoordeling en compatibiliteitstests. Blootstelling aan het internet op zich maakt Level 2 nog niet tot de juiste keuze.

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.

Bepaal, voordat u met een pilot begint, welke baseline van toepassing is op elk systeem. Een Benchmark is opgesteld voor een specifieke productversie en functie, waardoor één organisatie vaak meerdere baselines nodig heeft. Leg voor elke baseline het volgende vast:

• de systemen binnen de scope, met vermelding van het exacte product en de exacte versie van elk systeem
• de rol van elk systeem, die bepalend is voor het profiel (server of werkstation, domeincontroller of lidserver)
• de gekozen Benchmark-versie en het gekozen Level, aangepast aan uw eigen goedgekeurde baseline
• een aangewezen eigenaar die uitzonderingen en wijzigingen goedkeurt

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, eventuele compenserende maatregelen, een verantwoordelijke en een herzieningsdatum, 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 doorlopende controles overbodig. Een systeem dat is opgebouwd op basis van een Golden Image of dat via IaC is geïmplementeerd, wijkt in de loop van de tijd af van die baseline doordat er patches worden toegepast, software wordt geïnstalleerd en er onder tijdsdruk goedbedoelde wijzigingen worden doorgevoerd. Voer periodieke beoordelingen uit met CIS-CAT of een gelijkwaardige tool, en niet slechts één keer vóór een audit, zodat afwijkingen worden opgemerkt terwijl het nog om een kleine afwijking gaat. CIS-CAT ondersteunt niet alle Benchmarks, dus voor sommige platforms, met name clouddiensten, zijn de eigen beveiligingsbeoordelingstools van de aanbieder of handmatige controles nodig. Een CIS-CAT-score heeft bovendien alleen betrekking op de aanbevelingen die zijn beoordeeld: deze vervangt niet de beoordeling van Manual-aanbevelingen, het uitzonderingsregister of een ISO 27001- of PCI DSS-audit.

Waar CIS Benchmarks passen binnen een audit

De meeste compliance-kaders vereisen een veilige configuratiebaseline zonder CIS specifiek te noemen; daarom zijn CIS Benchmarks uitgegroeid tot een van de meest gebruikte bronnen van bewijs voor die vereiste. ISO 27001, Annex A, controle 8.9, Configuration Management, vereist dat configuraties, met inbegrip van beveiligingsconfiguraties, worden vastgesteld, gedocumenteerd, geïmplementeerd, bewaakt en geëvalueerd. Een CIS Benchmark, in combinatie met een beoordelingsrapport, levert sterk technisch bewijs voor die controlemaatregel, maar bewijst niet het bijbehorende beheerproces: wie keurt de baseline goed, hoe worden wijzigingen beheerd en hoe vaak wordt deze herzien? De configuratiestandaard die een auditor beoordeelt, moet bovendien uw eigen gedocumenteerde standaard zijn, en geen ongewijzigde kopie van de CIS-PDF die als beleid is gearchiveerd.

Requirement 2.2.1 van PCI DSS v4.0.1 vereist voor alle systeemcomponenten configuratiestandaarden die in overeenstemming zijn met in de sector algemeen aanvaarde beveiligingsnormen of aanbevelingen van leveranciers. In de toelichting bij de standaard wordt CIS als een van die bronnen genoemd, met hetzelfde voorbehoud: de standaard moet worden afgestemd op uw eigen omgeving en mag niet louter als referentie worden gebruikt. In NIST CSF 2.0 wordt in subcategorie PR.PS-01 verwacht dat er werkwijzen voor configuratiebeheer worden vastgesteld en toegepast. Artikel 21 van NIS2 schrijft maatregelen voor zoals beveiliging bij de aanschaf, ontwikkeling en het onderhoud van netwerk- en informatiesystemen; het toewijzen van CIS Benchmarks hieraan is een keuze bij de implementatie, niet iets wat NIS2 vereist.

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 een kloof die u relatief snel kunt 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.