? Это часть 9 серии “Управление уязвимостями для самых маленьких” - практического руководства по VM с нуля. Главы самостоятельны, но если хочется по порядку - оглавление и все части серии тут.

Нельзя защитить то, о чем не знаешь. Управление активами - даже более фундаментальная вещь, чем управление уязвимостями. Это база, без которой VM превращается в красивые отчеты ни о чем.

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

Откуда брать данные об активах

Источников несколько и сканеры уязвимостей - лишь один из них. Сведения о состоянии активов можно получать также из:

• SIEM - из событий безопасности

• NTA/NDR (анализ трафика) - из сетевой активности

• Active Directory и CMDB - из систем ИТ-департамента

• систем виртуализации, оркестрации и облачных API - оттуда, где активы создаются

• ручного ввода - если автоматизация еще не налажена

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

Что должно быть в записи об активе

Прежде чем категоризировать, стоит договориться, из чего состоит запись. CIS Controls в первом же контроле перечисляют минимум: сетевой адрес (если он статический), MAC-адрес, имя машины, владелец, подразделение и статус - одобрен ли актив к подключению в сеть [1].

Для VM к этому минимуму добавляется еще три поля, и они важнее остальных:

• значимость актива - от нее зависят требования SLA;

• ответственный за устранение - конкретный человек или команда, а не абстрактное “ИТ”;

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

Все три поля обычно пустые. Заполнить их - это уже половина зрелости процесса.

Зачем категоризировать активы

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

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

Лучший вариант - автоматическая группировка: новые серверы сразу добавляются в группу, и для них заранее действует утвержденный SLA. Главный вопрос, который мы себе задаем: подвержены ли эти активы или группы атакам, ведущим к недопустимым событиям?

Важность актива

По умолчанию все активы стоит считать важными, но можно разделить их на три категории:

• Высокая важность - активы, обычно задействованные в цепочках атак: веб-серверы на периметре, сетевые устройства, VPN, целевые системы вроде “1С:Бухгалтерии”

• Средняя важность - активы, которые косвенно позволяют проникнуть внутрь

• Низкая важность - активы, атаки на которые не приводят к недопустимым событиям

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

Принцип “неизвестное считаем важным” не моя выдумка. NIST в CSF 2.0 требует приоритизировать активы по классификации, критичности и объему задействованных ресурсов (подкатегория ID.AM-05) [2], а CIS Controls предписывают реагировать на неавторизованный актив в сети, а не сначала выяснять, насколько он ценный [1]. Логика простая: пока про актив ничего не известно, самое дешевое предположение - что он критичный. Ошибка в эту сторону стоит лишнего сканирования. Ошибка в обратную стоит инцидента.

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

Что требуют регуляторы и стандарты

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

Приказ ФСТЭК № 117 от 11.04.2025, вступивший в силу 1 марта 2026 года, прямо говорит о системах инвентаризации ИТ-активов как об источнике данных для контроля конфигураций [3]. И даже там, где инвентаризация не названа, она подразумевается арифметикой: приказ требует выявлять уязвимости не реже раза в месяц, а критические устранять за 24 часа. Попробуйте выполнить такой SLA, если половина парка вам неизвестна. Формально можно даже отчитаться - по тем активам, которые видите. Фактически это отчет про часть инфраструктуры, а злоумышленник работает со всей.

Категорирование объектов КИИ за 2025 год изменилось сильнее, чем за предыдущие пять. Федеральный закон № 58-ФЗ от 07.04.2025 ввел типовые отраслевые перечни объектов КИИ, а постановление Правительства № 1762 от 07.11.2025 переписало правила категорирования: точкой отсчета теперь служат типовые отраслевые объекты, а не самостоятельный анализ критических процессов, как было в исходной редакции постановления № 127 [4]. Для VM-специалиста это означает, что категорирование из упражнения “придумай сам, что у тебя критично” превращается в сверку с отраслевым перечнем. Что, кстати, честнее: раньше границы значимости каждый рисовал себе сам, и рисовал их удобно.

Международные фреймворки требуют того же, но в других словах:

