Van CTI-JSON naar formele cyber-terrain kennisgrafen

Abstract, Deze paper analyseert hoe een stack van cyber-ontologieën en tooling kan worden ingezet als semantische control plane voor cyber threat intelligence (CTI), vulnerability management, control assurance, AI-ondersteunde security-analyse en risicogestuurde besluitvorming. De onderzochte artefacten vervullen complementaire rollen: STONES formaliseert STIX 2.1 in OWL 2, STONEWORK breidt dit uit richting dreigingen, technieken, kwetsbaarheden, producten, risico's en controls, D3FEND levert een verdedigingsgerichte kennisgrafiek van cybersecurity countermeasures, Amethyst biedt een collaboratieve OWL 2 editor en governance-workbench, en NCOR positioneert dit geheel binnen een bredere ontologische methodologie voor interoperabiliteit en robuuste AI.

Kernconclusie, Deze stack moet niet primair als "nog een taxonomy" worden gezien, maar als een formeel kennisinfrastructuurpatroon: een manier om assets, CVE's, CWE's, ATT&CK-technieken, D3FEND-countermeasures, NIST/CIS-controls, detectieregels, procedures, risico's en bewijsobjecten consistent met elkaar te verbinden. De strategische waarde zit in traceerbaarheid: van kwetsbaarheid naar weakness, van weakness naar aanvalstechniek, van techniek naar verdedigingsmaatregel, van maatregel naar control, en van control naar operationeel bewijs.

Keywords: OWL 2, RDF, SPARQL, STIX 2.1, CTI, knowledge graph, D3FEND, ATT&CK, CWE, NIST SP 800-53, Zero Trust, ontology governance, secure AI, semantic interoperability

1. Inleiding en probleemstelling

Enterprise security kampt met een structureel integratieprobleem. CTI-platformen spreken STIX/TAXII, vulnerability management gebruikt CVE, CPE, CVSS en EPSS, secure SDLC gebruikt CWE, SAST en SBOM, SOC-teams gebruiken SIEM/EDR-detecties, GRC-teams werken met ISO 27001, NIST CSF, NIST SP 800-53, CIS Controls en interne policies. Elk domein bevat relevante kennis, maar de relaties tussen die kennisobjecten zijn vaak impliciet, documentgebaseerd of vendor-specifiek.

De onderzochte stack adresseert dit probleem via formele semantiek. STIX 2.1 definieert een consistente CTI-taal voor dreigingsinformatie en beschrijft CTI als een graph-based model met objecten en relaties, maar gebruikt JSON als verplichte implementatieserialisatie. Dat is uitstekend voor uitwisseling, maar minder geschikt voor formeel redeneren, inferentie, constraint checking, semantische integratie en herbruikbare competency questions.

OWL 2 en RDF bieden een ander paradigma: ontologieën modelleren gedeelde vocabulaires, conceptdefinities en relaties op een formele manier, terwijl SPARQL query's mogelijk maakt over RDF-grafen en verschillende gegevensbronnen. De hypothese van deze paper is dat cyber defense een formele kennislaag nodig heeft bovenop bestaande standaarden, omdat operationele cyberbesluitvorming steeds vaker vraagt om explainability, auditeerbaarheid, risk-based prioritization en AI-agenten die niet alleen tekst samenvatten, maar gecontroleerd redeneren over expliciete relaties.

Dit is een bron- en architectuuranalyse, geen runtime benchmark.

2. Onderzochte artefacten en functionele decompositie

De vijf artefacten in deze stack vervullen complementaire rollen:

