1 open besluit1414 voorstellen

Onderwerp

De beveiligingsbaseline

De beveiligingsbaseline van het platform: risicogerichte, gelaagde maatregelen met norm en bewijs, met BIO2 en ISO/IEC 27002:2022 als kader, getoetst aan de referentieset securityeisen, met uitzonderingen, onderhoud en naleving.

Nog niet bevestigd door een mens. Eigenaar: vdo89. Bron in de atlas

Domein
Volgt uit
Functies
Producten
Verwant

Wat het is

De beveiligingsbaseline is de vaste set beveiligingsmaatregelen van het platform: genummerde maatregelen in elf domeinen, elk met een norm, het bewijs bij oplevering, de verwijzing naar BIO2 en de eisen uit de referentieset die zij dekt. Dit onderwerp legt vast van welke uitgangspunten de baseline uitgaat en hoe zij is opgebouwd, hoe zij aansluit op BIO2, ISO/IEC 27002:2022 en de referentieset securityeisen, welke maatregelen dragend of geërfd zijn, en hoe documentatie, naleving, uitzonderingen en onderhoud zijn geregeld.

Waarom zo

Controle achteraf per audit is lichter, maar kan afwijkingen maanden laten bestaan en maakt het bewijs per dienst tot handwerk. Door de maatregelen in de standaard op te nemen, per maatregel het bewijs vast te leggen en de baseline te toetsen aan toetsbare eisen, regelt het platform de gemeenschappelijke beveiliging één keer voor alle teams en blijft iedere afwijking zichtbaar, tot zij is hersteld of als uitzondering is aanvaard.

Vastgesteld zijn de keuze voor één baseline met BIO2 en ISO/IEC 27002:2022 als kader, de uitgangspunten, de rol van de referentieset, de plaats van de voorzieningen en de geërfde maatregelen. De afzonderlijke maatregelen en normen, de dekking per onderwerp, de uitzonderingen en het onderhoud zijn een voorstel: zij werken die keuze uit en blijven staan tot een architect erover besluit.

Uitspraken

6 vastgesteld24 voorstellen

Alle 24 voorstellen vaststellen

Uitgangspunten en opbouw

VastgesteldOntwerpbesluit#

Het platform heeft één beveiligingsbaseline: genummerde maatregelen per domein, elk met een norm, het bewijs bij oplevering, de verwijzing naar BIO2 en de eisen uit de referentieset die zij dekt. Tenzij anders vermeld gelden de maatregelen voor het fundament en voor ieder applicatiecluster, in alle dienstprofielen.

Toelichting

Iedere maatregel heeft een vaste aanduiding, zodat auditor, SOC en beheer over dezelfde maatregel spreken; beleid, controles, bewijs, uitzonderingen en meldingen verwijzen ernaar. Afgewezen: controle achteraf per audit, die lichter is maar afwijkingen maanden kan laten bestaan en het bewijs per dienst tot handwerk maakt; zie de ontwerpkeuze Beveiliging en controle in de standaard.

VastgesteldUitgangspunt#

De baseline gaat uit van zeven uitgangspunten: risicogericht, standaard veilig, gelaagd, uitgaan van een inbraak, toegang op basis van identiteit, aantoonbaar en herstelbaar na een aanval.

UitgangspuntWat het betekent
RisicogerichtMaatregelen volgen, in lijn met BIO2, uit de risico’s voor werk en gegevens. Ook een ontwikkelomgeving krijgt bescherming die bij haar risico’s past.
Standaard veiligDe beveiligingsinstellingen horen bij de standaardinrichting. De toelatingscontrole weigert een wijziging ervan door een team, en het platform controleert ze na oplevering periodiek.
GelaagdDringt een aanvaller een laag binnen, dan begrenzen de andere lagen zijn bereik. Beheercellen, zones en clusters hebben een eigen grens, net als naamruimten en toepassingen.
Uitgaan van een inbraakIedere laag is ingericht alsof de laag ervoor al is doorbroken. Geen netwerk, cluster of onderdeel geldt als vertrouwd omdat het binnen staat; het platform beoordeelt ieder toegangsverzoek op identiteit en herkomst.
Toegang op basis van identiteitToegang volgt uit een gecontroleerde identiteit en een expliciete toestemming, niet uit het netwerk waarin een persoon of werklast zich bevindt.
AantoonbaarPer maatregel ligt vast welk bewijs toont dat zij bij oplevering is ingericht en daarna periodiek dat zij werkt. Het platform verzamelt dat bewijs waar mogelijk automatisch; ontbrekend of afwijkend bewijs blijft zichtbaar.
Herstelbaar na een aanvalHet platform is vanuit code en gecontroleerde kopieën opnieuw op te bouwen, met nieuwe geheimen en sleutels. Daarom liggen de sleutels van de versleutelde kopieën buiten de cel; is het beheer zelf aangetast, dan begint de herbouw vanuit de herstelkern.
Toelichting

De uitgangspunten werken de principes uit dat maatregelen risicogebaseerd zijn, dat het platform veilig is door ontwerp en dat de beveiliging gelaagd is.

VoorstelMaatregel#

De maatregelen van de baseline vormen zeven lagen die elkaar opvangen: faalt een laag, dan begrenzen de andere wat een aanvaller kan bereiken.

