Введение

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

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

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

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

Исходные данные:

• система CMDB;

• любой сканер уязвимостей;

• программист CMDB;

• время и желание.

Подготовительный этап

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

Поэтому первая задача — это определиться с тем, кому какой сервер принадлежит, я начал решать проблему поэтапно в таком порядке:

• определил список систем (бизнесов, сервисов, кто как называет);

• выгрузил список всех сетей c сетевого оборудования;

• определил какой системе принадлежит каждая сеть;

• определил какие сети общие - те сети, в которых есть серверы более чем одной системы и выставил для таких сетей дефолтную систему «Корпоративные ресурсы», себя сделал ее «Менеджером инцидентов»;

• определил какие серверы в общих сетях каким системам принадлежат.

К примеру, вот такая CMDB с сетями получилась:

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

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

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

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

Инциденты

Для нас уязвимость – это инцидент. Соответственно результат сканирования должен приводить к созданию инцидента. Но как понять кто должен отвечать за инцидент? Мы назвали таких людей «Менеджер инцидента», обычно это главный прикладной администратор или иное лицо ответственное за работу серверов системы, или всей системы в целом.

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

На скриншоте система «Корпоративные ресурсы» как раз и является той самой дефолтной на которую валятся уязвимости IP адресов из общих сетей, по ним руками приходится разбирать чей сервер и закреплять IP за какой-то системой. Как происходит разбор будет чуть ниже.

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

Что интересного мы видим в карточке:

• Уникальное «Название уязвимости» чтобы уязвимости не двоились при последовательных загрузках одних и тех же уязвимостей. Я завязался на уникальных параметрах, что выдавал сканер уязвимостей: IP сервера, уровень уязвимости, Plugin ID (идентификатор уязвимости), порт и протокол. Заодно просто по «Названию уязвимости» примерно понятно, о чем она. Если два раза загрузить одну и ту же уязвимость, всего лишь будет обновлена «Дата повторного обнаружения».

• Plugin ID – связь собственно с самой уязвимостью из базы уязвимостей:

  Поля информации об уязвимости

• Risk Factor – собственно уровень опасности уязвимости, уязвимости уровня Critical должны быть устранены незамедлительно.

• Раздел «Комментарии» – раздел для возможности переписки по уязвимости:

  Раздел комментарии в карточке уязвимости

  Информация о каждом комментарии падает мне уведомлением в почту:

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

• Вкладка «Инциденты по устранению уязвимости» - перечень инцидентов, в которых данная уязвимость когда-либо была, то есть при наличии как минимум двух инцидентов можно судить о качестве работы Менеджера инцидентов.

• Кнопки «Принять риск» и «Устранена» для управления инцидентом, соответственно:

  • «Принять риск» - уязвимость переходит в статус «Отклонена». Если при следующей загрузке отчета от сканера уязвимостей содержащем информацию об этой же уязвимости по ней не будет создан еще один инцидент;

  • «Устранена» - уязвимость устранена, риск её эксплуатации отсутствует. Если при следующей загрузке отчета от сканера уязвимостей содержащем информацию об этой же уязвимости по ней будет создан еще один инцидент, а сама уязвимость будет переведена в статус «Новая».

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

Удалили ее и добавили кликабельную таблицу к инциденту, конечный вид таблицы с уязвимостями в инциденте получился следующим:

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

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

Так что же делать с уязвимостями?

Я предусмотрел следующие действия:

• Принять риск – «Статус» уязвимости переходит в статус «Отклонена», риск эксплуатации принят Менеджером инцидента, при этом Менеджер инцидента должен указать обоснование, обоснование переносится в раздел «Комментарии» у уязвимости, информация о комментарии письмом падает мне как безопаснику для оценки действий Менеджера инцидентов;

• Устранена – Менеджер инцидентов устранил уязвимость сам либо получил отчет фактического исполнителя заявки на устранения уязвимости и переводит уязвимость в статус «Устранена», в случае если уязвимость фактически не была устранена, то при повторной загрузке отчета сканера уязвимостей, у уязвимости статус вернется в «Новая» и обновится «Дата повторного обнаружения»;

• Уязвимость не относится к системе – открывает форму выбора другой системы из перечня

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

• Создать заявку на устранение – открывает форму создания новой заявки с выбором исполнителя:

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

• Заявка будет отображена в специальном разделе инцидента:

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

• Пример такой заявки:

  Пример заявки на устранение выбранных уязвимостей

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

По результату реализации данной системы управления уязвимостями: 

• Менеджеры инцидентов систем отвечают за уязвимости, несут за ответственность за их устранение;

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

Что еще полезного?

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

Для эффективного управления уязвимостями потребуется регламент сканирования уязвимостей, инструкция по устранению уязвимостей.

Реализовали учет дат, когда каждая сеть была сканирована последний раз:

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

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