3.2.3.1 Threat Intelligence Platform

Dit document beschrijft het Solution Building Block (SBB) voor het Threat Intelligence Platform (TIP). 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 doorontwikkelen 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

Het TIP biedt een centrale voorziening voor het verzamelen, analyseren en distribueren van dreigingsinformatie binnen de organisatie. Dit platform ondersteunt de detectie, preventie en respons op cyberdreigingen door relevante dreigingsdata te correleren en te verrijken met interne en externe bronnen. Hiermee wordt de informatiepositie van de organisatie versterkt en kunnen beveiligingsmaatregelen proactief worden afgestemd op actuele risico’s.

Het platform vormt een essentieel onderdeel van de securityketen en draagt bij aan de verhoging van de weerbaarheid van IT-diensten en infrastructuren. In dit SBB-document worden de technische, organisatorische en operationele aspecten van het Threat Intelligence Platform vastgelegd, inclusief afspraken over prestaties, verantwoordelijkheden, beveiliging en lifecycle management.

Scope

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

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

Buiten de scope vallen:

• Gedetailleerde configuraties (LLD) en implementatiestappen.
• Operationele procedures en beheerinstructies.

Doelgroep

Dit document is bedoeld voor alle stakeholders die betrokken zijn bij de ontwikkeling, implementatie en het beheer van de oplossing. 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 verantwoordelijk zijn voor het beheer en de exploitatie van de oplossing
• Security- en compliancefunctionarissen die toezicht houden op naleving van beveiligings- en regelgevingskaders

Hoofdfuncties

Het Threat Intelligence-proces richt zich op het verzamelen, analyseren en vertalen van inlichtingen uit diverse bronnen naar bruikbare dreigingsproducten. Deze producten worden binnen de organisatie ingezet voor onder andere security monitoring en vulnerability management, en partners van Rijkswaterstaat tijdig te informeren over mogelijke dreigingen. Het Threat Intelligence Platform (TIP) ondersteunt de kernprocessen van het Threat Intelligence-proces door middel van de volgende hoofdfuncties:

• Verzamelen van inlichtingen Het platform integreert en centraliseert gegevens uit diverse interne en externe bronnen, waardoor een volledig en actueel beeld van dreigingen beschikbaar is.
• Analyse en creatie van dreigingsproducten TIP faciliteert de verwerking en analyse van verzamelde inlichtingen en ondersteunt de vertaling naar bruikbare dreigingsproducten, zoals rapportages, indicators of compromise (IOCs) en alerts.
• Distributie en toepassing van dreigingsinformatie Het platform maakt de dreigingsproducten beschikbaar voor relevante teams binnen de organisatie, en ondersteunt toepassingen zoals security monitoring, vulnerability management en rapportage aan stakeholders.
• Integratie met andere systemen Het platform biedt interfaces en koppelingen met andere systemen, zoals Threat Detection- en EDR-oplossingen, waardoor dreigingsinformatie effectief kan worden gedeeld en benut.

Dienstverlening

Het TIP faciliteert de SOC-analisten door middel van geautomatiseerde dreigingsverrijking, correlatie van interne en externe indicatoren, en het delen van relevante dreigingsinformatie binnen beveiligingsdomeinen. 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 het TIP 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): Threat Intelligence v1.0
• Architecture Building Block (ABB): 
  • 3.2.1 Monitoringvoorziening
  • 3.2.2 Security incident en response
  • 3.2.4 Threat Hunting

• 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 gedurende meerdere jaren gebruikgemaakt van het Threat Intelligence Platform (TIP) van EclecticIQ (EIQ), waarmee aansluiting werd gehouden op de lijn van het NCSC en het JSOC. Inmiddels is het NCSC gemigreerd naar een nieuw platform op basis van OpenCTI Enterprise. Binnen Rijkswaterstaat heeft de implementatie van EIQ echter niet het gewenste volwassenheidsniveau bereikt. De oplossing bleek complex in beheer, kampte met frequente operationele verstoringen en bood onvoldoende flexibiliteit voor verdere integratie en doorontwikkeling.

Naar aanleiding hiervan heeft het SOC een functionele marktuitvraag voorbereid voor de selectie van een nieuw platform. In een vroeg stadium is echter besloten deze uitvraag in te trekken. Belangrijke factoren hierbij waren kostenbeheersing, personele capaciteit binnen het CTI-team en een herijking van de prioriteiten op basis van een haalbaar implementatiepad.

