Руслан Рахметов, Security Vision
В мире, где новые киберугрозы появляются ежедневно, специалистам по информационной безопасности нужен универсальный и понятный инструмент для оценки рисков. Как определить, какая из сотен уязвимостей в вашей системе требует немедленного внимания, а какая может подождать? Для ответа на этот вопрос был создан стандарт CVSS (Common Vulnerability Scoring System) – общепринятая система оценки серьезности уязвимостей, о которой мы расскажем в этом обзоре.
CVSS – это не просто набор цифр, а открытый стандарт, который позволяет IT-специалистам, исследователям безопасности и разработчикам говорить на одном языке. Он предоставляет прозрачную и объективную шкалу для оценки уязвимостей в программном обеспечении, помогая приоритезировать задачи по их устранению.
Независимо от того, являетесь ли вы опытным ИБ-профессионалом или только начинаете свой путь в IT, это руководство поможет вам понять и эффективно использовать CVSS для защиты цифровых активов. Стандарт CVSS не появился из ниоткуда. Его разработка была ответом на острую необходимость в единой системе классификации уязвимостей: идея зародилась в 2003-2004 годах в рамках исследовательской группы NIAC (National Infrastructure Advisory Council), консультирующей президента США по вопросам безопасности национальной инфраструктуры. Первая версия, CVSS v1, была представлена в 2005 году, а далее некоммерческая организация FIRST (Forum of Incident Response and Security Teams) стала основным двигателем прогресса в развитии этой оценки. С 2007 года FIRST является хранителем и основным разработчиком стандарта, обеспечивая его независимость и открытость. Мы не будем сильно вдаваться в историю, но подчеркнем, что стандарт развивается до сих пор, в 2023 году вышла CVSS v4.0.
Основным источником CVSS-оценок для общеизвестных уязвимостей (CVE) является Национальная база данных уязвимостей США (NVD). На странице каждого CVE в NVD можно найти присвоенную оценку и векторную строку для разных версий CVSS. В начале 2024 года NVD испытывала значительные задержки с анализом и обогащением данных, но ситуация начала улучшаться благодаря сотрудничеству с Агентством по кибербезопасности и защите инфраструктуры США (CISA). В России же дополнительно используется база данных угроз (БДУ) ФСТЭК и калькулятор уязвимостей для самой актуальной 4й версии.
Разобрав историю возникновения и основные источники информации, перейдем к анализу того, из чего состоит оценка серьезности уязвимости (число от 0 до 10), которая формируется на основе набора характеристик, сгруппированных в три группы метрик. Каждая группа отвечает на свой вопрос:
1) Базовая (Base) описывает, каковы внутренние свойства уязвимости? Это ее постоянная характеристика.
2) Временная (Temporal) группа описывает то, что известно об этой уязвимости на текущий момент? Этот параметр может меняться со временем, например аналитики Security Vision обновляют базу трендовых уязвимостей ежедневно, это позволяет адаптироваться и использовать новые знания.
3) Контекстная (Environmental) группа содержит те параметры, которые «скажут», насколько эта уязвимость опасна именно для нашей системы? Эти параметры зависят от среды и инфраструктуры.
Базовая группа метрик – это ядро стандарта, на основе метрик которого рассчитывается Базовая оценка (Base Score), которую вы чаще всего видите в бюллетенях безопасности (например, от NVD). Представьте, что уязвимость — это возможность незаконно проникнуть в чужой дачный дом (осуждается и наказывается по закону, но мы используем эту аналогию в учебных целях). Тогда, метрики эксплуатируемости описывают, как именно это можно сделать и что для этого нужно.
– Вектор атаки (Attack Vector) описывает то, как злоумышленник может использовать уязвимость. Например, сетевой (N) вектор, когда атака возможна через сеть – признан одним из самых опасных вариантов. Противоположностью будет физический (P) вектор, когда требуется физический доступ к оборудованию. Еще два вектора, смежная сеть (A) и локальный (L) соответствуют уязвимостям, которым требуется доступ к той же локальной сети (физической или логической) или локальный доступ к системе (например, через консоль или SSH).
В нашей аналогии вектор атаки опишет, как вор попадает в дом. Если вор, сидя у себя в офисе, взламывает систему «умного дома» через интернет и удаленно открывает дверь – это сетевой вектор. Если же он просто выбивает дверь плечом или ломом, т. е. грабителю требуется прямое физическое воздействие на дом – вектор будет физическим. Когда вор уже стоит на вашем участке (например, проник через калитку) и подбирает ключ к замку двери. Если ему нужен доступ к вашему участку («локальной машине» в терминах ИТ-систем) – в описании будет локальный вектор, а если он только перелезает через забор с соседнего участка, т. е. находится в непосредственной близости (в «одной сети» с домом) – смежный вектор атаки.
– Сложность атаки (Attack Complexity) разделяется на низкую и высокую, когда, например, особых условий не требуется и уязвимость можно эксплуатировать «в лоб» или когда факторов, не контролируемых злоумышленником (например, необходимость угадать токен сессии или провести атаку «человек посередине») становится больше.
– Отвечая на вопрос, какой уровень доступа/привилегий (Privileges Required) нужен атакующему до начала эксплуатации, аналитики выделяют 3 варианта: когда привилегии не требуются (т.е. любой неавторизованный пользователь может провести атаку), когда они низкие (базовые пользовательские права) или высокие (права администратора).
Сложность можно описать в той же аналогии: если дверь дома не заперта или ключ лежит под ковриком, т.е. никаких особых навыков или условий не требуется – сложность будет низкой. А если же замок открывается только когда мимо проезжает поезд, и вибрация как-то влияет на замок в двери (представить такое трудно, но в общем виде успех зависит от внешних условий, не контролируемых вором) – сложность будет высокой.
– Метрики влияния (Impact Metrics) оценивают последствия успешной атаки на три столпа информационной безопасности: конфиденциальность (Confidentiality, C), целостность (Integrity, I) и доступность (Availability, A). Для каждой из этих трех метрик используется одна и та же шкала (отсутствие влияния, низкий и высокий уровни).
На вопрос «Что нужно вору заранее?» отвечает метрика влияния: если забора вокруг участка нет, дверь открыта и любой прохожий может зайти – влияние нулевое, т.е. отсутствует. Базовым уровнем доступа будет ситуация, когда у вора есть ключ от калитки, чтобы попасть на участок, а высоким уровнем – когда у него есть ключ от сигнализации хозяина (условный пароль администратора ИТ-системы).
– Уязвимости иногда также взаимодействуют с пользователем (User Interaction). Уязвимость может быть полностью автоматизированной (когда никаких действий не нужно) или же когда жертва должна совершить какое-то действие (например, перейти по вредоносной ссылке, открыть зараженный файл).
Если вор все делает сам: проникает в дом ночью, когда хозяева спят или отсутствуют – ему не нужно участие хозяина (пользователя). Если же он звонит в дверь под видом сантехника, и хозяин сам его впускает внутрь (жертва должна совершить действие, чтобы атака удалась) – уязвимости требуется участие «пользователя).
Базовая оценка статична. Но реальный мир меняется: появляются рабочие эксплойты, выходят патчи. Временная группа метрик корректирует базовую оценку с учетом этих факторов. Давайте немного отойдем от темы грабежей и рассмотрим другую ситуацию, когда в вашем доме завелись муравьи. Это будет наша «уязвимость».
– Если уже существует публичный код для эксплуатации уязвимости, определяется доступность эксплойта. В модуле управления уязвимостями и сканере защищенности Security Vision доступность эксплойта определяется по классической шкале: если эксплойт недоступен – оценка не меняется, если существует работающий эксплойт – метрика становится рабочей. Высоким уровнем будет ситуация, когда доступен автоматизированный эксплойт «под ключ» или вредоносное ПО от злоумышленников. Чем доступнее эксплойт, тем выше итоговая оценка.
То, насколько хорошо муравьи изучили дорогу к вашему сахару – будет описывать уровень наличия эксплойта: если вы случайно увидели одного-единственного муравья-разведчика на стене (он, кажется, заблудился и пока нет никакой системной угрозы) – эксплойт не подтвержден. Если же муравей-разведчик нашел вашу сахарницу и оставил за собой феромонный след (теперь по этому следу уже идет десяток других муравьев) – появился работающий «маршрут» для эксплуатации. А ситуация, в которой муравьи уже проложили полноценную, оживленную «магистраль» от своего муравейника за окном прямо к вашей кухне (они идут сплошным потоком, а проблема стала массовой и автоматизированной) эксплойт приобрел более серьезный характер.
– Уровень исправления (Remediation Level) определяет, доступны ли средства для устранения уязвимости: если решение недоступно, то оценка так же не изменяется, если есть «костыль» на языке программистов – признается неофициальное решение. Если вендор уязвимой программы выпустил временный патч, оценка становится временной, а наличие официального исправления снижает итоговую оценку. Кстати, возможности автопатчинга уязвимостей также входят в модуль управления уязвимостями SV VM.
Вы начинаете анализировать, какие средства борьбы с муравьями у вас есть. Если вы не знаете, откуда они лезут и что с ними делать – решения нет. Когда вы прочитали в интернете, что можно протереть их тропинку уксусом, чтобы сбить феромонный след, вы начинаете использовать «костыль» (временную меру, которая может помочь, но не решает проблему кардинально), а если вы купили в магазине обычный спрей от насекомых и побрызгали в углу, откуда они появляются – считайте, что вы применили временный патч, который отпугнет их на пару дней, но не уничтожит муравейник. Официальным уровнем станет, когда вы вызвали профессионального дезинсектора: он нашел муравейник, уничтожил его и заделал все щели, через которые муравьи могли попасть в дом. Проблема решена полностью.
– Степень достоверности (Report Confidence) описывает, насколько подтверждена информация об уязвимости. Она может быть неизвестной, разумной (когда есть неподтвержденные сообщения, например, в блогах специалистов) или подтверждённой (когда вендор подтвердил наличие уязвимости и показывает тем самым, что работает над устранением проблемы).
Теперь обратимся к вопросу, насколько вы уверены, что проблема с муравьями действительно существует. Представим, что вам показалось, что на кухонном столе промелькнула какая-то точка (может, муравей, а может, просто соринка). Это значит, что вы не уверены в существовании проблемы. Если же ваш сосед пожаловался, что у него на кухне появились муравьи (скорее всего, и у вас они скоро будут) – есть веские основания полагать, что проблема реальна. Подтвержденной проблема становится в тот момент времени, когда вы своими глазами видите четкую дорожку из сотен муравьев, идущих к сахарнице. Существование «уязвимости» не вызывает никаких сомнений.
Использование временных метрик позволяет получить более реалистичную картину угрозы на данный момент. Но третья группа метрик, контекстуальная – самая гибкая и самая важная для конкретной организации: она позволяет адаптировать оценку к уникальным условиям вашей IT-инфраструктуры. По сути, вы отвечаете на вопрос: «Что эта уязвимость значит именно для нас?». Именно контекстная оценка дает наиболее точное представление о реальном риске и помогает эффективно распределять ресурсы на его устранение.
Здесь вы можете переопределить любую из базовых метрик. Например:
– Модифицированный вектор атаки (MAV): если уязвимость имеет вектор «Сетевой» (AV:N), но уязвимый сервер находится в изолированном сегменте сети без доступа извне. Вы можете изменить MAV на «Локальный», и оценка серьезности резко снизится.
– Кроме того, добавляются требования к безопасности, ваши регламенты и применяемые средства защиты информации.
– Требования к Конфиденциальности (CR), Целостности (IR), Доступности (AR) также можно переопределить в зависимости от уязвимых активов (как это устроено в ресурсно-сервисной модели модулей Платформы Security Vision). Насколько важен конкретный актив для вашего бизнеса? Уязвимость в сервере с публичными маркетинговыми материалами и точно такая же уязвимость в сервере с базой данных клиентов будут иметь разную итоговую оценку.
Common Vulnerability Scoring System (CVSS) — это фундаментальный стандарт в арсенале любого специалиста по кибербезопасности. Он предоставляет универсальный, прозрачный и структурированный язык для классификации и оценки серьезности программных уязвимостей.
Мы рассказали, как для получения наиболее точной картины необходимо выходить за рамки одной лишь базовой оценки. Использование временных метрик позволяет понять актуальность угрозы, а контекстные метрики — адаптировать ее к реалиям вашей IT-инфраструктуры. Новая версия CVSS v4.0 делает этот процесс еще более гибким и детальным.
Помните, что CVSS — это мощный инструмент для приоритизации, но не панацея. Используйте его в комплексе с другими данными об угрозах и глубоким знанием собственных систем. Только так можно выстроить по-настоящему эффективную стратегию защиты.