LaagWat de laag regeltAls de laag faalt
Apparatuur en opstartAlleen ondertekende firmware en opstartsoftware; sleutels in de TPM; de beheerinterfaces van de servers in een apart netwerk.Zones en toegangslijsten in het datacenternetwerk, buiten de server, begrenzen wat een aangetaste server kan bereiken; regels op de server zelf kan zo’n server omzeilen.
NetwerkZones met vastgestelde stromen; standaard dicht tussen naamruimten, clusters en cellen; alleen gedeclareerd verkeer; uitgaand verkeer alleen naar vastgelegde bestemmingen.Iedere dienst vereist daarnaast authenticatie met een eigen identiteit, een certificaat of een geheim; een stroom zonder authenticatie is een uitzondering met einddatum.
Mensen en beheerpadPersoonlijke accounts met meerfactoraanmelding; rollen uit het identiteitsbeheer; tijdelijk verhoogde rechten na goedkeuring door een ander dan de aanvrager; iedere bevoorrechte sessie via de beheerwerkplek.Bevoorrechte sessies worden opgenomen. Rechten gelden per cel, behalve voor vlootbrede rollen, en de noodtoegang staat buiten het platform.
Werklasten en geheimenIedere toepassing heeft een eigen kortlevende identiteit en krijgt haar geheimen uit het geheimenbeheer; iedere cel heeft eigen sleutels. Wederzijdse authenticatie, versleuteling en toegangsregels per identiteit tussen diensten komen met het dienstennetwerk.Een gestolen geheim verloopt of wordt vervangen, maar wat ermee is gedaan, blijft staan. Een incident in de ene cel blijft binnen die cel, behalve via vlootbrede rollen en gedeelde voorzieningen.
SoftwareAlleen software uit de eigen containerregistry; een onveranderbaar besturingssysteem op de knooppunten; containers met een alleen-lezen bestandssysteem, afgedwongen in productie, en zonder verhoogde rechten, op vastgelegde systeemonderdelen na.De beveiligingsbewaking volgt het gedrag tijdens gebruik; zij meldt afwijkende processen en beëindigt ze waar dat vooraf is toegestaan en beproefd.
Gedrag, logging en reactieAudit- en beveiligingslogboeken van alle lagen naar het SOC; detectieregels met een draaiboek; automatische isolatie of beëindiging, na beproeving.Herstel uit code en uit gecontroleerde kopieën.
HerstelEen onveranderbare kopie; een herstelomgeving voor herstel op een gezonde cel; herbouw vanuit code met nieuwe geheimen.Laatste laag: hierop steunt het herstel na een geslaagde aanval.
VoorstelWerking#

Ieder toegangsverzoek doorloopt de drie functies die de zero-trust-benadering van NIST SP 800-207 onderscheidt. Informatiebronnen leveren de context: de inventaris, de bewaking en het identiteitsbeheer. Beslispunten staan het verzoek toe of weigeren het: de toegangsvoorziening, de beleidstoetsing, de zonecontrole en de toelatingscontrole. Handhavingspunten voeren de beslissing uit: het netwerkbeleid, de toelating van software en de toegangsgateway. De beveiligingsbewaking sluit de kring: zij volgt het gedrag tijdens gebruik, meldt afwijkingen en laat het cluster zelf ingrijpen waar dat vooraf is toegestaan en beproefd.

Toelichting

Niet iedere laag vult alle drie de functies in. Waar het toegangspad dat ondersteunt, telt ook de toestand van het verzoekende onderdeel mee, en welk pad welke controle uitvoert, wordt vastgelegd en beproefd. De voorbeeldinrichtingen van NIST SP 1800-35 zijn het ijkpunt voor de eigen inrichting. Zie zero trust.

VoorstelWaarde#

De maatregelen van de baseline zijn ingedeeld in elf domeinen.

DomeinWaar het over gaat
Identiteit en toegangAccounts, aanmelding, rollen, herbeoordeling en vertrek.
BeheertoegangBeheerpaden, verhoogde rechten, noodtoegang en sessieopname.
Geheimen, sleutels en certificatenGeheimenbeheer, sleutelbeheer, versleuteling en certificaten.
Apparatuur en fysieke basisFirmware, beveiligde opstart, beheerinterfaces, fysieke toegang en afvoer.
Netwerk en scheidingZones, verkeersregels, uitgaand verkeer en ingangen.
Clusters en werklastenClusterinrichting, compliancecontrole, rechten van containers, integriteit en inventaris.
Logging en detectieLogbronnen, bescherming en bewaring van logboeken, detectieregels, beoordeling en dreigingsinformatie.
Softwareketen en kwetsbaarhedenBouwen, testen, ondertekenen, toelaten, scannen en bijwerken.
Back-up en herstelOnveranderbare kopieën, herstelomgeving, continuïteitsplan en herstel na een aanval.
Leveranciers en ontwikkelteamScreening, toegang, gegevensgebruik, afspraken en overdracht.
Beleid, documentatie en nalevingBeveiligingsdocumentatie, dreigingsmodel, eisen in projecten en doorlopende bewaking van de naleving.
VastgesteldOntwerpbesluit#

Beveiligingsvoorzieningen die de hele vloot bedienen, staan op het vlootcluster; wat een cel nodig heeft om zelfstandig te werken, staat in die cel. De herstelvoorzieningen en de eigen bewakingsvoorziening staan buiten de platformclusters, zodat zij blijven werken als het platform zelf uitvalt. Controles per cluster draaien op het cluster zelf en werken bij een tijdelijk onbereikbaar vlootbeheer door met het laatst ontvangen beleid; nieuwe ondertekeningen en het centrale overzicht van de beveiligingsbewaking staan dan stil.

Toelichting

De eigen bewakingsvoorziening volgt in groeipadstap 2; zie bewaking die per datacenter onafhankelijk werkt. Dat de clusters doorwerken bij uitval van het vlootbeheer, toont de toets Uitval van het vlootbeheer.

VoorstelWaarde#

Iedere beveiligingsvoorziening heeft een vaste plaats en een vaste functie.