Artefact	Primaire rol	Technische functie	Productiewaarde
STONES	STIX-formalisatie	OWL 2 representatie van STIX 2.1 objecten, relaties, observables en properties	Maakt CTI graph-querying, reasoning en KG-integratie mogelijk
STONEWORK	Semantische cyber-terrain laag	Uitbreiding op STONES met dreiging, risico, techniek, weakness, product, control en scenario-concepten	Verbindt CVE, CWE, ATT&CK, CAPEC, D3FEND, NIST/CIS en enterprise context
D3FEND	Defensieve kennisgrafiek	Ontologie van cybersecurity countermeasures, defensive techniques en relaties naar offensieve TTP's	Onderbouwt control coverage, defense engineering en detectie/mitigatie-redenering
Amethyst	Collaboratieve ontology workbench	OWL 2 authoring, SPARQL, graph view, GitHub-integratie, branching, audit, RBAC	Maakt governance, curation en review door security architects en domeinexperts mogelijk
NCOR	Methodologische en community-laag	Ontology engineering, semantic interoperability, BFO/CCO-context, research community	Verhoogt kwaliteit, interoperabiliteit en wetenschappelijke verankering

STONES positioneert zichzelf als "STIX ONtology Expression System" en geeft STIX 2.1 formele OWL-semantiek, waarbij STIX domain objects, cyber observable objects en relationship types als OWL-klassen en properties worden gerepresenteerd. De bronontologie bevestigt dit met een OWL 2 ontology description en imports voor datatype properties, object properties en vocabularies.

STONEWORK is de "Semantic Threat Ontology and Research Framework" en bouwt expliciet voort op STONES. Het doel is modellering "beyond the scope of STIX 2.1", waaronder adversary techniques, software weaknesses, defensive controls en vulnerability linkage. In de bron importeert STONEWORK STONES en definieert een extensielaag met properties zoals affected, exploitsWeakness, hasWeakness, relatedAttackPattern, mitigatesAttackPattern en concepten zoals Threat, ThreatScenario, Risk, Likelihood, Impact, Weakness, Product, Control, Procedure en Technique.

D3FEND is de verdedigingsgerichte tegenhanger van MITRE. De knowledge graph modelleert hoe defensieve maatregelen werken en onder welke omstandigheden. Release 1.4.0 is de actuele versie, beschikbaar in OWL, TTL en JSON-LD. De GitHub-repository bevat de workflow voor het bouwen van distributiebestanden, inclusief een inference-enhanced d3fend-full.owl voor SPARQL endpoints.

Amethyst is de operationele curation-laag, een lichtgewicht collaboratieve webgebaseerde OWL 2 ontology editor voor niet-experts, met authoring, multi-project workspaces, branching en merge, SPARQL 1.1 via Oxigraph, import/export, GitHub-integratie, RBAC, comments, audit trail en een AI assistant. Architectonisch bestaat Amethyst uit een single Node container met React, Express, Oxigraph in-process, SQLite of PostgreSQL, met per ontology een named graph voor isolatie.

NCOR (National/Network Center for Ontological Research) levert de methodologische context: een internationaal non-profit netwerk dat ontology engineering best practices bevordert voor interoperabiliteit en robuuste AI-systemen. Het netwerk focust op foundational ontology (BFO/ISO 21838-2), semantic interoperability, ontology methodology en toepassingen in defense, intelligence, healthcare, manufacturing en AI.

3. Technische analyse per component

3.1 STONES: STIX als formeel OWL-model

STONES vervangt STIX 2.1 niet, maar projecteert het semantisch. STIX blijft het uitwisselingsformaat; STONES levert de formele representatie voor query's en reasoning. In de Turtle-bron zijn STIX-objecttypes via OWL-klassen en owl:equivalentClass-constructies verbonden aan stixType-waarden. Een AttackPattern wordt zo niet alleen een JSON-object met typewaarde attack-pattern, maar een formeel klasseconcept.

De belangrijkste architectuurwaarde is semantische normalisatie. CTI uit verschillende STIX-bundles kan in een RDF-graf worden geladen, waarna analisten vragen kunnen stellen zoals:

PREFIX stones: ＜https://cyberterrain.org/ns/stones#＞

SELECT ?actor ?technique ?malware WHERE {
  ?actor a stones:IntrusionSet .
  ?actor stones:uses ?technique .
  OPTIONAL { ?actor stones:uses ?malware . ?malware a stones:Malware . }
}

In een klassieke STIX-pipeline vraagt dit om JSON-parsing, object-id lookups en applicatielogica. In een semantische pipeline wordt dit een graph query. Het verschil is fundamenteel: relaties worden eerste-klas objecten in een kennisruimte.

