Arhitectura soluțiilor cross-domain pentru rețele militare clasificate

Atunci când un sistem informatic militar trebuie să transfere date dintr-o rețea SECRET într-una NECLASIFICATĂ — sau dintr-un mediu compartimentat TOP SECRET într-o rețea a unui partener de coaliție — nu poate pur și simplu să ruteze traficul printr-un firewall standard. Bariera de clasificare nu este o problemă de control al accesului rezolvabilă prin politică de rețea. Este o problemă de integritate a conținutului: informațiile în sine pot purta marcaje, compartimente sau elemente de date încorporate care nu trebuie să părăsească enclava cu clasificare mai ridicată. Mecanismul proiectat pentru a rezolva această problemă este soluția cross-domain, iar proiectarea uneia corecte necesită înțelegerea arhitecturii barierei, a logicii de filtrare a conținutului, a standardelor de marcare și a unui proces de acreditare guvernamentală care durează de obicei mai mult decât aplicația pe care o protejează.

Acest articol explică modul în care barierele CDS funcționează din interior — modelul monitorului de referință care stă la baza fiecărui produs aprobat, logica regulilor de filtrare care implementează aplicarea marcajelor CAPCO, tehnicile de inspecție specifice protocolului pentru fluxuri XML și SMTP, și calea de acreditare NSA care determină dacă o implementare este autorizată legal să funcționeze. Este scris pentru ingineri și manageri de program care trebuie să înțeleagă constrângerile înainte de a se angaja la o arhitectură.

Ce este o soluție cross-domain și când este necesară

O soluție cross-domain este un produs sau sistem care aplică o politică de securitate atunci când datele se deplasează între rețele acreditate la niveluri de clasificare diferite sau cu controale de acces incompatibile. Termenul acoperă diodele de date hardware, barierele bidirecționale bazate pe software și combinații ale acestora. Ceea ce distinge un CDS de o poartă de rețea obișnuită este că operează la nivelul conținutului, nu la nivelul pachetelor — inspectează încărcăturile utile, citește marcajele de clasificare, aplică reguli de filtrare structurate și ia o decizie de permitere sau respingere pentru fiecare element de date în mod individual.

Un CDS este obligatoriu ori de câte ori ambele condiții sunt adevărate: rețeaua sursă deține informații la un nivel de clasificare mai ridicat decât cel pe care rețeaua de destinație este acreditată să îl primească, iar cerința operațională este de a transfera unele — dar nu toate — dintre aceste informații în rețeaua inferioară. Dacă nimic nu ar trebui să treacă niciodată de la nivelul superior la cel inferior, izolarea fizică (un air gap) este mai ieftină și mai sigură. Dacă tot conținutul din rețeaua superioară poate fi transferat în cea inferioară, rețelele ar trebui să fie unificate sau rețeaua de destinație ar trebui re-acreditată. Cazul transferului selectiv este cel care necesită un CDS.

Scenariile comune care impun un CDS în programele de apărare includ: transferul datelor de urmărire sanitizate dintr-o imagine operațională comună SECRET într-un afișaj al unui partener de coaliție NECLASIFICAT; publicarea produselor de informații care pot fi divulgate dintr-un mediu de analiză TS/SCI într-o rețea de diseminare SECRET; alimentarea cu date de senzori dintr-o platformă de colectare clasificată într-o arhivă neclasificată pentru retenție pe termen lung; și conectarea unei rețele naționale de informații la o rețea combinată acreditată NATO unde schemele de clasificare diferă. În fiecare caz, CDS-ul este mecanismul de aplicare a frontierelor — iar acreditarea sa este cea care oferă autorității conectoare încrederea că frontiera este aplicată corect.

Alternativa la un CDS în unele scenarii limitate este revizuirea manuală: un revizor uman citește documentul, determină că poate fi eliberat și retastează sau redactează conținutul în rețeaua inferioară. Aceasta este soluția cross-domain originală și rămâne în uz pentru transferuri cu volum redus și sensibilitate ridicată, unde filtrarea automată nu poate fi de încredere pentru a detecta tot conținutul sensibil. Produsele CDS automate sunt adecvate numai atunci când conținutul este suficient de structurat (XML marcat, SMTP cu anteturi de clasificare, formate de mesaje bine definite) încât un filtru poate aplica în mod fiabil politica fără judecata umană pentru fiecare transfer. Textul liber nestructurat — evaluări narative, rapoarte analitice, estimări ale comandantului — necesită adesea în continuare revizuire umană înainte de eliberare, chiar și atunci când o barieră CDS este prezentă pentru transferul tehnic.