VoorzieningPlaatsFunctie
Centrale beveiligingsbewakingVlootcluster, met een sensor op ieder clusterKwetsbaarheden tijdens gebruik, afwijkend gedrag, netwerkinzicht en beleid voor werklasten; eindpuntbeveiliging en forensisch onderzoek geërfd van het SOC.
OndertekenvoorzieningVlootclusterCertificaten voor ondertekening, transparantielogboek en tijdstempels.
ToelatingscontroleIeder cluster en ieder knooppuntLaat alleen ondertekende software uit de eigen containerregistry toe, of leverancierssoftware uit de gecontroleerde spiegel met de handtekening van de leverancier; het knooppunt controleert de handtekening opnieuw bij het ophalen.
Compliancecontrole en integriteitsbewakingIeder cluster, uitgerold door het vlootbeheerScans tegen het baselineprofiel; integriteitsbewaking van bestanden op de knooppunten; controle van de gehoste besturing op het clusterbeheer.
Geheimenbeheer, toegangsvoorziening en identiteitsbeheerBasisdienstencluster van iedere cel, gevoed vanuit de centrale RWS-bronnenGeheimen, sleutels, PKI, aanmelding en levenscyclus van identiteiten.
Logverzameling en bewakingIeder cluster; samengevatte metingen op het vlootcluster; centrale logopslag, verkeersstromen en metingen van apparatuur vanaf groeipadstap 2 in de eigen bewakingsvoorzieningBewaking en meldingen per cluster. Audit- en beveiligingslogboeken gaan rechtstreeks naar het SOC, dat de ontvangst vóór de overdracht bevestigt en een kopie bewaart waarop platformbeheer geen schrijf- of verwijderrechten heeft.
BeheerwerkplekToegangsgateway en beheerservers op het basisdienstencluster: de beheeringang alleen bereikbaar vanuit het apparatuurbeheernetwerk, de teamingang voor verhogingen van teams via de externe verkeersverdeling; de noodwerkplek buiten de clustersOpname van iedere bevoorrechte sessie, rechtstreeks naar de vergrendelde opslag; noodtoegang, onafhankelijk van de toegangsvoorziening, als het platform zelf is aangetast.
Onveranderbare kopie en herstelomgevingKopie op de back-upvoorziening van RWS, met eigen beheer en een afgezonderde bewaarplaats buiten de datacenters; herstelomgeving in de herstelzone, met eigen aanmelding en netwerkBewaring, controle en terugzetten na een incident.

Kaders en herkomst

VastgesteldOntwerpbesluit#

BIO2 is het kader van de baseline: iedere maatregel verwijst naar BIO2, met de nummering van de beheersmaatregelen uit ISO/IEC 27002:2022 die BIO2 volgt. De SAK’s en de Cyberbeveiligingswet gelden daarnaast rechtstreeks.

Toelichting

Sinds 15 augustus 2026 schrijft de Cyberbeveiligingsregeling voor de sector overheid de beheersmaatregelen uit ISO/IEC 27002:2022 voor, behalve die voor licenties en privacy, en vult ze aan met de overheidsmaatregelen uit BIO2 versie 1.3. De baseline verwijst ook naar de maatregelen voor licenties en privacy, omdat die voor het platform relevant blijven. Voor de wettelijke verankering van BIO2 zie het bestuur is eindverantwoordelijk.

VoorstelWaarde#

De eisen van de referentieset zijn afgeleid van de beheersmaatregelen uit NIST SP 800-53, revisie 5, en per onderwerp gekoppeld aan de beheersmaatregelen uit ISO/IEC 27002:2022, de basis van de nummering van BIO2. Een koppeling stelt maatregelen niet gelijk en bewijst geen naleving.

OnderwerpBeheersmaatregelen uit NIST SP 800-53Beheersmaatregelen uit ISO/IEC 27002:2022
Identiteit en toegangAC-2 Account Management; AC-3 Access Enforcement; AC-5 Separation of Duties; AC-6 Least Privilege; AC-17 Remote Access; IA-2 Identification and Authentication (Organizational Users); IA-5 Authenticator Management; IA-7 Cryptographic Module Authentication5.15 Toegangsbeveiliging; 5.16 Identiteitsbeheer; 5.17 Authenticatie-informatie; 5.18 Toegangsrechten; 8.21 Beveiliging van netwerkdiensten; 8.24 Gebruik van cryptografie
Configuratie, hardening en assetbeheerCM-2 Baseline Configuration; CM-6 Configuration Settings; CM-7 Least Functionality; CM-8 System Component Inventory; MA-4 Nonlocal Maintenance5.9 Inventaris van informatie en andere bedrijfsmiddelen; 5.15 Toegangsbeveiliging; 5.16 Identiteitsbeheer; 8.2 Bevoorrechte toegangsrechten; 8.9 Configuratiebeheer; 8.31 Scheiding van ontwikkel-, test- en productieomgevingen
Kwetsbaarheden en veilige softwareRA-5 Vulnerability Monitoring and Scanning; SI-2 Flaw Remediation; SI-3 Malicious Code Protection; SI-4 System Monitoring; SI-7 Software, Firmware, and Information Integrity; SA-11 Developer Testing and Evaluation; SR-3 Supply Chain Controls and Processes; SR-5 Acquisition Strategies, Tools, and Methods5.8 Informatiebeveiliging in projectbeheer; 5.19 Informatiebeveiliging in leveranciersrelaties; 5.21 Informatiebeveiliging in de ICT-toeleveringsketen; 8.7 Bescherming tegen malware; 8.8 Beheer van technische kwetsbaarheden; 8.9 Configuratiebeheer; 8.16 Monitoren van activiteiten; 8.28 Veilig programmeren
Logging, audit en detectieAU-2 Event Logging; AU-6 Audit Record Review, Analysis, and Reporting; AU-8 Time Stamps; AU-9 Protection of Audit Information8.15 Loggen; 8.16 Monitoren van activiteiten; 8.17 Kloksynchronisatie; 8.24 Gebruik van cryptografie
IncidentresponsIR-4 Incident Handling; IR-5 Incident Monitoring; IR-6 Incident Reporting5.24 Planning en voorbereiding van incidentbeheer; 5.25 Beoordeling van en besluitvorming over gebeurtenissen; 5.26 Reactie op incidenten; 5.27 Leren van incidenten; 5.28 Verzamelen van bewijsmateriaal; 8.7 Bescherming tegen malware; 8.16 Monitoren van activiteiten
Netwerkbeveiliging en cryptografieSC-3 Security Function Isolation; SC-5 Denial-of-Service Protection; SC-7 Boundary Protection; SC-8 Transmission Confidentiality and Integrity; SC-12 Cryptographic Key Establishment and Management; SC-13 Cryptographic Protection; SC-18 Mobile Code; SC-23 Session Authenticity; SC-28 Protection of Information at Rest; SC-39 Process Isolation5.16 Identiteitsbeheer; 5.17 Authenticatie-informatie; 8.9 Configuratiebeheer; 8.20 Netwerkbeveiliging; 8.21 Beveiliging van netwerkdiensten; 8.24 Gebruik van cryptografie; 8.28 Veilig programmeren; 8.31 Scheiding van ontwikkel-, test- en productieomgevingen, alleen als nummer uit de referentieset
Continuïteit en herstelCP-2 Contingency Plan; CP-6 Alternate Storage Site; CP-7 Alternate Processing Site; CP-9 System Backup; CP-10 System Recovery and Reconstitution5.30 ICT-gereedheid voor bedrijfscontinuïteit; 8.13 Back-up van informatie
Beleid en documentatiePL-2 System Security and Privacy Plans; CA-7 Continuous Monitoring5.1 Beleid voor informatiebeveiliging; 5.8 Informatiebeveiliging in projectbeheer; 8.9 Configuratiebeheer; 8.16 Monitoren van activiteiten
Toelichting

