3.2.2.2 Cyber Operations & Response Engine (CORE)

Dit document beschrijft het Solution Building Block (SBB) voor de Cyber Operations & Response Engine (CORE). Het SBB biedt een samenhangend overzicht van de oplossing, waarin zowel de functionele en organisatorische context als de technische architectuur wordt vastgelegd. Het document dient als referentie voor architecten, ontwerpers, beheerders en andere stakeholders bij het realiseren, beheren en doorontwikkellen van de oplossing. Het SBB is opgebouwd uit twee hoofdhoofdstukken:

1. Solution Design: Dit hoofdstuk beschrijft de functionele en conceptuele aspecten van de oplossing, inclusief de doelstelling, scope, dienstverlening, afhankelijkheden en aansluiting op bestaande processen en architectuurkaders. Het biedt inzicht in wat de oplossing doet, voor wie deze bedoeld is en welke randvoorwaarden gelden.
2. High Level Design (HLD): Dit hoofdstuk geeft een overzicht van de technische en functionele architectuur op hoofdlijnen. Het beschrijft de belangrijkste componenten, hun onderlinge relaties, integraties met externe systemen en de wijze waarop de oplossing wordt gerealiseerd binnen de bestaande architectuur. Het HLD vormt tevens de basis voor verdere detaillering in een Low Level Design (LLD).

Door deze opbouw biedt het SBB zowel een conceptueel kader als een technisch overzicht, waarmee samenhang, consistentie en besluitvorming over implementatie en beheer worden ondersteund.

Solution design

CORE is een centrale voorziening die fungeert als technisch koppelvlak tussen het Security Operations Center (SOC) en de bredere IT-omgeving binnen RWS. De oplossing ondersteunt de monitoring- en responseprocessen van het SOC en creëert één gestandaardiseerde en geautomatiseerde werkwijze. Hierdoor kan het SOC efficiënter en schaalbaarder opereren, met minder afhankelijkheid van individuele systemen.

Binnen CORE is de businesslogica losgekoppeld van onderliggende COTS-tools (Commercial Off-The-Shelf). Logica, verrijking, correlatie en orkestratie worden centraal beheerd, waardoor tooling kan worden vervangen of uitgebreid zonder impact op processen of werkwijzen. Dit voorkomt vendor lock-in en vergroot de flexibiliteit van het securitylandschap.

Door integraties, datastromen en automatiseringsregels te bundelen in één uniforme laag, bevordert CORE consistentie, herbruikbaarheid en wendbaarheid binnen de securityketen. Als integraal onderdeel daarvan draagt het platform bij aan de versterking van de weerbaarheid van IT-diensten en infrastructuren. In dit SBB-document worden de technische, organisatorische en operationele kaders van CORE vastgelegd, inclusief afspraken over prestaties, verantwoordelijkheden, beveiliging en lifecyclemanagement.

Scope

Dit document behandelt het ontwerp van de oplossing op hoofdlijnen. Binnen deze scope vallen:

• Belangrijkste functionele en technische componenten van de oplossing
• De relaties tussen gebruikers en RWS systemen/componenten.
• Architectuurkaders die richting geven aan de verdere uitwerking in het LLD.

Doelgroep

Dit document is bedoeld voor alle stakeholders die betrokken zijn bij de ontwikkeling, beheer en gebruik van het platform. Daartoe behoren onder andere:

• Architecten die verantwoordelijk zijn voor de uitwerking en borging van enterprise- en solution-architectuurprincipes
• Ontwerpers en engineers die het technische ontwerp realiseren en vertalen naar het Low Level Design (LLD)
• Beheerders en operationele teams die betrokken zijn bij technische koppelingen met CORE
• Security- en compliancefunctionarissen die toezicht houden op naleving van beveiligings- en regelgevingskaders

Hoofdfuncties

CORE vervult binnen de securityketen twee primaire functies die gericht zijn op beheersing, continuïteit en voorspelbaarheid van de dienstverlening. Enerzijds faciliteert het platform de aansluiting op IT-servicemanagementprocessen, anderzijds ondersteunt het de geautomatiseerde uitvoering van terugkerende operationele taken. Samen zorgen deze functies voor een gestructureerde afhandeling van verstoringen en een betrouwbare uitvoering van werkzaamheden binnen de IT- en securityomgeving.