Pentru programele care trebuie să abordeze nu doar mecanismul de transfer, ci și postura de securitate mai largă a mediului clasificat, arhitectura zero trust pentru software de apărare oferă cadrul de control al accesului în care se integrează un CDS.

Arhitecturi de bariere CDS

Patru tipare arhitecturale acoperă majoritatea implementărilor CDS. Fiecare face compromisuri între asigurarea securității, complexitatea operațională și capabilitate.

Diodă de date hardware. Un dispozitiv fizic care utilizează izolarea optică sau electrică pentru a garanta fluxul de date unidirecțional la nivel hardware. Electronii — și prin extensie, semnalele — nu pot circula în direcția blocată. O diodă între o rețea clasificată și una neclasificată garantează că, chiar dacă software-ul din partea inferioară este complet compromis, niciun semnal de la partea inferioară nu poate ajunge la cea superioară. Limitarea este strictă: protocolul de aplicație trebuie să tolereze fluxul unidirecțional. Mecanismul de confirmare al TCP se defectează peste o diodă; streaming-ul UDP, syslog și replicarea fișierelor prin protocoale personalizate funcționează. Diodele sunt adecvate pentru exporturi în vrac unidirecționale — streaming de senzori, replicare de jurnale, distribuție video — unde partea superioară nu are niciodată nevoie de confirmare a livrării.

Barieră bidirecțională cu procese proxy separate. Cea mai comună arhitectură pentru aplicații care necesită protocoale de cerere-răspuns. Bariera rulează un proces proxy pe partea superioară și un proces proxy pe partea inferioară, fără spațiu de adrese partajat, sistem de fișiere partajat sau comunicare directă între procese. Singura cale de la superior la inferior — și de la inferior la superior — trece prin kernelul barierei, care aplică politica de securitate pentru fiecare transfer. Aplicația din partea superioară se conectează la proxy-ul din partea superioară; aplicația din partea inferioară se conectează la proxy-ul din partea inferioară. Din perspectiva rețelei, fiecare parte vede doar propriul proxy. Kernelul barierei este monitorul de referință — o componentă mică, formal specificată, evaluată independent, a cărei singură funcție este să aplice politica de transfer.

Barieră cu filtru de conținut. O barieră al cărei mecanism principal de aplicare este inspecția conținutului — parsarea încărcăturii utile, extragerea marcajelor de clasificare, potrivirea cu regulile de filtrare și fie trecerea, respingerea sau sanitizarea conținutului înainte de redirecționare. Barierele cu filtru de conținut implementează vocabularul de marcare CAPCO ca limbaj al politicii. Sunt adecvate atunci când datele transferate sunt structurate și bine marcate, iar politica necesită trecere selectivă, nu blocare totală. Majoritatea barierelor bidirecționale moderne includ un filtru de conținut ca primă etapă după separarea bidirecțională.

Modelul monitorului de referință. Principiul fundamental de securitate pe care toate cele patru arhitecturi îl implementează. Un monitor de referință este o componentă care: mediază fiecare cerere de acces între un subiect (expeditorul) și un obiect (elementul de date transferat); este întotdeauna invocat (niciun transfer nu îl ocolește); este rezistent la modificări (nu poate fi modificat sau dezactivat de niciuna dintre părți); și este suficient de mic pentru a putea fi verificat formal. În termeni CDS, monitorul de referință este kernelul barierei — iar proprietățile sale de rezistență la modificări și de mediere completă sunt cele pe care evaluatorii le verifică în timpul procesului de acreditare. Un produs CDS care permite transferuri să ocolească kernelul barierei în orice condiție — mod de întreținere, rezervă la sarcină mare, stare de eroare — nu îndeplinește cerința monitorului de referință și nu poate fi acreditat pentru frontierele rețelelor clasificate.

Diagrama de mai jos prezintă arhitectura barierei bidirecționale cu procese proxy separate:

  ┌──────────────────────┐          ┌──────────────────────┐
  │  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

