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

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

Также в рамках данной статьи я раскрою основные мероприятия на каждом этапе процесса управления уязвимостями, приведу примеры и типовые ошибки построение процесса VM.

Управление уязвимостями (vulnerability management, VM) – непрерывный, циклический процесс выявления и устранения уязвимостей в инфраструктуре организации и состоит из следующих этапов:

• Инвентаризация активов

• Выявление уязвимостей

• Выработка рекомендаций

• Устранение уязвимостей

• Контроль устранения уязвимостей

Теперь перейдем к рассмотрению каждого из этапов VM.

Инвентаризация.

Инвентаризировать активы можно готовыми решениями, опенсорсными продуктами или самописными скриптами. Решение о том, что выбрать исходит из Вашего бюджета желания.

Однако, тут главный вопрос стоит в том, чтобы охватить как можно больше устройств в своей сети и собрать необходимую по ним информацию (ip-адрес, имя устройства, операционная система, список установленного программного обеспечения, пользователи системы, наличие установленных обновлений безопасности, открытые TCP/UDP порты и т.д.).

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

Советы:

• Грамотно раздробить активы на более мелкие группы, чтобы ошибок при инвентаризации было как можно меньше. Самый яркий пример - у Вас большая организация, головной центр которой находится в Москве, а филиалы (офисы) в разных городах нашей необъятной. Если Вы запустите сканирование в 15 часов по Москве, то Ваши товарищи во Владивостоке просто передадут Вам привет, ибо в 22 часа на работе уже никого не будет, и как следствие все машины будут выключены.

• Правильно настроить время сканирования активов (исходя из определенных ранее групп). Например, если у вас есть контроллеры домена, то они работают 24/7. Стоит сканировать их в нерабочее время (ночью), когда они минимально загружены. А вот с пользовательскими машинами ситуация обстоит совсем наоборот. Их лучше сканировать в рабочее время (днем), когда машины включены.

• Не забывать  про сетевую доступность до сканируемых активов (поверьте, об это тоже можно обжечься).

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

Выявление уязвимостей.

Теперь когда у нас есть данные инвентаризации активов, можно и перейти к уязвимостям.

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

После сбора списка уязвимостей следует "отсеять" неактуальные. Например если в организации на рабочих станциях установлены только ОС Windows и Linux, то уязвимости в macOS (CVE-2022-22620 , CVE-2022-22675, CVE-2022-22676) явно не стоит ресерчить (по крайней мере в рамках рабочих процессов).

После отсеивания, появляется главный вопрос: "В каком порядке начинать обрабатывать уязвимости?".

Ответ прост - приоритизация. Не стоит "кидаться" ресерчить всё подряд. Стоит выстроить тайную формулу, по которой будет определятся степень критичности конкретной уязвимости для Вашей организации.

Конечно в интернете таких формул Вы не найдете, но советую, при создании формулы обратить внимание на: критичность активов (контроллеры домена, телекоммуникационное оборудование, пользовательские активы...), скоринг уязвимости в системе CVSS, наличие эксплоитов или PoC-ов в открытых источниках, epss скоринг и т.д.

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

Советы:

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

• Разберитесь с процессам Threat Intelligence и Threat Hunting (опционально). В процессе VM это не обязательно, но прокачает именно Вас.

Выработка рекомендаций

При выработке рекомендаций стоит выделить две сущности - mitigations (набор смягчающих решений) и официальное решение от производителя (разработчика).

У обеих сущностей есть свои плюсы и минусы.

Mitigations - не всегда позволяют полностью закрыть уязвимость на ваших активах, однако снижают риск её эксплуатации.

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

НКЦКИ предлагает алгоритм принятия решения по обновлению критичного ПО, не относящегося к open-source:

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

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

Непрерывность работы проще всего показать на примере:

В ходе ресерча уязвимости  CVE-2021-38631 не удалось выработать смягчающих мер и было принято решение установить обновление безопасности  KB5007186. После инсталляции на уязвимые активы, перестали работать все сетевые принтеры для данных активов. Как итог, работа в организации "встала", специалист получил по шапке и пошел откатывать обновление со всеми вытекающими последствиями.

Советы:

• Тесирование! Всегда применяйте свои рекомендации сначала к тестовым стендам, а после успешных испытаний (в течении нескольких дней/недель) переходите на "боевые условия". Так и только так!

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

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

Тут следует упомянуть такой процесс как Patch Managment. Про процесс Patch Managment есть много толковых статей (например тут и тут). По-хорошему этим процессом должны заниматься администраторы инфраструктуры организации, поэтому для нас (специалистов по управлению уязвимостями) связь процессов PM и VM будет выглядеть следующим образом:

*на рисунке под решающим правилом понимаются не обновления безопасности, а рекомендации по закрытию уязвимостей, выработанные специалистом.

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

Советы:

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

• Доведение рекомендаций до администраторов лучше всего проводить задачами (например в какой-нибудь Incident Response Platform, или Project Management Tool), с установлением срока выполнения и списком уязвимых активов. Не стоит забывать про изолированность вашей IRP или PMT со стороны интернета (мы же тут про секьюрность пишем).

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

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

Контроль устранения уязвимостей

Логическое завершение любой итерации процесса управления уязвимостями. На данном этапе всё просто.

Если администратор инфраструктуры говорит: "Уязвимость CVE-2021-40444 на устройствах A,B,C...Z закрыта по выработанным рекомендациям", то следует выборочно полностью проверить данные активы (A,B,C...Z) на наличие уязвимости. Процесс проверки лучше всего автоматизировать (сканеры безопасности, опенсорсные решения, самописные скрипты), чтобы не тратить время на перебор руками.

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

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

Советы:

• Следить за ходом выполнения задачи (состояние, остаток времени). Это дело лучше автоматизировать. Например написать бота в телеграмме корпоративном мессенджере, который будет "отстукивать" Вам, если сроки выполнения задачи подходят к концу, а состояние по прежнему - "запланирована" .

• Сильно не загружать администраторов. Если скопом начать закрывать сразу все уязвимости, то в 90 % случаев с инфраструктурой можно попрощаться.

Описанные мной этапы не являются парадигмой или единственным верным решением при построении процесса управления уязвимостями. Всегда можно что-то "докрутить".

Я просто хотел поделится информацией как с людьми, не занимающимися вопросами управления уязвимостями, так и с действующими специалистами в процессе VM.

В комментариях приветствую всех для обсуждения, советов и поправок)

P.S: в четвертый раз ссылка на мою прошлую статью, которая отлично синергирует с этой.

P.S.S.: Передаю привет Алексею. (@Rock8848star)