• IT Service Management (ITSM). Ondersteunt en borgt de aansluiting op ITSM-processen, met nadruk op incident management. Het platform faciliteert registratie, verrijking en opvolging van incidenten en zorgt voor eenduidige afhandeling, traceerbaarheid en rapportage, zodat verstoringen gecontroleerd en aantoonbaar worden afgehandeld.

• Scheduled Tasks. Voorziet in de geautomatiseerde uitvoering van geplande en terugkerende taken, zoals synchronisaties, controles en onderhoudsactiviteiten. Door deze taken centraal te beheren en te orkestreren, wordt consistentie verhoogd en wordt handmatige foutgevoeligheid verminderd.

Dienstverlening

Omdat het platform uitsluitend ten dienste staat van interne securityprocessen, is het niet aanvraagbaar of direct bruikbaar door andere onderdelen van de organisatie. Eventuele resultaten of inzichten uit CORE worden via bestaande SOC-diensten of rapportages beschikbaar gesteld aan relevante stakeholders.

Relaties

Belangrijke bovenliggende documenten en kaders die als input zijn gebruikt bij dit HLD zijn onder andere:

• Regelgeving: BIO, NIS2
• RWS-kaders en richtlijnen: strategie en beleid
• Security Architectuur Kader (SAK): Security incident en response v1.0
• Architecture Building Block (ABB): 
  • Security Monitoring
  • Security Incident Response

• Solution Building Block (SBB): 
  • tbd: SIEM
  • tbd: EDR

High Level Design

Dit hoofdstuk beschrijft het High Level Design (HLD) van de oplossing, als onderdeel van het Solution Building Block (SBB). Het HLD biedt op hoofdlijnen inzicht in de functionele en technische opzet, de belangrijkste componenten, hun onderlinge afhankelijkheden en de relaties met externe systemen en gebruikers. Het vormt tevens de basis voor de verdere detaillering in het Low Level Design (LLD).

Architectuur

Dit hoofdstuk beschrijft de architectuur van de oplossing op hoofdlijnen en geeft inzicht in de wijze waarop de verschillende componenten samenwerken binnen de organisatie en in relatie tot externe systemen en gebruikers. Het hoofdstuk is onderverdeeld in verschillende aspecten van de architectuur: een contextdiagram dat de algemene positionering en relaties visualiseert; de overwegingen voor productselectie; een overzicht van applicatiecomponenten en hun samenhang; de belangrijkste gegevensstromen; de classificatie van data; beveiligingsmaatregelen; en de onderliggende infrastructuur. Samen bieden deze paragrafen een integraal beeld van de functionele en technische opzet van de oplossing en vormen zij de basis voor verdere detaillering in het Low Level Design (LLD).

Contextdiagram

Product Selectie

Het SOC van Rijkswaterstaat heeft de keuze gemaakt om de tooling te schrijven in Python. De keuze is gevallen op deze taal aangezien deze veel support heeft vanuit verschillende partijen en valt onder een foundation die het onderhoud. Aangezien er veel partijen zijn die gebruik maken van Python, is er ook veel documentatie te vinden. Ook zijn er veel libraries beschikbaar die open-source zijn. Dit zorgt ervoor dat men niet alles zelf hoeft te ontwikkelen maar gebruik kan maken van de kennis en kunde van de gemeenschap. Als laatste is het een codeertaal die redelijk gemakkelijk te leren en je eigen te maken is. Dit zorgt ervoor dat men al kan beginnen met ontwikkelen met beperkte kennis en ervaring.

Voor CORE is verder gekozen om gebruik te maken van Django. Django is een open source, op python gebaseerd, web framework die het redelijk standaard Model-Template-View architectuur kader volgt. Django wordt bijgehouden en ontwikkeld door een onafhankelijke non-profit die zijn financiering van bedrijven en individuen krijgt. Het framework wordt gebruikt door bijv. Instagram en Bitbucket wat ook wijst op de professionalisering en functionering van het platform. Verder zijn er geen licentiekosten of dergelijke verbonden aan het platform wat in gebruik name ook bevorderd. Zie ook de memo omtrent het gebruik van open-source software.

Applicatiecomponenten & architectuur

