Cross-domain solution architectuur voor geclassificeerde militaire netwerken

Wanneer een militair informatiesysteem gegevens moet verplaatsen van een SECRET-netwerk naar een niet-geclassificeerd netwerk — of van een TOP SECRET compartimenteerde omgeving naar een coalitiepartnernetwerk — kan het verkeer niet eenvoudig via een standaard firewall worden gerouteerd. De classificatiebarrière is geen toegangsbeheerproblem dat door netwerkbeleid kan worden opgelost. Het is een content-integriteitsprobleem: de informatie zelf kan markeringen, compartimenten of ingebedde gegevenselementen bevatten die het hoger-geclassificeerde enclave niet mogen verlaten. Het mechanisme dat is ontworpen om dit op te lossen is de cross-domain solution, en het correct engineeren ervan vereist begrip van guard-architectuur, inhoudsfilterlogica, markeringsstandaarden en een overheidsaccreditatieproces dat doorgaans langer duurt dan de applicatie die het beschermt.

Dit artikel legt uit hoe CDS guards van binnenuit werken — het referentiemonitormodel dat aan elk goedgekeurd product ten grondslag ligt, de filterregellogica die CAPCO-markering afdwingt, de protocolspecifieke inspectietechnieken voor XML- en SMTP-pijplijnen, en het NSA-accreditatietraject dat bepaalt of een implementatie wettelijk bevoegd is te opereren. Het is geschreven voor engineers en programmamanagers die de beperkingen moeten begrijpen voordat ze zich aan een architectuur committeren.

Wat is een cross-domain solution en wanneer is het vereist

Een cross-domain solution is een product of systeem dat een beveiligingsbeleid afdwingt wanneer gegevens worden verplaatst tussen netwerken die zijn geaccrediteerd op verschillende classificatieniveaus of met incompatibele toegangscontroles. De term omvat hardware-data diodes, softwaregebaseerde bidirectionele guards en combinaties van beide. Wat een CDS onderscheidt van een gewone netwerkgateway is dat het op de inhoudslaag werkt, niet op de pakketlaag — het inspecteert payloads, leest classificatiemarkeringen, past gestructureerde filterregels toe en neemt een toestaan-of-weigeren-beslissing voor elk afzonderlijk gegevensitem.

Een CDS is verplicht wanneer twee voorwaarden beide van toepassing zijn: het bronnetwerk bevat informatie op een hoger classificatieniveau dan het doelnetwerk bevoegd is te ontvangen, en de operationele vereiste is om sommige — maar niet alle — van die informatie over te dragen naar het lagere netwerk. Als er nooit iets van hoog naar laag mag worden verplaatst, is fysieke isolatie (een luchtgat) goedkoper en veiliger. Als alles aan de hoge kant naar de lage kant kan worden verplaatst, moeten de netwerken worden samengevoegd of moet het doelnetwerk opnieuw worden geaccrediteerd. Het is het geval van selectieve overdracht dat een CDS vereist.

Veelvoorkomende scenario's die een CDS verplichten in defensieprogramma's zijn: het overdragen van gesanitiseerde trackgegevens van een SECRET gemeenschappelijk operationeel beeld naar een niet-geclassificeerd coalitiepartnersdisplay; het publiceren van vrijgeefbare inlichtingenproducten vanuit een TS/SCI-analyseomgeving naar een SECRET-verspreidingsnetwerk; het invoeren van sensorgegevens van een geclassificeerd verzamelplatform naar een niet-geclassificeerd archief voor langdurige bewaring; en het verbinden van een nationaal inlichtingennetwerk met een door NATO geaccrediteerd gecombineerd netwerk waar de classificatieschema's verschillen. In elk geval is de CDS het grenshandhavingsmechanisme — en de accreditatie ervan is wat de verbindende autoriteit het vertrouwen geeft dat de grens correct wordt gehandhaafd.

Het alternatief voor een CDS in sommige beperkte scenario's is handmatige beoordeling: een menselijke beoordelaar leest het document, bepaalt dat het kan worden vrijgegeven en typt of herschrijft de inhoud op het lagere netwerk. Dit is de originele cross-domain "solution" en blijft in gebruik voor laag-volume, hoog-gevoelige overdrachten waarbij geautomatiseerde filtering niet kan worden vertrouwd om alle gevoelige inhoud te detecteren. Geautomatiseerde CDS-producten zijn alleen geschikt wanneer de inhoud voldoende gestructureerd is (gemarkeerde XML, SMTP met classificatiekoppen, goed gedefinieerde berichtformaten) zodat een filter het beleid betrouwbaar kan afdwingen zonder menselijk oordeel voor elke overdracht. Ongestructureerde vrije tekst — narratieve beoordelingen, analytische rapporten, commandantenramingen — vereist vaak nog steeds menselijke beoordeling vóór vrijgave, zelfs wanneer een CDS guard aanwezig is voor de technische overdracht.