Op basis van deze heroverweging is gekozen voor de open-source editie van OpenCTI. OpenCTI biedt een modulair en uitbreidbaar platform dat aansluit bij de behoeften van het SOC en de bredere security-architectuur van Rijkswaterstaat. De keuze voor open-source software stelt Rijkswaterstaat in staat om onafhankelijk van leveranciers te opereren en voorkomt herhaalde marktuitvragen bij toekomstige uitbreidingen. Hierdoor behoudt de organisatie zelf de regie over de functionele en technische roadmap, wat de wendbaarheid en toekomstvastheid van het Threat Intelligence Platform aanzienlijk vergroot. Zie ook de memo omtrent het gebruik van open-source software.

Daarnaast sluit OpenCTI technisch goed aan op de enterprise-architectuur en securitykaders van Rijkswaterstaat:

• Het platform ondersteunt open standaarden zoals STIX 2.1 en TAXII 2.1, waardoor interoperabiliteit met andere beveiligingsoplossingen (zoals SIEM, SOAR en Vulnerability Management) wordt gewaarborgd.
• De API-first architectuur maakt integratie met bestaande tools en maatwerkconnectors eenvoudig en beheersbaar.
• Door de modulaire opzet met connectors kan informatie uit uiteenlopende interne en externe bronnen efficiënt worden verzameld, verrijkt en gedeeld.
• Het onderliggende datamodel is transparant en uitbreidbaar, wat bijdraagt aan een toekomstvaste en controleerbare inrichting van het dreigingsbeeld.

Gezamenlijk zorgt dit ervoor dat OpenCTI niet alleen voorziet in de huidige behoeften van het SOC, maar ook een solide basis vormt voor verdere professionalisering van de threat intelligence-capaciteit binnen Rijkswaterstaat.

Applicatiecomponenten & architectuur

Deze paragraaf beschrijft de opbouw en samenhang van de belangrijkste applicatiecomponenten waaruit de oplossing bestaat. OpenCTI is ontworpen volgens een microservices-architectuur, waarbij de verschillende onderdelen onafhankelijk van elkaar functioneren en samenwerken via gestandaardiseerde interfaces. De componenten worden als containerized workloads uitgerold binnen de Kubernetes-omgeving van Rijkswaterstaat, wat zorgt voor schaalbaarheid, flexibiliteit en vereenvoudigd beheer. In de subparagraaf Componenten worden de afzonderlijke bouwstenen van de oplossing toegelicht, terwijl in de subparagraaf Architectuur een overzichtsdiagram de onderlinge relaties en gegevensstromen tussen deze componenten visualiseert.

Componenten

De architectuur van de OpenCTI-toepassing bestaat uit de volgende componenten:

• OpenCTI Server. Het kernplatform dat de webinterface en API aanbiedt en verantwoordelijk is voor het beheer en de orkestratie van dreigingsinformatie.
• OpenCTI Worker. Verwerkt achtergrondtaken zoals data-imports, verrijking en het opbouwen van de grafendatabase voor efficiënte backend-verwerking.
• OpenCTI Connectors. Modulaire integraties die gegevens uit externe bronnen ophalen of daarheen verzenden (bijv. MISP, MITRE ATT&CK, VirusTotal).
• OpenSearch. Slaat gestructureerde dreigingsinformatie op en indexeert deze voor snelle zoekopdrachten en analyses.
• MinIO. Een S3-compatibele objectopslagdienst voor bestanden, zoals import/export data en bijlagen (bijv. rapporten).
• RabbitMQ. Een message broker die betrouwbare, asynchrone communicatie en taakqueues mogelijk maakt tussen OpenCTI-componenten (server, workers, connectors).
• Dragonfly. Een in-memory datastore gebruikt voor caching en het beheren van taakwachtrijen ter verbetering van prestaties en coördinatie (Redis-compatibel).

Architectuur

Infrastructuur

Voor de implementatie van de OpenCTI-omgeving is bewust gekozen om de oplossing te draaien binnen een Kubernetes-cluster. Deze keuze sluit aan bij de bredere strategie om cloud-native principes te hanteren voor schaalbare, beheersbare en veerkrachtige applicaties. OpenCTI bestaat uit meerdere onderling afhankelijke componenten (zoals de server, worker, connectoren en ondersteunende services zoals RabbitMQ, OpenSearch, Dragonfly en MinIO). Kubernetes biedt een gestandaardiseerde manier om dergelijke gedistribueerde workloads te orkestreren en te beheren, inclusief automatische herstart, schaling en netwerkisolatie.

Schaalbaarheid en betrouwbaarheid

