Коли військова інформаційна система повинна передати дані із засекреченої мережі (SECRET) до незасекреченої (UNCLASSIFIED) — або з середовища TOP SECRET/SCI до мережі партнерів по коаліції — вона не може просто маршрутизувати трафік через стандартний міжмережевий екран. Бар'єр класифікації — це не проблема контролю доступу, яку можна вирішити мережевою політикою. Це проблема цілісності вмісту: сама інформація може містити маркування, відсіки або вбудовані елементи даних, які не повинні виходити за межі анклаву вищого рівня класифікації. Механізм, розроблений для вирішення цієї проблеми, — це рішення міжмережевого обміну, і його правильне проектування вимагає розуміння архітектури захисних шлюзів, логіки фільтрації вмісту, стандартів маркування та урядового процесу акредитації, який зазвичай займає більше часу, ніж сам додаток, який він захищає.

Ця стаття пояснює, як захисні шлюзи CDS працюють зсередини — модель монітора посилань (reference monitor), що лежить в основі кожного затвердженого продукту, логіка правил фільтрації, яка реалізує виконання маркування CAPCO, методи перевірки для конкретних протоколів — XML та SMTP — і шлях акредитації NSA, що визначає, чи є розгортання юридично уповноваженим до роботи. Стаття написана для інженерів і керівників програм, яким необхідно розуміти обмеження перед тим, як вони зобов'яжуться до певної архітектури.

Що таке рішення міжмережевого обміну і коли воно потрібне

Рішення міжмережевого обміну — це продукт або система, що виконує політику безпеки, коли дані переміщуються між мережами, акредитованими на різних рівнях класифікації або з несумісними засобами контролю доступу. Цей термін охоплює апаратні однонаправлені діоди даних, програмні двонаправлені шлюзи і їх комбінації. Те, що відрізняє CDS від звичайного мережевого шлюзу, — це робота на рівні вмісту, а не на рівні пакетів: він перевіряє корисне навантаження, зчитує маркування класифікації, застосовує структуровані правила фільтрації і приймає рішення «дозволити або відхилити» для кожного елемента даних окремо.

CDS є обов'язковим, коли одночасно виконуються дві умови: вихідна мережа містить інформацію на вищому рівні класифікації, ніж дозволено отримувати цільовій мережі, і операційна вимога полягає в передачі частини — але не всієї — цієї інформації до нижчої мережі. Якщо нічого ніколи не повинно переміщуватися з рівня high до low, фізична ізоляція (повітряний зазор) є дешевшою і безпечнішою. Якщо все на стороні high може переміщатися на сторону low, мережі слід об'єднати або перереєструвати цільову мережу. Саме у випадку вибіркової передачі необхідний CDS.

Поширені сценарії, що потребують CDS в оборонних програмах, включають: передачу знезараженого відображення позицій із засекреченої загальної оперативної картини (SECRET COP) на незасекречений дисплей партнера по коаліції; публікацію розсекречених розвідувальних продуктів із середовища аналізу TS/SCI до мережі розповсюдження SECRET; передачу даних сенсорів із засекреченої платформи збору до незасекреченого архіву для довгострокового зберігання; та підключення національної розвідувальної мережі до об'єднаної мережі, акредитованої НАТО, де схеми класифікації відрізняються. У кожному разі CDS є механізмом виконання граничних умов — і його акредитація дає підключному органу впевненість у тому, що межа дотримується правильно.

Альтернативою CDS в деяких обмежених сценаріях є ручна перевірка: рецензент людини читає документ, визначає, що він може бути оприлюднений, і передруковує або перероблює вміст у нижній мережі. Це оригінальне «рішення» міжмережевого обміну і воно залишається у використанні для передач малого обсягу з підвищеною чутливістю, де автоматизована фільтрація не може забезпечити виявлення всього чутливого вмісту. Автоматизовані CDS-продукти підходять лише тоді, коли вміст є достатньо структурованим (розмічений XML, SMTP із заголовками класифікації, чітко визначені формати повідомлень), щоб фільтр міг надійно виконувати політику без людського судження для кожної передачі. Неструктурований вільний текст — аналітичні оцінки, звіти, командирські оцінки ситуації — часто все ще вимагає перевірки людиною перед оприлюдненням, навіть якщо для технічної передачі присутній захисний шлюз CDS.

