Контроль состояния процесса Управления Уязвимостями

Что такое уязвимости

Начнем с определений. Уязвимости – это, упрощенно, баги, которые могут использоваться злоумышленниками, ошибки.

Можно вспомнить старый мем про то, что такое фича и что такое бага: фича – это задокументированная бага. Уязвимость – это тоже бага, но такая, которой может воспользоваться злоумышленник для реализации зловредных действий в инфраструктуре.

Специалистам по безопасности в организации необходимо эти уязвимости определить и исправить в рамках процесса, который называется Vulnerability Management.

Vulnerability Management

Он обычно изображается в виде цикла. В рамках этого цикла необходимо детектировать уязвимости в инфраструктуре, определить самые приоритетные и исправлять их в первую очередь. По всем уязвимостям заводятся задачи на исправление, затем уязвимости устраняются и проверяется, что они действительно устранены.

Существует руководство в ФСТЭК – нормативный документ, из которого взято это изображение.

Западные источники описывают процесс Vulnerability Management примерно так же. Это изображение из Gartner. В любом случае, это всегда процесс детектирования уязвимостей и приоритетного их исправления.

Мне не нравится представление этого процесса в виде цикла, потому что его можно воспринимать так, будто сначала одна команда детектирует уязвимости, затем приоритизирует найденное, затем заводит задачи и выполняет другие шаги последовательно.

Возможно, когда Vulnerability Management был деятельностью, которой занимались раз в квартал, раз в полгода или раз в год в рамках аудитов, это действительно выглядело именно так. Сейчас это регулярные процессы. Необходимо постоянно проводить инвентаризацию инфраструктуры, постоянно детектировать уязвимости, постоянно заводить задачи на их устранение. Поэтому не стоит воспринимать этот цикл буквально. Его правильнее рассматривать как перечень подпроцессов.

Руководство по организации VM-процесса ФСТЭК

Как строить процесс Vulnerability Management, подробно описано в РУКОВОДСТВЕ ПО ОРГАНИЗАЦИИ ПРОЦЕССА УПРАВЛЕНИЯ УЯЗВИМОСТЯМИ В ОРГАНЕ (ОРГАНИЗАЦИИ) https://fstec.ru/dokumenty/vse-dokumenty/spetsialnye-normativnye-dokumenty/metodicheskij-dokument-ot-17-maya-2023-g.

Схема выглядит примерно так.

На входе есть информация об уязвимости, неважно, получена она из сканера или из другого источника. В конце уязвимость исправляется тем или иным способом.

Каким образом она может исправляться?

Либо мы говорим, что эта уязвимость для нас неприменима. Либо говорим, что эта уязвимость должна быть исправлена в приоритетном порядке. Либо, что она должна быть исправлена в плановом порядке. Либо, что уязвимость должна быть закрыта с помощью компенсирующих мер: например, отключением уязвимого сервиса и другими подобными способами.

Основное ограничение этого руководства в том, что самому детектированию уязвимостей уделяется очень мало внимания. По сути, этот квадрат – все, что связано с детектированием уязвимостей. В начале предлагается просканировать инфраструктуру, получить список уязвимостей, а в конце снова просканировать и убедиться, что уязвимостей нет.

Подробностей не дается. Также не дается подробного описания управления активами в инфраструктуре. Предполагается, что вы знаете обо всех активах и можете проводить на них работу по устранению уязвимостей.

Поэтому остается пространство для дополнения этого руководства. Его я заполняю своим подходом, который описываю как базовую оценку состояния процесса управления уязвимостями (БОСПУУ).

Детекты

Если вы хотите построить нормальный процесс Vulnerability Management в организации, необходимо гарантировать, что ваше решение для детектирования уязвимостей, сканер уязвимостей – будь то Nessus, MaxPatrol, Qualys или любое другое решение – содержит всю информацию об уязвимостях, которые могут встретиться в инфраструктуре. Методы детектирования должны быть достаточны для того, чтобы эти уязвимости действительно детектировались, а сами детекты оперативно поступали в решение. Если процесс запаздывает, если сканер начинает получать информацию о том, как детектировать уязвимости, например, через неделю, а за эту неделю инфраструктуру уже взломали через эту уязвимость, смысл такого процесса быстро теряется.

Сравнение сканеров уязвимостей

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

Тем не менее, в 2024 году было сравнение от компании Pentest Tools. Они взяли несколько коммерческих и open source решений и сравнили их между собой.

В качестве таргетов были взяты уязвимые образы из проекта vulhub. В основном это open source веб-сервисы. Они были просканированы в режиме без аутентификации, поэтому уязвимости, связанные, например, с повышением привилегий на хосте, таким образом не детектировались. В этом режиме были просканированы 167 уязвимых программных продуктов, и получилась такая картина.

Не стоит слишком обольщаться результатами, потому что победили сами Pentest Tools: скорее всего, за счет хорошей заточенности под конкретный набор софта. Тем не менее, это сравнение показывает, что не все сканеры одинаковые и не все из них одинаково хорошо детектируют уязвимости.