Voor programma's die niet alleen het overdrachtemechanisme maar ook de bredere beveiligingshouding van de geclassificeerde omgeving moeten aanpakken, biedt de zero trust voor defensiesoftware-architectuur het omringende toegangscontrole-kader waarbinnen een CDS integreert.

CDS guard-architecturen

Vier architectuurpatronen bestrijken de meerderheid van CDS-implementaties. Elk maakt een afweging tussen beveiligingsborging, operationele complexiteit en functionaliteit ten opzichte van de andere.

Hardware data diode. Een fysiek apparaat dat optische of elektrische isolatie gebruikt om unidirectionele gegevensstroom op hardwareniveau te garanderen. Elektronen — en daarmee signalen — kunnen niet in de geblokkeerde richting reizen. Een diode tussen een geclassificeerd netwerk en een niet-geclassificeerd netwerk zorgt ervoor dat zelfs als de software aan de lage kant volledig is gecompromitteerd, er geen signaal van de lage kant de hoge kant kan bereiken. De beperking is strikt: het applicatieprotocol moet eenrichtingsverkeer kunnen verdragen. Het bevestigingsmechanisme van TCP werkt niet over een diode; UDP-streaming, syslog en bestandsreplicatie via aangepaste protocollen werken wel. Diodes zijn geschikt voor bulk unidirectionele exports — sensorstreaming, loginreplicatie, videodistributie — waarbij de hoge kant nooit bevestiging van levering nodig heeft.

Bidirectionele guard met gescheiden proxyprocessen. De meest voorkomende architectuur voor applicaties die verzoek-antwoord-protocollen vereisen. De guard voert een hoge-kant-proxyproces en een lage-kant-proxyproces uit zonder gedeelde adresruimte, gedeeld bestandssysteem of directe interprocesscommunicatie tussen hen. Het enige pad van hoog naar laag — en van laag naar hoog — loopt door de guard-kernel, die het beveiligingsbeleid voor elke overdracht afdwingt. De applicatie aan de hoge kant maakt verbinding met de hoge-kant-proxy; de applicatie aan de lage kant maakt verbinding met de lage-kant-proxy. Vanuit het perspectief van het netwerk ziet elke kant alleen zijn eigen proxy. De guard-kernel is de referentiemonitor — een klein, formeel gespecificeerd, onafhankelijk geëvalueerd onderdeel waarvan de enige functie is het overdrachtsbeleid af te dwingen.

Inhoudsfilterguard. Een guard waarvan het primaire handhavingsmechanisme inhoudsinspectie is — het parsen van de payload, het extraheren van classificatiemarkeringen, het matchen met filterregels en het doorgeven, weigeren of sanitiseren van de inhoud vóór doorsturen. Inhoudsfilterguards implementeren de CAPCO-markeerwoordenschat als hun beleidstaal. Ze zijn geschikt wanneer de overgedragen gegevens gestructureerd en goed gemarkeerd zijn, en wanneer het beleid selectieve doorgang vereist in plaats van algehele blokkering. De meeste moderne bidirectionele guards bevatten een inhoudsfilter als eerste fase na de bidirectionele scheiding.

Referentiemonitormodel. Het fundamentele beveiligingsprincipe dat alle vier architecturen implementeren. Een referentiemonitor is een onderdeel dat: elke toegangsaanvraag bemiddelt tussen een subject (de afzender) en een object (het over te dragen gegevensitem); altijd wordt aangeroepen (geen overdracht omzeilt het); manipulatiebestendig is (het kan niet worden gewijzigd of uitgeschakeld door beide kanten); en klein genoeg is om formeel geverifieerd te worden. In CDS-termen is de referentiemonitor de guard-kernel — en de manipulatiebestendigheid en volledige bemiddelingseigenschappen zijn wat evaluatoren verifiëren tijdens het accreditatieproces. Een CDS-product dat overdrachten toestaat om de guard-kernel onder welke omstandigheid dan ook te omzeilen — onderhoudsmodus, terugval bij hoge belasting, foutstatus — voldoet niet aan de referentiemonitorvereiste en kan niet worden geaccrediteerd voor geclassificeerde netwerkgrenzen.

