STANAG 4774/4778 implementeren: vertrouwelijkheidslabels in de praktijk

Datagerichte beveiliging – het idee dat bescherming het dataobject volgt in plaats van de netwerkperimeter – is niet nieuw, maar de praktische implementatie ervan in militaire coalitiesystemen is historisch gezien moeilijk geweest. STANAG 4774 en STANAG 4778 zijn NATO's formele antwoord: twee in elkaar grijpende standaarden die definiëren hoe vertrouwelijkheidslabels zijn gestructureerd, hoe ze aan data worden gebonden en hoe beleidsengines ze evalueren. Dit artikel behandelt de praktische engineering van een conforme labelimplementatie: labelsyntaxis, het bindingsmechanisme, het ontwerp van het beleidshandhavingspunt, aggregatieafhandeling en de labelbehoudsdiscipline die bepaalt of uw architectuur de accreditatiebeoordeling overleeft. Voor de classificatie- en vrijgavebeleidscontext die dit engineeringwerk kadert, zie het bijbehorende artikel over STANAG 4774/4778 classificatie en coalitievrijgave.

Het datagerichte beveiligingsmodel: waarom labels met data meereizen

Traditionele netwerkgerichte beveiliging steunt op het classificatieniveau van de enclave: zodra een stuk data op een SECRET-netwerk staat, wordt elk systeem op dat netwerk vertrouwd om ermee om te gaan. Dit model valt uiteen in coalitieomgevingen waar data tussen enclaves met verschillende accreditatieniveaus, verschillende nationale beleidslijnen en verschillende geautoriseerde ontvangerssets beweegt. Een SECRET-document op een gezamenlijk netwerk is niet noodzakelijk vrijgegeven aan elke partnernatie met toegang tot dat netwerk.

Datagerichte beveiliging lost dit op door het label een onafscheidelijke eigenschap van het dataobject te maken. Elk object draagt een machineleesbaar vertrouwelijkheidslabel dat zijn classificatieniveau specificeert, de behandelingsvoorbehouden die het gebruik ervan regelen en de vrijgavemarkeringen die identificeren welke organisaties geautoriseerd zijn om het te ontvangen. Beleidsbeslissingen – of een object moet worden doorgestuurd, weergegeven, opgeslagen of afgedrukt – worden genomen door het label van het object te evalueren tegen de machtiging van het verzoekende subject en het accreditatieniveau van het doelsysteem, in plaats van erop te vertrouwen dat het netwerk de juiste grens handhaaft.

STANAG 4774 definieert de labelstructuur. STANAG 4778 definieert het bindingsmechanisme. Samen bieden ze het technische substraat voor coalitie-datadeling die het nationale openbaarmakingsbeleid van elke natie respecteert zonder handmatige beoordeling van elke data-uitwisseling te vereisen. Beide standaarden als een paar begrijpen – niet geïsoleerd – is de voorwaarde voor een conforme implementatie.

STANAG 4774-labelsyntaxis: structuur en codering

Een STANAG 4774-vertrouwelijkheidslabel is een XML-document dat voldoet aan het STANAG 4774-XML-schema. Het topniveau-element is <ConfidentialityLabel>, dat drie verplichte kinderen en verscheidene optionele uitbreidingen draagt.

Beleidsidentificator. Het <PolicyIdentifier>-element bevat een Object Identifier (OID) die verwijst naar het labelbeleidsdocument dat dit label regelt. De OID is geregistreerd bij een erkende autoriteit – doorgaans het nationale C3-kantoor of NATO C3-bureau – en is de sleutel waarmee ontvangende systemen de volledige beleidsdefinitie kunnen opzoeken en het label correct kunnen evalueren. Een label zonder een oplosbare beleids-OID kan niet worden geëvalueerd door een conforme beleidsengine en moet als ongeverifieerd worden behandeld.

Classificatie. Het <Classification>-element specificeert het classificatieniveau als een opgesomde waarde: UNCLASSIFIED, RESTRICTED, CONFIDENTIAL of SECRET. De codering is hoofdlettergevoelig en moet exact overeenkomen met de stringwaarden die zijn gedefinieerd in het door de OID gerefereerde beleidsdocument. Een label dat "Secret" gebruikt in plaats van "SECRET" zal falen bij schemavalidatie in een conforme implementatie – een veelvoorkomende integratiefout bij het genereren van labels met algemene XML-bibliotheken die de opsomming niet afdwingen.

Behandelingsvoorbehouden en vrijgave. Het <CategoryData>-element draagt behandelingsvoorbehouden zoals ATOMAL, CRYPTO, EYES ONLY of missiespecifieke voorbehouden die door het beleid zijn gedefinieerd. Het <PermittedCountryCodes>-element draagt de vrijgavemarkering als een set ISO 3166-1 alpha-3-landcodes. De vrijgavemarkering is het operationeel belangrijkste deel van het label in multinationale omgevingen: het bepaalt welke partnernatie-systemen gemachtigd zijn om de gelabelde data te ontvangen, ongeacht het classificatieniveau.

Labelgeneratie: validatievereisten

