В корпоративной безопасности есть свой любимый вид спорта: забег по граблям под названием управление уязвимостями (Vulnerability Management или VM). Процесс обычно выглядит так: сканер нашел дыру, окрасил ее в пугающий бордовый цвет (CVSS 9.8 - CRITICAL), ИБ бежит с криками к сисадминам, сисадмины отбиваются лопатой, потому что «если мы сейчас накатим этот патч, отвалится биллинг и нас всех уволят».
В итоге ИБ пишет бумажку о принятии рисков и все расходятся пить кофе до следующего инцидента.
Почему эта система не работает? Потому что мы слишком сильно поверили в магию цифр CVSS.
Иллюзия метрики CVSS
Common Vulnerability Scoring System (CVSS) - это отличный стандарт, но это стандарт оценки технической тяжести уязвимости, а не вероятности ее эксплуатации в вашей конкретной инфраструктуре.
CVSS не знает, что уязвимый сервер стоит за тремя фаерволами. CVSS не знает, что для эксплуатации дыры нужен локальный доступ к машине, которого нет ни у кого, кроме двух сеньоров с аппаратными ключами. CVSS оценивает сферический софт в вакууме.
Пример из жизни:
- Сценарий А (CVSS 9.8): Уязвимость RCE (удаленное выполнение кода) в старой версии Apache. Страшно? Очень, но этот Apache крутится на тестовом виртуалке (Staging), к которой имеют доступ полтора разработчика через VPN, и которая физически не может инициировать соединение во внешнюю сеть. Реальный риск: Минимальный.
- Сценарий Б (CVSS 5.3): Уязвимость типа SSRF (Server-Side Request Forgery) или обход каталога в публично торчащем веб-приложении (Reverse Proxy). По CVSS это всего лишь «Medium», но атакующий может использовать этот SSRF, чтобы достучаться до внутреннего API без авторизации и вытянуть базу клиентов. Реальный риск: Катастрофический.
Если вы заставляете ИТ патчить Сценарий А раньше Сценария Б только потому, что «циферка больше» - вы занимаетесь бумажной безопасностью, а не защитой бизнеса.
Перестаньте швыряться отчетами
Самая частая ошибка безопасников - генерировать слепые отчеты на тысячи страниц. Сисадмины ненавидят эти эксельки. Патчинг - это больно. Патчинг требует даунтайма, тестирования совместимости (потому что после обновления библиотеки может лечь половина самописных костылей) и резервного копирования.
Когда вы приносите админу 500 «критических» уязвимостей, у него опускаются руки. Ему нужна приоритизация. Ему нужен Risk-Based Vulnerability Management (RBVM).
Как строится здоровый RBVM (Risk-Based VM)
Зрелый процесс управления уязвимостями строится на трех китах, где базовый балл CVSS играет далеко не первую роль.
1. Контекст актива (Asset Criticality) Первое, что нужно сделать - умножить уязвимость на ценность актива.
- Сервер процессинга платежей (Tier 0).
- Ноутбук HR-специалиста.
- Плазма в переговорке, крутящая презентации. Уязвимость на плазме в переговорке может подождать квартального ТО. Уязвимость на шлюзе VPN требует подъема инженеров ночью. Нет инвентаризации и понимания критичности (CMDB) - нет нормального патч-менеджмента.
2. Threat Intelligence и CISA KEV (Known Exploited Vulnerabilities) Это неплохой козырь. Существуют десятки тысяч уязвимостей с высоким CVSS, для которых есть только теоретический PoC (Proof of Concept), написанный студентом из Небраски для курсовой. Хакеры их не используют.
Однако есть каталог CISA KEV. Это поддерживаемый правительством США список уязвимостей (осуждаем, но что поделать), которые прямо сейчас, в эту самую секунду активно эксплуатируются реальными хакерскими группировками (APT) и операторами шифровальщиков в дикой природе.
Если сканер нашел уязвимость, и она есть в каталоге KEV - споры заканчиваются. Мы не смотрим на CVSS (пусть там хоть 4.0). Мы идем и патчим. Потому что это уже не теория, это заряженный пистолет, приставленный к виску вашей инфраструктуры.
3. Цепочки атак (Attack Chaining) Хакеры редко ломают системы через одну красивую уязвимость на 10 баллов. Обычно это цепочка из нескольких мелких багов.
Например:
- Фишинг дает доступ к непривилегированному ПК (CVSS: N/A).
- Локальное повышение привилегий через старый драйвер принтера (CVSS: 6.8).
- Извлечение пароля из памяти и Lateral Movement (CVSS: N/A).
Современные сканеры и платформы управления уязвимостями (ASM / RBVM) учатся строить графы атак, показывая, какие именно «средние» уязвимости открывают путь к короне домена. Именно их нужно рубить первыми.
В итоге. Чтобы ИТ перестал саботировать задачи на обновление, стоит начать говорить с ними на языке здравого смысла и аптайма. Перестаньте поклоняться цифре 9.8. Обогащайте данные сканеров контекстом вашей сети и Threat Intelligence.
Когда вы придете к сисадмину и скажете: «Слушай, из 500 уязвимостей я отфильтровал 497. Но вот эти 3 висят на публичных IP, и прямо сейчас через них ломают компании по всему миру (вот ссылка на KEV). Давай закроем их сегодня, а остальное закинем в плановый патчинг на конец месяца» - вы удивитесь, насколько охотно ИТ пойдет вам навстречу.