Сканер может не поддерживать часть программного обеспечения. В инфраструктуре могут быть активы, которые не поддерживаются сканером полностью или частично. Например, могут быть сетевые устройства, которые сканер уязвимостей не поддерживает. Могут быть Windows-хосты, для которых часть программного обеспечения не поддерживается. Возможна ситуация, когда заявлена поддержка определенного софта, но детектируются не все возможные уязвимости. Либо уязвимости детектируются только в определенных режимах. Например, в режиме pentest-сканирования они детектируются, а в режиме сканирования с аутентификацией – нет, и наоборот.

Эта область слабо регулируется. Можно выпустить на рынок сканер, который детектирует одну уязвимость для одного программного продукта, и формально это будет сканер уязвимостей. Можно получить сертификат ФСТЭК, и все будет считаться корректным. Это похоже на ситуацию, когда черный – это цвет, белый – это цвет, и черно-белый телевизор считается цветным.

Поэтому при выборе сканера уязвимостей ответственность ложится на пользователя. Если вы выбираете сканер, спросите вендора, умеет ли он работать с вашими активами. Если есть возможность сравнить несколько решений, сравните, как они сканируют один и тот же актив, и сопоставьте найденные уязвимости. Скорее всего, вас ждет немало сюрпризов.

Пример проблем с детектированием в Linux

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

Если софт установлен из официального репозитория вендора, все достаточно просто. Есть бюллетени безопасности вендора, где указано, какие пакеты каких версий подвержены каким уязвимостям. Для такого случая написать сканер уязвимостей несложно.

Проблемы возникают, если софт установлен способами, которые перечислены в этом списке:

• Из подключенного стороннего репозитория,

• Из пакета (вендорского или самосборного) стандартной пакетной системы дистрибутива (deb, rpm), который принесли на хост руками,

• Из альтернативных пакетов для распространения софта (snap, flatpak, appimage и т.д.),

• Из средств распространения модулей (pip, conda, npm и т.д.),

• Из образа контейнера (docker, podman и т.д.),

• Из исходников софта, при этом сборка софта может происходить на том же хосте или собранный софт может быть перенесен в виде бинарных файлов.

Способов установки много. Соответственно, такой софт с высокой вероятностью станет проблемой с точки зрения детектирования уязвимостей.

Возникает вопрос, что с этим делать. Можно пытаться договариваться с вендором и просить поддержать такие способы установки. Либо решать этот вопрос процессно: например, отказаться от способов установки софта, которые не поддерживаются используемыми сканерами уязвимостей.

Анализ и задачи

Предположим, детектирование уязвимостей налажено, уязвимости выявлены. Дальше нужно перейти к их исправлению. Обычно уязвимостей в инфраструктуре тысячи или десятки тысяч. В первую очередь необходимо исправлять наиболее критичные.

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

Не всегда очевидно, зачем заводить задачи. Кажется, что можно просто отправлять отчеты, а дальше специалисты сами будут исправлять. К этому вопросу мы еще вернемся.

Существует несколько способов определять критичность уязвимостей. Наиболее распространенный – Common Vulnerability Scoring System (CVSS). Это, по сути, заполнение определенных опросников.

Если вы работаете в государственной организации, для вас основным может быть метод оценки критичности уязвимостей по методике ФСТЭК. Эта методика использует CVSS, причем не только Base Score, который можно взять из National Vulnerability Database, но и Temporal и Environmental показатели. В результате требуется заполнить достаточно большое количество опросников, чтобы получить итоговое значение CVSS.

Вторая часть оценки связана с инфраструктурой.

Методика учитывает тип компонента информационной системы, подверженного уязвимости (К). Необходимо понимать, относится ли уязвимость к автоматизированным рабочим местам, серверам, телекоммуникационному оборудованию или средствам защиты информации. Все активы должны быть протипизированы, и должно быть понятно, какой именно актив подвержен уязвимости.

Второй параметр – количество уязвимых компонентов информационной системы (L). Например, если это десктопная уязвимость, необходимо понимать, какой процент десктопов ей подвержен. Для этого требуется сканирование всех десктопов, то есть фактически выполнение требования по покрытию инфраструктуры процессом управления уязвимостями.

Третий параметр – влияние уязвимости на эффективность защиты периметра системы (Р). Нужно понимать, какие системы размещены на периметре. В любом случае это полезная информация, но для применения методики необходимо, чтобы периметр был приведен в упорядоченное состояние.

После получения всех этих данных можно рассчитать итоговое значение, подставив параметры из таблицы в формулу. Расчет выполняется достаточно быстро.

Проблема методик оценки критичности уязвимостей

У оценки критичности уязвимостей есть существенная проблема. Наиболее значимый фактор для критичности уязвимости – используется ли она в реальных атаках прямо сейчас.

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

