Чому поєднання агентного та безагентного сканування формує повну картину ризиків

Як працює кожен підхід

Агентне сканування передбачає встановлення програмного забезпечення безпосередньо на кожен хост. Це дає привілейований доступ до конфігураційних файлів, запущених процесів і даних файлової системи.
Безагентні інструменти працюють інакше: вони використовують API хмарних провайдерів, знімки дисків (snapshots) та мережеві протоколи, щоб оцінювати системи «ззовні». Вони не підключаються до хоста і не виконують код всередині нього.
Практичний висновок:безагентні підходи краще відповідають на питання «що може бути атаковано», тоді як агентні — на «що відбувається прямо зараз».
Саме тому агентні рішення ефективні для виявлення загроз та поведінкового аналізу — вони відстежують, що реально відбувається на хості в конкретний момент.

Скоригована картина покриття

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

Є два важливі уточнення, які варто прямо виділити з початкової моделі.
По-перше, віддалені пристрої та ноутбуки поза корпоративною мережею (наприклад, у домашніх мережах) повністю невидимі для безагентного сканування. Воно потребує стабільного мережевого з’єднання, тому не підходить для віддалених співробітників, чиї пристрої недоступні зі сторони сканера. Це особливо актуально в реаліях після 2020 року.
По-друге, OT та IoT-пристрої. Безагентне сканування може виявляти IoT-девайси та мережеве обладнання (роутери, свічі), які не мають ОС із підтримкою агентів. Однак глибина аналізу вразливостей для таких пристроїв обмежена.
Такі активи не є повністю «досліджуваними»: вони видимі на рівні мережі, але дані про вразливості менш детальні, ніж для стандартних endpoint’ів. Лише за умови автентифікованого сканування можна отримати рівень деталізації, близький до агентного — але навіть тоді результат залежить від частоти сканування.

Сліпі зони, які стають точкою атаки

Ці прогалини — не теорія.Під час інциденту з Capital One у 2019 році неправильно налаштований AWS WAF відкрив доступ до даних у S3 — і безагентне сканування могло б виявити цю проблему ще до атаки.
У випадку з Uber у 2022 році runtime-телеметрія з агентного сенсора могла б зафіксувати lateral movement всередині інфраструктури.
Патерн очевидний: різні типи атак використовують саме ті прогалини, які залишає організація.

Операційна важливість у тому, що вимоги комплаєнсу та аудитів часто штовхають організації обирати лише один підхід, створюючи хибне відчуття повного покриття.
Вимоги SOC 2 та ISO 27001 формально можуть бути виконані за рахунок безагентного сканування на рівні хмари. Але це не означає, що поведінкові загрози в runtime на керованих endpoint’ах дійсно покриті.
Аудит пройдено — але «сліпа зона» нікуди не зникає.

Що насправді означає «комбінований підхід»

Використання двох окремих інструментів і зведення CSV-файлів — це не комбінований підхід.
Це проблема узгодження даних, замаскована під програму безпеки.

Повноцінна мультиметодна архітектура потребує трьох речей, яких більшість point-рішень не забезпечують:

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

IP-адреси змінюються. Імена хостів «дрейфують». Якщо платформа сприймає їх як різні активи, кількість вразливостей штучно зростає, а метрики їх усунення втрачають сенс.

По-друге — єдине уявлення про ризик.
Результати обох підходів мають бути нормалізовані та пріоритезовані разом.
Наприклад, CVSS 9.8, знайдений безагентно в cloud-середовищі, і CVSS 9.8, знайдений агентом на сервері, повинні потрапляти в одну чергу на усунення — з однаковою логікою пріоритезації.

По-третє — чесна звітність про покриття.
Найнебезпечніший наслідок використання лише одного методу — це хибна впевненість.

Платформа, яка показує «12 000 вразливостей під управлінням», але не уточнює, що вона покриває лише 60% активів, — це не інструмент управління ризиками, а джерело ризику.