De titels komen uit ISO/IEC 27002:2022. De koppeling volgt de referentieset, op vier punten gecorrigeerd; zie correcties op de koppeling.

VoorstelOntwerpbesluit#

De referentieset geeft enkele ISO-nummers een andere titel en koppelt ze daardoor aan een ander onderwerp. Op vier punten is de koppeling daarom gecorrigeerd, in lijn met de nummering die de baseline zelf gebruikt.

NIST-maatregelenIn de referentiesetGebruikte koppelingReden
Incidentrespons: IR-4, IR-5 en IR-6Bescherming tegen malware (8.7)Aangevuld met 5.24 tot en met 5.28Die maatregelen beschrijven het incidentbeheer zelf.
Sleutelbeheer (SC-12) en authenticatie van cryptografische modules (IA-7)Levenscyclus van veilige ontwikkeling (8.25)Gebruik van cryptografie (8.24)Sleutelbeheer valt onder 8.24, net als bij de sleutelmaatregelen van de baseline.
Onderhoud op afstand (MA-4)Toegang tot broncode (8.4)Bevoorrechte toegangsrechten (8.2)Zo koppelt ook de baseline haar maatregelen voor het afgeschermde beheerpad en de opname van sessies.
Isolatie van beveiligingsfuncties en processen (SC-3 en SC-39)Scheiding van ontwikkel-, test- en productieomgevingen (8.31)8.31 alleen als nummer uit de referentieset, niet als dekkingDe baseline vult die isolatie in met de maatregelen voor containers en knooppunten en gebruikt 8.31 voor de scheiding van ontwikkel-, test- en productieomgevingen.
VoorstelUitgangspunt#

Release 5.2.0 van NIST SP 800-53, van augustus 2025, voegt maatregelen toe voor een vaste opbouw van logregels, voor ontwerpen op cyberweerbaarheid en voor oorzaakanalyse bij foutherstel, en verbreedt de integriteitscontrole naar alle software. Omdat die maatregelen buiten de standaardselecties van NIST vallen, is de referentieset niet aangepast; de CISO-functie beoordeelt bij de herziening van de baseline of zij voor het platform gelden.

Toelichting

De baseline dekt ze nu deels: de logdoorsturing legt de opbouw van logregels niet vast, de verbeterpunten na een incident zijn geen ontwerp op cyberweerbaarheid en geen oorzaakanalyse bij iedere foutreparatie, en de ondertekening van software beschermt alleen toegelaten containerbeelden.

Referentieset en dekking

VastgesteldUitgangspunt#

De referentieset securityeisen vertaalt BIO2 naar toetsbare eisen voor een containerplatform: 53 eisen in acht onderwerpen. Zij vult de SAK’s en de wet aan, maar vervangt ze niet. De baseline is aan die eisen getoetst, en per eis liggen het ontwerp, de leverfase, het bewijs en een eventuele uitzondering vast.

Toelichting

Aan iedere eis hangt ten minste één maatregel, maar een koppeling is nog geen aangetoonde dekking. Daarom volgt bij de levering per eis het bewijs of een goedgekeurde uitzondering; de acceptatieproef voor bewijs en naleving toetst dat. Uitzonderingen, bevindingen en nieuwe dreigingen stellen de baseline bij.

VoorstelWaarde#

Van de 53 eisen zijn er 38 gedekt, 14 aangevuld en één deels gedekt. Gedekt betekent: in het ontwerp belegd en in een leverfase gepland. Aangevuld betekent hetzelfde, nadat de baseline op grond van de toetsing is aangevuld of aangescherpt. Deels gedekt is alleen de versleuteling van al het verkeer tussen knooppunten.

