Управление ИТ-⁠активами: нельзя защитить то, о чём не знаешь

Понедельник, 09:15. Сканер уязвимостей закончил еженедельный прогон — критичных находок нет. В 11:00 приходит письмо от внешнего исследователя: на поддомене компании открыта админка тестового веб-⁠сервера со старой версией CMS. Сервер поднял подрядчик полтора года назад под пилот, пилот закрыли, а виртуалка осталась. В сканер её никто не добавил — о ней просто никто не знал.

В этом главный парадокс ИБ: неприятные инциденты часто начинаются не с изощрённой атаки, а с актива, которого нет ни в одном списке. Поэтому управление ИТ-⁠активами (IT Asset Management, ITAM) — не бухгалтерская задача и не «таблица для аудита». Это фундамент, на котором стоят управление уязвимостями, реагирование на инциденты и комплаенс.

Что считать ИТ-⁠активом

Интуитивно актив — это «компьютер с инвентарным номером». Для безопасности этого мало. Активом стоит считать всё, что может стать точкой входа, хранит данные или участвует в бизнес-процессе — и у чего должен быть владелец.

• Оборудование — серверы, рабочие станции, ноутбуки, сетевые устройства, принтеры, IoT: всё, что получает IP-⁠адрес.
• Программное обеспечение — ОС, приложения и их версии. Именно версия ПО связывает актив с уязвимостями.
• Учётные записи — пользовательские, сервисные, локальные администраторы. Забытая сервисная учётка с бессрочным паролем — такой же актив, как сервер.
• Виртуальные машины и контейнеры — создаются за минуты и так же быстро теряются из виду.
• Облачные ресурсы — инстансы, хранилища, публичные IP, которые можно поднять с корпоративной карты в обход ИТ.
• Сервисы и информационные системы — «CRM-⁠клиенты», 1С, почтовый шлюз: логические сущности, которые объединяют десятки хостов и учёток и имеют бизнес-владельца.

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

Теневое ИТ: откуда оно берётся и чем опасно

Теневое ИТ (Shadow IT) — всё, что работает в инфраструктуре, но не учтено ИТ и ИБ. Злого умысла здесь обычно нет: люди решают задачи быстрее, чем служба ИТ успевает их согласовать. Типичные источники:

• пилоты и тестовые стенды, которые «временно» живут годами;
• виртуалки, созданные разработчиками «на пять минут» в общем гипервизоре;
• облачные сервисы и SaaS, оплаченные подразделением напрямую;
• оборудование подрядчиков и интеграторов, оставшееся после проектов;
• личные устройства и «свой» Wi-⁠Fi-роутер в переговорной;
• учётные записи уволенных сотрудников и сервисные учётки без владельца.

Опасность теневого ИТ в том, что на него не распространяется ни один процесс. Его не обновляют, не сканируют, не мониторят, его журналы не попадают в SIEM. Атакующему не нужно обходить защиту — её там просто нет.

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

Инвентаризация ИТ-⁠активов: как собирать данные

Агентский и безагентский сбор

Данные об активах собирают двумя способами. Агент — небольшая программа на хосте, которая сама отправляет сведения на сервер. При безагентском сборе сервер сам подключается к хосту штатными средствами: для Windows это обычно PowerShell, для Linux — SSH.

На практике выигрывает комбинация. Безагентский сбор быстро даёт широкий охват, агенты закрывают то, что редко бывает в сети. А сетевое сканирование находит то, что не видно ни тем, ни другим, — устройства, о которых никто не подозревал.

Источники данных

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

• Active Directory / LDAP — компьютеры домена, учётные записи, группы, даты последнего входа. Незаменим для учёток, но не видит ничего вне домена.
• Сетевые сканеры и сканеры уязвимостей — всё, что отвечает в сети, включая неизвестные устройства, плюс открытые порты и версии сервисов.
• Гипервизоры и системы виртуализации — полный список виртуальных машин, включая выключенные и «забытые».
• CMDB и ITSM — владельцы, назначение, связь с сервисами и заявками.
• Средства защиты — консоли антивирусов и EDR показывают, где агент защиты стоит, а где нет.
• Кадровые системы и договоры — кто владелец, работает ли он ещё в компании, на каком основании используется оборудование.

Самое ценное рождается на пересечениях. Хост есть в сканере, но нет в AD — кандидат в теневое ИТ. Есть в AD, но нет в консоли антивируса — дыра в защите. Учётка активна, а сотрудник по данным кадровой системы уволен — прямой риск.

Жизненный цикл актива, договоры и лицензии

