Пастка CVSS: чому стандартна оцінка вразливості не справляється із сучасним захистом

1

Індустрія кібербезпеки зіткнулася з системною кризою сприйняття. Протягом багатьох років організації покладалися на загальну систему оцінки вразливості (CVSS), щоб визначити пріоритети виправлення помилок. Однак нещодавні гучні хаки — і перш за все операція «місячний пік» – виявили фатальний недолік: CVSS оцінює вразливості ізольовано, тоді як зловмисники використовують їх у ланцюгах.

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

Кейс Palo Alto: провал логіки

Під час операції «місячний пік» у листопаді 2024 року зловмисники отримали кореневий доступ до понад 13 000 інтерфейсів управління Palo Alto Networks. Цей масштабний злом став можливий завдяки “зв’язці” двох конкретних вразливостей:

  1. ** CVE — 2024-0012:** обхід аутентифікації (високий бал-9.3).
  2. ** CVE — 2024-9474:** уразливість підвищення привілеїв (більш низький бал-6.9).

Оскільки друга вразливість мала відносно низький бал, вона не потрапила в поріг обов’язкового виправлення в багатьох корпоративних стандартах. Більше того, оскільки для експлуатації помилки підвищення привілеїв технічно потрібен був «доступ адміністратора», її визнали низькопріоритетною. ** Фатальною помилкою стало нерозуміння того, що перша вразливість якраз і надавала той самий адміністративний доступ, який був необхідний для другої.**

Як зазначає Адам Майерс, старший віце-президент з операцій протидії супротивникам CrowdStrike, логіка сортування загроз часто страждає від свого роду «амнезії», розглядаючи взаємопов’язані загрози як розрізнені події.


5 критичних сліпих зон у сучасному управлінні вразливістю

Розрив між теоретичною серйозністю (CVSS) та реальним ризиком зростає через п’ять КЛАСІВ загроз, що розвиваються:

1. Ланцюжки вразливостей (vulnerability Chaining)

Як показав приклад Пало Альто, нападники не б’ють по одній помилці за раз. Вони поєднують баг із» середнім ” ризиком з багом «високого» ризику, щоб викликати «критичну» катастрофу. Якщо ваш процес пріоритизації враховує лише окремі бали, ви незмінно пропустите кумулятивний ефект.

2. Гонка озброєнь

Вікно для захисту звужується. Дані з * CrowdReport 2026 від CrowdStrike * показують, що хакери, пов’язані з Китаєм, можуть перетворити щойно виявлені вразливості на зброю протягом від двох до шести днів. При тому, що середній «час прориву» (breakout time) атакуючого становить всього 29 хвилин, традиційна модель «Patch Tuesday» (вівторок) безнадійно застаріла.

3. Ризик» складів ” вразливостей

Державні хакерські угруповання часто роками утримують відомі вразливості (CVE), чекаючи слушного моменту для удару. У випадку з атаками “Salt Typhoon” пристрої Cisco були скомпрометовані за допомогою вразливостей, які були виправлені більше року тому. ** CVSS не враховує» вік ” експозиції**: це означає, що вразливість, яка не була усунена протягом 14 місяців, розглядається з тією ж терміновістю, що і виявлена вчора.

4. Пробіл в управлінні ідентифікацією

Не всі вразливості пов’язані з кодом. Дзвінок соціальної інженерії в службу підтримки може обійти багатомільйонні системи захисту ПЗ без єдиного випуску CVE. Крім того, оскільки** агентські системи AI * * починають працювати з власними маркерами API та правами доступу, вони створюють нову «поверхню ідентифікації», яку традиційні сканери програмного забезпечення просто не бачать.

5. Вибухове зростання виявлень за допомогою ШІ

Обсяг вразливостей досягає критичної точки. Кількість розкриттів CVE зростає більш ніж на 20% щорічно, а моделі ШІ (такі як Claude від Anthropic) здатні знаходити баги у величезних масштабах і з низькою вартістю. Індустрія готується до»цунамі вразливостей”. Якщо ШІ призведе до десятикратного зростання швидкості виявлення, нинішня інфраструктура управління патчами просто розвалиться.


Стратегічний план дій для керівників безпеки

Щоб перейти від реактивного виправлення помилок до проактивного захисту, організації повинні змінити свої моделі управління:

      • Аудит ланцюжків: * * Не обмежуйтеся окремими CVE. Проводьте “аудит залежностей ланцюжків” для всіх відомих експлуатованих вразливостей (KEV). Якщо в одній системі існують обхід аутентифікації і підвищення привілеїв, вони повинні розглядатися як єдиний критичний пріоритет.
      • Прискорення SLA: для систем, що мають вихід в інтернет, переходите до 72-годинного вікна установки патчів * * для KEV. Щотижневих циклів вже недостатньо, щоб протистояти сучасним швидкостям злому.
      • Відстеження “віку вразливості”: ** надайте керівництву звіти, що показують не тільки те, що не виправлено, але і * як довго * це залишається без виправлень. Тривала незахищеність-основна мішень для професійних хакерів.
      • Об’єднання управління ідентифікацією та ПЗ: * * інтегруйте протоколи аутентифікації служби підтримки і управління обліковими даними ШІ в ваш стандартний процес звітності про вразливості.
    • Висновок: * * покладатися виключно на Бали CVSS означає створювати помилкове відчуття безпеки. Справжня стійкість вимагає переходу від» оцінки багів «до» аналізу шляхів атаки”, враховуючи швидкість, масштаб і взаємопов’язаність сучасних методів експлуатації.