Het risico is dat STIX-semantiek en OWL-semantiek niet één-op-één samenvallen. STIX kent open vocabularies, confidence, markings, created/modified timestamps, revocation en granular markings. OWL redeneert monotonic: nieuwe feiten verwijderen oude conclusies niet vanzelf. Een volwassen implementatie moet temporele context, confidence, provenance en markings expliciet modelleren, bij voorkeur met named graphs en policy-aware query rewriting.

3.2 STONEWORK: cyber-terrain als semantisch fusielaag

STONEWORK is de meest ambitieuze component, omdat het het cyberdomein probeert te modelleren als samenhangend terrein: actoren, technieken, procedures, weaknesses, producten, kwetsbaarheden, controls, risico's en scenario's. Vier kerngebieden: adversary TTP's, software weaknesses, defensive controls en vulnerability linkage van CVE naar CWE naar ATT&CK-techniek naar control.

De bronontologie formaliseert STIX shortcut relationships (mitigates, detects, targets, exploits, indicates, uses) en voegt eigen semantische relaties toe. Cruciale brugrelaties zijn:

• Vulnerability -> affected -> Product
• Vulnerability -> hasWeakness / exploitsWeakness -> Weakness
• Weakness -> relatedAttackPattern -> AttackPattern
• Control -> mitigatesAttackPattern -> AttackPattern
• ThreatScenario -> relates to Threat, Impact, Likelihood, Risk

