Керування zero-day та вразливостями для оборонних систем

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

Zero-day проти відомих: дві проблеми, два сценарії

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

Друга проблема — zero-day: недолік, що експлуатується в реальних умовах без публічного бюлетеня та без патча. Сигнатурні сканери не бачать його, бо сигнатури ще немає. Для оборонних організацій, що стикаються з противниками, спонсорованими державою, zero-day — не гіпотеза, а клас загроз, найімовірніше навмисно націлений на конкретну платформу. Сценарій тут не «патчити швидше»; це виявлення, сегментація та компенсаційні засоби контролю, бо те, що ви б пропатчили, ще не існує.

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

Варто назвати третю категорію, що лежить між двома: n-day — вразливість, яка вчора була zero-day, а сьогодні щойно отримала публічний бюлетень і proof-of-concept експлойт. Вікно n-day — найнебезпечніша фаза життєвого циклу, бо недолік тепер широко відомий і перетворений на зброю, тоді як більшість парків ще не пропатчені. Швидкість циклу «бюлетень — усунення» в організації вимірюється майже виключно проти n-day, і саме цей показник противники експлуатують найагресивніше проти оборонних цілей, що патчать за повільними бюрократичними графіками.

Спершу інвентаризація: не можна керувати тим, що не можеш перелічити

Найпоширеніший збій у керуванні оборонними вразливостями — не повільний патчинг, а незнання того, що встановлено. Коли з'являється критичний бюлетень, питання, що вирішує час реагування, є жорстоко простим: чи присутній цей компонент і де? Організація, яка відповідає, розсилаючи листи власникам систем і чекаючи на відповіді, уже програла гонку противнику, що просканував фід бюлетенів того ж ранку.

Відповідь дає software bill of materials. Software bill of materials перелічує кожен компонент, бібліотеку та версію всередині збірки з машиночитними ідентифікаторами (CPE і PURL), які можна зіставити з даними бюлетенів. Збережений у придатній для запитів інвентаризації й оновлюваний на кожній збірці, SBOM перетворює питання «чи присутній?» з ручного полювання на пошук у базі даних, що повертає результат за секунди. SBOM є фундаментом; усе нижче за течією — кореляція, оцінка, окреслення — залежить від того, щоб він був повним і актуальним.

Як зберігати інвентаризацію чесною

SBOM, згенерований одного разу при постачанні і ніколи не оновлюваний, занепадає негайно. Патчі змінюють версії, керування конфігурацією встановлює нові пакети, а польові модифікації додають ПЗ, якого первинний перелік ніколи не описував. Інвентаризацію слід регенерувати як частину конвеєра збірки й оновлення, а не виробляти як разовий артефакт відповідності. Саме тут генерація SBOM належить усередині процесу CI/CD — тема, докладно розкрита в нашому аналізі DevSecOps для оборони. Bill of materials, що регенерується автоматично, є активом; той, що курується вручну, є зобов'язанням, яке тихо відходить від реальності.

Кореляція бюлетенів: перетворення фідів на окреслені знахідки

За наявності актуальної інвентаризації наступний етап — безперервна кореляція з джерелами даних про вразливості. Платформа керування оборонними вразливостями отримує кілька фідів паралельно: National Vulnerability Database (NVD) для деталей CVE та оцінки CVSS, вендорські бюлетені PSIRT для специфічних для продукту недоліків, базу бюлетенів OSV для компонентів з відкритим кодом і — критично — каталог CISA Known Exploited Vulnerabilities (KEV) для підмножини CVE з підтвердженою активною експлуатацією.

Кожен бюлетень несе один чи більше ідентифікаторів уражених компонентів. Механізм кореляції зіставляє ці ідентифікатори з інвентаризацією SBOM і видає окреслену знахідку: не «CVE-2026-XXXX є поганим», а «CVE-2026-XXXX уражає компонент openssl 3.0.11, присутній на цих 14 платформах у цих 3 анклавах». Це окреслення — різниця між таблицею з тисячами теоретичних CVE та коротким, придатним до дії списком, прив'язаним до реального обладнання. Воно також робить випадок відсутності збігу явним і цінним: підтвердження, що гучна вразливість не присутня у вашому парку, само по собі є розвідувальним продуктом, що запобігає марним зусиллям з усунення.

