Тестування на проникнення є стандартним елементом будь-якої серйозної програми безпеки. У комерційних середовищах це відносно добре зрозуміла вправа: зовнішня команда отримує обсяг, документ щодо правил взаємодії та часове вікно для пошуку вразливостей, придатних для експлуатації, раніше ніж це зроблять реальні зловмисники. Результатом є звіт; шлях до усунення — це завдання управління проєктами.
В оборонних середовищах жодна з цих концепцій не застосовується повністю. Структура правових повноважень інша, модель загроз інша, обмеження щодо того, що тестувальники можуть торкатися, інші, а шлях від знахідки до усунення проходить через формальний процес акредитації, якому немає комерційного еквівалента. Організації, які застосовують комерційні стандарти пентесту до оборонних систем — або які наймають комерційні пентест-фірми без досвіду в оборонній галузі — регулярно виробляють оцінки, що пропускають найбільш актуальні ризики, виходять за межі законних повноважень або генерують знахідки, з якими програмний офіс не може нічого зробити.
У цій статті розглядається, що насправді відрізняє пентест в оборонній сфері, що це означає операційно та як структурувати оцінку, що дає результати, придатні для використання у військовій програмі.
Правові повноваження: основа, що не має комерційного еквівалента
У комерційних завданнях правова основа для пентесту — це контракт і документ щодо правил взаємодії, підписаний особою, що має повноваження авторизувати тестування цільових систем. Ці повноваження зазвичай прості — компанія володіє системами, і CISO або CTO може надати дозвіл.
В оборонних середовищах ланцюг повноважень складніший, а ставки за помилку значно вищі. Урядові інформаційні системи функціонують на підставі Авторизації на експлуатацію (ATO), наданої Уповноваженою офіційною особою (AO). ATO визначає стан безпеки, дозволений для системи. Тестування на проникнення змінює цей стан, принаймні тимчасово, і має бути явно авторизоване AO — а не просто менеджером програми або ISSO системи.
Для систем DoD США застосовуються Закон про комп'ютерне шахрайство та зловживання (CFAA) та UCMJ. Особа, яка отримує доступ до урядової інформаційної системи без належної авторизації — навіть з добрими намірами, навіть у рамках нібито авторизованого тесту — вчинила федеральний злочин. Документ авторизації — це не формальність: це інструмент, що перетворює те, що інакше було б несанкціонованим доступом, на законне тестування. Кожен тестувальник, зазначений в авторизації, має бути ідентифікований поіменно. Обсяг авторизованого тестування має бути конкретним. Дії поза цим обсягом не захищені.
Вимога до правових повноважень: Ніколи не починайте пентест оборонних систем без підписаного конкретного документа авторизації від Уповноваженої офіційної особи системи. Загальні схвалення «оцінки безпеки» від менеджерів програм або генеральних підрядників не забезпечують захист за CFAA. Авторизація повинна ідентифікувати тестувальників поіменно, визначати системи в межах обсягу, визначати вікно тестування та перераховувати дозволені методи.
Вимоги до допуску додають ще один рівень. Тестування засекреченої системи вимагає, щоб тестувальники мали дійсні допуски відповідного класифікаційного рівня. Організація, що проводить тестування, повинна мати допуск об'єкта (FCL) цього рівня. Залучення неперевіреного персоналу — навіть у допоміжних ролях — до засекреченого тестового середовища є порушенням безпеки незалежно від того, що вони фактично бачать або торкаються.
ITAR (Міжнародні правила торгівлі зброєю) вводить додаткові обмеження для програм, що включають контрольовані предмети оборони. Інформація про вразливості в системах, що підпадають під ITAR, може сама підлягати обмеженням щодо контролю за експортом, обмежуючи те, що може бути задокументовано, передано або поширено через міжнародні кордони — в тому числі в рамках багатонаціональних союзницьких програм. Тестові фірми, що діють за міжнародними субпідрядними угодами, повинні явно враховувати це.
Емуляція загрозливих акторів: TTP державного рівня, а не загальні експлойти
Комерційний пентест часто зосереджений на пошуку будь-якої вразливості, придатної для експлуатації — найпоширеніших, найбільш доступних, з найвищим балом CVSS проблем на поверхні атаки цілі. Для корпоративної мережі це розумний підхід: опортуністичний зловмисник скористається найпростішим доступним шляхом.
Оборонні системи стикаються з принципово іншою популяцією загроз. Основні противники для цілей оборони високої цінності — це державні актори зі значними ресурсами, розвиненими можливостями та довгими часовими горизонтами. Їх не зупинить виправлення проблеми OpenSSL з оцінкою CVSS-10, якщо вони можуть здійснити pivot через надійного партнера в ланцюзі постачання, застарілий вбудований компонент або неправильно налаштоване міждоменне рішення.
Ефективний пентест оборонних систем використовує емуляцію противника: команда тестування відтворює тактики, техніки та процедури (TTP) конкретних груп загрозливих акторів, релевантних для моделі загроз програми. Фреймворк MITRE ATT&CK надає структуровану таксономію для цього з матрицями Enterprise та ICS, що охоплюють техніки, найбільш часто використовувані групами вдосконалених постійних загроз.
Для оборонних систем релевантні загрозливі актори зазвичай включають:
- APT28 (Fancy Bear / підрозділ ГРУ 26165) — російська військова розвідка, відома спеціальним фішингом, збором облікових даних та збереженням доступу через зловживання легітимними інструментами. Тактики, релевантні для оборонного програмного забезпечення, включають атаки на робочі станції розробників та конвеєри збірки для впровадження шкідливого коду до розгортання.
- Lazarus Group (КНДР) — північнокорейський державний актор із репутацією атак на оборонних підрядників та аерокосмічні компанії, зокрема через атаки типу «водопій» та озброєні приманки для кандидатів на роботу, спрямовані на персонал із допусками.
- Volt Typhoon (КНР) — китайський державний актор, зосереджений на техніках «живлення за рахунок ресурсів землі» для досягнення постійного, малопомітного доступу до критичної інфраструктури та оборонних мереж. Відзначається уникненням власного шкідливого ПЗ на користь вбудованих системних інструментів для ухилення від виявлення.
План тестування повинен визначати, який профіль противника емулюється і чому, виходячи з оцінки загроз програми. Тест, що емулює підхід Volt Typhoon «живлення за рахунок ресурсів землі», виглядатиме зовсім інакше, ніж той, що емулює операції APT28, орієнтовані на облікові дані, — і обидва відрізнятимуться від тесту, зосередженого на сценаріях внутрішніх загроз або цілісності ланцюга постачання.
Примітка щодо вибору противника: Профіль загрозливого актора має бути обумовлений розвідувально-обґрунтованою оцінкою загроз програми, а не перевагами тестувальника або загальними ярликами «просунутий». Для програм із конкретними географічними профілями загроз або відомою історією атак ISSO повинен провести брифінг команди тестувальників щодо поточних звітів про загрози до початку завдання.
Управління обсягом: обмеження щодо простоїв та ізольовані тестові середовища
Обмеження обсягу при комерційному пентесті — це насамперед управління відповідальністю та фокусування зусиль. Обмеження обсягу в оборонній сфері мають додаткові виміри, що кардинально визначають, як може проводитися тест.
Багато оборонних систем не можуть допустити жодних простоїв під час тестування. Системи управління та контролю, комунікаційна інфраструктура та платформи злиття даних у реальному часі можуть бути операційно активними під час тестового вікна. Спроба експлуатації, що спричиняє перерву в обслуговуванні — навіть коротку — може мати операційні наслідки, яких жодна контрактна компенсація не може усунути. Стандартний комерційний підхід до тестування проти виробничих систем із правилом «зупинитися, якщо побачиш щось нестабільне», є неприйнятним для таких середовищ.
Практичний наслідок полягає в тому, що багато оборонних пентестів проводяться у виділених тестових середовищах: ізольованих мережевих сегментах, постановочних середовищах або лабораторних репліках, що максимально наближені до виробничого. Достовірність тестового середовища надзвичайно важлива. Тестове середовище, що використовує різні версії прошивки, не має виробничих інтеграцій або функціонує з послабленими засобами контролю доступу порівняно з виробничим, дасть знахідки, що не відображають фактичний стан ризику операційної системи. Достовірність тестового середовища — це інвестиція, до якої повинен бути готовий програмний офіс; це не проблема команди тестування для вирішення.
Порушення обсягу розглядаються з більшою серйозністю в оборонних середовищах, ніж у комерційних. Випадковий дотик до системи поза авторизованим обсягом — це не незначне процедурне питання — це може становити несанкціонований доступ до урядової інформаційної системи. Тестувальники повинні вести детальний журнал активності протягом усього завдання, документуючи значущі дії практично в режимі реального часу, щоб будь-які питання щодо обсягу, що виникнуть під час або після тесту, можна було вирішити за допомогою доказів, а не спогадів.
Класи вразливостей, специфічні для оборонної галузі
Окрім процедурних відмінностей, оборонні системи містять класи вразливостей, що недостатньо представлені в комерційних методологіях пентесту.
Застарілі вбудовані системи. Оборонні платформи регулярно запускають програмне забезпечення на апаратному забезпеченні віком 10–20 років із вбудованою прошивкою, яку не можна виправити через звичайні механізми оновлення. Вразливості в цих компонентах можуть бути відомі, але не піддаватися лікуванню протягом життєвого циклу системи — знахідка пентесту стане постійним записом у POAM із запитом на відхилення, а не квитком на усунення. Тестувальникам потрібно розуміти, що означає «знахідка» в цьому контексті: цінність полягає в документуванні та кількісній оцінці ризику, а не обов'язково в прагненні до негайного усунення.
Міждоменні рішення. Системи, що обробляють дані на кількох рівнях класифікації, використовують міждоменні рішення (CDS) для переміщення даних між доменами безпеки. Це цілі високої цінності: CDS, яке можна маніпулювати для передачі інформації у невірному напрямку, нівелює всю архітектуру обробки даних. Тестування CDS вимагає спеціальної експертизи та конкретної авторизації — ці компоненти часто розглядаються як окремі обсяги в рамках більш широкої оцінки програми.
Цілісність ланцюга постачання. Найбільш значущі атаки на ланцюг постачання програмного забезпечення за останні роки (SolarWinds, XZ Utils) були спрямовані на конвеєри збірки та впровадження залежностей, а не на запущені системи. Оборонні програми є цілями високої цінності для цього класу атак. Пентест повинен включати оцінку середовища збірки: чи може зловмисник із доступом до робочої станції розробника ввести шкідливий код, що потрапляє до виробничої збірки? Чи може бути введена скомпрометована залежність без спрацювання наявних засобів контролю?
Управління сертифікатами та ключами. Оборонні системи значною мірою покладаються на інфраструктуру PKI для автентифікації та забезпечення безпеки зв'язку. Неправильно налаштована перевірка сертифікатів, надто широкі конфігурації якорів довіри та неналежне управління життєвим циклом ключів стабільно є знахідками з високим ступенем серйозності. На відміну від вразливостей додатків, вони часто невидимі для автоматичного сканування та вимагають ручної перевірки архітектури PKI щодо проєкту безпеки системи.
Життєвий цикл знахідки: вплив на POAM, ATO та запити на відхилення
У комерційних завданнях звіт про пентест надходить до CISO, знахідки сортуються, частина з них усувається, а решта старіє в трекері до наступної оцінки. Процес визначається схильністю до ризику та інженерними потужностями.
В оборонних середовищах знахідки живлять формальний цикл акредитації з юридичними та контрактними наслідками. Ключова концепція — План дій та контрольних точок (POAM): документ, що відстежує кожну відому слабкість у системі, щодо якої надана або запитується ATO. Кожна знахідка з пентесту, яку не можна негайно усунути, повинна бути внесена до POAM із запланованою датою усунення, відповідальним власником та тимчасовим заходом пом'якшення.
POAM переглядається Уповноваженою офіційною особою як умова підтримки ATO. Відкриті елементи з високим ступенем серйозності без адекватних тимчасових заходів або реалістичних графіків усунення можуть призвести до призупинення ATO — фактично виводячи систему з роботи до вирішення стану ризику. Для програмного офісу цей результат настільки серйозний, що деякі програми відкладають або обмежують обсяг пентесту, щоб уникнути генерації знахідок, які можуть ініціювати перегляд ATO. Це провал управління ризиками: вразливості існують незалежно від того, задокументовані вони чи ні.
Для знахідок, які неможливо усунути — застарілі компоненти без доступних патчів, архітектурні обмеження, що вимагали б повного перепроєктування системи — програмний офіс може подати запит на відхилення або прийняття ризику до AO. Це не визнання провалу; це формальний механізм функціонування з відомим залишковим ризиком під явною авторизацією. Тестувальники повинні розуміти цей процес і формулювати знахідки таким чином, щоб допомогти ISSO побудувати захищені записи POAM та запити на відхилення, а не просто максимізувати бали CVSS.
Оформлення звіту для оборонних програм: Звіти про пентест оборонних систем повинні включати для кожної знахідки: маркування класифікації, рейтинг серйозності, узгоджений з критеріями прийняття ризику програми, оцінку придатності для експлуатації з урахуванням фактичних загрозливих акторів програми та рекомендоване розпорядження POAM. Звіти, написані у комерційному форматі — бали CVSS, загальні поради щодо усунення, виконавчі резюме, спрямовані на нетехнічне керівництво, — вимагають значного доопрацювання перш ніж ISSO зможе ними скористатися.
Як визначити обсяг і авторизувати пентест оборонної системи
Наступні кроки відображають вимоги для захищеного, законно авторизованого тестування на проникнення оборонної програмної системи.
Крок 1: Встановити правові повноваження та письмову авторизацію. Отримати підписаний документ авторизації тестування від AO системи. Документ повинен поіменно зазначати тестувальників, визначати системи в межах обсягу, визначати вікно тестування та перераховувати дозволені методи. Це не формальність — це інструмент, що робить тестування законним.
Крок 2: Перевірити допуски та облікові дані об'єкта. Підтвердити, що всі тестувальники мають дійсні допуски на рівні класифікації цільової системи, а організація тестування має FCL необхідного рівня. Проінструктувати всіх тестувальників щодо керівництва з класифікації безпеки програми до отримання доступу до будь-якого засекреченого середовища.
Крок 3: Визначити межі обсягу та тестового середовища. Визначити, які системи, мережі та інтерфейси входять до обсягу. Там, де операційні системи не можуть допустити простоїв, встановити виділене тестове середовище. Задокументувати явні виключення та проінструктувати тестувальників щодо правових наслідків порушення обсягу.
Крок 4: Відібрати та перевірити інструменти тестування. Перевірити зобов'язання ITAR та вимоги акредитації програми, щоб визначити, які інструменти дозволені. Виключити інструменти з компонентами іноземного походження, хмарним ліцензуванням або вихідною телеметрією. Задокументувати набір інструментів у плані тестування та подати на розгляд програмному офісу до початку завдання.
Крок 5: Провести емуляцію загрозливого актора на основі моделі загроз програми. Вибрати профіль противника, найбільш релевантний для системи. Використовувати MITRE ATT&CK для ICS або Enterprise відповідно, адаптоване до конкретної архітектури системи та профілю місії. Не замінювати загальне «просунуте» тестування на реальну емуляцію противника.
Крок 6: Документувати активність та знахідки з маркуванням класифікації. Вести детальний журнал активності протягом усього завдання. Всі знахідки повинні мати відповідні маркування класифікації та рейтинги серйозності, узгоджені з критеріями прийняття ризику програми.
Крок 7: Внести знахідки до POAM і відстежувати усунення. Працювати з ISSO для внесення всіх відкритих знахідок до POAM. Призначити відповідальних за усунення, заплановані дати та тимчасові заходи. Знахідки з високим ступенем серйозності слід доповідати безпосередньо AO — не допускати, щоб критичні вразливості чекали у черзі без явного прийняття ризику або активного усунення.