Elk label dat door een conform systeem wordt gegenereerd, moet worden gevalideerd tegen het STANAG 4774-XML-schema voordat het aan enig dataobject wordt gebonden. Schemavalidatie vangt structurele fouten op – misvormde OID's, ongeldige classificatiestrings, ontbrekende verplichte elementen – maar valideert geen semantische correctheid tegen het beleidsdocument. Een afzonderlijke validatiestap op beleidsniveau moet controleren dat elk voorbehoud en elke vrijgavemarkering in het label is gedefinieerd in het gerefereerde beleidsdocument, en dat de combinatie van classificatieniveau en voorbehouden door dat beleid is toegestaan. Een implementatie die de validatie op beleidsniveau overslaat, zal labels genereren die de schemavalidatie doorstaan maar door downstream-beleidsengines worden afgewezen met fouten die achteraf moeilijk te diagnosticeren zijn. Bouw de validatiestap op beleidsniveau in de labelgenerator, niet in een afzonderlijke audit na generatie.

STANAG 4778-bindingsmechanismen: assertie en encapsulatie

STANAG 4778 definieert twee mechanismen voor het binden van een STANAG 4774-label aan een dataobject: assertiebinding en encapsulatiebinding. Ze dienen verschillende gebruiksscenario's en hebben verschillende beveiligingseigenschappen, en de keuze ertussen moet bij het ontwerp van de architectuur worden gemaakt.

Assertiebinding produceert een ondertekende XML-assertie die het label, een verwijzing naar het dataobject (doorgaans een cryptografische hash van de payload) en een digitale handtekening van de labelautoriteit bevat. De handtekening wordt berekend met XML Digital Signature (XMLDSig) over de gecanoniseerde label-XML. Het dataobject en de ondertekende assertie worden samen verzonden – ofwel in dezelfde berichtenvelop ofwel als een verwijzing-en-assertie-paar. Het ontvangende systeem verifieert de assertie door de handtekening te controleren tegen het openbare sleutelcertificaat van de labelautoriteit, en controleert vervolgens de hash van het dataobject tegen de hash in de assertie. Als beide controles slagen, wordt het label geverifieerd als authentiek en ongewijzigd, en is de binding tussen het label en het dataobject cryptografisch bevestigd.

Assertiebinding is verplicht voor data die classificatiegrenzen overschrijdt via een cross-domain-oplossing (CDS). De accreditator moet verifiëren dat de CDS labels correct handhaaft, en de ondertekende assertie levert het auditbewijs dat voor deze verificatie vereist is. Zonder assertiebinding aan de CDS-grens kan de accreditator niet bevestigen dat labels die aan het laagzijdesysteem worden gepresenteerd authentieke weergaven zijn van de beslissing van de hoogzijde-labelautoriteit – en de CDS zal niet worden geaccrediteerd.

Encapsulatiebinding bedt het label rechtstreeks in de structuur van het dataobject in – in een berichtheader, een metadatablok of een gedefinieerd uitbreidingsveld. Er is geen afzonderlijke cryptografische handtekening; de binding steunt op de integriteit van het transportkanaal. Encapsulatiebinding is eenvoudiger te implementeren en wordt breed gebruikt voor data die binnen één beveiligingsdomein blijft. Voor een C2-systeem dat volledig binnen een SECRET-enclave opereert, is encapsulatiebinding in het berichtschema voldoende en vermijdt het de PKI-overhead van assertiebinding voor elk intern bericht.

Het mengen van bindingsmechanismen binnen hetzelfde systeem – encapsulatiebinding gebruiken voor interne berichten en assertiebinding alleen aan de CDS-grens – is correct en gangbaar, maar de grens moet duidelijk gedefinieerd zijn en in de implementatie worden gehandhaafd. Ambiguïteit over welk bindingsmechanisme aan welke systeemgrens van toepassing is, is een bron van accreditatiebevindingen.

Ontwerp van het beleidshandhavingspunt

Een Policy Enforcement Point (PEP) is de softwarecomponent die datatoegangs- en uitwisselingsverzoeken onderschept en het label van het gevraagde object evalueert tegen de machtiging van het verzoekende subject en het accreditatieniveau van het verzoekende systeem. In een STANAG 4774/4778-conforme architectuur is de PEP niet optioneel: het is het mechanisme waarmee het label feitelijke toegangscontrole produceert, in plaats van louter een metadata-annotatie te zijn die nooit wordt geëvalueerd.

Het PEP-evaluatiealgoritme moet dominantie correct implementeren. Een subject kan een object benaderen als en slechts als de machtiging van het subject het label van het object domineert: het classificatieniveau van het subject is minstens zo hoog als dat van het object, het subject bezit alle voorbehouden die de behandelingsmarkeringen van het object vereisen, en de geautoriseerde vrijgaveset van het subject dekt alle vrijgavemarkeringen op het object. Elk van deze drie voorwaarden moet onafhankelijk worden geëvalueerd; twee van de drie doorstaan is een beleidsovertreding, geen gedeeltelijke toegangsverlening.