Het volgende diagram toont de bidirectionele guard-architectuur met gescheiden proxyprocessen:

  ┌──────────────────────┐          ┌──────────────────────┐
  │  SECRET Network       │          │  UNCLASSIFIED Network │
  │  (High Side)          │          │  (Low Side)           │
  │                       │          │                       │
  │  ┌─────────────────┐  │          │  ┌─────────────────┐  │
  │  │  C2 Application │  │          │  │  COP Display    │  │
  │  └────────┬────────┘  │          │  └────────▲────────┘  │
  │           │            │          │           │            │
  │  ┌────────▼────────┐  │          │  ┌────────┴────────┐  │
  │  │  High-Side Proxy│  │          │  │ Low-Side Proxy  │  │
  └──┴────────┬────────┴──┘          └──┴────────▲────────┴──┘
              │                                   │
              │         ┌─────────────────┐       │
              └────────►│  Guard Kernel   ├───────┘
                        │  (Reference     │
                        │   Monitor)      │
                        │                 │
                        │  ┌───────────┐  │
                        │  │ Filter    │  │
                        │  │ Rules     │  │
                        │  │ (CAPCO)   │  │
                        │  └───────────┘  │
                        │                 │
                        │  ┌───────────┐  │
                        │  │ Audit Log │  │
                        │  │ (Signed)  │  │
                        │  └───────────┘  │
                        └─────────────────┘
                        Physical separation
                        of proxy processes
                        No shared memory/FS

Inhoudsgebaseerde filtering: wat guards inspecteren

Inhoudsgebaseerde filtering is het mechanisme dat CDS guards hun selectieve doorlaatmogelijkheid geeft. In plaats van alles te blokkeren of alles door te laten, leest een inhoudsfilterguard de gegevens, extraheert de beveiligingsrelevante velden, past beleidsregels toe en neemt een toestaan/weigeren/sanitiseren-beslissing per bericht.

CAPCO-markeerparsing. De basis van inhoudsfiltering in Amerikaanse geclassificeerde systemen is de CAPCO-markeerstandaard, die een gecontroleerde woordenschat van tokens definieert die verschijnen in classificatiebanniers, portiemerken en gestructureerde metadatavelden. De CAPCO-parser van een guard leest het classificatiemetadata-element uit elk inkomend bericht en extraheert de componenttokens. Voor een bericht gemarkeerd als SECRET//SI//REL TO USA,GBR produceert de parser: classificatieniveau = SECRET; SCI-compartiment = SI; verspreiding = REL TO; vrijgeefbaarheid = USA, GBR. Elk token wordt vervolgens gecontroleerd aan de hand van de beleidsmatrix voor het doelnetwerk. Als het doelnetwerk niet geaccrediteerd is voor het SI-compartiment, wordt de overdracht geweigerd. Als het doelnetwerk geaccrediteerd is voor REL TO GBR-inhoud, is de overdracht toegestaan — maar de filter controleert nog steeds of een ander veld in de berichttekst een hogere markering heeft dan de document-niveaumarkering beweert.

Handhaving van gevoelige compartimenten. SCI-compartimenthandhaving vereist dat de guard de volledige reeks compartimenttokens herkent die zijn gedefinieerd in de toepasselijke classificatiegids. De meest voorkomende compartimenten in Amerikaanse systemen zijn SI (Signals Intelligence), TK (Talent Keyhole, beeldvorming vanuit de ruimte), HCS (Humint Control System) en G (Gamma, een sub-compartiment van SI). Elk moet afzonderlijk worden gecontroleerd aan de hand van de compartimentaccreditatie van het doelenclave. Een doelnetwerk dat geaccrediteerd is voor SI maar niet voor TK, mag geen berichten ontvangen met TK-markering — zelfs als de classificatie op documentniveau binnen het toegestane bereik valt.