OnderwerpEisenStandHoe de baseline het onderwerp dekt
Identiteit en toegang87 gedekt, 1 aangevuldToegangsvoorziening en identiteitsbeheer per cel, gevoed uit de centrale RWS-bronnen; rechten alleen via rollen, met teamrollen per naamruimte en platformrollen zonder blijvende clusterbeheerrechten; bevoorrechte sessies alleen via de beheerwerkplek; alle geheimen uit het geheimenbeheer, kortlevend per soort; een tussen-CA per cel onder de interne PKI van RWS; een verlopen of ingetrokken verhoging werkt binnen één uur nergens meer.
Configuratie, hardening en assetbeheer75 gedekt, 2 aangevuldDe gewenste inrichting in versiebeheer, met afwijkingen gemeld en, waar het beleid afdwingt, teruggezet; een baselineprofiel volgens erkende benchmarks, met het striktste profiel voor teamnaamruimten; een automatisch gevulde inventaris; twee beoordelaars naast de auteur; een onveranderbaar besturingssysteem, met audit van iedere noodsessie.
Kwetsbaarheden en veilige software85 gedekt, 3 aangevuldEen scan bij de bouw en ten minste dagelijks voor draaiende software; een sensor op ieder cluster en integriteitsbewaking van de knooppunten; verplichte analyses en tests in het pijplijnsjabloon; ondertekening met transparantielogboek en toelating alleen na vrijgave; een toelatingsroute voor software van derden en een beoordeling van leveranciers.
Logging, audit en detectie64 gedekt, 2 aangevuldAudit van de clusterbesturing met de inhoud van verzoeken; alle logbronnen versleuteld naar het SOC, met ten hoogste vijf minuten vertraging; tijd geërfd van de tijdvoorziening van netwerkbeheer; onveranderbare bewaring bij het SOC en in een vergrendelde logopslag; een wekelijkse beoordeling van de logboeken door het SOC.
Incidentrespons65 gedekt, 1 aangevuldDraaiboeken per incidenttype, vóór de overdracht aantoonbaar uitgevoerd door de primaire en plaatsvervangende beheerders; vaste rollen bij een incident; forensisch onderzoek geërfd van het SOC; opvolging van meldingen binnen de reactietijd van de regel; het meldtraject onder de Cyberbeveiligingswet; isolatie met netwerkbeleid, die ook de analist van het SOC kan starten.
Netwerkbeveiliging en cryptografie86 gedekt, 1 aangevuld, 1 deelsBeheerdersbeleid met de hoogste voorrang op alle clusters en een basisregel die weigert wat niet is toegestaan; versleuteling van gevoelige objecten en van alle opslag- en systeemschijven; kortlevende certificaten uit de tussen-CA van de cel; een beperkte beveiligingscontext voor iedere container; limieten en quota per naamruimte; begrensde sessies. De versleuteling van al het verkeer tussen knooppunten is deels gedekt.
Continuïteit en herstel54 gedekt, 1 aangevuldEen continuïteitsplan dat aansluit op de continuïteitsplanning van RWS; een tweede dienstexemplaar in de andere cel voor bedrijfskritische productie, met gecontroleerde overname; momentopnamen en replicatie binnen de cel en een onveranderbare kopie daarbuiten; een herstelproef ieder kwartaal, vergeleken met het dienstprofiel.
Beleid en documentatie52 gedekt, 3 aangevuldDe beveiligingsarchitectuur in het ISMS, een dreigingsmodel, de gewenste inrichting in versiebeheer, doorlopende bewaking van de naleving en toetsing van iedere dienstbeschrijving en ieder ontwerp.
Totaal5338 gedekt, 14 aangevuld, 1 deels—
Toelichting

Tenzij anders vermeld hoort een dekkende maatregel bij de eerste levering en geldt het bewijs bij oplevering.

VoorstelMaatregel#

Een aantal maatregelen van de baseline dekt een eis uit de referentieset maar gedeeltelijk. Die grenzen zijn bekend en blijven zichtbaar bij de beoordeling van het restrisico.

MaatregelWat zij niet dekt
Baselineprofielen voor containers en knooppuntenZij beperken rechten en toegang tot het knooppunt, niet de functies van de toepassing zelf.
Registratie van gebeurtenissen in het versiebeheerHet versiebeheer heeft geen eigen auditlogboek: het toegangslogboek en een dagelijkse vergelijking van rechten leveren de gebeurtenissen, niet iedere wijziging.
SchijfversleutelingZij beschermt tegen verlies van media, niet tegen een beheerder van het draaiende systeem.
Limieten en quota per naamruimteZij begrenzen de aangevraagde capaciteit bij toelating, niet het feitelijke verbruik van gedeelde netwerk- en opslagcapaciteit; de externe verkeersverdeling begrenst wel de verbindingen per virtuele server.
Geen uitvoerbare software van buiten de containerregistryGeïnterpreteerde code en code in het geheugen worden beperkt en gemeld, niet uitgesloten.
Isolatie met netwerkbeleidSecundaire interfaces en het hostnetwerk vallen erbuiten; zij zijn alleen toegestaan als de dienstbeschrijving ze vermeldt.
Gescheiden netwerken en netwerkbeleidZij beperken wie een onversleutelde stroom kan bereiken, maar maken haar niet vertrouwelijk.
VoorstelOntwerpbesluit#

Vier eisen uit de referentieset waarvoor bij de toetsing een keuze nodig was, zijn als volgt ingevuld.

EisInvulling
Veilig ontwikkelen en testenEen verplichte statische en dynamische test in het pijplijnsjabloon, naast de afhankelijkheidsanalyse, voor alle via het platform geleverde software; software van derden gaat via de toelatingsroute, met een scan bij toelating.
Afscherming van containersDe beperkte beveiligingscontext met SELinux en seccomp voor iedere container, vanaf de eerste levering; een aparte sandbox per container voor werklasten met verhoogde eisen in bedrijfskritische productie, in groeipadstap 4.
Onveranderbare logboekenEen kopie bij het SOC vanaf de overdracht, waarop platformbeheer geen schrijf- of verwijderrechten heeft, en een vergrendelde logopslag in de eigen bewakingsvoorziening vóór de vrijgave voor reguliere productie. De vergrendeling geldt ook voor opslagbeheerders en wordt vóór de ingebruikname beproefd.
DreigingsmodelOpgesteld bij de inrichting van de baseline en daarna onderhouden; beoordeeld vóór de vrijgave voor productie.
Toelichting

Tot de vergrendelde logopslag er is, blijft de dienst in het profiel ontwikkelen en beproeven, onder een goedgekeurde uitzondering met einddatum; zie lopende uitzonderingen.

VoorstelMaatregel#

De eis dat al het verkeer tussen knooppunten versleuteld is, is deels gedekt. Het platform versleutelt het verkeer tot de ingang van ieder cluster, op alle beheerpaden en naar geheimenbeheer, databases en opslag. Tussen de knooppunten van een gehost applicatiecluster kan de netwerklaag het verkeer niet versleutelen, omdat gehoste besturing dat niet ondersteunt. Tot het dienstennetwerk er is, versleutelen toepassingen hun onderlinge verkeer zelf, en is iedere onversleutelde stroom een uitzondering met einddatum.

Toelichting

In de doelsituatie versleutelt het dienstennetwerk het verkeer tussen de deelnemende toepassingen wederzijds; het wordt ingeschakeld zodra de leverancier deze opstelling in de gekozen versie ondersteunt. Verkeer van virtuele machines, van pods op het hostnetwerk en van platformonderdelen valt er ook dan buiten. De afwijking wordt bij iedere platformversie opnieuw beoordeeld.

