Модуль «Управление уязвимостями» на платформе Security Vision

Данила Луцив, Руслан Рахметов, Security Vision

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

Рис.1. Карточка объекта «Уязвимость»

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

Анализ результатов отчетов - безусловно важная, но не главная проблема специалистов по информационной безопасности, в чьей зоне ответственности оказался процесс управления уязвимостями. Примерно половина клиентов называет главной проблемой взаимодействие с IT-отделом. Как договориться об окнах сканирования, как сформировать заявки на устранение, как доказать необходимость установки патча и актуальность уязвимости для конкретного окружения, как учесть компенсирующие меры и проверить, что уязвимость устранена? В Модуле Управления Уязвимостями мы постарались продумать все узкие места и слепые зоны, которые возникают у специалистов ИБ, для того чтобы процесс анализа, обогащения и коммуникации с другими отделами был прозрачным, удобным и максимально автоматизированным.

Как не нажить врагов из IT-отдела и бизнес-подразделений?

Процесс обнаружения уязвимостей в большинстве организаций начинается с активного сканирования. Как часто стоит выполнять сканирование? С точки зрения полноты обнаружения ответ конечно же «чем чаще, тем лучше». Однако очевидно, что сканер уязвимостей оказывает влияние на систему, которое может непредсказуемо повлиять как на производительность, так и на функционал. Эта ситуация отягощается еще и тем, что нерадивые IT-специалисты часто спекулируют в объяснениях сбоев в информационных системах причинами, связанными со сканированием уязвимостей. «Кто все поломал?» – «Ну конечно сканер. Давайте его отключим, от него только вред». Подразделение киберзащиты должно быть готово к подобного рода вопросам и «предложениям». В платформе Security Vision в рамках процесса классификации активов бизнес-владелец систем и технический администратор устанавливают для системы допустимые диапазоны сканирована, в рамках которых должен быть осуществлен процесс выявления уязвимостей. Каждая задача на сканирование для каждого сервера доступна для последующего анализа, в случае выявления негативного эффекта на системы. Инженер за считанные минуты сможет сказать, когда точно, с какой политикой и с какими ошибками началась и закончилась задача сканирования на конкретном оборудовании или рабочей станции. Если используемый в компании сканер поддерживает формирование политик и запуск сканирования через API, Security Vision может в полностью автоматизированном режиме следить за запуском соответствующих политик в указанный временной промежуток, информируя ответственных лиц о начале сканирования, завершении в установленный или не установленный период, его ошибках и результатах.

Рис 2. API – Запустить сканирование, создать политику, остановить сканирование

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

• MaxPatrol 8\10

• RedCheck

• Tenable Nessus\Security Center

• Qualys

• Rapid7

• SkyBox

• Penterra

В статье о Модуле Управления Активами мы уже касались уникального функционала обработки структурированных XML и JSON отчетов. Его применение в Модуле Управления Уязвимостями позволяет отрабатывать всю доступную информацию из многогигабайтных отчетов за считанные минуты. Оно ограничено лишь размерами доступной на сервере оперативной памяти, требование к которой составляет один к одному в соответствии с размерами отчета.   

Рис. 3. Поддерживаемые сканеры

Большинство решений по управлению уязвимостями при дедупликации, создании ссылок на активы и формировании инкрементальных отчетов используют одно лишь, всегда доступное свойство – IP адрес. Решение вполне понятное, но не лишённое недостатков: у одного актива может быть множество сетевых интерфейсов, IP адреса могут меняться и на месте одного устройства может появляться другое. В случае неаутентифицированного сканирования модуль Security Vison поступает аналогичным образом, однако, если учетные данные верны и из отчета возможно получить дополнительную информацию, такую как BIOS UUID и MAC адрес сетевого интерфейса, комбинация этих свойств выступает в качестве ключа дедупликации, однозначно идентифицируя обнаруженный актив, вне зависимости от изменения сетевых параметров и нейминга.

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

Рис. 4. Правила группировки

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

С точки зрения подразделения информационной безопасности, процесс управления вращается вокруг самой уязвимости и таких ее характеристик, как:

• параметры критичности уязвимости, которые могут быть:

• общие и неизменные, такие как тип уязвимости, ее вектор, последствия эксплуатации и т.д.

