Уязвимости приоритизируют так: берут числовую оценку серьёзности (CVSS) как первое приближение, поправляют её ответами на пять вопросов о вашей системе и записывают итоговый класс со сроком. Оценка описывает ошибку в вакууме, поэтому порядок по одной оценке часто неверен: «критическая» уязвимость в неиспользуемой функции может подождать, а «средняя» ошибка прав на странице клиентов нет.
Статья не про то, как устроен весь процесс, а про один шаг: как решить, что закрывать первым. Процесс целиком (реестр, сроки, исключения, метрики) описан в статье «Управление уязвимостями: от находки до закрытия», работа в вашем контуре — на странице «Управление уязвимостями».
Что на самом деле показывает оценка CVSS
CVSS — открытый способ описать тяжесть уязвимости числом от нуля до десяти и словом: низкая, средняя, высокая, критическая. Число считается по набору характеристик ошибки, и обычно в каталогах и сканерах вы видите его базовую часть. Она отвечает на вопрос «насколько плоха эта ошибка в среднем случае», а не «насколько она плоха у вас».
| Группа характеристик | Что описывает | Кто знает ответ | Чего не учитывает |
|---|---|---|---|
| Базовая | свойства самой ошибки: откуда можно атаковать, насколько сложно, нужны ли права, нужно ли участие пользователя, что будет с данными и работой сервиса | Автор оценки, обычно разработчик продукта или каталог | Ваше окружение, ваши настройки, ваши данные |
| Текущая | что изменилось со временем: появился ли готовый способ эксплуатации, вышло ли исправление | Каталог и поставщик; меняется со временем | Эксплуатацию именно против вас |
| Окружения | поправка на вашу систему: насколько важны ваши данные и работа, какие меры уже стоят | Только вы | Ничего, но её почти никто не заполняет, и сканер её не знает |
Отсюда два вывода. Первый: базовая оценка нужна как стартовая точка, а не как приговор. Второй: недостающую часть, оценку окружения, придётся делать вам, и лучше делать её коротко и по одинаковым правилам, чем пытаться пересчитывать числа. Самодельные баллы создают видимость точности и спорят друг с другом, а письменное решение «срочно / в релиз / по плану» с причиной работает лучше.
Как прочитать характеристики и задать вопрос о своей системе
Вектор оценки выглядит как набор сокращений, но каждое превращается в вопрос, на который вы можете ответить за минуту. Ниже условные характеристики и вопросы к ним.
| Что написано в оценке | Как это понимать | Вопрос к вашей системе |
|---|---|---|
| Атака по сети | Эксплуатировать можно удалённо | Доступна ли уязвимая часть из интернета, из внутренней сети или только с сервера? |
| Права не нужны | Вход в систему не требуется | Есть ли у уязвимого адреса проверка входа в вашем приложении, пусть даже библиотека ею не занимается? |
| Нужно действие пользователя | Жертве надо открыть ссылку или файл | Кто эти пользователи: клиенты, сотрудники, администраторы? Что они откроют по ссылке? |
| Низкая сложность | Не требуются особые условия | Нужна ли определённая настройка, включённая функция или версия, которой у вас нет? |
| Влияние на конфиденциальность | Можно прочитать данные | Какие именно данные лежат в этом сервисе и кому они принадлежат? |
| Влияние на доступность | Можно вывести сервис из строя | Что остановится в бизнесе, если сервис недоступен час, и есть ли резерв? |
Иногда ответ на вопрос о настройке снимает находку сразу: уязвимость есть в библиотеке, но срабатывает только при включённой функции, которую вы не используете. Такие случаи проверяются по описанию уязвимости и по конфигурации, это занимает минуты, а не дни. Результат записывайте: «не затронуты, потому что функция отключена, проверено в конфигурации такой-то даты».
Пять сигналов, которых нет в оценке
Эти сигналы меняют порядок сильнее, чем разница между восемью и девятью баллами. Для каждого есть простой источник.
| Сигнал | Откуда берём | Как меняет порядок |
|---|---|---|
| Эксплуатация уже идёт | Перечни уязвимостей, которые используются в атаках (такой перечень ведёт, например, американское агентство CISA), сообщения поставщика, новости отрасли | Поднимает находку в первую очередь, даже если оценка средняя: ошибка не теоретическая |
| Вероятность эксплуатации | Статистические оценки вероятности, что уязвимость начнут использовать в ближайшее время (одна из них называется EPSS) | Помогает отсортировать длинный хвост находок с одинаковой оценкой; не заменяет сведения о вашей системе |
| Достижимость | Ваш код и конфигурация: вызывается ли уязвимая функция, попадают ли в неё данные от внешнего пользователя | Снижает срочность, если путь недостижим, и повышает, если данные клиента идут прямо в уязвимую функцию |
| Ценность того, что за ошибкой | Инвентарь: что хранит и делает сервис, какие данные через него проходят | Ошибка в сервисе с персональными данными клиентов весит больше, чем та же ошибка во внутреннем справочнике |
| Чем прикрыто | Сетевые правила, ограничения прав, фильтры перед сервисом | Временно снижает срочность, но только если мера записана, проверена и у неё есть срок |
Шестым пунктом иногда добавляют цену исправления: обновление может ломать совместимость. Эта цена не должна снижать приоритет, она влияет на способ: если пакет нельзя обновить сегодня, нужна временная мера, а не пониженный класс.
Матрица решений: как свести сигналы в класс
Чтобы решения не зависели от настроения, сведите сигналы в короткую таблицу. Ниже пример, который можно взять за основу. Сроки по классам заданы в вашем регламенте (шкала для небольшой команды есть в статье об управлении уязвимостями), здесь только условия отнесения к классу.
| Условия | Класс | Что делаем |
|---|---|---|
| Эксплуатация идёт или есть готовый способ, система видна снаружи, за ней данные клиентов или деньги | Критический | В тот же день временная мера, исправление вне обычного релиза |
| Оценка высокая или критическая, система видна снаружи, уязвимая часть достижима, эксплуатации пока нет | Высокий | В ближайший релиз; временная мера, если релиз не скоро |
| Высокая оценка, но система только во внутренней сети или функция не вызывается | Средний | В один-два релиза, с записью причины понижения |
| Низкая оценка, нужен вход и участие пользователя, данных за ошибкой нет | Низкий | По плану вместе с другими работами |
| Две средних находки в одной цепочке: одна даёт вход, другая даёт доступ к данным | Выше каждой по отдельности | Оценивается как одна находка, цепочка записывается в реестре |
Цепочки стоит запомнить отдельно. Сканеры оценивают находки по одной, а нарушитель действует связкой. Слабая проверка адреса вместе со средней ошибкой в обработке файла может дать то, чего не даёт ни та ни другая по отдельности. Такие связки видны человеку, который знает приложение, и почти не видны автоматике.
Разбор пяти условных находок
Ниже условные примеры: выдуманные находки в выдуманных сервисах, чтобы показать ход рассуждения, а не результаты какой-либо проверки.
| Находка | Оценка по описанию | Что выяснили | Решение |
|---|---|---|---|
| В библиотеке разбора изображений ошибка выполнения кода | Критическая | Библиотека подключена, но используется только во внутренней утилите администратора; файлов от клиентов она не получает | Средний класс: обновить в ближайшие релизы, причину записать |
| В публичной странице восстановления доступа возможно внедрение скрипта | Средняя | Страница видна снаружи, пользователи — клиенты; через неё можно перехватить вход | Высокий класс: исправить в ближайший релиз |
| В системном пакете базового образа ошибка с высокой оценкой | Высокая | Пакет есть в образе, но служба из него не запускается и не доступна из сети | Низкий класс: пересобрать образ в плановом порядке |
| В каркасе приложения ошибка удалённого выполнения кода, способ эксплуатации опубликован | Критическая | Версия работает на публичном сервисе с данными клиентов | Критический класс: временная мера сегодня, исправление в ближайшие дни |
| Не хватает защитного заголовка | Низкая | Сервис хранит персональные данные, в опроснике клиента есть прямой вопрос | Средний класс: исправить вместе с настройками, ответить клиенту |
Из пяти находок оценка и итоговый класс совпали дважды. Это нормально: цель не в том, чтобы спорить с числом, а в том, чтобы у каждого отклонения была записанная причина. Через месяц, когда спросят, почему критическую находку не закрыли за день, ответ лежит в реестре, а не в чьей-то памяти.
Типичные ошибки при расстановке приоритетов
- Сортировка по числу. Список выстроен по убыванию оценки, и первые строки — это один и тот же класс ошибок в зависимостях, в то время как проблема с правами лежит ниже. Сначала отсекаем недостижимое, потом сортируем.
- Понижение «по ощущению». «Это внутренний сервис, он безопасен» без записи, кто проверил сеть. Снижать класс можно, но с причиной, проверкой и датой пересмотра.
- Самодельные баллы. Команда придумывает свою формулу со множителями. Через квартал никто не помнит, откуда взялись коэффициенты. Три-четыре класса и таблица условий работают лучше.
- Забытые цепочки. Каждая находка оценена отдельно, связки не рассматривались. Раз в квартал просматривайте открытые средние находки одного сервиса вместе.
- Одинаковый срок для всех. «Всё высокое за две недели» превращает срочное в обычное. Срок задаётся классом, а не оценкой сканера.
- Приоритет без владельца. Решение принято, но записано «команда разработки». Нужен человек с фамилией.
Хорошая проверка процесса: возьмите десять последних закрытых находок и спросите по каждой, почему она закрыта именно тогда. Если ответа нет в записи, приоритеты работают как слухи.
Как записать решение, чтобы его можно было защитить
Решение о приоритете — документ, а не реплика на созвоне. Достаточно пяти полей в карточке находки:
- Оценка источника. Число и слово из сканера или каталога, как есть, без правок.
- Что выяснили. Ответы на пять сигналов одной-двумя фразами.
- Итоговый класс. Критический, высокий, средний или низкий.
- Кто решил и когда. Человек, а не команда.
- Когда пересмотреть. Дата, после которой решение проверяют заново: например, если систему откроют наружу или выйдет способ эксплуатации.
Последнее поле важно для понижений. Недостижимая сегодня функция становится достижимой после следующего релиза, и тогда запись о понижении без даты превращается в мину. Поэтому понижение класса — это всегда исключение с датой, как описано в разделе о принятии риска в статье об управлении уязвимостями.
Чем помогают инструменты, а где нужен человек
Автоматика хорошо делает три вещи: собирает находки из разных источников в одном месте, подтягивает оценки и сведения об эксплуатации, показывает, в каких выпусках встречается уязвимый пакет. Последнее возможно, если при сборке создаётся перечень состава выпуска.
Человек нужен для трёх вещей: ответить, достижима ли функция, оценить ценность данных за ошибкой и увидеть цепочку. Поэтому ставка на «автоматическую приоритизацию» чаще всего означает автоматическую сортировку по числу, и ту же ошибку, но быстрее. Разумное разделение таково: инструмент предлагает порядок, а человек раз в неделю за полчаса подтверждает или меняет его с записью причины. Как выбрать проверки и не утонуть в срабатываниях, см. статью «SAST, DAST, SCA: в чём разница».
Что делаем мы и с чего начать
Начинаем с обследования: 200 000 ₽ и 2–3 недели за одно-два приложения, 350 000 ₽ и 3–4 недели, если приложений несколько. Составляем инвентарь, берём накопленные находки и вместе с вашим техническим руководителем прогоняем их через таблицу условий, чтобы получилась ваша матрица решений, а не наша. Обследование вычитается из первого этапа, если продолжаете с нами, а матрицей можно пользоваться и без нас.
Дальше, если нужно, лёгкий пилот (150 000–400 000 ₽) настраивает реестр, классы и проверки в сборке, а сопровождение (20 000 / 60 000 / 120 000 ₽ в месяц) берёт еженедельный разбор очереди. Мы не дежурим круглосуточно, не ведём SIEM, не проводим пентест боевых систем и аттестацию, лицензии ФСТЭК у нас нет. Всё остаётся в вашем репозитории и трекере. Цены и сроки — на странице «Тарифы», описание услуги — на странице «Управление уязвимостями». Если находок ещё нет, начните с аудита безопасности или ревью кода.
Частые вопросы
Как приоритизировать уязвимости, если их сотни?
Сначала отсечь недостижимое: уязвимые функции, которые не вызываются, и пакеты, которых нет в боевом выпуске. Затем разделить оставшееся по четырём классам, учитывая эксплуатацию, видимость из интернета и ценность данных. Критических обычно остаются единицы, остальное идёт по плану.
Достаточно ли ориентироваться на оценку CVSS?
Нет. Она описывает тяжесть ошибки вообще и не знает вашу систему, настройки, данные и меры защиты. Оценка годится как стартовая точка и как общий язык с подрядчиками и клиентами, а порядок работ определяют ответы на вопросы о контексте.
Что делать, если у уязвимости высокая оценка, но она недостижима?
Понизить класс до среднего или низкого, записать причину и проверку (функция не вызывается, версия не используется, сервис закрыт сетью) и поставить дату пересмотра. Обновление при этом всё равно планируют, просто не срочно.
Нужно ли считать собственную оценку по окружению?
Расчёт баллов обычно не нужен. Достаточно письменного решения: класс, причина, владелец, дата пересмотра. Свои числа создают ложную точность и разъезжаются между командами.
Чем отличается приоритизация от управления уязвимостями?
Приоритизация — один шаг: решить, что и в каком порядке закрывать. Управление уязвимостями включает ещё инвентарь, реестр, сроки, проверку закрытия, исключения и ритм разборов.
Помогают ли модели вероятности эксплуатации?
Да, как дополнительный сигнал: они помогают упорядочить длинный список находок с одинаковой оценкой. Но они не знают, как устроена ваша система, поэтому решение за человеком, который знает приложение.
Как приоритизировать уязвимости в зависимостях?
По тому же правилу: какие выпуски содержат пакет, вызывается ли уязвимая функция и доходят ли до неё внешние данные. Ответить быстро позволяет перечень состава, создаваемый при каждой сборке. Без него поиск по выпускам делается вручную.
Сколько стоит такая работа?
Обследование — 200 000 ₽ за одно-два приложения (350 000 ₽ за несколько), оно вычитается из первого этапа, если продолжаете с нами. Лёгкий пилот с реестром и проверками в сборке стоит 150 000–400 000 ₽, сопровождение — 20 000 / 60 000 / 120 000 ₽ в месяц.