Главные ошибки работы с CVSS | Блог Касперского

При знакомстве с рейтингом CVSS (Common Vulnerability Scoring System) многим кажется, что он прекрасно подходит для сортировки уязвимостей и их приоритизации: если больше цифра рейтинга, значит уязвимость важнее. На практике этот подход не срабатывает. Уязвимостей с высоким рейтингом каждый год становится все больше, закрывать их все команды ИБ не успевают, при этом львиная доля этих дефектов никогда не эксплуатируется в реальных атаках. В то же время злоумышленники то и дело используют менее броские уязвимости с невысоким рейтингом. Есть и другие подводные камни — от чисто технических (конфликтующие оценки CVSS) до концептуальных (отсутствие бизнес-контекста).

Считать это недостатками самого рейтинга CVSS нельзя, нужно просто применять этот инструмент правильно: в рамках более сложного и комплексного процесса управления уязвимостями.

Разночтения CVSS

Иногда одна и та же уязвимость получает разную оценку критичности в доступных источниках: у исследователя ИБ, который ее нашел; у производителя уязвимого ПО; в национальном реестре уязвимостей. Кроме банальных ошибок у этих разночтений может быть и более серьезная причина — разные эксперты могут расходиться в оценках контекста эксплуатации: например, о том, с какими привилегиями выполняется уязвимое приложение, доступно ли оно из Интернета, и так далее. Производитель может ориентироваться здесь на свои рекомендации лучших практик, а исследователь ИБ — на то, как приложения настроены в реальных организациях. Один исследователь может оценить сложность эксплуатации как высокую, а другой — как низкую. Все это далеко не редкость. В исследовании VulnCheck, проведенном в 2023 году, подсчитали, что 20% уязвимостей из NVD содержат два рейтинга CVSS3 из разных источников и 56% этих парных оценок конфликтуют между собой.

Главные ошибки в применении CVSS

Хотя целое десятилетие FIRST пропагандирует методически корректное применение CVSS, организации, использующие рейтинг CVSS в своих процессах управления уязвимостями, продолжают совершать типичные ошибки.

1. Использование базовой оценки CVSS как основного индикатора риска. CVSS оценивает серьезность уязвимости, а не то, когда ее проэксплуатируют и какие последствия возникнут в организации из-за ее эксплуатации. Иногда критическая уязвимость безобидна в реалиях конкретной компании, потому что содержится в малозначительных и изолированных системах. Зато масштабная атака ransomware начинается со скучной на вид уязвимости утечки информации с CVSS 6.
2. Использование базовой оценки CVSS без корректировок threat/temporal, environmental. Наличие патчей, публичных эксплойтов и компенсирующих мер значительно влияет на то, как и насколько срочно ее стоит закрывать.
3. Фокус на уязвимостях выше определенного рейтинга. Этот подход порой навязан государственными или индустриальными регуляторами («устранять уязвимости с CVSS выше 8 в течение месяца»). В результате ИБ-службы сталкиваются с постоянно растущим объемом работ, которые по факту не делают инфраструктуру безопаснее. Число ежегодно выявляемых уязвимостей с высоким рейтингом CVSS стремительно растет последние 10 лет.
4. Использование CVSS для оценки вероятности эксплуатации. Эти показатели слабо связаны: лишь 17% критических уязвимостей когда-либо эксплуатируются в атаках.
5. Использование только рейтинга CVSS. Стандартизованная строка вектора появилась в CVSS, чтобы защитники понимали детали уязвимости и могли самостоятельно рассчитать важность уязвимости в своей организации. И CVSS 4.0 специально переработан, чтобы по дополнительным метрикам было проще учитывать бизнес-контекст. Любые работы по управлению уязвимостями, основанные только на числовом рейтинге, будут малоэффективны.
6. Отсутствие дополнительных источников информации. Пользоваться единственной БД уязвимостей и анализировать только CVSS нельзя. Отсутствие данных о патчах, работоспособных proof-of-concept и реальной эксплуатации усложняет принятие осмысленных решений по борьбе с уязвимостью.

Какие факторы остаются за рамками CVSS

CVSS является стандартизованным способом описания серьезности уязвимости; условий, в которых она может быть проэксплуатирована; и возможного влияния на уязвимую систему. За рамками этого описания (и базового рейтинга CVSS) остаются вопросы.