Handhaving van portiemarkering. Een geclassificeerd document bevat vaak alinea's, secties of gegevenselementen met verschillende gevoeligheidsniveaus. CAPCO vereist dat elke portie zijn eigen markering draagt. Een guard die portiemerken handhaaft, moet niet alleen de bannière op documentniveau parsen maar ook elke (S//SI) of (U//FOUO)-tag op alineaniveau en een afzonderlijke beleidsbeslissing nemen voor elk. Sanitisatie — het verwijderen van de porties die het beleid niet doorstaan terwijl de rest wordt doorgestuurd — is complexer dan algehele weigering maar operationeel essentieel voor gemengde-inhoudsdocumenten.

Bijlageverwijdering. SMTP-berichten en HTTP-multipart-payloads bevatten vaak bijlagen die de guard onafhankelijk van de berichttekst moet inspecteren. Elke bijlagepartij wordt afzonderlijk geparsed: het MIME-inhoudstype bepaalt welke parser wordt gebruikt, de bijlage wordt geïnspecteerd op ingebedde classificatiemetadata (PDF-documenteigenschappen, aangepaste Word-eigenschappen, EXIF-velden van afbeeldingen) en het beleid wordt op elke bijlage afzonderlijk toegepast. Bijlagen in formaten die de guard niet kan parsen — niet-herkende binaire formaten, versleutelde archieven — worden standaard geweigerd, nooit doorgegeven zonder inspectie.

De wisselwerking tussen CAPCO-markeerhandhaving op de CDS-laag en het onderliggende datamodel wordt uitvoerig beschreven in het artikel over militaire datafusie uitgelegd, dat behandelt hoe classificatie zich verspreidt door een multi-bron trackdatabase. Voor NATO-omgevingen wordt de koppeling tussen CAPCO-equivalente markeringen en de NATO-vertrouwelijkheidsmarkeringsstandaard behandeld in de referentie over STANAG 4774/4778-markeringsimplementatie.

Gegevensformaten en protocollen ondersteund door moderne CDS-producten

Een CDS guard is alleen zo nuttig als de ondersteuning voor de formaten die uw applicatie daadwerkelijk gebruikt. De parser van de guard moet het formaat diep genoeg begrijpen om classificatievelden te extraheren en inhoud te inspecteren — oppervlakkige headerinspectie is onvoldoende.

Formaat / Protocol	Locatie classificatieveld	Typisch militair gebruik	Complexiteit guard-inspectie
XML (IC-ISM / UCORE)	Namespace-attributen op rootelement en elke geclassificeerde portie	Trackberichten, inlichtingenproducten, NiemXML-rapporten	Hoog — volledige schema-bewuste XPath-evaluatie
JSON met ISM-metadata	Top-level ism:classification-veld of ingebedde markeringsobjecten	REST API-payloads, moderne C2-microservices	Gemiddeld — schema-afhankelijk, recursieve inspectie vereist
SMTP / MIME	X-Classification:-header + bodybannière + markering per bijlage	Verspreiding van inlichtingenproducten, SITREP-distributie	Hoog — recursieve MIME-parsing, detectie bijlagetype
HTTP/HTTPS (REST)	Aangepaste header + payload-body	API-aanroepen tussen geclassificeerde en niet-geclassificeerde services	Gemiddeld — TLS-beëindiging + her-inhoudsinspectie vereist
MTF (Message Text Format)	CLASSIFICATION-veld in berichtheaderreeks	NATO/legacy militaire berichten, USMTF, ADatP-3	Gemiddeld — vaste veldindeling, goed gespecificeerde parsing
PDF / Office-documenten	Aangepaste documenteigenschappen, XMP-metadata, bannièretekst in body	Afgewerkte inlichtingenproducten, orders, plannen	Zeer hoog — ingebedde objecten, macro's, metadataverwijdering vereist
Video (RTP/RTSP)	Streammetadata-headers (indien aanwezig); overlay-tekst op frameniveau	ISR-video-downlink, UAV-feeds	Zeer hoog — vereist doorgaans diode + speciale videoproxy

Voor XML-gebaseerde militaire berichten worden filterregels uitgedrukt in XPath. Een regel die elk bericht met een TK-compartimenttoken weigert, ziet er als volgt uit:

<!-- Guard filter rule: reject if TK compartment is present -->
<FilterRule id="REJ-TK-001" action="REJECT">
  <Description>Reject messages carrying Talent Keyhole (TK) compartment</Description>
  <Condition>
    <XPathExpression>
      //*[contains(
        translate(
          @ism:SCIcontrols,
          'ABCDEFGHIJKLMNOPQRSTUVWXYZ',
          'abcdefghijklmnopqrstuvwxyz'
        ),
        'tk'
      )]
    </XPathExpression>
  </Condition>
  <AuditMessage>Transfer rejected: TK compartment detected in payload</AuditMessage>