Актив — не статичная запись, а объект с историей. Упрощённо его жизненный цикл выглядит так: обнаружение → назначение владельца → эксплуатация и контроль изменений → вывод из эксплуатации → утилизация. На каждом этапе у ИБ свой интерес:

• при обнаружении — понять, что это за объект и не теневой ли он;
• в эксплуатации — отслеживать изменения конфигурации и установленного ПО;
• при выводе — отключить учётные записи и отозвать доступы, а из мониторинга убирать только после фактического выключения;
• при утилизации — гарантировать уничтожение данных на носителях.

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

Для ИБ это ещё и сигнал. ПО без лицензии и без поддержки производителя почти всегда оказывается ПО без обновлений.

И наконец, изменения. Новое ПО на сервере бухгалтерии, внезапно появившийся локальный администратор, открытый порт на хосте, где его раньше не было, — всё это события, которые ИБ хочет видеть. Если реестр активов хранит историю, каждое такое изменение можно сравнить с предыдущим состоянием и превратить в проверку, а не заметить случайно через полгода.

Учёт активов ИБ: критичность как основа для VM и SOAR

Главная причина, по которой ИБ нужен учёт активов, — не отчётность, а приоритизация. Критичность актива отвечает на вопрос «насколько плохо будет, если с ним что-⁠то случится». Обычно её оценивают по нескольким факторам: какие данные обрабатываются, какой бизнес-процесс зависит от актива, доступен ли он из интернета, относится ли к объектам КИИ или системам с персональными данными.

Не нужно начинать с многомесячной методики. Трёх-⁠четырёх уровней достаточно, чтобы приоритизация заработала, а уточнять шкалу можно по ходу:

Дальше критичность работает везде:

• в управлении уязвимостями — одна и та же CVE на сервере бухгалтерии и на изолированном стенде получает разный приоритет;
• в SOAR — алерт с критичного хоста повышает уровень инцидента, запускает эскалацию и подсказывает, можно ли изолировать хост автоматически или нужно согласование;
• в комплаенсе — требования регуляторов привязываются к конкретным системам, а не к «инфраструктуре вообще».

Частые ошибки инвентаризации

1. Инвентаризация как проект, а не процесс. Список, собранный вручную к аудиту, устаревает через месяц.
2. Источник правды, который правдой не является. Excel или CMDB, которые никто не сверяет с реальной сетью.
3. Учитывают только железо. Учётные записи, облака и виртуалки остаются за бортом, хотя атаки часто идут именно через них.
4. Нет владельца. Актив без ответственного — актив, который никто не обновит и не выключит.
5. Нет критичности. Все активы «средние», и приоритизация превращается в угадывание.
6. Попытка описать всё и сразу. Карточка актива на сотню полей, которую невозможно заполнить, топит проект на старте.

С чего начать управление ИТ-⁠активами

1. 01

   Определите цель и границы

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

2. 02

   Подключите быстрые источники

   Active Directory, гипервизоры и сетевое сканирование дают основу реестра за дни, а не месяцы.

3. 03

   Сверьте данные и найдите расхождения

   Хосты вне домена, машины без антивируса, учётки без владельцев — это первый список рисков и первые быстрые победы.

4. 04

   Назначьте владельцев и критичность

   Хотя бы для систем верхнего уровня: какие сервисы и данные на них, доступны ли они из интернета.

5. 05

   Поставьте сбор на расписание

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

6. 06

   Свяжите реестр с другими процессами

   Передайте критичность в управление уязвимостями и реагирование на инциденты — ради этого всё и затевалось.

Как это устроено в Versium AM

Модуль Versium AM отвечает за учёт активов в единой платформе Versium. Сеть он сам не сканирует, а по расписанию сводит в один реестр данные систем, которые уже знают об узлах, — Active Directory, Kaspersky Security Center и RedCheck. У каждого актива есть владелец и критичность.

Отчёт «Неучтённые и устаревшие активы» показывает узлы без владельца или критичности, давно не появлявшиеся в источниках, впервые увиденные за период и видимые только в одном источнике — то есть ровно те пробелы, из-⁠за которых активы выпадают из-⁠под контроля.

Поскольку AM работает на одной платформе с Versium VM и SOAR, данные об активах не нужно переносить между системами вручную: они сразу используются в приоритизации уязвимостей и в сценариях реагирования. Лимитов по количеству активов нет, так что в учёт можно брать всю инфраструктуру, а не выборку. Как это выглядит на реальной инфраструктуре, покажем на демонстрации.