• Кто нашел уязвимость? Сам производитель, этичный исследователь, сообщивший производителю о дефекте и дождавшийся выхода патча, или злоумышленники?
• Существует ли для уязвимости публичный эксплойт, то есть код для ее эксплуатации?
• Насколько реально ее проэксплуатировать на практике?
• Доступен ли патч, насколько легко его установить, для всех ли уязвимых версий ПО он есть, каковы побочные эффекты применения патча?
• Должна ли заниматься этим сама организация или уязвимость затрагивает облачный сервис (SaaS) и его дефекты автоматически устранит поставщик сервиса?
• Есть ли признаки эксплуатации в реальных атаках?
• Если таких признаков нет, какова вероятность, что атакующие захотят воспользоваться данной уязвимостью в будущем?
• Что за системы уязвимы в конкретной организации?
• Доступна ли эксплуатация атакующему на практике? Например, система может быть веб-сервером компании, доступным любому через Интернет, а может быть уязвимым принтером, который физически подключен к одному компьютеру, не имеющему доступа в сеть. Или, приводя более сложный пример, уязвимость находится в методе программного компонента, но конкретное бизнес-приложение, использующее этот компонент, никогда не вызывает этот метод.
• Что будет, если уязвимые системы скомпрометируют?
• Какова цена этого события для бизнеса?

Все эти факторы существенно влияют на решение, когда и как устранять уязвимость (и устранять ли вообще).

Как сделать поправку в CVSS? Отвечает RBVM!

Все упомянутые факторы, которые редко получается учесть в рамках CVSS, используются в популярном подходе к управлению уязвимостями, основанном на оценке рисков (Risk-Based Vulnerability Management).

RBVM — это целостный процесс, состоящий из нескольких фаз, которые повторяются на регулярной основе:

• инвентаризация всех ИТ-активов бизнеса, включая компьютеры, серверы, используемое ПО, облачные сервисы, устройства IoT и прочее;
• приоритизация активов по важности (определение crown jewels);
• сканирование активов на наличие известных уязвимостей;
• обогащение данных об уязвимостях, включая уточнение рейтингов CVSS-B и CVSS-BT, получение данных киберразведки, оценку вероятности эксплуатации и так далее. Среди популярных инструментов оценки вероятности эксплуатации выделим EPSS — другой рейтинг от FIRST, рассчитываемый для большинства уязвимостей и дающий вероятность реальной эксплуатации в процентах, а также обращение к базам данных вроде CISA KEV, содержащих информацию о подтвержденной эксплуатации злоумышленниками;
• определение бизнес-контекста — какие эффекты на подверженных уязвимости системах может породить ее эксплуатация с учетом их настроек и режима использования в организации;
• определение возможностей патчинга или компенсирующих мер для нейтрализации уязвимости;
• самое интересное — определение уровня бизнес-риска на основании всего этого и расстановка приоритетов. В первую очередь устраняют уязвимости, для которых ожидается максимальная вероятность эксплуатации и существенное влияние на ключевые ИТ-активы. Для ранжирования уязвимостей можно либо рассчитать CVSS-BTE, внеся в компоненту контекста (environment) все собранные данные, либо использовать одну из альтернативных методик ранжирования. На ранжирование влияет и регуляторный аспект;
• и наконец, определение для каждой уязвимости сроков, за которые она должна быть устранена, исходя из уровня риска и операционных соображений (например, наиболее удобное время для обновлений). Если обновления и патчи недоступны или их установка создает свои риски и сложности, вместо устранения уязвимости принимают компенсирующие меры. Иногда затраты на устранение уязвимости несопоставимы с создаваемым ей риском, и может быть принято решение, что уязвимость не будут устранять вообще. Тогда бизнес осознанно принимает риски эксплуатации уязвимости.

В дополнение к этому нужно периодически анализировать ландшафт уязвимостей и ИТ-инфраструктуры в компании, а затем внедрять меры ИБ, которые препятствуют эксплуатации целых классов уязвимостей или повышают общую защищенность конкретных ИТ-систем. Среди таких мер: микросегментация сети, минимизация привилегий, внедрение более строгих политик управления учетными записями.

Правильно внедренный процесс RBVM значительно снижает нагрузку на команды ИТ и ИБ, а потраченное ими время дает более весомые результаты — усилия в первую очередь тратятся на реально опасные для бизнеса дефекты. Чтобы понять масштаб экономии сил и повышения эффективности, можно взглянуть на исследование FIRST. Приоритизация по одному только EPSS позволяет сосредоточиться лишь на 3% уязвимостей и при этом достигает эффективности 65%, в то время как приоритизация по CVSS-B требует закрыть 57% уязвимостей с ужасающей эффективностью в 4%. Под эффективностью здесь понимается устранение уязвимостей, которые когда-либо были реально проэксплуатированы.

​Бизнес — Блог Касперского

​Read More