Deze paragraaf beschrijft de opbouw en samenhang van de belangrijkste applicatiecomponenten waaruit de oplossing bestaat. CORE is gebouwd volgens een monolith-architectuur waarbij de verschillende integraties met andere componenten wel gemaakt worden als losse apps. Deze kunnen dan dus ook los ontwikkeld worden door verschillende mensen van het ontwikkelteam. Er is gekozen voor een monolith architectuur aangezien er een beperkt aantal mensen tegelijk gebruik gaan maken van de tool en er geen noodzaak is om bepaalde componenten los te laten schalen. Zolang de gehele applicatie voldoende middelen heeft is de verwachting dat deze voldoende zal presteren.

Componenten

Aangezien CORE onder andere een Django project is, zijn de componenten van de oplossing de apps die er in gemaakt worden. Deze zullen dan ook besproken worden.

• UI. De UI/frontend biedt een een interactieve gebruikersinterface die gebruikers in staat stelt om gegevens te raadplegen, processen aan te sturen en functionaliteit op een intuïtieve manier te benutten.
• API. Het API component biedt een gestandaardiseerde en beveiligde koppelvlakintegratie waarmee externe systemen geautomatiseerd gegevens kunnen uitwisselen en functionaliteit kunnen aanroepen. 
• Engine. Vormt de verwerkingslaag waarin businesslogica, orkestratie en gegevensverwerking worden uitgevoerd en waar processen centraal worden aangestuurd.

Architectuur

TBD

Infrastructuur

Voor de implementatie van CORE is bewust gekozen voor uitrol binnen een Kubernetes-cluster. Deze keuze sluit aan bij de bredere ICT-strategie waarin cloud-native principes centraal staan, met als doel schaalbare, beheersbare en veerkrachtige applicaties te realiseren.

CORE wordt als containerized applicatie aangeboden en draait op basis van één image, waarbinnen één of meerdere containers kunnen worden ingezet afhankelijk van de functionele inrichting.

Daarnaast is gekozen voor Kubernetes omdat binnen het SOC reeds een andere applicatie op dit platform wordt beheerd. Door aan te sluiten op deze bestaande omgeving wordt optimaal gebruikgemaakt van aanwezige kennis, ervaring en beheerprocessen, wat de implementatie en exploitatie efficiënt en beheersbaar maakt.

Betrouwbaarheid

Het voordeel van Kubernetes, en het draaien van onze applicatie daar, is dat door de mogelijkheid van self-healing, en rolling updates dat er een hoge beschikbaarheid en minimale downtime tijdens onderhoud of updates gegarandeerd wordt.

Toekomstvastheid en integratie

De keuze van het runnen van gecreëerde containers in Kubernetes ondersteund dat het makkelijk updaten van nieuwe images die we maken. Hiervoor kunnen we een integratie met GitLab maken waar deze container staat en gebruikt kan worden.

Architecturale afweging: waarom niet Docker Compose of Vms?

Hoewel CORE ook met Docker Compose of als losse containers op virtuele machines kan worden uitgerold, brengen deze opties beperkingen met zich mee op het gebied van schaalbaarheid, beheer en beschikbaarheid. Bij een Compose-setup ontbreekt centrale orkestratie: containers worden handmatig gestart, herstartmechanismen zijn beperkt en resourceschaling is niet geautomatiseerd. Bovendien is het lastiger om monitoring, logging en netwerkbeveiliging consistent toe te passen over meerdere nodes.

Een VM-gebaseerde implementatie biedt stabiliteit, maar resulteert in een statische, minder flexibele omgeving waarin uitbreidingen of updates meer handmatige stappen vereisen. Kubernetes combineert het beste van beide werelden door containerisatie te koppelen aan geautomatiseerd lifecycle-beheer, waardoor de CORE omgeving robuuster, efficiënter en onderhoudsarm wordt.

Gegevensstromen

In dit HLD zijn uitsluitend de logische verkeersstromen in kaart gebracht die de applicatie binnenkomen of verlaten (externe koppelingen).

Data classificatie & retentie

Het geheel aan data binnen CORE is als RWS Bedrijfsvertrouwelijk gerubriceerd. Binnen CORE wordt er verder geen data opgeslagen en zijn er ook geen bewaartermijnen vastgesteld. Voor data naar andere bronnen wordt de bewaartermijn van die applicatie gehanteerd.