• временные, описывающие текущее состояние уязвимости, такие как наличие и зрелость рабочих эксплоитов

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

Все это в методологии CVSS именуется соответственно Base, Temporal и Environmental metrics.

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

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

Рис. 6. Карточка объекта Технический Актив (Модуль Управление уязвимостями)

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

• «Обновление не обнаружено — значит, сканируемый актив уязвим»

• «Какие уязвимости обнаружены? Все те, которые есть в бюллетене. Вот вам они через запятую»

• «А как понять конкретные характеристики каждой из этих уязвимостей, ведь все они уникальны и имеют свои CVSS вектора? – Ну, мы вставим один из векторов на наш вкус, остальные можете найти в интернете при желании»

Очевидно, что такой подход имеет ряд ограничений с точки зрения возможностей потенциального анализа контекста уязвимости. В качестве единицы учета было принято взять универсальный идентификатор уязвимости CVE или БДУ ФСТЕК, и только при их отсутствии собственные идентификаторы сканера. Главной причиной подобного рода декомпозиции информации стала необходимость анализа каждой конкретной уязвимости. Благодаря встроенной базе знаний и внешним аналитическим сервисам каждая из уязвимостей не только имеет конкретные, принадлежащие именно ей постоянные и временные характеристики CVSS, но и постоянно обновляемую из внешних источников информацию о наличии эксплоитов, упоминаниях в известных компьютерных атаках и фреймворках хакеров, а также способах устранения и компенсирующих мерах.

Дополнительным положительным эффектом подобного рода группировки стало то, что вне зависимости от количества сканеров, которые используются у клиента, аналитика производится по уникальным CVE\БДУ идентификаторам. Это дает возможность группировки информации из различных источников и позволяет выявить актуальную информацию о наиболее уязвимых хостах вне зависимости от количества источников.

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

Рис. 7. Аналитические сервисы (справочник)

В отличие от предыдущего направления анализа и категорирования, процесс устранения уязвимостей и взаимодействия с IT подразделениями в качестве основного объекта оперирует собственно технической задачей на устранение, то есть обновлением или компенсирующей мерой. Формирование подобного рода заявок происходит автоматически на основании Политики Устранения. Входными параметрами для подобного рода политик служат характеристики обнаруженной уязвимости, а также тип и характеристики уязвимого актива. В результате формируются заявки на устранение, снабженные приоритетом и согласованным SLA по устранению, при его наличии. Заявки, соответствующие указанной политике, могут автоматически транслироваться во внешнюю систему IT заявок. Security Vision поддерживает двустороннее взаимодействие со множеством современных тикетинг-систем, так что их интеграция не составит труда, а статусы, обновленные в одной из систем, автоматически будут обновлены в другой. Благодаря данным политикам специалисты кибербезопасности могут создавать критерии, по которым будет формироваться процесс не только регулярного, но и экстренного устранения, в случае, если обновление требуется для критических активов, доступ к которым с точки зрения сетевой топологии имеет большое количество пользователей. Аналогичным образом можно выстроить и заявки на тестирование, установив приоритет для установки в первую очередь на тех технических активах, группы которых соответствуют тестовым средам. Таким образом можно управлять процессом анализа потенциально отрицательных воздействий обновления.   

Рис. 8. Заявка на устранение

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

Как не забыть о принятых решениях?

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

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

Подписка на рассылки бюллетеней безопасности включена даже в ряд отраслевых стандартов, но сделать работу с ними удобной и автоматизированной пока удается крайне малому количеству решений по информационной безопасности. Многие уже внедрили у себя работу с бюллетенями НКЦКИ, однако не менее важная и полезная информация содержится в бюллетенях производителей программных и аппаратных решений. В платформе Security Vision реализована поддержка основных форматов бюллетеней производителей, таких как CVRF и OVAL. Бюллетени содержат не только списки уязвимостей и обновлений, но и конкретные технические рекомендации для дополнительной настройки, а также митигации уязвимостей, как в сфере расширенного логирования, так и непосредственные мероприятия по уменьшению или устранению поверхности атаки без применения обновлений.

Рис. 9. Справочник – Доступные источники бюллетеней

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

Как проанализировать прогресс и обнаружить слепые зоны?

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

Рис. 10. Дашборды и отчеты

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