</FilterRule>

<!-- Sanitization rule: strip SI-marked portion elements before forwarding -->
<FilterRule id="SAN-SI-001" action="SANITIZE">
  <Description>Strip SI-marked portions from otherwise-releasable documents</Description>
  <Condition>
    <XPathExpression>//*[@ism:SCIcontrols='SI']</XPathExpression>
  </Condition>
  <SanitizeAction>REMOVE_ELEMENT</SanitizeAction>
  <AuditMessage>Sanitized: SI-marked element removed from document</AuditMessage>
</FilterRule>

NSA-goedkeuring en accreditatieproces

Een CDS guard die een verbinding beschermt tussen twee geclassificeerde Amerikaanse overheidsnetwerken moet door NSA/CSS worden goedgekeurd voordat het in gebruik wordt genomen. Er is geen ontheffingstraject voor operationele urgentie — het inzetten van een niet-goedgekeurde CDS is een meldingsplichtig beveiligingsincident. Het accreditatieproces en de tijdlijn ervan begrijpen is een voorwaarde voor elk programma dat een geclassificeerde grens omvat.

NSA/CSS Evaluated Products List (EPL). NSA evalueert CDS-producten en publiceert de resultaten op de Evaluated Products List. Een EPL-vermelding certificeert dat een specifieke productversie, in een specifieke configuratie, het referentiemonitormodel correct implementeert en bestand is tegen de aanvalsklassen die evaluatoren hebben getest. De EPL-vermelding specificeert het exacte hardwaremodel en firmwareversie, softwareversie en configuratieopties die zijn geëvalueerd. Afwijken van de geëvalueerde configuratie — zelfs het toepassen van een besturingssysteempatch die geen deel uitmaakte van de geëvalueerde basislijn — vereist her-evaluatie of een afwijkingsautorisatie. Programma's moeten bijhouden welke EPL-versie overeenkomt met hun ingezette guard en die correspondentie gedurende de operationele levensduur van de guard handhaven.

Raise the Bar (RTB)-initiatief. Na een reeks incidenten waarbij onvoldoende ontworpen guards toestonden dat gegevens onjuist werden doorgegeven, heeft NSA/CSS de Raise the Bar-vereisten voor CDS-producten uitgevaardigd. RTB verplicht hardwarescheiding van hoge-kant- en lage-kant-verwerkingspaden, formele documentatie van elke filterregel en de beveiligingsreden, cryptografisch ondertekende auditlogs (zodat logmanipulatie detecteerbaar is), onafhankelijke verificatie door derden van de guard-logica en een gedefinieerde patchprocedure inclusief verificatie na beveiligingsrelevante wijzigingen. RTB-conforme producten staan op de EPL met een expliciete RTB-aanduiding. Niet-RTB-producten mogen mogelijk nog op oudere EPL-lijsten staan, maar kunnen niet nieuw worden goedgekeurd voor geclassificeerde Amerikaanse overheidsnetworkgrenzen.

DISA Unified Capabilities Approved Products List (UC APL). Voor DoD-programma's is de DISA UC APL-vermelding vereist naast de NSA EPL. De UC APL-evaluatie richt zich op interoperabiliteit met DoD-netwerkinfrastructuur en naleving van DoD-beveiligingstechnische implementatiegidsen (STIGs). Een product kan op de NSA EPL staan maar niet op de UC APL, of omgekeerd — beide zijn vereist voor de meeste DoD-geclassificeerde netwerkinzetten. Controleer beide lijsten bij het evalueren van kandidaat-CDS-producten.

Site-specifieke Authority to Operate (ATO). Zelfs met een EPL/UC APL-product vereist elke inzet een site-specifieke ATO die omvat: de specifieke hardware- en softwareconfiguratie die is ingezet; de netwerktopologie en fysieke beveiliging van de guard-installatie; de filterregelset en de relatie ervan tot het classificatiebeleid van de verbonden netwerken; procedures voor continue monitoring; en het patchbeheer- en configuratiewijzigingsproces. Het ATO-pakket wordt beoordeeld door de Authorizing Official (AO) voor de systemen aan beide kanten van de grens. Voor verbindingen tussen netwerken van verschillende agentschappen is een bilaterale overeenkomst tussen de twee AO's vereist voordat de ATO kan worden verleend. Tijdlijn: 6 tot 18 maanden voor een product dat al op de EPL staat in een niet-complexe configuratie.