Beveiligingsmaatregelen

De CORE-omgeving is ontworpen volgens het security-by-design-principe, waarbij op meerdere niveaus maatregelen zijn genomen om de vertrouwelijkheid, integriteit en beschikbaarheid van de oplossing te waarborgen. Zowel het Kubernetes-platform als de CORE-applicatie zelf zijn voorzien van specifieke beveiligingscontroles.

Netwerk- en compute-isolatie

CORE wordt uitgevoerd binnen de eigen SOC Kubernetes-namespace, waarmee logische en compute-isolatie wordt gerealiseerd met andere workloads binnen het cluster. Wel draaien dus meerde applicaties van het SOC binnen 1 cluster maar kunnen die ook niet met elkaar communiceren. Binnen deze namespace is netwerktoegang strikt beperkt. Toegang tot deze interne services vindt plaats via Kubernetes Services met interne DNS-resolutie, zonder directe externe blootstelling.

Toegangsbeheer en authenticatie

CORE maakt gebruik van Active Directory-integratie voor gecentraliseerd gebruikersbeheer en authenticatie. Dit zorgt ervoor dat de toegang tot CORE wordt beheerd via bestaande identiteits-en toegangsbeheerprocessen (IAM). Rollen en rechten binnen CORE worden via role-based access control (RBAC) geregeld. Als laatste is er ook nog een break-glass account beschikbaar voor noodgevallen. Denk, de Domain Controller is niet meer toegankelijk.

Inkomende toegang en TLS-beveiliging

Externe toegang tot CORE verloopt via een Kubernetes Ingress-controller die verantwoordelijk is voor HTTPS-verkeer en TLS-terminatie. Hierdoor wordt alle communicatie tussen gebruikers en de CORE-webinterface versleuteld en beschermd tegen afluisteren of manipulatie

Beheertoegang en logging

Beheertoegang tot de clusterinfrastructuur is uitsluitend toegestaan via geauthenticeerde kubectl-verbindingen en uitsluitend via een dedicated jumpbox. Alle beheeractiviteiten, inclusief configuratiewijzigingen, worden vastgelegd in centrale auditlogs. Applicatie- en infrastructuurlogs worden verzameld en gecorreleerd in het centrale monitoringplatform voor detectie en respons.

Configuratiebeheer en wijzigingscontrole

Het configuratiebeheer van CORE is ingericht volgens een Git-gebaseerde workflow, waarmee alle infrastructuur- en applicatieconfiguraties centraal en versieerbaar worden beheerd. Wijzigingen aan Kubernetes-manifests, Images en andere configuratiebestanden worden uitsluitend uitgevoerd via pull requests (merge requests) in de Git-repository. Hierbij is het de code van de applicatie onderhevig aan unit, en integration tests. Dit om de kwaliteit en integriteti van de code te waarborgen.

Elke wijziging doorloopt het vier-ogenprincipe, waarbij een tweede bevoegde collega de wijziging inhoudelijk beoordeelt voordat deze wordt goedgekeurd en samengevoegd. Dit borgt zowel de technische juistheid als de beveiligingsintegriteit van configuratiewijzigingen. Daarnaast worden alle commits automatisch gelogd, inclusief herkomst, tijdstip en inhoudelijke verschillen, wat volledige auditability en traceerbaarheid garandeert.

De Git-repository fungeert als single source of truth voor de actuele configuratiestatus van de CORE-stack. Deployments naar het Kubernetes-cluster vinden uitsluitend plaats via geautomatiseerde CI/CD-pijplijnen, die enkel wijzigingen uit de goedgekeurde hoofdtak (bijv. main of release) mogen uitrollen. Hiermee wordt voorkomen dat ongecontroleerde of ongeautoriseerde configuraties direct in productie worden gebracht, en wordt de consistentie tussen omgevingen (test, acceptatie, productie) gewaarborgd.

Low Level Design

Het Low Level Design (LLD) is vastgelegd binnen de Gitlab omgeving voor CORE van het SOC.

Roadmap

Dit hoofdstuk beschrijft enkele zaken die in de nabije toekomst ontwikkeld dienen te worden:

• Iris integratie