De meest geïmplementeerde verkeerde voorwaarde is vrijgave. Een correcte vrijgavevergelijking controleert dat de geautoriseerde vrijgaveset van het ontvangende systeem een superset is van de vrijgavemarkering van het object. Een systeem dat geautoriseerd is voor REL TO DEU GBR USA kan een object ontvangen dat is gemarkeerd als REL TO DEU GBR, omdat de geautoriseerde set alle gemarkeerde naties bevat. Een systeem dat geautoriseerd is voor REL TO GBR USA kan geen object ontvangen dat is gemarkeerd als REL TO DEU GBR, ook al verschijnt GBR in beide sets, omdat DEU niet in de geautoriseerde set van het ontvangende systeem zit. Een supersetcontrole implementeren in plaats van een doorsnedecontrole is de juiste logica; de doorsnedecontrole is de veelvoorkomende fout en produceert een systeem dat toegang verleent tot objecten die het niet gemachtigd is te ontvangen.

Aggregatie en labelescalatie

Aggregatie – het combineren van twee of meer gelabelde objecten tot een afgeleid product – is het moeilijkste probleem in een praktische STANAG 4774/4778-implementatie. Het afgeleide product moet een label dragen dat minstens zo restrictief is als de meest restrictieve invoer, over alle drie de labelcomponenten: classificatieniveau, behandelingsvoorbehouden en vrijgave.

Voor het classificatieniveau is de regel eenvoudig: de uitvoerclassificatie is het maximum van de invoerclassificaties. Een product afgeleid van RESTRICTED- en CONFIDENTIAL-invoeren is CONFIDENTIAL. Voor behandelingsvoorbehouden moet de uitvoer de unie van alle invoervoorbehouden bevatten: als één invoer ATOMAL draagt en een andere CRYPTO, moet de uitvoer beide dragen. Voor vrijgave moet de uitvoer de doorsnede van de invoervrijgavesets dragen: als één invoer vrijgegeven is aan DEU GBR USA en een andere aan GBR FRA, is de uitvoer alleen vrijgegeven aan GBR, omdat alleen GBR voor beide invoeren is geautoriseerd.

Deze aggregatielogica moet worden geïmplementeerd in elke component die afgeleide data produceert: fusie-engines, rapportgeneratoren, samenvattingsdiensten en elke analysepijplijn die invoeren uit meerdere bronnen combineert. De labelaggregatieberekening moet plaatsvinden voordat het uitvoerobject naar enige buffer of wachtrij wordt geschreven, niet als een naverwerkingsstap. Een uitvoer die zonder een correct label bestaat, zelfs voor korte tijd – voordat een naverwerkingsstap wordt geactiveerd – vertegenwoordigt een venster van beleidsnon-conformiteit dat een accreditator tijdens de ontwerpbeoordeling zal identificeren.

Labelbehoud bij coalitie-uitwisseling

Labelbehoud is de discipline van het waarborgen dat een STANAG 4774-label en zijn STANAG 4778-binding het volledige transportpad overleven van het oorspronkelijke systeem naar elke geautoriseerde ontvanger, inclusief door middleware, berichtenbrokers, federatiegateways en formaatvertaalcomponenten die mogelijk niet labelbewust zijn.

In een Federated Mission Network (FMN)-conforme uitwisselingsinfrastructuur is labelbehoud in het profiel ingebouwd: de FMN-serviceslaag is verplicht STANAG 4774-labels in berichtenenveloppen te dragen en bindingen bij ingestie te verifiëren. In de praktijk bevatten veel uitgerolde systemen componenten die dateren van vóór FMN-conformiteit of die zonder labelbewustzijn zijn geïntegreerd – verouderde berichtrelays, niet-conforme CoT-routers, databasemiddleware die metadata bij invoegen strijkt. Elke dergelijke component vertegenwoordigt een potentieel labelafvalpunt dat in het systeemontwerp moet worden geïdentificeerd en gemitigeerd.

De standaardmitigatie voor labelafvalrisico is om assertiebinding te gebruiken in plaats van encapsulatiebinding voor data die niet-vertrouwde infrastructuur passeert. Omdat de assertie deel uitmaakt van het payloadlichaam in plaats van een transportheader, overleeft ze transport door componenten die berichtheaders strijken of herschrijven. Aan de ontvangende kant bevestigt de assertiebindingverificatie dat het label authentiek en intact is, zelfs als de transportmetadata onderweg is gewijzigd.

Voor systemen die breder moeten aansluiten bij NATO-interoperabiliteitsstandaarden, moet labelbehoudtesten worden geïntegreerd in het CWIX-interoperabiliteitstestplan als een eersteklas testdoelstelling, niet als een toevoeging in een laat stadium. Een systeem dat alle functionele interoperabiliteitstests doorstaat maar onderweg stilzwijgend labels weglaat, zal de beveiligingsaccreditatiebeoordeling niet doorstaan, zelfs als het nooit een enkele functionele test faalt. De labelbehoudtestsuite moet objecten met bekende labels bij elk invoerpunt injecteren, objecten bij elk uitvoerpunt opvangen en inspecteren, en verifiëren dat zowel de labelinhoud als de bindingshandtekening identiek zijn tussen injectie en ontvangst.