Integratiepatronen voor C2- en ISR-pijplijnen

Het integreren van een CDS guard in een operationele C2- of ISR-pijplijn vereist nadenken over zowel de gegevensstroom-architectuur als de prestatieconstraints die de guard introduceert.

Het SECRET-naar-UNCLASSIFIED COP-patroon. De meest voorkomende integratie is een publiceer-abonneer-pijplijn waarbij een SECRET-broker geclassificeerde trackupdates verzorgt, en een CDS guard abonneert op de SECRET-broker, elke update inspecteert en gesanitiseerde updates opnieuw publiceert naar een niet-geclassificeerde broker waarop coalitiepartners of lager-zijde-verbruikers zich abonneren. De guard fungeert in deze architectuur als een filterabonnee aan de hoge kant en een producerende uitgever aan de lage kant — nooit als een doorgefilterde router. Dit zorgt ervoor dat er geen directe verbinding bestaat tussen de twee brokers.

SECRET Network                     UNCLASSIFIED Network
─────────────                      ────────────────────

┌─────────────┐   track updates   ┌─────────────────────────────┐
│ SECRET      │ ─────────────────►│     CDS Guard               │
│ Message     │                   │                             │
│ Broker      │                   │  High-Side     Low-Side     │
│             │                   │  Subscriber    Publisher    │
│             │                   │      │              │       │
│             │                   │      ▼              │       │
│             │                   │  CAPCO Filter       │       │
│             │                   │  SI/TK/HCS check    │       │
│             │                   │  Sanitize/Reject     │       │
│             │                   │      │              │       │
│             │                   │      └──────────────►       │
└─────────────┘                   └─────────────────────────────┘
                                               │
                                               ▼ sanitized updates
                                   ┌───────────────────┐
                                   │ UNCLASSIFIED      │
                                   │ Message Broker    │
                                   └─────────┬─────────┘
                                             │
                                             ▼
                                   ┌───────────────────┐
                                   │ Coalition COP /   │
                                   │ UNCLASSIFIED      │
                                   │ Display           │
                                   └───────────────────┘

Latentieplanning. Een CDS guard introduceert verwerkingslatentie voor elk bericht dat het inspecteert. Voor kleine XML-trackupdateberichten (onder 4 KB) voegen commerciële guards doorgaans 50 tot 200 milliseconden inspectielatentie toe. Voor grote berichten met binaire bijlagen of die sanitisatie van meerdere porties vereisen, kan de latentie oplopen tot 500 milliseconden tot 2 seconden. Voor PDF-documenten of complexe MIME-berichten kan de verwerking enkele seconden duren. Dit moet worden meegenomen in de COP-verversingsfrequentie en de SLA voor verspreiding van inlichtingenproducten. Guard-doorvoerbeoordelingen worden gepubliceerd in EPL-documentatie — verifieer dat de beoordeelde doorvoer bij de berichtgrootte en complexiteit van uw applicatie voldoende is voordat u zich aan een product committeert.

ISR-sensordatapaden. Voor ISR-sensoren die op geclassificeerd niveau opereren en gegevens moeten leveren aan lager-geclassificeerde verbruikers, omvat het gegevenspad doorgaans een geclassificeerde verwerkingsfase die gesanitiseerde afgeleide producten produceert, die vervolgens de CDS-grens oversteken. Ruwe sensorgegevens (volledige beeldresolutie, ruwe SIGINT-onderscheppingen) mogen nooit worden ontworpen om door een CDS guard te stromen — de classificatie van ruwe ISR is doorgaans ver boven wat de lage kant kan ontvangen, en inhoudsfiltering van ruwe sensorgegevens is onbetrouwbaar. Het ontwerppatroon is: verwerk op het classificatieniveau van de gegevens, produceer afgeleide producten ontdaan van de gevoelige bronindicatoren en stuur alleen de afgeleide producten door de guard.

Operationele beveiliging voor CDS-implementaties

Een CDS guard is een hoogwaardig doelwit precies omdat het compromitteren ervan gelijkstaat aan het elimineren van de geclassificeerde grens. De operationele beveiligingscontroles rondom een ingezette guard moeten evenredig zijn aan dat risico.