VoorstelWerking#

Bij iedere nieuwe dienst in het groeipad toetst de beveiligingsadviseur het ontwerp vóór het ontwerpbesluit aan de acht onderwerpen van de referentieset. De eisen zijn een ondergrens: het dreigingsmodel van de dienst kan aanvullende maatregelen vragen. Voegt een dienst een nieuw type onderdeel toe, dan wordt de dekking aangevuld met de maatregelen voor dat onderdeel; blijkt een eis niet gedekt, dan wordt de baseline uitgebreid.

Toelichting

Voorbeelden van zo’n nieuw onderdeel zijn het dienstennetwerk bij applicatieverkeer en ketenkoppelingen en versnelde rekenkracht bij datawetenschap en AI. Wijzigt de referentieset zelf, bijvoorbeeld na een nieuwe versie van NIST SP 800-53 of BIO2, dan volgt een nieuwe toetsing van de volledige baseline.

Aanvullingen, dragende en geërfde maatregelen

VoorstelWaarde#

De toetsing aan de referentieset leverde tien aanvullende maatregelen en zeven aangescherpte normen op; de uitwerking van softwarelevering, beheertoegang en geheimen voegde er drie maatregelen aan toe. De aanvullingen vallen in bestaande domeinen, behalve die voor beleid, documentatie en naleving: dat domein is toegevoegd, omdat het bewijs daarvoor vooral uit documenten en besluiten komt.

MaatregelSoortWat is toegevoegd of aangescherpt
Actuele inventarisAanvullingEen actuele inventaris, automatisch gevuld.
Geen software van buiten de containerregistryAanvullingWerklasten laden tijdens gebruik geen uitvoerbare software van buiten de containerregistry.
Veilig programmerenAanvullingVeilig programmeren voor applicatieteams, met verplichte analyses en tests in het pijplijnsjabloon.
Beoordeling van logboekenAanvullingEen wekelijkse beoordeling van audit- en beveiligingslogboeken door het SOC, naast de automatische detectie.
Beoordeling van leveranciersAanvullingEen beoordeling van leveranciers van platformonderdelen en SaaS.
ContinuïteitsplanAanvullingEen continuïteitsplan voor het platform met herstelvolgorde, afhankelijkheden en aansluiting op de bedrijfsimpactanalyse.
BeveiligingsarchitectuurAanvullingDe beveiligingsarchitectuur gedocumenteerd en in het ISMS opgenomen.
DreigingsmodelAanvullingEen dreigingsmodel per platformcluster, voor de vlootbrede voorzieningen en per dienst, beoordeeld vóór vrijgave.
Toetsing van dienstbeschrijving en ontwerpAanvullingToetsing van iedere dienstbeschrijving aan de baseline en van ieder ontwerp aan de referentieset.
Doorlopende nalevingAanvullingDoorlopende bewaking en rapportage van de naleving.
ToelatingsrouteAanvulling uit de uitwerking van de softwareleveringEen toelatingsroute voor software van derden.
Gewoon werk zonder verhogingAanvulling uit de uitwerking van de beheertoegangGewoon werk gebeurt zonder verhoging; een verhoging keurt een ander dan de aanvrager goed, ook binnen de eigen dienst.
Langlopende processen en koppelingenAanvulling uit de uitwerking van de geheimenEen vernieuwbare identiteit, of een beheerd geheim met overlappende vervanging.
Technische identiteiten en serviceaccountsAangescherpte normServiceaccounts per naamruimte, zonder automatisch gekoppeld token tenzij de toepassing de API nodig heeft; rechten buiten de naamruimte alleen voor vastgelegde platformtaken.
Rechten van containers en knooppuntenAangescherpte normVerplichte toegangscontrole met SELinux, afdwingend op ieder knooppunt.
Onveranderbaar besturingssysteemAangescherpte normWijzigingen alleen via de machineconfiguratie; geen rechtstreekse aanmelding buiten de noodroute.
KwetsbaarheidsscanAangescherpte normEen kritieke kwetsbaarheid blokkeert de vrijgave, een hoge de vrijgave voor productie zonder goedgekeurde tijdelijke maatregel.
Doorsturen van logboekenAangescherpte normVersleuteld transport van logboeken, met wederzijdse herkenning waar de ontvanger dat ondersteunt.
Bewaring van logboekenAangescherpte normOnveranderbare bewaring bij het SOC en in de vergrendelde logopslag van de eigen bewakingsvoorziening.
Opvolging van meldingenAangescherpte normDoorlopende bewaking van meldingen door het SOC, binnen de reactietijd.
VoorstelWaarde#

Twaalf maatregelen dragen elk aan drie of meer eisen bij en dekken samen 25 van de 53 eisen. Valt er één weg, dan verzwakt de dekking van meerdere eisen tegelijk. Daarom vragen zij het meeste bewijs en gaan zij bij de inrichting van de baseline voor: eerst identiteit en het beheerpad, dan versiebeheer en beleid, daarna softwareketen, logging, netwerk en herstel.

MaatregelEisenOnderwerpen van de referentieset
Compliancecontrole: ieder cluster voldoet aan het baselineprofiel5Configuratie, hardening en assetbeheer; kwetsbaarheden en veilige software; netwerkbeveiliging en cryptografie; beleid en documentatie
Wijzigingen buiten versiebeheer worden gemeld en teruggezet4Configuratie, hardening en assetbeheer; kwetsbaarheden en veilige software; beleid en documentatie
Technische identiteiten en serviceaccounts met eigenaar en minimale rechten4Identiteit en toegang; netwerkbeveiliging en cryptografie
Audit- en beveiligingslogboeken versleuteld naar het SOC4Logging, audit en detectie; incidentrespons
Wijzigingen via versiebeheer, behalve noodwijzigingen4Configuratie, hardening en assetbeheer; beleid en documentatie
Verkeer versleuteld tijdens transport4Identiteit en toegang; logging, audit en detectie; netwerkbeveiliging en cryptografie
Containers zonder verhoogde rechten, met SELinux afdwingend3Identiteit en toegang; configuratie, hardening en assetbeheer; netwerkbeveiliging en cryptografie
Onveranderbaar besturingssysteem en integriteitsbewaking3Configuratie, hardening en assetbeheer; kwetsbaarheden en veilige software
Rechten alleen via rollen3Identiteit en toegang
Verhoogde rechten tijdelijk en per taak3Identiteit en toegang
Gewoon werk zonder verhoging3Identiteit en toegang
Kwetsbaarheidsscan vóór vrijgave en tijdens gebruik3Kwetsbaarheden en veilige software
Toelichting

