Инвентаризация активов ИТ-инфраструктуры для информационной безопасности: как собрать перечень и поддерживать его в актуальном состоянии
В большой компании картина почти всегда одинаковая. Систем много, а ответа на вопрос, что у нас есть и где это лежит, нет. SIEM пишет события. Мониторинг опрашивает узлы и строит графики, и в нем же кто-то пытается вести инвентаризацию, потому что хосты уже заведены. ITSM знает заявки и согласованные сервисы. Рядом лежат локальные базы, выросшие исторически, и файл Excel на чьем-то диске. Его все считают временным, пока он на полгода не становится единственным источником правды.
ИБ в этой картине оказывается в странной позиции. Защищать формально надо все. Но что именно входит в это «все», целиком не назовет никто. Когда случается инцидент или проверка, вместо расследования начинается аудит инфраструктуры с нуля. Кто владелец, какой контур, какой адрес, отвечает ли узел, почему туннель настроен на оборудовании, но отсутствует в учете. Атакующие или просто беспорядок в процессах заставляют службу безопасности заниматься инвентаризацией всего подряд. Это дорого, поздно и почти всегда неполно.
Защищать то, чего не понимаешь, можно только наугад. И чем больше параллельных версий состава инфраструктуры, тем проще нарушителю, внешнему или внутреннему, найти брешь, которой нет ни в одной системе целиком.
Инструменты есть, мастер-системы нет
Дело не в отсутствии SIEM или мониторинга. Они как раз есть. Дело в том, что ни одна из этих систем не является мастером по составу инфраструктуры.
Мониторинг знает, какие узлы отвечают. Он не знает и не должен знать, должен ли этот хост существовать вообще, в каком он контуре и кто его заводил.
ITSM знает согласованную услугу, но не знает MAC на порту и актуальный peer IPsec.
SIEM видит аномалию. Без нормальной карточки актива она превращается в шум или в долгий поиск по пяти системам.
Excel обновляет тот, у кого сегодня есть время.
Отсюда типичная картина на разборе инцидента. В мониторинге хост зеленый. В ITSM услуга в норме. В SIEM странный трафик. А обратиться не к чему, потому что единой карточки актива с площадкой, владельцем, адресами и связями не существует. Дальше служба безопасности снова собирает инфраструктуру руками вместо того, чтобы ее защищать.
Сущности, которые существуют только в конфигурации
Отдельная проблема — объекты, которые фактически работают, но в учете отсутствуют. Типичный пример: IPsec. В конфигурации устройства туннель описан полностью. Видно, с кем он связан, какие подсети через него проходят, работает ли он. В инвентаре при этом пусто или в лучшем случае есть строка в чьей-то личной таблице.
Вопрос простой. Если туннель критичен для периметра или для связи с подрядчиком, почему он не заведен рядом с устройством и площадкой, с отметкой о критичности? Почему его нельзя сверить с фактической конфигурацией оборудования до того, как пошел странный трафик или пришли аудиторы?
Пока такие объекты существуют только в конфигурации, для ИБ их формально нет. Защищать то, что отсутствует в перечне, потом приходится наугад.
Неизвестное тоже подлежит учету
Еще одна типовая ошибка. В учет попадает только то, что уже описано и понятно. Неизвестный коммутатор в филиале, интерфейс без описания, адрес вне схемы откладываются до лучших времен. Правильный подход обратный: инвентаризировать нужно все объекты контура, включая те, назначение которых пока не установлено.
Неопознанный объект — это кандидат в риск ИБ. Его нужно завести в учет, присвоить статус или тег «требует разбора» и держать в работе, пока назначение не выяснится. Иначе теневая инфраструктура растет ровно там, где служба безопасности считает периметр чистым.
Сетевому инженеру иногда проще поправить конфигурацию на устройстве и работать дальше. Для ИБ каждая такая мелочь вне учета превращается в пробел в картине инфраструктуры. Через полгода их набирается на отдельный контур, которого нет ни в одной системе целиком.
Что должно быть опорой?
Нужно одно место, где хранится согласованная модель сети и активов. Мастер создания и изменения: любой объект появляется и меняется здесь. Остальные системы потребляют данные из него или сверяются с ним.
Для сетевой и инфраструктурной части таким местом становится ОдинХаб или NetBox. Площадки, устройства, интерфейсы, IP, VLAN, кабели, каналы, туннели, виртуализация собраны в одну связанную модель, где объекты ссылаются друг на друга. Ценность здесь в том, что актив можно разложить деревом: от площадки до устройства, порта и MAC на этой площадке. Расследование или сегментация идут сверху вниз по этому дереву, и служба безопасности перестает тратить сутки на переходы между Excel и Zabbix ради сбора общей картины.
Такая система не заменяет SIEM и не должна им становиться. Мониторинг остается мониторингом, ITSM ведет заявки. Каждая система сильна в своей роли. Слабость начинается там, где она притворяется реестром активов.
Сначала достоверные данные, потом автоматизация
У нас в свое время ломалось именно на порядке действий. Сначала пытались интегрировать все со всем, потом удивлялись, почему в трех системах три разных списка хостов.
Рабочая схема проще.
1. Объявить мастер.
Появление устройства, префикса, туннеля и смена адресации проходят через него или через интеграцию, которая в него пишет. То, чего в мастере нет, для процессов ИБ не считается легитимным активом контура, пока не заведено.
2. Наполнить данными без многолетнего проекта.
Часть данных уже где-то есть: в ITSM, в DHCP, в старых базах, у сетевых инженеров. Их нужно свести в одно место. Но сведение таблиц не покажет расхождений с фактом: что в сети есть, а в учете отсутствует.
Здесь помогает плагин автообнаружения сети, который сможет пройти по выбранным подсетям и покажет, какие узлы отвечают, что это за оборудование, какие у него адреса и интерфейсы. Результат приходит списком находок на проверку: что завести новым, что обновить, что выглядит лишним. В учет попадает только подтвержденное.
Порядок здесь важен. Если заливать все подряд без разбора, через неделю в инвентаре окажутся гостевые ноутбуки и тестовые стенды, и реестру уже никто не поверит. Для ИБ ценна именно эта пауза: сначала увидеть теневые активы, потом решить, что с ними делать. Без нее расхождения между системами живут годами.
На сверках обычно всплывают три класса расхождений:
- объект есть в сети, в учете отсутствует: кандидат в теневые активы;
- объект есть в учете, в сети не отвечает: выключен, ошибка учета или неактуальная карточка;
- объект есть в обеих системах, но серийный номер, ОС или имя различаются: нужно исправить карточку, дубликат не заводить.
3. Завести неизвестные объекты в учет.
Неизвестный узел из сверки не откладывается в тикет на потом. Для него заводится карточка, статус, ответственный за разбор и срок. Если срок прошел, а разбора не было, это уже процессный инцидент.
4. Критичные объекты помечать явно.
IPsec, стыки с подрядчиками, оборудование на границе, сегменты с ПДн и КИИ получают теги, уровень критичности и обязательные поля: владелец, контур, площадка. Если туннель важен для бизнеса, он должен быть в учете рядом с устройством и префиксами. Вывода команды show на оборудовании для этого недостаточно.
5. Права и валидация.
Пока реестр может править кто угодно и как угодно, он остается общим блокнотом. Нужны роли, тенанты по контурам, запрет на удаление активного объекта без вывода из эксплуатации, обязательные поля для классов активов. Работа скучная, но без нее через квартал все снова вернутся к таблице на диске.
И не стоит заводить в реестре сто полей про запас. Для ИБ обычно хватает короткого набора, которым действительно пользуются. Остальное добавляется, когда возникает конкретная потребность.
Отклонение от мастера — это инцидент ИБ
Это главный сдвиг в подходе, без которого централизация ничего не даст.
Если в сети или на оборудовании появилось устройство, префикс, туннель или адресная привязка, которых нет в системе инвентаризации, это отклонение. Если объект в системе есть, но по результатам сверки его быть не должно, он отсутствует физически или его атрибуты критично разошлись с фактом, это тоже отклонение. Дальше идет разбор. Причиной может быть ошибка учета, пробел в процессе ввода, теневой IT или признак несанкционированного изменения. Форма реакции бывает разной: заявка, алерт или полноценный инцидент информационной безопасности. Суть одна. Расхождение с мастером не откладывают на потом.
Иначе снова получится пять систем и спокойствие только на бумаге.
На практике заводить инцидент на каждую опечатку в описании не нужно. Нужна договоренность по классам отклонений. К критичным обычно относят новый узел в периметре вне учета, IPsec или стык с подрядчиком, настроенный только на оборудовании, адресацию, изменившуюся в обход мастера, и устройство в статусе «активно», на которое все еще опираются доступы и исключения в СЗИ, хотя в сети его давно нет. Менее критичны, но тоже обязательны в работу расхождения по ключевым атрибутам и просроченные объекты со статусом «требует разбора».
Когда мастер развернут, Сонар выполняет сверки, а процесс разбора отклонений зафиксирован, логично замкнуть контур на существующий SIEM. Плагин Журнал ИБ пишет события безопасности из коробки: входы, ошибки аутентификации, изменения прав и конфигурации, экспорт данных. Он отдает их в CEF, формат, который большинство SIEM понимает без самодельных парсеров. Задача здесь не в том, чтобы SIEM стал инвентарем. Задача в том, чтобы факты о доступе к системе учета и изменениях в ней не оставались только внутри системы инвентаризации. Мастер и сверки настроены — можно подключать поток в уже работающий SIEM.
Каждый инструмент остается в своей роли. ОдинХаб или NetBox держит состав инфраструктуры, Сонар или другой модуль автообнаружения сверяет его с фактическим состоянием сети, Журнал ИБ передает в SIEM понятные события, остальные системы делают свою работу.
С чего начать?
Начинать стоит с одного контура, где проблема ощущается острее всего: периметр, ЦОД, сеть с особыми требованиями. Корпоративная программа на три года здесь не нужна.
Порядок действий такой. Зафиксировать, что мастер — это ОдинХаб. Свести туда площадки, роли, префиксы, а также оборудование и туннели, которые и так известны всем. Прогнать сверку с фактическим состоянием сети через Сонар и завести неизвестные объекты явно. При необходимости включить Журнал ИБ и отдать CEF в действующий SIEM. Договориться с эксплуатацией и ИБ одной фразой: создание и изменение актива идет через мастер, устойчивое отклонение считается инцидентом. И только потом подключать мониторинг, ITSM и SIEM как потребителей единой модели данных. Своих конкурирующих списков хостов они больше не ведут.
SIEM, мониторинг и ITSM никуда не денутся, и не должны. Они просто перестанут притворяться инвентарем. А служба безопасности перестанет проводить внеплановый аудит всего предприятия каждый раз, когда кто-то задает простой вопрос: что у нас есть и как это защитить.