Fysieke beveiliging. De guard-hardware moet worden geïnstalleerd op een fysiek beveiligde locatie — een afgesloten apparatenruimte met toegangsgecontroleerde toegang en bezoekersregistratie. Zowel de hoge-kant-netwerkverbinding als de guard-hardware moeten zich binnen de fysieke beveiligingsperimeter van het hoger-geclassificeerde netwerk bevinden. Guard-manipulatie — het invoegen van een verborgen kanalapparaat op de netwerkverbinding, het vervangen van firmware — is een reële dreiging die fysieke controles aanpakken.

Out-of-band beheer. De beheerinterface van de guard moet op een apart fysiek netwerk staan, gescheiden van zowel de operationele hoge-kant- als lage-kant-netwerken. Beheerverkeer — configuratiewijzigingen, software-updates, logophaling — dat door een van de operationele netwerken gaat, creëert een verborgen kanaalmogelijkheid. Beheerwerkstations moeten zich binnen de beveiligingsperimeter van het hoger-geclassificeerde niveau bevinden en dienovereenkomstig worden geaccrediteerd.

Logintegriteit en manipulatiedetectie. CDS-auditlogs zijn het primaire bewijs dat de grens correct werd gehandhaafd. Logs moeten cryptografisch worden beschermd — elk logrecord bevat een HMAC over de recordinhoud en de hash van het vorige record (een hash-keten). Dit maakt invoeging, verwijdering of wijziging van elk record detecteerbaar wanneer de keten wordt geverifieerd. Logs moeten worden opgeslagen op een systeem waar noch het hoge-kant- noch het lage-kant-netwerk naar kan schrijven of kan verwijderen — een speciale logserver die alleen toegankelijk is voor de beveiligingsbeheerder via het out-of-band-beheernetwerk. Logbeoordeling moet een actieve, dagelijkse activiteit zijn: weigeringsanomalieën, ongewone berichtvolumes of herhaalde beleidsschendingen door dezelfde afzender zijn indicatoren van verkenning of aanval.

Configuratiewijzigingsbeheer. Elke wijziging aan de filterregelset — een regel toevoegen, een voorwaarde wijzigen, een regel verwijderen — moet een gedocumenteerd wijzigingsproces doorlopen dat omvat: een schriftelijk wijzigingsverzoek met beveiligingsreden; onafhankelijke beoordeling door een tweede beveiligingsfunctionaris; testuitvoering tegen het representatieve verkeersmonster; en post-wijzigingsaudit van de eerste 24 uur productiegbeslissingen om te verifiëren dat de regel zich gedraagt zoals beoogd. Wijzigingen die dit proces niet hebben doorlopen, mogen niet worden toegepast op productieconfigurations van guards. Een standaardwijzigingsvries moet gelden tijdens hoge-tempo-operationele perioden wanneer een guard-misconfiguratie het meest schadelijk zou zijn.

Patchbeheer. Beveiligingspatches voor het guard-besturingssysteem en de applicatie vereisen zorgvuldige behandeling. Het toepassen van een patch die geen deel uitmaakt van de geëvalueerde configuratie kan de ATO ongeldig maken — en het niet toepassen van beveiligingspatches creëert exploiteerbare kwetsbaarheden. De procedure is: de patch ontvangen en beoordelen; bepalen of het de geëvalueerde configuratiebasislijn beïnvloedt; als dat zo is, overleg met de EPL-leverancier en verkrijg een evaluatieafwijkingsautorisatie of plan een her-evaluatie; test de patch in een geïsoleerde guardomgeving die productie weerspiegelt; pas toe op productie tijdens een gepland onderhoudsvenster met korte serviceonderbreking; verifieer dat het filterregelgedrag ongewijzigd is na patching.

Red team-testen. Jaarlijkse penetratietests van de CDS-installatie moeten een vereiste zijn in het beveiligingsplan. De testomvang moet omvatten: pogingen om geclassificeerde inhoud te extraheren via de lage-kant-interface met behulp van formaatinjectie- en coderingsaanvallen; pogingen tot exploitatie van verborgen kanalen via timing-, opslag- en protocolniveaukanalen; pogingen om toegang te krijgen tot de guard-beheerinterface vanuit operationele netwerken; en pogingen tot fysieke manipulatiescenario's. Bevindingen van red team-testen worden direct ingevoerd in het rapport voor continue monitoring en kunnen configuratiewijzigingen of her-evaluatie triggeren.