Deze modellering maakt een cyber risk graph mogelijk waarin technische kwetsbaarheden niet losstaan van controls en business risk. De klassen Risk, Impact en Likelihood modelleren risico als exposure aan schade. De klasse Procedure onderscheidt concrete observeerbare acties (commando's, API-calls) van abstractere technieken, een cruciaal onderscheid voor SOC-operationalisering: een ATT&CK-techniek is geen detectie, een procedure kan dat wel worden.

Een conceptuele query voor vulnerability-to-control reasoning:

PREFIX stones: ＜https://cyberterrain.org/ns/stones#＞
PREFIX stonework: ＜https://cyberterrain.org/ns/stonework#＞

SELECT ?vuln ?product ?weakness ?attackPattern ?control WHERE {
  ?vuln a stones:Vulnerability ;
        stonework:affected ?product ;
        (stonework:hasWeakness|stonework:exploitsWeakness) ?weakness .
  ?weakness stonework:relatedAttackPattern+ ?attackPattern .
  ?control a stonework:Control ;
           stonework:mitigatesAttackPattern ?attackPattern .
}

Deze query traceert van vulnerability naar product, weakness, attack pattern en control. De academische uitdaging zit in semantische precisie: mitigatesAttackPattern betekent niet automatisch "control elimineert risico", het betekent dat er een gemodelleerde mitigatierelatie bestaat. Voor besluitvorming zijn additionele dimensies nodig: context, maturity, implementation status, assurance level, evidence, compensating controls, adversary capability en environmental preconditions.

3.3 D3FEND: verdedigingssemantiek en countermeasure reasoning

D3FEND biedt een verdedigingsgerichte kennisgrafiek die expliciet modelleert hoe cyber countermeasures werken. Het semantisch rigoureuze model koppelt countermeasure components en capabilities inferentieel aan offensieve tactics, techniques en procedures.

Technisch relevant is dat D3FEND niet alleen statische tabellen levert. De distributie omvat TTL, OWL en JSON, query's en reports, en een d3fend-full.owl die inference-enhanced is voor SPARQL endpoints in productiecontext. De conventies tonen bewust OWL-patterns: punning van defensive techniques als instanties van parent classes, consistente CamelCase IRIs en labelconventies.

Binnen een enterprise-architectuur wordt D3FEND waardevol als vertaalbrug tussen engineering en governance:

• ATT&CK techniek: Credential Dumping
• D3FEND defensive technique: Credential Hardening, Process Analysis, Memory Boundary Tracking
• Control family: Identity and Access Management, Endpoint Protection, Logging and Monitoring
• Operational evidence: EDR policy, LSASS protection setting, SIEM detection rule, incident response playbook

D3FEND moet niet behandeld worden als control catalogus die automatisch voorschrijft wat geïmplementeerd moet worden. D3FEND modelleert verdedigingskennis. Besluitvorming vereist contextuele risk assessment, architectuurkeuzes, kosten, false positives, coverage gaps en effectiviteitsdata.

3.4 Amethyst: governance-workbench voor ontologiecuratie

Amethyst is belangrijk omdat ontologieën anders snel academische artefacten blijven. De tool biedt functies die direct relevant zijn voor enterprise governance: multi-project workspaces, branching, merge en conflict resolution, GitHub pull requests, comments, audit trail, rollen, import/export en SPARQL.

De implementatie bevat meerdere security-relevante ontwerpkeuzes:

• Session hardening: SESSION_SECRET vereist in productie; cookies zijn httpOnly, sameSite=lax, secure afhankelijk van omgeving
• CORS: allowlist-gebaseerd
• Rate limiting: globaal en per auth-endpoint
• CSRF-bescherming: X-Requested-With header verplicht voor state-changing API-aanvragen
• RBAC: globale rollen (admin/user) plus projectrollen (manager, editor, viewer)
• SPARQL scoping: per graph scope, cross-graph references geweigerd voor niet-admins, gevaarlijke UPDATE-operaties (DROP, CLEAR, LOAD, CREATE, ADD, MOVE, COPY) geblokkeerd
• Input validatie: path traversal guard, UUID-allowlisting voor ontology identifiers, safe IRI-validatie
• RDF verwerking: Oxigraph in-process via WASM, per ontology een named graph (urn:ontology-editor:onto:＜id＞), worker threads voor parsing/serialisatie

Voor productie is Amethyst beter te positioneren als ontology governance workbench dan als high-throughput analytical triplestore. De in-process Oxigraph-architectuur is geschikt voor collaboratieve authoring en middelgrote grafen, maar grootschalige SOC-analyses, streaming CTI, multi-tenant query workloads en materialized inference pipelines vragen om een dedicated graph backend.

4. Referentiearchitectuur voor enterprise inzet

Een robuuste implementatie bestaat uit vijf lagen:

Laag 1: Brondata en ingest. STIX/TAXII feeds, MITRE ATT&CK, D3FEND, CVE/NVD, CWE, CAPEC, CPE, SBOM's, CMDB, cloud asset inventory, EDR/SIEM events, IaC-scans, SAST/DAST/SCA, NIST/CIS/ISO-control mappings en interne risk registers.

Laag 2: Semantische normalisatie. STONES normaliseert STIX-objecten naar RDF/OWL. STONEWORK voegt domeinconcepten toe voor threat, weakness, product, risk, technique, procedure en control. D3FEND wordt geladen als verdedigingsontologie. Identifiers moeten strikt worden beheerd: STIX IDs, CVE IDs, CWE IDs, CPE URIs, ATT&CK IDs, D3FEND IRIs, control IDs en interne asset IDs mogen niet willekeurig worden gemengd.

Laag 3: Reasoning, validatie en materialisatie. OWL-reasoning benut hiërarchieën en property-relaties. SHACL valideert data tegen het verwachte profiel. SPARQL materialiseert afgeleide views, bijvoorbeeld "high-risk products with known exploited vulnerabilities and missing mitigating controls". Semantische relaties moeten getyped en geannoteerd worden met confidence, provenance en mapping rationale, mappings zijn niet automatisch equivalent.

Laag 4: Governance en collaboration. Amethyst wordt gebruikt voor ontology curation, review, branching, pull requests, audit, controlled imports en discussie. De GitHub-integratie en branching/merge-functies maken GitOps voor ontologieën mogelijk. Productie vereist aanvullende controls: OIDC SSO, MFA, short-lived tokens, vault-backed secret management, signed commits, SBOM, dependency scanning, SLSA-achtige build provenance en change advisory policies.

Laag 5: Consumptie door SOC, GRC, DevSecOps en AI. Consumers krijgen gecontroleerde query views, API's, dashboards en agent tools. AI-agents krijgen uitsluitend allowlisted SPARQL-tools met read-only scopes, output citation requirements en policy checks.

5. Toepassingen binnen enterprise security

5.1 Risk-based vulnerability management

Klassieke kwetsbaarheidsprioritering op CVSS is te grof. Een semantische cyber-terrain graph kan prioriteren op basis van:

• CVE -> affected product -> asset criticality
• CVE -> CWE -> attack pattern -> ATT&CK technique
• ATT&CK technique -> known actor usage -> sector targeting
• ATT&CK technique -> D3FEND technique -> implemented control evidence
• Threat scenario -> likelihood x impact -> business risk

Dit maakt vragen mogelijk zoals: "Welke internet-facing producten in kritieke business services hebben kwetsbaarheden die te herleiden zijn naar weaknesses die door bekende technieken worden misbruikt, terwijl de corresponderende D3FEND-countermeasures of NIST-controls niet aantoonbaar effectief zijn geïmplementeerd?"

De waarde is niet alleen prioritering, maar explainability. Een CISO kan zien waarom een kwetsbaarheid prioriteit krijgt: niet omdat een score hoog is, maar omdat de chain van product, exploitability, adversary behavior, control gap en business impact expliciet is.

5.2 CTI fusion en threat hunting

SOC-teams ontvangen CTI vaak als losse indicatoren, rapporten of STIX-bundles. STONES maakt STIX-objecten formeel querybaar. STONEWORK voegt techniek-, procedure- en risk-semantics toe. D3FEND koppelt offensieve TTP's aan defensieve mogelijkheden. Daardoor ontstaat een workflow:

1. Ingest STIX-bundle met intrusion sets, malware, indicators en relationships
2. Projecteer STIX naar STONES
3. Verrijk technieken via STONEWORK en ATT&CK/D3FEND mappings
4. Genereer hunt hypotheses op procedure-niveau
5. Koppel hypotheses aan telemetry sources, SIEM-regels en EDR-controls
6. Sla bewijs en coverage terug op als graph annotations

Het cruciale onderscheid is tussen technique en procedure. Een techniek zoals credential access is te abstract voor directe detectie. Een procedure zoals een specifieke command line, API-call, registry key of process pattern is operationeel detecteerbaar. STONEWORK maakt dit onderscheid expliciet.

5.3 Control coverage en assurance

D3FEND en STONEWORK maken control coverage analyse preciezer. In plaats van "control X bestaat" kan de organisatie vragen:

• Welke D3FEND defensive techniques dekken deze ATT&CK techniques?
• Welke NIST SP 800-53 of CIS-controls claimen deze capability?
• Welke assets vallen onder de implementatiescope?
• Welk bewijs toont werkende implementatie?
• Welke dreigingsscenario's blijven uncovered?

Een volwassen graph moet onderscheid maken tussen mapsTo, partiallySupports, implements, evidencedBy, testedBy, mitigatesUnderCondition en notApplicableBecause.

5.4 DevSecOps en secure SDLC

In secure SDLC kan de stack de brug slaan tussen code-level weaknesses en enterprise risk:

• SAST finding -> CWE
• CWE -> CAPEC / ATT&CK attack pattern
• Affected component -> SBOM / CPE / package URL
• Weakness -> D3FEND defensive technique / secure coding control
• Pipeline evidence -> policy decision

Een SAST-finding voor injection wordt niet alleen als code issue behandeld, maar verbonden aan CWE, exploit patterns, affected services, runtime compensating controls, WAF-signatures, API gateway policies, secrets exposure en business criticality. De pipeline gate wordt risk-based: niet elke finding blokkeert release, maar findings zonder compenserende controls of met hoge exploit path plausibility wel.

5.5 AI-governance en ontology-constrained agents

Deze stack is bijzonder relevant voor AI-agents in security. Zonder formele kennislaag hallucineert een agent makkelijk control-relaties, verzint mitigaties of overschat mappings. Met een ontologiegestuurde architectuur krijgt de agent beperkte, controleerbare tools:

1. Agent intent -> policy check -> approved SPARQL template
2. SPARQL result -> cited evidence graph
3. LLM summary -> provenance-preserving explanation
4. Human approval -> action or ticket

De governance-eis is scherp: de LLM mag niet de bron van waarheid worden. De knowledge graph is de bron van waarheid; de LLM is een taalinterface, planner of summarizer. Beslissingen met impact op security posture vereisen expliciete evidence, confidence en menselijke of policy-based goedkeuring.

6. Security en compliance threat model

Risico	Oorzaak	Impact	Mitigatie
Ontology supply chain poisoning	Malafide TTL/OWL-imports, externe owl:imports	Foute inferenties, misleidende risk scores	Signed releases, allowlisted imports, PR-review, SHACL/ROBOT-tests, SBOM
Cross-tenant graph leakage	Onvoldoende SPARQL-scoping of named graph ACL's	CTI- of assetdata lekt tussen projecten	AST-gebaseerde SPARQL policy enforcement, named graph ACL's, read-only query templates
OAuth/PAT compromise	GitHub-integratie en AI assistant gebruiken tokens	Repo takeover, data-exfiltratie	OIDC met PKCE, fine-grained tokens, short TTL, vault, secret scanning
Prompt injection in AI assistant	Ontologiecontent of comments sturen modelgedrag	Onjuiste aanbevelingen, unsafe tool calls	Tool allowlisting, retrieval sandboxing, system prompt isolation, output validation
Mapping false equivalence	Controls, techniques en weaknesses worden semantisch te hard gekoppeld	Overschatte control coverage, audit misleiding	Geen owl:sameAs tenzij strikt bewezen; typed mappings met confidence en rationale
Availability degradation	Grote imports, zware SPARQL-query's, reasoning blow-up	Tragere editor, timeouts	Async ingest, job queues, query limits, graph partitionering
Privacy en markings	STIX markings, enterprise data met PII	AVG-risico, overexposure	Data minimization, ABAC, graph-level policy, no-PII-by-default

Amethyst heeft al meerdere defensieve keuzes in de codebase. Voor gereguleerde enterprise-omgevingen is dit een goede basis, geen eindstaat. Met name import-by-URL, AI-assistentie, OAuth/PAT-integratie, raw SPARQL en externe ontology imports moeten onder Zero Trust-principes worden geplaatst.

7. Implementatieroadmap

Fase 0: Ontology governance baseline. Definieer naming conventions, IRI-strategie, mapping policy, provenance model, confidence model, reviewproces, releaseproces en threat model. Gebruik NCOR/BFO/CCO-principes waar semantische interoperabiliteit over domeinen heen nodig is.

Fase 1: Labomgeving. Draai Amethyst als curation tool, laad STONES, STONEWORK en D3FEND, importeer een beperkte dataset (bijvoorbeeld Log4Shell of een interne kwetsbaarheidsketen).

Fase 2: Één narrow use case naar productie. Kies één waardevolle competency question, bijvoorbeeld: "Welke kritieke assets hebben kwetsbaarheden waarvan de weakness is gekoppeld aan technieken waarvoor wij geen bewezen detectie of mitigatie hebben?" Maak een end-to-end pipeline met ingest, RDF-transformatie, SHACL-validatie, SPARQL-view, dashboard en ticketing.

Fase 3: Production-grade knowledge graph. Gebruik Amethyst voor curatie en governance, maar plaats zware workloads in een dedicated triplestore. Voeg CI/CD toe voor ontology releases: syntax checks, OWL consistency checks, SHACL validation, competency question tests, dependency scanning, signed artifacts en audit export naar SIEM.

Fase 4: AI-augmented workflows. Introduceer ontology-constrained agents voor query generatie, triage summaries en control gap explanations. Alleen read-only, template-based SPARQL. Alle AI-antwoorden verwijzen naar graph evidence, niet naar vrije modelkennis. High-impact acties blijven onder human approval of policy-as-code.

8. PhD-niveau onderzoeksagenda

• Semantische equivalentie tussen STIX en OWL. Hoe behoud je STIX-objectidentiteit, markings, confidence, revoked states en temporal validity in OWL/RDF zonder foutieve monotone inferenties?
• Control-effectiviteit als empirische laag boven ontologie. Hoe modelleer je het verschil tussen "control maps to technique", "control is implemented", "control is operating effectively" en "control reduces likelihood under these preconditions"?
• Uncertainty-aware cyber reasoning. Cyberkennis is onzeker, incompleet en adversarieel. OWL is logisch sterk maar beperkt in probabilistische redenering. Een hybride model met RDF/OWL, probabilistic graphical models en causal inference is een relevant onderzoeksgebied.
• Ontology alignment en mapping governance. ATT&CK, D3FEND, CWE, CAPEC, STIX, NIST en CIS hebben verschillende granulariteit en intentie. Onderzoek naar formele mapping types, confidence, version drift en semantische regressietesten.
• Non-monotonic CTI en temporal knowledge graphs. Threat intelligence verandert. Actor-attributie, exploitstatus, campaign activity en mitigatieadvies kunnen vervallen. Dit vraagt temporal named graphs, validity intervals, revocation semantics en query's met tijdscontext.
• Secure ontology engineering for AI agents. Hoe voorkom je dat AI-agents ontologieën vervuilen, mappings overschrijven, SPARQL misbruiken of confidence verkeerd interpreteren?
• Federatieve en privacy-preserving cyber graphs. Voor sectorale CTI-sharing zonder ruwe assetdata te delen: named graphs, differential privacy, secure multiparty computation en policy-aware federation.

9. Strategische beoordeling

De stack is sterk omdat hij vijf volwassen ideeën combineert: STIX (uitwisseling van dreigingsinformatie), OWL/RDF/SPARQL (formele semantiek en graph reasoning), D3FEND (verdedigingskennis), STONEWORK (cyber-terrain integratie), Amethyst (governance en collaboration) en NCOR (methodologische discipline).

Voor een CISO of enterprise architect is de praktische waarde groot in drie domeinen:

1. Van compliance naar assurance, Controls worden niet alleen afgevinkt, maar gekoppeld aan dreigingen, technieken, assets en bewijs.
2. Van vulnerability lists naar attack-informed risk, Kwetsbaarheden worden geprioriteerd op exploit paths, adversary behavior, asset criticality en control gaps.
3. Van AI-chat naar controlled reasoning, LLM's krijgen een formele, auditeerbare kennisbasis in plaats van vrije tekst als bron van waarheid.

De beperkingen zijn even belangrijk. STONES en STONEWORK zijn actieve, relatief jonge ontologieën en moeten niet zonder validatie als normatief enterprise datamodel worden opgelegd. D3FEND is krachtig voor verdedigingssemantiek, maar de keuze en effectiviteit van controls blijven afhankelijk van context, implementatiekwaliteit en empirisch bewijs.

10. Conclusie

Amethyst, STONES, STONEWORK, D3FEND en NCOR vormen samen een overtuigend patroon voor een semantische cyber risk en defense knowledge graph. STONES geeft STIX 2.1 formele OWL-semantiek. STONEWORK verbindt CTI met weaknesses, producten, controls, risico's en scenario's. D3FEND levert de verdedigingsgerichte kennisgrafiek. Amethyst maakt collaboratieve curatie, review en governance praktisch uitvoerbaar. NCOR biedt de methodologische basis voor interoperabiliteit en robuuste AI.

De aanbevolen inzet is evolutionair, niet big bang. Start met één scherpe competency question, bijvoorbeeld vulnerability-to-control traceability of ATT&CK-to-D3FEND coverage. Bouw daarna een gecontroleerde knowledge graph pipeline met provenance, validation, graph-scoped access, GitOps, SHACL, policy enforcement en evidence integration. Pas daarna is AI-agent orchestration verantwoord.

De kern: gebruik deze stack niet als statische taxonomie, maar als formele, auditeerbare beslissingsinfrastructuur voor cyber defense. Dat is precies waar de combinatie van OWL, RDF, SPARQL, D3FEND, STIX-formalisatie en ontology governance het meeste strategische rendement oplevert.