Die volgorde geldt voor de volledige invulling; een basis voor logging, netwerkscheiding en back-up is vanaf de eerste opbouw in bedrijf. De meeste dragende maatregelen zijn beleid in het vlootbeheer, dat platformbeheer één keer inricht en dat dan voor alle clusters geldt, met grotendeels automatisch verzameld bewijs. De tijdelijke verhoging en het gewone werk zonder verhoging lopen via het identiteitsbeheer, de kwetsbaarheidsscan via de bouwpijplijn en de dagelijkse scan van draaiende software.

VoorstelUitgangspunt#

Eisen uit de referentieset die het platform al door zijn opbouw vervult, zoals met het onveranderbare besturingssysteem van de knooppunten, vragen per cluster weinig extra beheer; het bijhouden van beelden, uitzonderingen en bewijs blijft wel werk voor platformbeheer. Eisen die mensenwerk blijven, zoals de periodieke beoordeling van logboeken, het dreigingsmodel en de afspraken met leveranciers, hebben een eigenaar en een ritme, zodat de inspanning zichtbaar blijft.

VastgesteldRegel#

Het platform erft maatregelen van bestaande RWS-diensten. Het SOC levert eindpuntbeveiliging, forensisch onderzoek, operationele en tactische dreigingsinformatie, de kwartaalevaluatie van detectieregels en de SIEM; netwerkbeheer levert DNSSEC en geauthenticeerde tijd; de Linux-updatedienst levert de updates; en de bestaande bestandsopslag dient als migratiebron. Voor iedere geërfde maatregel is er een dienstafspraak met koppelvlak en bewijs, die bij de inrichting van de baseline wordt gesloten en bij de acceptatie van de eerste levering hoort.

Toelichting

De bescherming van de inhoud tegen lekken en ongewenst kopiëren en het toezicht op niet-toegelaten clouddiensten zijn geërfd van de werkplekdienst; zie gegevens blijven van RWS en zeggenschap bij SaaS. Ook de crisisorganisatie is geërfd, van de continuïteitsplanning van RWS. Voor de afspraken zelf geldt afspraken voor gedeelde voorzieningen.

Beleid, documentatie en naleving

VoorstelMaatregel#

De beveiligingsarchitectuur van het platform is gedocumenteerd en opgenomen in het managementsysteem voor informatiebeveiliging (ISMS) van RWS: de architectuur en de vertrouwensgrenzen, de maatregelen, hun technische invulling en de koppeling aan BIO2, de referentieset en de SAK-versies waartegen zij is opgesteld. Zij wordt bijgewerkt bij iedere nieuwe versie en bij ieder ontwerpbesluit dat een maatregel raakt, en jaarlijks door de CISO-functie vastgesteld.

Toelichting

De beveiligingsarchitectuur staat in versiebeheer, in de opslagplaats Beleid; iedere versie krijgt een versielabel en een registratie in het ISMS. Een ontwerpbesluit dat een maatregel raakt, verwijst naar die maatregel. Het bewijs is de vastgestelde versie met datum en de registratie in het ISMS.

VoorstelMaatregel#

Voor het platform en voor iedere platformdienst is er een dreigingsmodel dat vóór de vrijgave voor productie is beoordeeld: per platformcluster, voor de vlootbrede voorzieningen die beide cellen kunnen raken en per dienst in het groeipad. Het wordt jaarlijks en bij een grote wijziging herzien, en een dreiging zonder maatregel staat in het risicoregister.

Toelichting

Het dreigingsmodel volgt de methode STRIDE per vertrouwensgrens en staat in de opslagplaats Beleid, naast de baseline; iedere dreiging verwijst naar de maatregel die haar afdekt of naar het risicoregister. De beveiligingsadviseur beoordeelt het vóór de vrijgave, en de jaarlijkse herziening staat in de beproevingskalender.

VoorstelMaatregel#

Beveiligingseisen zijn onderdeel van iedere levering. Iedere dienstbeschrijving wordt getoetst aan de baseline en ieder ontwerp van een nieuwe dienst aan de referentieset en de toepasselijke SAK-eisen. Bij de oplevering is er per maatregel bewijs van een gemeten of beproefde werking, niet alleen van een aanwezige instelling, en zonder beoordeling door de beveiligingsadviseur en een besluit over het restrisico is er geen vrijgave.

Toelichting

De beleidstoetsing van de dienstbeschrijving draait in de pijplijn van de opslagplaats Afnemers. Ieder ontwerpbesluit heeft een vast onderdeel ‘beveiliging’ met de geraakte maatregelen en eisen. Het acceptatiedossier bevat per maatregel het bewijs, met eigenaar en bewaard resultaat, of de goedgekeurde uitzondering. Zie vrijgave en restrisico.

VoorstelMaatregel#

De naleving van de baseline wordt doorlopend bewaakt en gerapporteerd: met een nalevingsoverzicht per cluster, dagelijks bijgewerkt uit de compliancescan, de toelatingscontrole en de beleidsafwijkingen, en met een kwartaalrapportage aan het bestuur over de open afwijkingen en uitzonderingen.

Toelichting

Het overzicht combineert de beleidsstatus per cluster in het vlootbeheer, de complianceweergave van Advanced Cluster Security en de rapportage van de Compliance Operator. Een geplande taak stelt maandelijks het nalevingsrapport samen, met de open afwijkingen, de uitzonderingen en hun leeftijd. Zie de maatstaf naleving bij de maatstaven.