Обратите внимание на две детали. Первая: CIS отдельно разделяет периодичность инвентаризации (раз в полгода) и периодичность реакции на незнакомый актив (раз в неделю). Это разные процессы с разной срочностью, и в большинстве организаций второго нет вообще. Вторая: ID.AM-08 появилась только в CSF 2.0, и появилась по делу. Управление жизненным циклом - это как раз про то, о чем мы поговорим дальше: вывод из эксплуатации ломает данные об активах ничуть не меньше, чем ввод.

Инвентаризация. Управление активами

Управление активами (asset management) - процесс формирования подробной картины ИТ-инфраструктуры и поддержания сведений об активах в актуальном состоянии. Он неразрывно связан с управлением уязвимостями, управлением изменениями (change management) и управлением исправлениями (patch management).

Связь эта односторонняя только на первый взгляд. Да, VM процесс берет данные из asset management. Но и обратно тоже: сканирование - самый честный аудит вашей CMDB, потому что сканер не умеет вежливо не замечать то, чего по документам быть не должно.

Управление активами глазами ИБ и ИТ

Процесс можно рассмотреть с двух сторон.

Со стороны ИБ:

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

2. Отслеживание изменений конфигурации и ПО - чтобы данные были актуальны

3. Контроль состояния активов - убедиться, что узлы доступны для инвентаризации и в эксплуатации

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

Со стороны ИТ:

1. Использование CMDB - новый узел регистрируется в базе

2. Контроль изменений на узлах, включая ПО, с отражением в CMDB

3. Вывод из эксплуатации - аналогично ИБ

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

Именно поэтому NIST в CSF 2.0 вынес управление жизненным циклом в отдельную подкатегорию ID.AM-08 [2]: вывод активов и уничтожение данных - такая же часть управления активами, как первичная инвентаризация. А в системах управления уязвимостями не забывайте настраивать срок жизни активов.

Активы, которых не было в первой редакции

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

Облачные ресурсы, которые никто не выключил. В своей серверной забытый сервер хотя бы шумит и греет воздух. Облачный ресурс не шумит, он просто списывает деньги. Harness в отчете FinOps in Focus 2025 оценивает потери на недоиспользуемой облачной инфраструктуре в 44,5 миллиарда долларов за 2025 год, около 21% всех облачных расходов, причем без автоматизации на выявление и устранение такого ресурса уходит в среднем 31 день [5]. Это финансовая метрика, но для нас она читается иначе: месяц - это срок жизни актива, которым никто не управляет. Уязвимости на нем при этом абсолютно настоящие.

SaaS-сервисы. Отдел маркетинга завел себе сервис рассылок, разработка - трекер задач, HR - платформу для собеседований. Ни один из них не проходил через ИТ и не попал ни в одну инвентаризацию, а корпоративные данные там лежат. Активом это стало ровно в тот момент, когда в сервис завели первую учетную запись с рабочей почтой.

AI-системы и AI-агенты. Здесь регуляторы (не отечественные, но все же) оказались быстрее практики. ISO/IEC 42001 требует вести перечень AI-систем как часть управления жизненным циклом, статья 49 EU AI Act - регистрировать высокорисковые системы, NIST AI RMF ведет к тому же через функцию Map [6]. То есть реестр AI-компонентов - уже не идея на будущее, а требование трех фреймворков одновременно. О том, что делать с уязвимостями самих AI-систем, поговорим в отдельной части серии.

Контейнеры, Kubernetes, IoT и АСУ ТП. Эти типы активов заслуживают отдельного разговора, и он будет: контейнерам и облакам посвящена отдельная часть.

Поверхность атаки: от списка технологий к экспозиции

Еще в 2022 году Gartner в обзоре трендов кибербезопасности поставил на первое место расширение поверхности атаки (attack surface expansion) [7]. Вывод простой: поверхность атаки растет из-за цифровизации бизнеса, гибридной работы и облаков, и растет быстрее, чем организации успевают ее осознавать.

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

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

Связь управления уязвимостями и управления активами

Чтобы выявлять и устранять уязвимости полно, нужно досконально знать инфраструктуру. Качество VM напрямую зависит от полноты, достоверности и актуальности сведений об активах.

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

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