Een belangrijke motivatie voor Kubernetes is de dynamische schaalbaarheid van de OpenCTI-onderdelen. De worker- en connectorcomponenten kunnen horizontaal opgeschaald worden afhankelijk van de hoeveelheid te verwerken dreigingsinformatie of integraties met externe bronnen. Kubernetes maakt dit mogelijk via native scaling-mechanismen (zoals HorizontalPodAutoscaler), wat bijdraagt aan een stabiele verwerking van data zonder handmatige tussenkomst. Daarnaast zorgen self-healing en rolling updates voor een hoge beschikbaarheid en minimale downtime tijdens onderhoud of updates.

Beheer, uniformiteit en automatisering

Het gebruik van Kubernetes maakt beheer en uitrol eenduidig en reproduceerbaar. Door de inzet van Helm charts wordt de complete OpenCTI-stack — inclusief afhankelijkheden zoals RabbitMQ, OpenSearch en MinIO — als één geheel gedefinieerd en beheerd. Dit vergemakkelijkt versiebeheer, omgevingsconsistentie (bijvoorbeeld tussen test en productie) en geautomatiseerde CI/CD-integratie. Bovendien sluit deze aanpak aan bij bestaande beheer- en monitoringtools binnen het Kubernetes-ecosysteem, zoals Prometheus, Grafana en OpenTelemetry.

Toekomstvastheid en integratie

Tot slot biedt Kubernetes een toekomstvaste basis voor verdere groei en integratie. Nieuwe OpenCTI-connectoren of aanvullende ondersteunende services kunnen eenvoudig als nieuwe pods of deployments worden toegevoegd. Dit maakt de omgeving flexibel en uitbreidbaar, zonder dat de onderliggende infrastructuur hoeft te worden aangepast. Tevens ondersteunt Kubernetes zowel on-premises als cloudomgevingen, waardoor de gekozen architectuur vendor-neutraal blijft en geschikt is voor hybride of multi-cloud scenario’s.

Architecturale afweging: waarom niet Docker Compose of VM’s?

Hoewel OpenCTI 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 OpenCTI-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 het TIP is als RWS Bedrijfsvertrouwelijk gerubriceerd.

Door middel van een DPIA traject zijn de volgende bewaartermijnen vastgesteld:

• 6 maanden voor reguliere indicatoren/rapporten.
• 18 maanden voor sightings/incident gerealteerde informatie.

Beveiligingsmaatregelen

De OpenCTI-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 OpenCTI-applicatie zelf zijn voorzien van specifieke beveiligingscontroles.

Netwerk- en compute-isolatie

De OpenCTI-componenten worden uitgevoerd binnen een eigen Kubernetes-namespace, waarmee logische en compute-isolatie wordt gerealiseerd ten opzichte van andere workloads binnen het cluster. Binnen deze namespace is netwerktoegang strikt beperkt: enkel noodzakelijke communicatie tussen componenten (zoals tussen de server, worker, connectors, RabbitMQ, OpenSearch, Dragonfly en MinIO) is toegestaan. Toegang tot deze interne services vindt plaats via Kubernetes Services met interne DNS-resolutie, zonder directe externe blootstelling.

Toegangsbeheer en authenticatie

De OpenCTI-server maakt gebruik van Active Directory-integratie voor gecentraliseerd gebruikersbeheer en authenticatie. Dit zorgt ervoor dat toegang tot de OpenCTI-omgeving consistent wordt beheerd via bestaande identiteits- en toegangsbeheerprocessen (IAM). Rollen en rechten binnen OpenCTI worden via role-based access control (RBAC) toegepast, waarmee gebruikers enkel toegang krijgen tot informatie en functionaliteiten die relevant zijn voor hun functie. Daarnaast is een break-glass account beschikbaar voor noodgevallen, bijvoorbeeld bij een storing in de identiteitsprovider.

Inkomende toegang en TLS-beveiliging

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

Beheertoegang en logging

Beheertoegang tot de clusterinfrastructuur is uitsluitend toegestaan via geauthenticeerde kubectl- of helm-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 de OpenCTI-omgeving is ingericht volgens een Git-gebaseerde workflow, waarmee alle infrastructuur- en applicatieconfiguraties centraal en versieerbaar worden beheerd. Wijzigingen aan Kubernetes-manifests, Helm-waarden en andere configuratiebestanden worden uitsluitend uitgevoerd via pull requests (merge requests) in de Git-repository.

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 OpenCTI-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 van het SOC: https://gitlab.at.rws.nl/soc/soc-analisten/engineering/platform-engineering/opencti

Roadmap

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

• Service monitoring met behulp van Prometheus
• Active Directory (LDAP) authenticatie vervangen door Keycloak
• Externe secrets store (bijv. Vault,
• Backup/restore (niet perse noodzakelijk, maar nice-to-have), bijv. Velero
• MinIO wordt niet langer als OSS oplossing ondersteund, onderzoek alternatieven: CEPH+S3, Rook