В методике ФСТЭК этот фактор не учитывается. Наличие эксплойта в CVSS учитывается, но с небольшим весом, поэтому влияние этого фактора можно считать недостаточным. Этот отбор приходится делать вручную.

Если в прошлом году в National Vulnerability Database было добавлено около 40 000 уязвимостей, то трендовых уязвимостей нами отобрано 74.

Задачи

Вопрос заведения задач не всегда кажется очевидным. Рассмотрим его с прагматичной точки зрения.

Если проводится аудит или происходит серьезный инцидент, начинается разбор причин. Часто выясняется, что инцидент произошел из-за эксплуатации уязвимости. Затем начинают разбираться, почему эта уязвимость не была исправлена. В этот момент ответственность часто пытаются переложить на специалиста по управлению уязвимостями.

Задача процесса Vulnerability Management и специалиста по Vulnerability Management – не оказаться крайним в этой ситуации. Для этого специалист должен показывать, что он:

• Своевременно и достаточно полно анализировал инфраструктуру.

• Оперативно информировал ответственных о найденных уязвимостях и связанных рисках, ставил им задачи на исправление.

• Контролировал выполнение задач ответственными и указывал, если задачи не были выполнены в срок.

• Особое внимание уделял критичным уязвимостям из рассылок регуляторов – ФСТЭК, ЦБ, НКЦИ. Если инцидент произойдет через такие уязвимости, ситуация будет выглядеть крайне плохо.

Как делать все это без задач? Я, честно говоря, не знаю. Если задача на устранение уязвимости не заведена, ответственный всегда может сказать, что он не знал о проблеме и не понимал, что это необходимо было делать.

Охват

Охват – еще одна важная тема. Проблема в том, что можно выстроить отличный Vulnerability Management процесс на десяти хостах: там все хорошо детектируется и устраняется. При этом в организации могут быть десятки тысяч хостов, и на остальных – полный хаос. Когда произойдет инцидент, атака с большой вероятностью пойдет именно через те хосты, которые не охвачены процессом.

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

Целевые активы – это активы, получив доступ к которым можно реализовать недопустимое событие.

Недопустимое событие – это событие, которое для бизнеса или организации является критически неприемлемым. Перечень событий должен согласовываться с высшим руководством. Для банка это может быть утечка клиентских данных или хищение крупной суммы денег. Для транспортной компании – техногенная катастрофа с угрозой человеческим жизням. От этого и нужно отталкиваться при определении целевых систем.

Ключевые системы – это системы, через которые можно попасть на целевые, то есть какой-то промежуточный срез.

Обычные системы – все остальные.

Также необходимо гарантировать, что нет активов без назначенных ответственных. Если актив существует, должно быть понятно, кто отвечает за устранение уязвимостей и на кого заводятся задачи. Не должно быть активов без согласованного SLA. Задачи создаются с пониманием сроков их выполнения. Если сроки нарушаются, должна происходить эскалация.

Проблемы согласования SLA с бизнесом

С SLA возникает отдельная сложность. При попытке согласовать их с ИТ и бизнесом часто выясняется, что некоторые системы, по мнению владельцев, вообще нельзя обновлять никогда.

Это сложный и долгий процесс – приводить такие ожидания в порядок и вырабатывать приемлемые SLA. В государственных организациях с этим проще: можно опираться на требования регуляторов. В методике оценки критичности уже заданы сроки устранения уязвимостей определенной критичности, вплоть до недели.

При этом подход может быть достаточно гибким. Главное, чтобы уязвимости в принципе исправлялись. Если в инфраструктуре есть уязвимости, которые не исправлялись больше года, значит, в процессе что-то работает неправильно.

Выполнение SLA

Если все предыдущие подпроцессы выстроены, процесс Vulnerability Management в основном сводится к контролю SLA.

По сути, вы смотрите на свои скоупы, которые, как правило, заведены по системам. В этих скоупах находятся целевые, ключевые и обычные активы, а также плановые и приоритетные задачи на устранение уязвимостей.

Задачи, которые выполняются в рамках SLA, и команды, которые их выполняют, необходимо отмечать и показывать как положительный пример. По тем задачам, которые не укладываются в SLA, вопрос должен эскалироваться – как по самим задачам, так и по ответственным командам.

Так процесс выглядит в целом.

Часто говорят: все это хорошо, но невозможно сделать охват на 100%. Предлагают сделать «светофорчик» или уровень, который считается приемлемым.

На это можно ответить так: хотелось бы, но, по сути, это профанация. Если процесс управления уязвимостями охватывает 90% активов, а про оставшиеся 10% неизвестно ничего – они не классифицированы, у них нет SLA и ответственных, – то именно в этих 10% с наибольшей вероятностью будет максимальный риск. Эти активы, как правило, не обновляются, а уязвимости на них не исправляются годами и имеют максимальную критичность.

Поэтому необходимо стремиться к 100% охвату. Можно отслеживать прогресс: сначала 20%, потом 70%, и это действительно хороший результат. Но останавливаться на 70% не стоит.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAMLEAD&CIO EVENT.