VoorstelEis#

Voor beleid en documentatie stelt de referentieset vijf eisen, die de baseline als volgt dekt.

EisDekkingStand
Het platform is gedocumenteerd in het ISMS of in een beschrijving van de beveiligingsarchitectuur.De beveiligingsarchitectuur is gedocumenteerd en in het ISMS opgenomen.Aangevuld
De beveiligingsdocumentatie omvat de platformarchitectuur, de vertrouwensgrenzen, het dreigingsmodel en de koppeling van maatregelen aan NIST, ISO en BIO.De beveiligingsarchitectuur en het dreigingsmodel, dat bij de inrichting van de baseline wordt opgesteld en vóór de vrijgave voor productie is beoordeeld.Gedekt
Doorlopende bewaking is ingericht via dashboards, compliancescans en meldingen tijdens gebruik.Het nalevingsoverzicht per cluster en de kwartaalrapportage, samen met de compliancecontrole en de beveiligingsbewaking.Aangevuld
De configuratiedocumentatie is actueel en weerspiegelt de werkelijke clustertoestand.De gewenste inrichting staat in versiebeheer; het vlootbeheer meldt afwijkingen, die zichtbaar blijven tot herstel of een goedgekeurde uitzondering.Gedekt
Beveiligingseisen zijn onderdeel van projecten (projectbeveiliging).Beveiliging in iedere levering: toetsing van dienstbeschrijving en ontwerp, en bewijs bij de oplevering.Aangevuld

Uitzonderingen en onderhoud

VoorstelRegel#

Iedere uitzondering op de baseline staat in het uitzonderingsregister in de opslagplaats Beleid, met een compenserende maatregel, een eigenaar en een einddatum van ten hoogste zes maanden na het besluit. Zij geldt pas na het besluit van de bevoegde verantwoordelijke, niet al bij registratie, en blijft in het nalevingsoverzicht zichtbaar als afwijking met aanvaard risico, niet als naleving. Zonder verlenging geldt de afwijking na de einddatum weer als open.

Veld in het registerInhoud
Aanduiding en maatregelVolgnummer, de maatregel waarvan wordt afgeweken en de versie van de baseline.
Onderdeel of dienstHet cluster, de dienst of de voorziening waarvoor de uitzondering geldt; bij een onversleuteld pad de verkeersstroom.
RedenWaarom de maatregel nog niet kan worden toegepast.
RisicoBeschrijving en inschatting van het risico, beoordeeld door de beveiligingsadviseur.
Compenserende maatregelWat het risico intussen beperkt en hoe de werking daarvan wordt aangetoond.
Eigenaar en einddatumDe verantwoordelijke persoon; de einddatum ligt ten hoogste zes maanden na het besluit.
BesluitDatum en ondertekening door de bevoegde verantwoordelijke, met medeondertekening door de CISO-functie voor het restrisico.
VoortgangDe stand van de oplossing en de werking van de compenserende maatregel, bij iedere verlenging.
Toelichting

Een uitzondering is soms nodig, bijvoorbeeld omdat een leverancier een instelling nog niet ondersteunt. Wie het restrisico mag aanvaarden, staat bij vrijgave en restrisico; zie ook een principe dat nog niet volledig is ingevuld.

VoorstelWaarde#

De eerste levering begint met drie bekende uitzonderingen op de baseline, elk met een compenserende maatregel en een vast einde.

UitzonderingCompenserende maatregelEinde
Onversleutelde verkeersstromen tussen toepassingen, zolang het dienstennetwerk ontbreekt; een uitzondering per stroomVersleuteling op toepassingsniveau; gescheiden netwerken en netwerkbeleid beperken wie de stroom kan bereiken.Bij de vrijgave voor reguliere productie gesloten, of door de CISO-functie opnieuw geaccepteerd met een nieuwe einddatum.
Een tweede factor met eenmalige codes (TOTP) op de gateway van de voorlopige beheerwerkplek, in plaats van een phishingbestendige factorGeharde beheerapparaten en opname van de sessies.De acceptatie van het basisdienstencluster.
Geen centrale logopslag en geen historie van verkeersstromen tot groeipadstap 2De dienst blijft in het profiel ontwikkelen en beproeven; audit- en beveiligingslogboeken gaan rechtstreeks naar het SOC, dat een kopie bewaart waarop platformbeheer geen schrijf- of verwijderrechten heeft.De eigen bewakingsvoorziening met vergrendelde logopslag, vóór de vrijgave voor reguliere productie.
Toelichting

Voor de onversleutelde stromen is de CISO-functie genoemd als degene die de uitzondering opnieuw accepteert, terwijl een uitzondering in het algemeen pas geldt na het besluit van de bevoegde verantwoordelijke, met medeondertekening door de CISO-functie. Welke rol hier beslist, ligt nog niet vast.

VoorstelWerking#

De CISO-functie is eigenaar van de baseline en herziet haar jaarlijks, en daarnaast na een significant incident, na een nieuwe versie van BIO2 of van de referentieset en bij een nieuwe dienst in het groeipad. De jaarlijkse herziening verwerkt nieuwe versies van de SAK’s, het patchbeleid, de bewaartermijnen van het SOC, het forensisch beleid, het classificatieschema en de cryptografietabel van RWS, en gemeten afwijkingen van de normen.

Toelichting

De baseline volgt nu de SAK’s in de versie van juli 2025. Hoe normen worden gemeten, staat bij getalsmatige normen.

VoorstelRegel#

Een wijziging van de baseline loopt via een beoordeeld wijzigingsvoorstel in de opslagplaats Beleid. Nieuwe en strengere regels gaan, net als ander beleid, in twee fasen van melden naar afdwingen. Een regel die al wordt afgedwongen, gaat niet blijvend terug naar alleen melden; tijdelijk terugzetten kan alleen als terugvaloptie tijdens een uitrol, per uitrolgolf, of als goedgekeurde uitzondering met einddatum.

Verwijzen hiernaar

Onderwerpen 4
Ontwerpkeuzes 1