Filtrarea bazată pe conținut: ce inspectează barierele

Filtrarea bazată pe conținut este mecanismul care oferă barierelor CDS capacitatea de trecere selectivă. În loc să blocheze totul sau să lase totul să treacă, o barieră cu filtru de conținut citește datele, extrage câmpurile relevante pentru securitate, aplică regulile de politică și ia o decizie de permitere/respingere/sanitizare per mesaj.

Parsarea marcajelor CAPCO. Baza filtrării conținutului în sistemele clasificate din SUA este standardul de marcare CAPCO, care definește un vocabular controlat de jetoane care apar în bannere de clasificare, marcaje de porțiuni și câmpuri de metadate structurate. Parserul CAPCO al unei bariere citește elementul de metadate de clasificare din fiecare mesaj primit și extrage jetoanele componente. Pentru un mesaj marcat SECRET//SI//REL TO USA,GBR, parserul produce: nivel de clasificare = SECRET; compartiment SCI = SI; control de diseminare = REL TO; disponibilitate = USA, GBR. Fiecare jeton este apoi verificat față de matricea de politici pentru rețeaua de destinație. Dacă destinația nu este acreditată pentru compartimentul SI, transferul este respins. Dacă destinația este acreditată pentru conținut REL TO GBR, transferul este permis — dar filtrul verifică în continuare dacă vreun alt câmp din corpul mesajului poartă un marcaj mai ridicat decât cel afirmat de marcajul la nivel de document.

Aplicarea compartimentelor sensibile. Aplicarea compartimentelor SCI necesită ca bariera să recunoască setul complet de jetoane de compartiment definit în ghidul de clasificare guvernant. Cele mai comune compartimente în sistemele din SUA sunt SI (Signals Intelligence), TK (Talent Keyhole, imagerie din spațiu), HCS (Humint Control System) și G (Gamma, un sub-compartiment al SI). Fiecare trebuie verificat individual față de acreditarea de compartiment a enclavei de destinație. O rețea de destinație acreditată pentru SI dar nu pentru TK nu trebuie să primească mesaje care poartă marcajul TK — chiar dacă clasificarea la nivel de document se află în intervalul permis.