Для програм, яким необхідно вирішити не лише механізм передачі, а й ширший стан безпеки засекреченого середовища, архітектура нульової довіри для оборонного програмного забезпечення забезпечує навколишній фреймворк контролю доступу, в який інтегрується CDS.

Архітектури захисних шлюзів CDS

Чотири архітектурні шаблони охоплюють більшість розгортань CDS. Кожен з них поєднує гарантії безпеки, операційну складність і можливості з різними компромісами.

Апаратний однонаправлений діод даних. Фізичний пристрій, що використовує оптичну або електричну ізоляцію, яка гарантує однонаправлений потік даних на апаратному рівні. Електрони — і відповідно сигнали — не можуть рухатися в заблокованому напрямку. Діод між засекреченою мережею і незасекреченою гарантує, що навіть якщо програмне забезпечення на нижній стороні повністю скомпрометоване, жоден сигнал від нижньої сторони не може досягти верхньої. Обмеження є суворим: протокол додатку повинен допускати однонаправлений потік. Механізм підтвердження TCP не працює через діод; UDP-трансляція, syslog і реплікація файлів через спеціальні протоколи підходять. Діоди підходять для масового однонаправленого експорту — трансляції даних сенсорів, реплікації журналів, розповсюдження відео — де висока сторона ніколи не потребує підтвердження доставки.

Двонаправлений шлюз з розділеними проксі-процесами. Найпоширеніша архітектура для додатків, що потребують протоколів запит-відповідь. Шлюз запускає проксі-процес для верхньої сторони та проксі-процес для нижньої сторони без спільного адресного простору, спільної файлової системи або прямого міжпроцесного зв'язку між ними. Єдиний шлях від верхньої сторони до нижньої — і від нижньої до верхньої — проходить через ядро шлюзу, яке виконує політику безпеки для кожної передачі. Додаток на верхній стороні підключається до верхнього проксі; додаток на нижній стороні підключається до нижнього проксі. З точки зору мережі, кожна сторона бачить лише свій власний проксі. Ядро шлюзу є монітором посилань — невеликим, формально специфікованим, незалежно оціненим компонентом, єдина функція якого — виконання політики передачі.

Шлюз фільтрації вмісту. Шлюз, основним механізмом якого є перевірка вмісту — розбір корисного навантаження, отримання маркувань класифікації, зіставлення з правилами фільтрації і або пропуск, або відхилення, або дезінфекція вмісту перед пересиланням. Шлюзи фільтрації вмісту реалізують словник маркування CAPCO як свою мову політики. Вони підходять, коли дані, що передаються, є структурованими і добре позначеними, і коли політика вимагає вибіркового пропуску, а не суцільного блокування. Більшість сучасних двонаправлених шлюзів включають фільтр вмісту як першу стадію після двонаправленого розділення.

Модель монітора посилань. Фундаментальний принцип безпеки, який реалізують усі чотири архітектури. Монітор посилань — це компонент, який: опосередковує кожен запит на доступ між суб'єктом (відправником) і об'єктом (елементом даних, що передається); завжди викликається (жодна передача не оминає його); є стійким до втручання (він не може бути змінений або відключений жодною стороною); і є достатньо малим, щоб бути формально перевіреним. В термінах CDS монітор посилань — це ядро шлюзу, і його властивості стійкості до втручання і повного посередництва перевіряються оцінювачами під час процесу акредитації. CDS-продукт, який дозволяє передачам обминати ядро шлюзу за будь-яких умов — режим технічного обслуговування, запасний варіант при високому навантаженні, стан помилки — не відповідає вимогам монітора посилань і не може бути акредитований для меж засекречених мереж.

Наступна діаграма показує архітектуру двонаправленого шлюзу з розділеними проксі-процесами:

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

Фільтрація на основі вмісту: що перевіряють шлюзи