Оцінка експозиції: серйозність — це не пріоритет

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

Захищена оцінка експозиції поєднує три виміри. Технічна серйозність походить від базової оцінки CVSS. Імовірність експлуатації походить від імовірності EPSS (Exploit Prediction Scoring System) і, вирішально, від наявності у KEV — знахідка зі списку KEV прямо зараз використовується реальними противниками і має перестрибнути чергу. Місійний контекст походить від критичності активу, мережевої доступності та того, чи блокує вже шлях атаки компенсаційний засіб контролю. Зважування їх разом дає єдину впорядковану чергу, що відображає операційний ризик, а не абстрактну серйозність.

Де zero-day входять в оцінку

За визначенням zero-day не має CVE, CVSS і запису в KEV, тож його не можна оцінити механізмом відомих вразливостей. Його місце в моделі непряме: оцінка експозиції активу має бути збільшена його поверхнею атаки та критичністю саме для того, щоб цінні, доступні з інтернету системи отримували превентивне посилення ще до того, як буде названий будь-який конкретний zero-day. Ви оцінюєте експозицію активу до невідомого, а не сам невідомий недолік.

Саме тому оцінка експозиції має бути безперервною, перераховуваною величиною, а не разовим рішенням тріажу. Імовірності EPSS зсуваються щодня, в міру накопичення доказів експлуатації; CVE можна додати до каталогу KEV через тижні після розкриття; а місійний контекст системи змінюється, коли вона переміщується між гарнізоном та операційним розгортанням. Модель оцінки, що виконується одного разу і дає статичний пріоритет тікета, уже застаріла до того, як тікет призначено. Платформа має переупорядковувати всю чергу на кожному оновленні фіду, щоб знахідка, яка в понеділок була низькопріоритетною, автоматично піднялася на вершину в четвер, коли її оцінка EPSS потроїться і вона потрапить до списку KEV — без того, щоб людина мусила помітити зміну вручну.

Оркестрація патчів у під'єднаних та air-gapped анклавах

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

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

Для air-gapped анклавів конвеєр отримує етап перенесення. Патчі дзеркаляться і валідуються у під'єднаному staging-середовищі, потім пакуються з їхнім повним замиканням залежностей і криптографічними підписами у пакет перенесення. Цей пакет перетинає межу через затверджене cross-domain рішення або контрольований процес перенесення на знімних носіях. Усередині анклаву внутрішній репозиторій патчів і контролер оркестрації перевіряють підписи, розгортають оновлення на тестове кільце і лише потім просувають до бойових систем. Архітектура має припускати офлайн-роботу з першого дня — і вона тісно пов'язана з ширшими патернами, описаними в дизайні розгортання air-gapped оборони, де кожен шлях оновлення є задокументованою, придатною до аудиту процедурою, а не імпровізованим копіюванням.

Перевірка того, що патч справді приземлився

Тікет на патч, позначений як «закритий», — не те саме, що зникла вразливість. Замикання циклу вимагає повторного сканування чи регенерації SBOM після розгортання і підтвердження, що вразлива версія більше не присутня на уражених платформах. В air-gapped середовищах цей крок перевірки є вдвічі важливішим, бо латентність зворотного зв'язку велика, а невдале перенесення може лишити анклав у переконанні, що його пропатчено, хоча це не так. Контролер оркестрації має вважати знахідку усуненою лише тоді, коли інвентаризація після патча це підтверджує.

Коли патча немає: компенсаційні засоби контролю

Деякі знахідки не можна пропатчити. Недолік може бути справжнім zero-day без доступного виправлення, уражений компонент може мати завершений термін підтримки без супроводу постачальника, або система може бути в операційному стані, де вікно обслуговування за місяці попереду. Для них керування вразливостями зміщується до зниження ризику, а не його усунення.

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

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