Aplicarea marcajelor de porțiuni. Un document clasificat conține adesea paragrafe, secțiuni sau elemente de date cu niveluri de sensibilitate diferite. CAPCO impune ca fiecare porțiune să poarte propriul marcaj. O barieră care aplică marcajele de porțiuni trebuie să parseze nu doar bannerul la nivel de document, ci și fiecare etichetă (S//SI) sau (U//FOUO) la nivel de paragraf și să ia o decizie de politică separată pentru fiecare. Sanitizarea — eliminarea porțiunilor care nu trec de politică în timp ce se redirecționează restul — este mai complexă decât respingerea totală, dar este esențială din punct de vedere operațional pentru documentele cu conținut mixt.

Eliminarea atașamentelor. Mesajele SMTP și încărcăturile utile HTTP multipart transportă frecvent atașamente pe care bariera trebuie să le inspecteze independent de corpul mesajului. Fiecare parte atașament este parsată separat: tipul de conținut MIME determină parserul de utilizat, atașamentul este inspectat pentru metadate de clasificare încorporate (proprietăți document PDF, proprietăți personalizate Word, câmpuri EXIF imagine), iar politica este aplicată fiecărui atașament individual. Atașamentele în formate pe care bariera nu le poate parsa — formate binare nerecunoscute, arhive criptate — sunt respinse implicit, fără a fi vreodată trecute neinspectate.

Interacțiunea dintre aplicarea marcajelor CAPCO la nivelul CDS și modelul de date subiacent este descrisă în detaliu în articolul despre fuziunea datelor militare explicată, care acoperă modul în care clasificarea se propagă printr-o bază de date de urmărire multi-sursă. Pentru mediile NATO, legătura dintre marcajele echivalente CAPCO și standardul NATO de etichetare a confidențialității este acoperită în referința implementarea etichetării STANAG 4774/4778.

Formate de date și protocoale suportate de produsele CDS moderne

O barieră CDS este utilă numai în măsura în care suportă formatele pe care aplicația dumneavoastră le folosește efectiv. Parserul barierei trebuie să înțeleagă formatul suficient de bine pentru a extrage câmpurile de clasificare și a inspecta conținutul — inspecția superficială a antetelor nu este suficientă.

Format / Protocol	Locul câmpului de clasificare	Utilizare militară tipică	Complexitatea inspecției barierei
XML (IC-ISM / UCORE)	Atribute de spațiu de nume pe elementul rădăcină și fiecare porțiune clasificată	Mesaje de urmărire, produse de informații, rapoarte NiemXML	Ridicată — evaluare XPath completă conștientă de schemă
JSON cu metadate ISM	Câmp ism:classification de nivel superior sau obiecte de marcare încorporate	Sarcini utile API REST, microservicii C2 moderne	Medie — dependent de schemă, necesită inspecție recursivă
SMTP / MIME	Antet X-Classification: + banner corp + marcaj per atașament	Diseminarea produselor de informații, distribuția SITREP	Ridicată — parsare MIME recursivă, detectarea tipului atașamentului
HTTP/HTTPS (REST)	Antet personalizat + corp sarcină utilă	Apeluri API între servicii clasificate și neclasificate	Medie — terminare TLS + re-inspecție conținut necesară
MTF (Message Text Format)	Câmpul CLASSIFICATION în setul antet mesaj	Mesagerie militară NATO/moștenire, USMTF, ADatP-3	Medie — format cu câmpuri fixe, parsare bine specificată
PDF / documente Office	Proprietăți document personalizate, metadate XMP, text banner în corp	Produse de informații finale, ordine, planuri	Foarte ridicată — obiecte încorporate, macrocomenzi, eliminare metadate necesară
Video (RTP/RTSP)	Anteturi metadate flux (dacă există); text suprapus pe cadru	Downlink video ISR, fluxuri UAV	Foarte ridicată — necesită de obicei diodă + proxy video dedicat

Pentru mesajele militare bazate pe XML, regulile de filtrare sunt exprimate în XPath. O regulă care respinge orice mesaj care poartă un jeton de compartiment TK arată astfel:

<!-- 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>

Aprobarea NSA și procesul de acreditare

O barieră CDS care protejează o conexiune între două rețele clasificate ale guvernului SUA trebuie aprobată de NSA/CSS înainte de a funcționa. Nu există nicio cale de derogare pentru urgența operațională — implementarea unui CDS neaprobat este un incident de securitate raportabil. Înțelegerea procesului de acreditare și a calendarului său este o condiție prealabilă pentru orice program care include o frontieră clasificată.

Lista de produse evaluate NSA/CSS (EPL). NSA evaluează produsele CDS și publică rezultatele pe Lista de Produse Evaluate. O listare EPL certifică că o versiune specifică a produsului, într-o configurație specifică, implementează corect modelul monitorului de referință și rezistă claselor de atacuri pe care evaluatorii le-au testat. Listarea EPL specifică modelul exact de hardware și versiunea firmware, versiunea software și opțiunile de configurare care au fost evaluate. Devierea de la configurația evaluată — chiar și aplicarea unui patch de sistem de operare care nu a făcut parte din linia de bază evaluată — necesită re-evaluare sau o autorizație de deviere. Programele trebuie să urmărească la ce versiune EPL corespunde bariera implementată și să mențină această corespondență pe durata de viață operațională a barierei.

Inițiativa Raise the Bar (RTB). În urma unei serii de incidente în care barierele proiectate inadecvat au permis trecerea necorespunzătoare a datelor, NSA/CSS a emis cerințele Raise the Bar pentru produsele CDS. RTB impune separarea hardware a căilor de procesare de pe partea superioară și inferioară, documentarea formală a fiecărei reguli de filtrare și a raționamentului de securitate al acesteia, jurnale de audit semnate criptografic (astfel încât alterarea jurnalelor să fie detectabilă), verificarea independentă de către o terță parte a logicii barierei și o procedură definită de aplicare a patch-urilor care include re-verificarea după modificările relevante pentru securitate. Produsele conforme RTB sunt listate pe EPL cu o desemnare RTB explicită. Produsele non-RTB pot fi încă pe listele EPL mai vechi, dar nu mai pot fi nou aprobate pentru frontierele rețelelor clasificate ale guvernului SUA.

Lista de produse aprobate pentru capabilități unificate DISA (UC APL). Pentru programele DoD, listarea DISA UC APL este necesară pe lângă NSA EPL. Evaluarea UC APL se concentrează pe interoperabilitatea cu infrastructura de rețea DoD și conformitatea cu ghidurile tehnice de implementare a securității DoD (STIG). Un produs poate fi pe NSA EPL dar nu pe UC APL, sau invers — ambele sunt necesare pentru majoritatea implementărilor de rețele clasificate DoD. Verificați ambele liste când evaluați produsele CDS candidate.

Autorizație de funcționare (ATO) specifică locației. Chiar și cu un produs EPL/UC APL, fiecare implementare necesită un ATO specific locației care acoperă: configurația hardware și software specifică implementată; topologia de rețea și securitatea fizică a instalației barierei; setul de reguli de filtrare și relația acestuia cu politicile de clasificare ale rețelelor conectate; procedurile de monitorizare continuă; și procesul de gestionare a patch-urilor și controlul modificărilor de configurație. Pachetul ATO este revizuit de Ofițerul Autorizator (AO) pentru sistemele de pe ambele părți ale frontierei. Pentru conexiunile între rețele deținute de agenții diferite, este necesară o înțelegere bilaterală între cei doi AO înainte ca ATO să poată fi acordat. Calendar: 6 până la 18 luni pentru un produs deja pe EPL într-o configurație necomplicată.

Modele de integrare pentru fluxuri C2 și ISR

Integrarea unei bariere CDS într-un flux C2 sau ISR operațional necesită reflectarea atât asupra arhitecturii fluxului de date, cât și asupra constrângerilor de performanță pe care bariera le introduce.

Modelul COP de la SECRET la NECLASIFICAT. Cea mai comună integrare este un flux de publicare-abonare în care un broker SECRET alimentează actualizări de urmărire clasificate, iar o barieră CDS se abonează la brokerul SECRET, inspectează fiecare actualizare și re-publică actualizări sanitizate la un broker NECLASIFICAT la care se abonează partenerii de coaliție sau consumatorii de la nivel inferior. Bariera în această arhitectură acționează ca un abonat de filtrare pe partea superioară și ca un producător de publicare pe partea inferioară — niciodată ca un router de trecere. Aceasta asigură că nu există nicio conexiune directă între cele două brokere.

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           │
                                   └───────────────────┘

Planificarea latenței. O barieră CDS introduce latență de procesare pentru fiecare mesaj pe care îl inspectează. Pentru mesajele mici de actualizare de urmărire XML (sub 4 KB), barierele comerciale adaugă de obicei 50 până la 200 de milisecunde de latență de inspecție. Pentru mesajele mari care conțin atașamente binare sau care necesită sanitizarea mai multor porțiuni, latența poate ajunge la 500 de milisecunde până la 2 secunde. Pentru documentele PDF sau mesajele MIME complexe, procesarea poate dura câteva secunde. Aceasta trebuie luată în considerare în rata de reîmprospătare COP și în SLA pentru diseminarea produselor de informații. Evaluările de debit ale barierei sunt publicate în documentația EPL — verificați că debitul evaluat la dimensiunea și complexitatea mesajului aplicației dumneavoastră este suficient înainte de a vă angaja la un produs.

Căile de date ale senzorilor ISR. Pentru senzorii ISR care operează la nivel clasificat și trebuie să alimenteze cu date consumatorii cu clasificare inferioară, calea datelor implică de obicei o etapă de procesare clasificată care produce produse derivate sanitizate, care traversează ulterior frontiera CDS. Datele brute ale senzorilor (imagerie de înaltă fidelitate, interceptări brute SIGINT) nu ar trebui niciodată proiectate să curgă printr-o barieră CDS — clasificarea ISR brut este de obicei mult mai mare decât ceea ce poate primi partea inferioară, iar filtrarea conținutului datelor brute ale senzorilor este nesigură. Modelul de proiectare este: procesați la nivelul de clasificare al datelor, produceți produse derivate lipsite de indicatorii sursei sensibile și transferați numai produsele derivate prin barieră.

Securitatea operațională pentru implementările CDS

O barieră CDS este o țintă de mare valoare tocmai pentru că compromiterea ei este echivalentă cu eliminarea frontierei clasificate. Controalele de securitate operațională din jurul unei bariere implementate trebuie să fie proporționale cu acel risc.

Securitate fizică. Hardware-ul barierei trebuie instalat într-o locație fizic securizată — o cameră de echipamente încuiată cu intrare controlată și înregistrarea vizitatorilor. Atât conexiunea de rețea de pe partea superioară, cât și hardware-ul barierei trebuie să se afle în perimetrul de securitate fizică al rețelei cu clasificare mai ridicată. Manipularea barierei — inserarea unui dispozitiv cu canal covert pe conexiunea de rețea, înlocuirea firmware-ului — este o amenințare reală pe care controalele fizice o abordează.

Management out-of-band. Interfața de management a barierei trebuie să fie pe o rețea fizică dedicată, separată atât de rețelele operaționale de pe partea superioară, cât și de cele de pe partea inferioară. Traficul de management — modificări de configurație, actualizări software, recuperarea jurnalelor — care tranzitează oricare dintre rețelele operaționale creează un vector de canal covert. Stațiile de lucru de management ar trebui să fie situate în interiorul perimetrului de securitate al clasificării mai ridicate și acreditate corespunzător.

Integritatea jurnalelor și detectarea alterărilor. Jurnalele de audit CDS sunt dovada principală că frontiera a fost aplicată corect. Jurnalele trebuie protejate criptografic — fiecare înregistrare jurnal include un HMAC peste conținutul înregistrării și hash-ul înregistrării anterioare (un lanț hash). Aceasta face ca inserarea, ștergerea sau modificarea oricărei înregistrări să fie detectabilă la verificarea lanțului. Jurnalele trebuie scrise pe un sistem pe care nici rețeaua de pe partea superioară, nici cea de pe partea inferioară nu poate scrie sau șterge — un server de jurnale dedicat accesibil numai administratorului de securitate prin rețeaua de management out-of-band. Revizuirea jurnalelor trebuie să fie o activitate activă, zilnică: anomaliile de respingere, volumele neobișnuite de mesaje sau încălcările repetate ale politicilor de către același expeditor sunt indicatori de sondare sau atac.

Controlul modificărilor de configurație. Fiecare modificare a setului de reguli de filtrare — adăugarea unei reguli, modificarea unei condiții, eliminarea unei reguli — trebuie să treacă printr-un proces documentat de modificare care include: o cerere de modificare scrisă cu raționament de securitate; revizuire independentă de către un al doilea ofițer de securitate; executarea testelor față de eșantionul de trafic reprezentativ; și auditul post-modificare al primelor 24 de ore de decizii de producție pentru a verifica că regula se comportă conform intenției. Modificările care nu au trecut prin acest proces nu trebuie aplicate configurațiilor de bariere de producție. O înghețare permanentă a modificărilor ar trebui să se aplice în perioadele operaționale de tempo ridicat, când o configurare greșită a barierei ar fi cel mai dăunătoare.

Gestionarea patch-urilor. Patch-urile de securitate pentru sistemul de operare al barierei și aplicație necesită o gestionare atentă. Aplicarea unui patch care nu face parte din configurația evaluată poate invalida ATO — și neaplicarea patch-urilor de securitate creează vulnerabilități exploatabile. Procedura este: primiți și evaluați patch-ul; determinați dacă afectează linia de bază a configurației evaluate; dacă da, consultați-vă cu furnizorul EPL și obțineți o autorizație de deviere de evaluare sau programați o re-evaluare; testați patch-ul într-un mediu de barieră izolat care oglindește producția; aplicați în producție în timpul unei ferestre de întreținere programate cu o scurtă întrerupere a serviciului; verificați că comportamentul regulilor de filtrare este neschimbat după aplicarea patch-ului.

Testare red-team. Testele anuale de penetrare a instalației CDS ar trebui să fie o cerință în planul de securitate. Domeniul de aplicare al testului ar trebui să includă: tentative de extragere a conținutului clasificat prin interfața de pe partea inferioară folosind atacuri de injecție de format și codare; tentative de exploatare a canalelor covert prin canale de temporizare, stocare și la nivel de protocol; tentative de acces la interfața de management a barierei din rețelele operaționale; și scenarii de tentative de manipulare fizică. Constatările din testarea red-team alimentează direct raportul de monitorizare continuă și pot declanșa modificări de configurație sau re-evaluare.