Фільтрація на основі вмісту — це механізм, який надає захисним шлюзам CDS можливість вибіркового пропуску. Замість блокування всього або пропуску всього, шлюз фільтрації вмісту зчитує дані, отримує поля, що стосуються безпеки, застосовує правила політики і приймає рішення «дозволити/відхилити/знезаразити» для кожного повідомлення.

Розбір маркування CAPCO. Основою фільтрації вмісту в засекречених системах США є стандарт маркування CAPCO, який визначає контрольований словник токенів, що з'являються в банерах класифікації, частинних позначках і структурованих полях метаданих. Парсер CAPCO шлюзу зчитує елемент метаданих класифікації з кожного вхідного повідомлення і отримує компонентні токени. Для повідомлення, позначеного SECRET//SI//REL TO USA,GBR, парсер видає: рівень класифікації = SECRET; відсік SCI = SI; засіб контролю розповсюдження = REL TO; релізованість = USA, GBR. Кожен токен потім перевіряється відповідно до матриці політики для цільової мережі. Якщо цільова мережа не акредитована для відсіку SI, передача відхиляється. Якщо цільова мережа акредитована для вмісту REL TO GBR, передача дозволяється — але фільтр все одно перевіряє, чи не містить якесь інше поле в тілі повідомлення вище маркування, ніж заявляє маркування на рівні документа.

Виконання відсіків чутливих відомостей. Виконання відсіків SCI вимагає від шлюзу розпізнавання повного набору токенів відсіків, визначених у відповідному посібнику з класифікації. Найпоширеніші відсіки в системах США: SI (розвідка сигналів), TK (Talent Keyhole, зображення з космосу), HCS (система контролю агентурної розвідки) і G (Gamma, підвідсік SI). Кожен з них необхідно перевіряти окремо відносно акредитації відсіку цільового анклаву. Цільова мережа, акредитована для SI, але не для TK, не повинна отримувати повідомлення з маркуванням TK — навіть якщо рівень класифікації документа знаходиться в межах дозволеного діапазону.