У одного клиента была ERP-система примерно из 500 узлов. Все регулярно сканировались, данные об уязвимостях шли в ИТ. В ходе модернизации число узлов выросло, и часть новых еще и “торчала наружу”. В CMDB, которую ИБ использовала как источник, новых активов не было: данные туда частично попадали автоматически, частично вносились руками, а новые узлы должны были заводиться вручную - и не были. Несоответствие всплыло не сразу.

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

Отсюда практический вывод: систему мониторинга тоже используйте как источник сведений об активах. Дополнительно - инструменты автоматизации ИТ. Вряд ли кто-то вручную разворачивает виртуальные машины, если есть инструмент оркестрации. Заберите данные и из него - полнота и достоверность вырастут. А чтобы найти все такие источники, обычно достаточно часовой беседы с командой ИТ.

Особенности управления активами

Управление активами помогает понять, что именно вы защищаете. Самые большие проблемы возникают не на активах, которые вы знаете и сканируете, а на тех, о которых не знаете, - на shadow IT. Чтобы с этим справиться, нужна система инвентаризации. Неважно, кто ее сделает - VM-команда, другое подразделение ИБ, SOC или ИТ. Главное, чтобы она была.

Часто на вопрос “как получить активы” вендоры VM отвечают: “Возьмите сети, просканируйте, найдите активные хосты, и поймете, что покрывать”. Но есть нюансы. Часть сетей может быть изолирована - вы о них не знаете, а если знаете, нужно сначала разместить там сканер. На сетевом оборудовании бывают правила, мешающие сканированию: видите все порты “открытыми”, а хоста там нет.

Другие вендоры предлагают выгрузку или скан AD. Но в AD могут быть не все хосты: некоторые специально вне домена, и вы их не увидите. Таких “но” очень много.

Полезно составить список вопросов к системе asset management:

• Все ли филиалы, дочерние и приобретенные компании учтены?

• Все ли типы хостов: десктопы, ноутбуки, серверы?

• Ноутбуки. После ковида во многих компаниях гибридный режим: люди работают из дома и могут вообще не подключаться к VPN. Увидите ли вы такой ноутбук? Достучитесь ли до него для проверки? Не факт.

• Разные ОС. Данные о Windows можно взять из AD. А Linux, macOS? С учетом импортозамещения доля Linux-машин в российских организациях растет, и это нужно учитывать.

• Все ли серверы: в домене и вне, в закрытых и открытых сетях, в облаке? Если компания мигрировала из западной инфраструктуры в российское облако, эту часть тоже нужно покрыть.

• Сложные системы: хосты “1С”, системы виртуализации и контейнеризации (Kubernetes), сетевые устройства. И экзотика: IP-телефония, камеры, СКУД, экраны бронирования переговорок.

Убедившись, что активы покрыты (или хотя бы понимая, что покрыто, а что нет и как расширять), идем дальше. Назначаем ответственного за каждый актив. С точки зрения VM ответственный - это тот, кто может принять решение об обновлении и выполнить его. Если делаете это сами - сами и отвечаете, если актив “ляжет”. И нужно понимать, что будет, если ответственный не уложится в SLA или вообще не возьмется за обновление.

Кстати, самый быстрый способ проверить зрелость процесса - выбрать случайный актив из системы и спросить, кто за него отвечает. Не подразделение, а человека. В незрелом процессе ответ приходит через неделю, после трех пересылок письма, и звучит как “исторически этим занимался Сергей, но он уволился”.

Дальше - значимость актива (от нее зависят требования SLA) и возможность сканирования.

Подведем итог. Управление активами - даже более важный аспект, чем управление уязвимостями. Это база. Не понимая, какие активы у вас есть, вы не сможете качественно приоритизировать устранение уязвимостей, и в инфраструктуре останутся незащищенные места, через которые вас и взломают.

А как у вас?

Насколько вы уверены, что знаете обо всех своих активах? Особенно про ноутбуки сотрудников на удаленке, которые могут не подключаться к VPN. Находили ли вы “невидимые” серверы, которых не было ни в одной системе учета? И отдельный вопрос для смелых: если выбрать в вашей системе случайный актив и спросить, кто за него отвечает - за сколько дней придет ответ с именем человека?

Навигация по серии: ⬅️ Предыдущая: Гл. 8. Агент, скан или что-то еще · ? Оглавление серии · Следующая: Гл. 10. Из 48 000 уязвимостей опасен 1% ➡️

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