Управление уязвимостями в CMDB

  • Tutorial

Введение

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

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

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

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

Что в итоге получилось

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

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

  • система CMDB (Naumen Service Desk в нашем случае);

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

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

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

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

Поэтому первая задача — это определиться с тем, кому какой сервер принадлежит. Под словом кому далее будем использовать термин система (бизнес, сервис, кто как называет, то есть такая сущность, объединяющая в себе используемые для выполнения конкретной бизнес-задачи или вспомогательной задачи ИТ активы). Примеры таких систем: система учета кадров, сайт компании, CRM-система.

Я начал решать проблему поэтапно в таком порядке:

  • определил список систем;

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

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

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

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

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

Перечень сетей компании
Перечень сетей компании

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

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

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

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

Инциденты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Перечень уязвимостей в текстовом виде
Перечень уязвимостей в текстовом виде

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

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

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

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

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

Перечень действий с уязвимостями
Перечень действий с уязвимостями

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

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

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

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

    Форма заявки на быстрое создание нового инцидента
    Форма заявки на быстрое создание нового инцидента

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для эффективного управления уязвимостями так же были разработаны:

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

  • инструкция по устранению уязвимостей (пользованию функционалом о котором идет речь в статье).

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

Учет даты последнего сканирования сетей в CMDB
Учет даты последнего сканирования сетей в CMDB

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

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

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

Где вы управляете уязвимостями?

  • 0,0%В компоненте сканера уязвимостей0
  • 16,7%В собственном подобном решении1
  • 16,7%В SGRC/SIEM или ином решении вендоров средств защиты информации (не разработчика сканера уязвимостей)1
  • 16,7%Услугу сканирования уязвимостей и организации устранения уязвимостей осуществляет иная компания1
  • 50,0%Не управляем уязвимостями3
  • 0,0%Иной вариант0

Кто у вас раздает задачи на устранение уязвимостей (отвечает за устранение уязвимостей)?

  • 50,0%Безопасник3
  • 0,0%Ответственный за сервер/систему к которой принадлежит сервер0
  • 0,0%Услугу сканирования уязвимостей и организации устранения уязвимостей осуществляет иная компания0
  • 50,0%Никто в явном виде не управляет уязвимостями3
  • 0,0%Иной работник0
Реклама
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее

Комментарии 16

    0
    Уважаемый автор, можно подробнее расписать про модуль CMDB Naumen Service Desk? Насколько известно, система заоблачных денег стоит
      +1
      Приветствую! В чем состоит вопрос?
      0

      Enterprise Ware как правило чудовищен с точки зрения интерфейса

        0
        Почему?
          0

          Потому что у пользователя нет выбора, что использовать. Что купили то и используют. А те кто выбирают, системой не пользуются

            0
            Как тогда утверждение соотносится со статьей?
            0

            А если интересует пример, то вот:
            https://m.habr.com/ru/post/470976/

          +1
          Круто! Мы радуемся, когда видим, что наша платформа помогает таким мотивированным и нацеленным на результат, как ты!
            0
            Реализуйте данный функционал по дефолту
              +1
              А у нас в целом есть решение — это процесса (практика) управления событиями и мониторингом.

              В этом решении Service Desk подключается к любым системам мониторинга. В том числе к системе мониторинга уязвимостей.

              И по факту выявления уязвимости (=события безопасности) создается инцидент. А дальше стандартная схема: выявление ответственного, информирование, устранение (или принятие риска и отмена).

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

              Также может инициироваться не только инцидент, но и изменение и проблема (она же риск).

                0
                Мы стараемся дать максимум уже на старте. Не всем нужна подобная функциональность именно в таком виде: вы не поверите, сколько существует разных вариантов решения одной типовой задачи в разных компаниях. Naumen SD — в том числе платформа, чтобы вы могли адаптировать её под свои нужды.

                Мы специализируемся в первую очередь на решение ИТ-задач, но надеюсь в ближайшем будущем мы совместим наш взгляд на уязвимости, как на события, инициирующие инцидент, и управление рисками.
                +1
                еще не хватает функционала управления рисками
                +1
                Добрый день, спасибо. Интересный подход к управлению уязвимостями. У меня несколько вопросов для вас, они скорее риторические:
                — как часто вы сканируете сеть? Просто если сканы периодические (раз в неделю/раз в месяц), то пометка «устранена» для по факту неисправленной уязвимости продлит время ее жизни в вашей сети, что может стать проблемой;
                  0
                  Да так и есть, сканирование периодическое, к сожалению невозможно накупить лицензий качественного сканера на все сетевые устройства (лицензирование у них за количество хостов), это финансово просто нереально. У вас иной подход?
                  0
                  И второй вопрос: как исполнители, кто у вас называется «Менеджер инцидента», тестируют патчи? Из своего опыта могу сказать, что установка некоторых патчей может негативно сказаться на работоспособности бизнес-приложений. Последние обновления для Windows 10, например, принесли проблемы в работе переферийных устройств на рабочих ноутбуках сотрудников, что повлияло на нагрузку на Help Desk.
                    0
                    Пока что каждый МИ решает сам как ему организовывать устранение уязвимостей. Не все уязвимости закрываются установкой нового ПО или обновлением старого.
                    Если речь про Win NT, то да, есть процесс проверки ПО в WSUS.

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

                  Самое читаемое