Penetratietesten is een standaardelement van elk serieus beveiligingsprogramma. In commerciële omgevingen is het een relatief goed begrepen oefening: een extern team krijgt een scope, een reglement van betrokkenheid en een tijdsvenster om uitbuitbare kwetsbaarheden te vinden voordat echte aanvallers dat doen. Het resultaat is een rapport; het hersteltraject is een projectmanagementprobleem.
In defensieomgevingen is geen van die kaders volledig van toepassing. De juridische gezagsstructuur is anders, het dreigingsmodel is anders, de beperkingen op wat testers mogen aanraken zijn anders, en het traject van bevinding tot herstel loopt door een formeel accreditatieproces dat geen commercieel equivalent heeft. Organisaties die commerciële pentestconventies toepassen op defensiesystemen — of die commerciële pentestbedrijven inhuren zonder defensie-ervaring — produceren routinematig beoordelingen die de meest relevante risico's missen, buiten juridisch verdedigbare grenzen opereren, of bevindingen genereren waarop het programmabureau niet kan handelen.
Dit artikel onderzoekt wat defensie-penetratietesten werkelijk anders maakt, wat dat operationeel betekent en hoe een beoordeling te structureren die resultaten oplevert die een militair programma kan gebruiken.
Juridische bevoegdheid: het fundament zonder commercieel equivalent
Bij commerciële opdrachten bestaat de juridische basis voor een pentest uit een contract en een reglement van betrokkenheid ondertekend door iemand met bevoegdheid om testen van de doelsystemen te autoriseren. Die bevoegdheid is doorgaans eenvoudig — het bedrijf bezit de systemen en de CISO of CTO kan toestemming verlenen.
In defensieomgevingen is de bevoegdheidsketen complexer en zijn de gevolgen van fouten aanzienlijk groter. Overheidsinformatiesystemen werken onder een Authorization to Operate (ATO) verleend door een Authorizing Official (AO). De ATO definieert de beveiligingshouding die het systeem bevoegd is te handhaven. Penetratietesten wijzigt die houding, ten minste tijdelijk, en moet expliciet worden geautoriseerd door de AO — niet alleen door de programmamanager of de ISSO van het systeem.
Voor US DoD-systemen zijn de Computer Fraud and Abuse Act (CFAA) en de UCMJ van toepassing. Een persoon die toegang krijgt tot een overheidsinformatiesysteem zonder juiste autorisatie — zelfs met goede bedoelingen, zelfs als onderdeel van een ogenschijnlijk geautoriseerde test — heeft een federaal misdrijf gepleegd. Het autorisatiedocument is geen formaliteit: het is het instrument dat wat anders ongeautoriseerde toegang zou zijn omzet in rechtmatig testen. Elke tester die in de autorisatie staat vermeld, moet individueel worden geïdentificeerd. De reikwijdte van geautoriseerd testen moet specifiek zijn. Activiteiten buiten die reikwijdte zijn niet beschermd.
Vereiste voor juridische bevoegdheid: Begin nooit met een defensie-pentest zonder een ondertekend, specifiek autorisatiedocument van de Authorizing Official van het systeem. Generieke "beveiligingsbeoordelings"-goedkeuringen van programmamanagers of prime contractors bieden geen CFAA-bescherming. De autorisatie moet testers bij naam identificeren, de systemen in scope specificeren, het testvenster definiëren en de toegestane methoden opsommen.
Machtigingsvereisten voegen een extra laag toe. Het testen van een geclassificeerd systeem vereist dat testers geldige machtigingen bezitten op het juiste classificatieniveau. De testorganisatie moet een facility clearance (FCL) op dat niveau bezitten. Het introduceren van niet-gemachtigde medewerkers — zelfs in ondersteunende rollen — in een geclassificeerde testomgeving is een beveiligingsovertreding, ongeacht wat zij feitelijk zien of aanraken.
ITAR (International Traffic in Arms Regulations) introduceert verdere beperkingen voor programma's met gecontroleerde defensieartikelen. Informatie over kwetsbaarheden in ITAR-gecontroleerde systemen kan zelf onderhevig zijn aan exportcontrolebeperkingen, waardoor wordt beperkt wat kan worden gedocumenteerd, verzonden of gedeeld over internationale grenzen heen — ook binnen multinationale geallieerde programma's. Testbedrijven die werken onder internationale onderaannemingsregelingen moeten dit expliciet meewegen.
Dreigingsactoremulatie: natiestaat-TTPs, geen generieke exploits
Commercieel penetratietesten richt zich vaak op het vinden van uitbuitbare kwetsbaarheden — de meest voorkomende, meest direct beschikbare, hoogst CVSS-gescoorde problemen in het aanvalsoppervlak van het doel. Voor een bedrijfsnetwerk is dit een redelijke aanpak: een opportunistische aanvaller benut het gemakkelijkste beschikbare pad.
Defensiesystemen worden geconfronteerd met een fundamenteel andere dreigingspopulatie. De primaire tegenstanders voor hoogwaardige defensiedoelen zijn natiestaat-actoren met aanzienlijke middelen, geavanceerde capaciteiten en lange tijdshorizonten. Ze worden niet tegengehouden door het patchen van het CVSS-10 OpenSSL-probleem als ze kunnen draaien via een vertrouwde supply chain-partner, een legacy ingebedde component of een misconfiguratie van een cross-domain solution.
Effectief defensie-penetratietesten gebruikt adversary emulation: het testteam repliceert de tactieken, technieken en procedures (TTPs) van specifieke dreigingsactorengroepen die relevant zijn voor het dreigingsmodel van het programma. Het MITRE ATT&CK-framework biedt een gestructureerde taxonomie hiervoor, met Enterprise- en ICS-matrices die de technieken omvatten die het meest worden gebruikt door advanced persistent threat-groepen.
Voor defensiesystemen omvatten de relevante dreigingsactoren doorgaans:
- APT28 (Fancy Bear / GRU Unit 26165) — Russische militaire inlichtingen, bekend om spearphishing, credential harvesting en persistentie via misbruik van legitieme tools. Tactieken die relevant zijn voor defensiesoftware omvatten het targeten van ontwikkelaarsworkstations en build-pipelines om kwaadaardige code stroomopwaarts van de implementatie te injecteren.
- Lazarus Group (DPRK) — Noord-Koreaanse staatsfactor met een trackrecord van het targeten van defensieaannemers en luchtvaartbedrijven, met name via watering hole-aanvallen en bewapende sollicitatiemiddelen gericht op gemachtigde medewerkers.
- Volt Typhoon (PRC) — Chinese staatsfactor gericht op living-off-the-land-technieken om persistente, laaggeluids toegang te bereiken tot kritieke infrastructuur en defensienetwerken. Opmerkelijk voor het vermijden van aangepaste malware ten gunste van ingebouwde systeemtools om detectie te ontwijken.
Het testplan moet specificeren welk tegenstandersprofiel wordt geëmuleerd en waarom, op basis van de dreigingsbeoordeling van het programma. Een test die de living-off-the-land-aanpak van Volt Typhoon emuleert ziet er heel anders uit dan een test die de credential-gerichte operaties van APT28 emuleert — en beide zien er anders uit dan een test gericht op insider-dreigingscenario's of supply chain-integriteit.
Noot over tegenstanderselectie: Het dreigingsactorensprofiel moet worden gestuurd door de inlichtingsinformatie dreigingsbeoordeling van het programma, niet door testervoorkeur of generieke "geavanceerde" labels. Voor programma's met specifieke geografische dreigingsprofielen of bekende doelstellingsgeschiedenis, moet de ISSO het testteam briefen over actuele dreigingsrapportage voordat de opdracht begint.
Scopebeheer: beperkingen voor geen downtime en geïsoleerde testomgevingen
Commerciële pentestscopebeperkingen gaan primair over het beperken van aansprakelijkheid en het richten van inspanningen. Defensiescopebeperkingen hebben extra dimensies die fundamenteel bepalen hoe een test kan worden uitgevoerd.
Veel defensiesystemen kunnen geen downtime accepteren tijdens testen. Command and control-systemen, communicatie-infrastructuur en realtime sensorfusieplatforms kunnen operationeel actief zijn tijdens een testvenster. Een exploitatiepoging die een serviceonderbreking veroorzaakt — zelfs een korte — kan operationele gevolgen hebben die geen contractuele vrijwaring kan aanpakken. De standaard commerciële aanpak van testen tegen productiesystemen met een "stop als je iets onstabiel ziet"-regel is niet acceptabel voor deze omgevingen.
De praktische consequentie is dat veel defensie-pentests worden uitgevoerd in toegewijde testomgevingen: geïsoleerde netwerksegmenten, stagingomgevingen of lab-replica's die de productie zo nauwkeurig mogelijk weerspiegelen. De getrouwheid van de testomgeving is van enorm belang. Een testomgeving die andere firmwareversies gebruikt, productie-integraties mist of werkt met versoepelde toegangscontroles vergeleken met productie, zal bevindingen produceren die de werkelijke risicohouding van het operationele systeem niet weerspiegelen. Testomgevingsgetrouwheid is een investering waartoe het programmabureau zich moet verbinden — het is niet het probleem van het testteam om op te lossen.
Scopeovertredingen worden in defensieomgevingen met grotere ernst behandeld dan in commerciële omgevingen. Per ongeluk een systeem buiten de geautoriseerde scope aanraken is geen kleine procedurele kwestie — het kan ongeautoriseerde toegang tot een overheidsinformatiesysteem vormen. Testers moeten gedurende de gehele opdracht een gedetailleerd activiteitenlogboek bijhouden, waarbij ze significante acties in quasi-realtime documenteren, zodat eventuele scopevragen die tijdens of na de test rijzen, kunnen worden opgelost met bewijs in plaats van herinneringen.
Defensiespecifieke kwetsbaarheidsklassen
Naast de procedurele verschillen presenteren defensiesystemen kwetsbaarheidsklassen die ondervertegenwoordigd zijn in commerciële pentestmethodologieën.
Legacy ingebedde systemen. Defensieplatforms draaien routinematig software op hardware die 10–20 jaar oud is, met ingebedde firmware die niet via normale software-updatemechanismen kan worden gepatcht. Kwetsbaarheden in deze componenten kunnen bekend zijn maar onbehandelbaar binnen de levenscyclus van het systeem — de pentest-bevinding wordt een permanente POAM-invoer met een deviatieaanvraag in plaats van een herstelticket. Testers moeten begrijpen wat "bevinding" in deze context betekent: de waarde ligt in het documenteren en kwantificeren van het risico, niet noodzakelijkerwijs in het aandrijven van onmiddellijk herstel.
Cross-domain solutions. Systemen die gegevens op meerdere classificatieniveaus verwerken, gebruiken cross-domain solutions (CDS) om gegevens tussen beveiligingsdomeinen te verplaatsen. Dit zijn hoogwaardige doelen: een CDS die kan worden gemanipuleerd om informatie in de verkeerde richting door te geven, verslaat de gehele gegevensverwerkingsarchitectuur. CDS-testen vereist gespecialiseerde expertise en specifieke autorisatie — deze componenten worden vaak behandeld als afzonderlijke scopes binnen een bredere programmabeoordeling.
Supply chain-integriteit. De meest significante software supply chain-aanvallen van de afgelopen jaren (SolarWinds, XZ Utils) hebben build-pipelines en dependency injection getarget in plaats van draaiende systemen. Defensieprogramma's zijn hoogwaardige doelen voor deze aanvalsklasse. Penetratietesten moet de beoordeling van de buildomgeving omvatten: kan een aanvaller met toegang tot een ontwikkelaarsworkstation kwaadaardige code introduceren die een productie-build overleeft? Kan een gecompromitteerde afhankelijkheid worden geïntroduceerd zonder bestaande controles te activeren?
Certificaat- en sleutelbeheer. Defensiesystemen zijn sterk afhankelijk van PKI-infrastructuur voor authenticatie en communicatiebeveiliging. Onjuist geconfigureerde certificaatvalidatie, te brede vertrouwensankerconfiguraties en slecht sleutellevenscyclusbeheer zijn consistent hoge-ernst-bevindingen. In tegenstelling tot applicatiekwetsbaarheden zijn deze vaak onzichtbaar voor geautomatiseerd scannen en vereisen handmatige verificatie van de PKI-architectuur ten opzichte van het beveiligingsontwerp van het systeem.
De levenscyclus van bevindingen: POAM, ATO-impact en deviatieaanvragen
Bij commerciële opdrachten gaat het pentestrapport naar de CISO, worden bevindingen getriaged, wordt een subset hersteld en verouderen de rest in een tracker tot de volgende beoordeling. Het proces wordt gestuurd door risicobereidheid en engineeringcapaciteit.
In defensieomgevingen worden bevindingen ingevoerd in een formele accreditatielevenscyclus met juridische en contractuele implicaties. Het sleutelbegrip is de Plan of Action and Milestones (POAM): een document dat elke bekende zwakte in het systeem bijhoudt waartegen een ATO is verleend of wordt gezocht. Elke bevinding van een pentest die niet onmiddellijk wordt hersteld, moet worden opgenomen in de POAM met een geplande hersteldatum, verantwoordelijke eigenaar en tijdelijke mitigatiemaatregel.
De POAM wordt beoordeeld door de Authorizing Official als voorwaarde voor ATO-onderhoud. Open items met hoge ernst zonder adequate tijdelijke mitigaties of realistische herstelschema's kunnen een ATO-opschorting triggeren — wat het systeem effectief offline haalt totdat de risicohouding wordt aangepakt. Voor een programmabureau is dit resultaat ernstig genoeg dat sommige programma's de reikwijdte van pentests uitstellen of beperken om te voorkomen dat bevindingen worden gegenereerd die een ATO-beoordeling kunnen triggeren. Dit is een risicobeheerfout: de kwetsbaarheden bestaan of ze nu worden gedocumenteerd of niet.
Voor bevindingen die niet kunnen worden hersteld — legacy-componenten zonder beschikbare patches, architecturale beperkingen die een volledig systeemherontwerp zouden vereisen — kan het programmabureau een deviatieaanvraag of een risicoaanvaarding indienen bij de AO. Dit is geen erkenning van falen; het is het formele mechanisme voor het werken met bekende residuele risico's onder expliciete autorisatie. Testers moeten dit proces begrijpen en bevindingen formuleren op manieren die de ISSO helpen verdedigbare POAM-invoeren en deviatieaanvragen op te stellen, niet alleen op manieren die CVSS-scores maximaliseren.
Rapportformulering voor defensieprogramma's: Defensie-pentestrapporten moeten voor elke bevinding bevatten: een classificatiemarkering, een ernstniveau afgestemd op de risicoaanvaardingscriteria van het programma, een beoordeling van uitbuitbaarheid gezien de werkelijke dreigingsactoren van het programma, en een aanbevolen POAM-dispositie. Rapporten geschreven in commercieel formaat — CVSS-scores, generiek hersteladvies, managementsamenvattingen gericht op niet-technisch leiderschap — vereisen aanzienlijke herwerking voordat de ISSO ze kan gebruiken.
Hoe u een defensie-pentest indeelt en autoriseert
De volgende stappen weerspiegelen de vereisten voor een verdedigbare, juridisch geautoriseerde penetratietest op een defensiesoftwaresysteem.
Stap 1: Juridische bevoegdheid en schriftelijke autorisatie vaststellen. Verkrijg een ondertekend testmachtigingsdocument van de AO van het systeem. Het document moet de testers bij naam vermelden, de systemen in scope specificeren, het testvenster definiëren en toegestane methoden opsommen. Dit is geen formaliteit — het is het instrument dat het testen rechtmatig maakt.
Stap 2: Machtiging en faciliteitsgeloofsbrieven verifiëren. Bevestig dat alle testers geldige machtigingen bezitten op het classificatieniveau van het doelsysteem, en dat de testorganisatie een FCL op het vereiste niveau bezit. Brief alle testers over de beveiligingsclassificatiegids van het programma voordat ze toegang krijgen tot een geclassificeerde omgeving.
Stap 3: Scope en testomgevingsgrenzen definiëren. Identificeer welke systemen, netwerken en interfaces in scope vallen. Waar operationele systemen geen downtime kunnen accepteren, richt een toegewijde testomgeving in. Documenteer expliciete uitsluitingen en brief testers over de juridische gevolgen van scopeovertredingen.
Stap 4: Testtools selecteren en screenen. Beoordeel ITAR-verplichtingen en programma-accreditatievereisten om te bepalen welke tools zijn toegestaan. Elimineer tools met componenten van buitenlandse herkomst, cloudgebaseerde licenties of uitgaande telemetrie. Documenteer de toolset in het testplan en dien in voor beoordeling door het programmabureau voordat de opdracht begint.
Stap 5: Dreigingsactoremulatie uitvoeren op basis van het dreigingsmodel van het programma. Selecteer het meest relevante tegenstandersprofiel voor het systeem. Gebruik MITRE ATT&CK voor ICS of Enterprise naar gelang van toepassing, afgestemd op de specifieke systeemarchitectuur en het missieprofiel. Vervang geen generiek "geavanceerd" testen door werkelijke adversary emulation.
Stap 6: Activiteiten en bevindingen documenteren met classificatiemarkeringen. Houd gedurende de gehele opdracht een gedetailleerd activiteitenlogboek bij. Alle bevindingen moeten passende classificatiemarkeringen en ernstniveaus dragen die zijn afgestemd op de risicoaanvaardingscriteria van het programma.
Stap 7: Bevindingen opnemen in de POAM en herstel bijhouden. Werk samen met de ISSO om alle openstaande bevindingen op te nemen in de POAM. Wijs hersteleigenaren, geplande data en tijdelijke mitigaties toe. Brief bevindingen met hoge ernst rechtstreeks aan de AO — laat kritieke kwetsbaarheden niet in een wachtrij zitten zonder expliciete risicoaanvaarding of actieve herstelmaatregelen.