Виконання часткових маркувань. Засекречений документ часто містить абзаци, розділи або елементи даних з різними рівнями чутливості. CAPCO вимагає, щоб кожна частина несла власне маркування. Шлюз, що виконує часткові маркування, повинен розбирати не лише банер на рівні документа, але і кожен тег абзацного рівня (S//SI) або (U//FOUO) і приймати окреме рішення щодо політики для кожного. Дезінфекція — видалення частин, які не пройшли перевірку політики, при пересиланні решти — є складнішою, ніж суцільне відхилення, але є операційно необхідною для документів зі змішаним вмістом.

Видалення вкладень. Повідомлення SMTP і HTTP-навантаження з кількома частинами часто містять вкладення, які шлюз повинен перевіряти незалежно від тіла повідомлення. Кожна частина вкладення розбирається окремо: тип вмісту MIME визначає парсер для використання, вкладення перевіряється на наявність вбудованих метаданих класифікації (властивості документа PDF, власні властивості Word, поля EXIF зображення), і політика застосовується до кожного вкладення індивідуально. Вкладення у форматах, які шлюз не може розібрати, — невизначені бінарні формати, зашифровані архіви — відхиляються за замовчуванням і ніколи не пропускаються без перевірки.

Взаємодія між виконанням маркування CAPCO на рівні CDS та базовою моделлю даних детально описана в статті про злиття військових даних, яка охоплює поширення класифікації через багатоджерельну базу даних відстеження. Для середовищ НАТО зв'язок між еквівалентними CAPCO маркуваннями та стандартом маркування конфіденційності НАТО розглядається в довіднику з реалізації маркування STANAG 4774/4778.

Формати даних і протоколи, що підтримуються сучасними CDS-продуктами

Захисний шлюз CDS є корисним рівно настільки, наскільки він підтримує формати, що фактично використовуються вашим додатком. Парсер шлюзу повинен розуміти формат достатньо глибоко, щоб отримувати поля класифікації та перевіряти вміст — поверхневої перевірки заголовків недостатньо.

Формат / Протокол Розташування поля класифікації Типове військове застосування Складність перевірки шлюзом
XML (IC-ISM / UCORE) Атрибути простору імен на кореневому елементі та кожній засекреченій частині Повідомлення про відстеження, розвідувальні продукти, звіти NiemXML Висока — повна схемо-орієнтована оцінка XPath
JSON з метаданими ISM Поле ism:classification верхнього рівня або вбудовані об'єкти маркування Корисні навантаження REST API, сучасні мікросервіси C2 Середня — залежить від схеми, потрібна рекурсивна перевірка
SMTP / MIME Заголовок X-Classification: + банер тіла + маркування для кожного вкладення Розповсюдження розвідувальних продуктів, розподіл SITREP Висока — рекурсивний розбір MIME, визначення типу вкладення
HTTP/HTTPS (REST) Спеціальний заголовок + тіло корисного навантаження Виклики API між засекреченими і незасекреченими службами Середня — потрібне завершення TLS + повторна перевірка вмісту
MTF (Message Text Format) Поле CLASSIFICATION у наборі заголовків повідомлення Військові повідомлення НАТО/застарілі, USMTF, ADatP-3 Середня — формат з фіксованими полями, добре специфікований розбір
PDF / Документи Office Спеціальні властивості документа, метадані XMP, банерний текст в тілі Готові розвідувальні продукти, накази, плани Дуже висока — вбудовані об'єкти, макроси, необхідне видалення метаданих
Відео (RTP/RTSP) Заголовки метаданих потоку (якщо є); накладений текст на кадрі Відеотрансляція ISR, потоки БПЛА Дуже висока — зазвичай потребує діода + виділеного відеопроксі

Для XML-орієнтованих військових повідомлень правила фільтрації виражаються у форматі XPath. Правило, що відхиляє будь-яке повідомлення з токеном відсіку TK, виглядає так:

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

Захисний шлюз CDS, що захищає з'єднання між двома засекреченими мережами уряду США, повинен бути затверджений NSA/CSS до початку роботи. Шляху для відмови через операційну терміновість не існує — розгортання несанкціонованого CDS є інцидентом безпеки, що підлягає звітуванню. Розуміння процесу акредитації та його часових рамок є обов'язковою умовою для будь-якої програми, що включає засекречену межу.

Перелік оцінених продуктів NSA/CSS (EPL). NSA оцінює CDS-продукти і публікує результати у Переліку оцінених продуктів. Список EPL засвідчує, що конкретна версія продукту в конкретній конфігурації правильно реалізує модель монітора посилань і протистоїть класам атак, які перевіряли оцінювачі. Список EPL вказує точну модель апаратного забезпечення та версію мікропрограмного забезпечення, версію програмного забезпечення та параметри конфігурації, що оцінювалися. Відхилення від оціненої конфігурації — навіть застосування патча операційної системи, що не входив до оціненого базового рівня — вимагає повторної оцінки або дозволу на відхилення. Програми повинні відстежувати, якій версії EPL відповідає їхній розгорнутий шлюз, і підтримувати цю відповідність протягом всього терміну служби шлюзу.

Ініціатива Raise the Bar (RTB). Після серії інцидентів, у яких неадекватно спроектовані шлюзи дозволили неправильний прохід даних, NSA/CSS видав вимоги Raise the Bar для CDS-продуктів. RTB вимагає апаратного розділення шляхів обробки для верхньої та нижньої сторін, формальної документації кожного правила фільтрації та обґрунтування його безпеки, журналів аудиту з криптографічним підписом (щоб підробка журналів була виявленою), незалежної стороннє верифікації логіки шлюзу та визначеної процедури патчингу з повторною верифікацією після змін, що стосуються безпеки. Продукти, що відповідають вимогам RTB, перераховані в EPL з явним позначенням RTB. Продукти без RTB можуть бути у старіших списках EPL, але не можуть бути новоствореними схваленими для засекречених меж уряду США.

Перелік затверджених продуктів DISA Unified Capabilities (UC APL). Для програм Міністерства оборони (DoD) список DISA UC APL є обов'язковим на додаток до EPL NSA. Оцінка UC APL зосереджена на сумісності з інфраструктурою мережі DoD і відповідності технічним посібникам з впровадження безпеки DoD (STIG). Продукт може бути в EPL NSA, але не в UC APL, або навпаки — обидва є обов'язковими для більшості розгортань засекречених мереж DoD. Перевіряйте обидва переліки при оцінці кандидатних CDS-продуктів.

Дозвіл на роботу для конкретного об'єкта (ATO). Навіть з продуктом EPL/UC APL кожне розгортання потребує окремого ATO, що охоплює: конкретну конфігурацію апаратного та програмного забезпечення; мережеву топологію та фізичну безпеку встановлення шлюзу; набір правил фільтрації та його зв'язок з політиками класифікації підключених мереж; процедури безперервного моніторингу; та процес управління патчами і контролю змін конфігурації. Пакет ATO перевіряється уповноваженою посадовою особою (AO) для систем по обидва боки межі. Для з'єднань між мережами, що належать різним агентствам, потрібна двостороння угода між двома AO до видачі ATO. Строки: від 6 до 18 місяців для продукту, вже включеного до EPL в нескладній конфігурації.

Шаблони інтеграції для конвеєрів C2 та ISR

Інтеграція захисного шлюзу CDS в операційний конвеєр C2 або ISR вимагає обдумування як архітектури потоку даних, так і обмежень продуктивності, що вносить шлюз.

Шаблон SECRET-до-UNCLASSIFIED COP. Найпоширенішою інтеграцією є конвеєр публікація-підписка, де брокер SECRET подає засекречені оновлення відстеження, а захисний шлюз CDS підписується на брокер SECRET, перевіряє кожне оновлення і повторно публікує знезаражені оновлення до брокера UNCLASSIFIED, на який підписані партнери по коаліції або споживачі нижньої сторони. У цій архітектурі шлюз виступає як підписник-фільтр на верхній стороні і видавець-виробник на нижній стороні — ніколи як прозорий маршрутизатор. Це гарантує, що між двома брокерами немає прямого з'єднання.

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

Планування затримок. Захисний шлюз CDS вносить затримку обробки для кожного повідомлення, яке він перевіряє. Для невеликих XML-повідомлень про оновлення відстеження (менше 4 КБ) комерційні шлюзи, як правило, додають від 50 до 200 мілісекунд затримки перевірки. Для великих повідомлень з бінарними вкладеннями або тих, що потребують дезінфекції кількох частин, затримка може досягати від 500 мілісекунд до 2 секунд. Для PDF-документів або складних MIME-повідомлень обробка може зайняти кілька секунд. Це необхідно враховувати при плануванні частоти оновлення COP і угодах про рівень обслуговування для розповсюдження розвідувальних продуктів. Оцінки пропускної здатності шлюзу публікуються в документації EPL — переконайтеся, що оцінена пропускна здатність для розміру та складності повідомлень вашого додатку є достатньою перед вибором продукту.

Шляхи даних ISR-сенсорів. Для ISR-сенсорів, що функціонують на засекреченому рівні та повинні передавати дані споживачам нижчої класифікації, шлях даних зазвичай включає засекречений етап обробки, що створює знезаражені похідні продукти, які потім перетинають межу CDS. Сирі дані сенсорів (зображення повної роздільної здатності, сирі перехоплення SIGINT) ніколи не слід проектувати для проходження через захисний шлюз CDS — класифікація сирих ISR-даних зазвичай значно перевищує те, що може отримати нижня сторона, а фільтрація вмісту сирих даних сенсорів є ненадійною. Шаблон проектування такий: обробляти на рівні класифікації даних, створювати похідні продукти з видаленими індикаторами чутливого джерела і передавати через шлюз лише похідні продукти.

Операційна безпека при розгортанні CDS

Захисний шлюз CDS є ціллю високої цінності саме тому, що його компрометація рівноцінна усуненню засекреченої межі. Засоби операційної безпеки навколо розгорнутого шлюзу повинні бути пропорційними цьому ризику.

Фізична безпека. Апаратне забезпечення шлюзу повинно бути встановлене у фізично захищеному місці — закритому серверному приміщенні з контрольованим доступом та реєстрацією відвідувачів. І з'єднання мережі верхньої сторони, і апаратне забезпечення шлюзу повинні знаходитися в межах фізичного периметра безпеки мережі вищої класифікації. Фізичне втручання в шлюз — вставка пристрою прихованого каналу в мережеве з'єднання, заміна мікропрограмного забезпечення — є реальною загрозою, якій протидіють фізичні засоби контролю.

Управління поза основним каналом. Інтерфейс управління шлюзом повинен знаходитися в окремій фізичній мережі, відділеній як від операційних мереж верхньої, так і нижньої сторони. Трафік управління — зміни конфігурації, оновлення програмного забезпечення, отримання журналів — що транзитує через будь-яку операційну мережу, створює вектор прихованого каналу. Робочі станції управління повинні знаходитися всередині периметра безпеки вищої класифікації та бути відповідно акредитовані.

Цілісність журналів і виявлення втручань. Журнали аудиту CDS є основним доказом того, що межа була правильно виконана. Журнали повинні бути криптографічно захищені — кожен запис журналу включає HMAC над вмістом запису та хешем попереднього запису (ланцюжок хешів). Це робить вставку, видалення або модифікацію будь-якого запису виявленими при перевірці ланцюжка. Журнали повинні записуватися в систему, до якої ні мережа верхньої, ні нижньої сторони не може записувати або видаляти — виділений сервер журналів, доступний лише адміністратору безпеки через мережу управління поза основним каналом. Перегляд журналів повинен бути активною щоденною діяльністю: аномалії відхилень, незвичні обсяги повідомлень або повторні порушення політики одним відправником є індикаторами зондування або атаки.

Контроль змін конфігурації. Кожна зміна набору правил фільтрації — додавання правила, зміна умови, видалення правила — повинна проходити задокументований процес змін, що включає: письмовий запит на зміну з обґрунтуванням безпеки; незалежну перевірку другим офіцером безпеки; виконання тестів на представницькій вибірці трафіку; і пост-змінний аудит перших 24 годин виробничих рішень для перевірки того, що правило поводиться так, як передбачено. Зміни, що не пройшли цей процес, не повинні застосовуватися до виробничих конфігурацій шлюзу. Постійне заморожування змін повинно застосовуватися в періоди інтенсивних операцій, коли неправильна конфігурація шлюзу була б найбільш руйнівною.

Управління патчами. Патчі безпеки для операційної системи шлюзу та додатків потребують ретельного поводження. Застосування патча, що не входить до оціненої конфігурації, може призвести до недійсності ATO — а незастосування патчів безпеки створює вразливості, що можуть бути використані. Процедура така: отримати та оцінити патч; визначити, чи він впливає на оцінений базовий рівень конфігурації; якщо так — проконсультуватися з постачальником EPL та отримати дозвіл на відхилення від оцінки або запланувати повторну оцінку; протестувати патч в ізольованому середовищі шлюзу, що відображає виробниче; застосувати до виробництва протягом запланованого вікна технічного обслуговування з короткою перервою в роботі; перевірити, що поведінка правила фільтрації не змінилася після патчингу.

Тестування методом «червоної команди». Щорічне тестування на проникнення установки CDS повинно бути вимогою в плані безпеки. Обсяг тестування повинен включати: спробу видобути засекречений вміст через інтерфейс нижньої сторони за допомогою атак ін'єкції форматів та кодування; спробу використати прихований канал через часові, сховищні та протокольні канали; спробу доступу до інтерфейсу управління шлюзом з операційних мереж; та сценарії спроб фізичного втручання. Результати тестування «червоної команди» безпосередньо вносяться до звіту безперервного моніторингу і можуть ініціювати зміни конфігурації або повторну оцінку.

Ключовий висновок: Найпоширеніший операційний режим збою при розгортанні CDS — це не прогалина в правилі фільтрації, а дрейф конфігурації. Шлюз, розгорнутий і акредитований у визначеній конфігурації, поступово відхиляється від неї через несанкціоновані патчі, довільні зміни правил і заміни компонентів апаратного забезпечення. Після 18 місяців роботи без формального аудиту конфігурації більшість шлюзів працює в конфігурації, яка ніколи не оцінювалася. Плануйте аудити конфігурації в операційний графік від самого початку.