ВМ в нетипичных средах: АСУ ТП, сети, IoT, мобильные устройства, оборудование и ML
Управление уязвимостями обычно описывают простой последовательностью: определить активы, найти слабые места, оценить риски, назначить сроки, устранить проблему и проверить результат. Этот подход работает почти везде, однако в нетипичных средах цена ошибки значительно выше. В промышленной автоматике неосторожное сканирование может остановить производство, в IoT обновление нередко невозможно в принципе, а в машинном обучении уязвимость может скрываться не в сервере, а в данных или самой логике модели.
АСУ ТП: безопасность не должна ломать производство
В промышленной среде процесс VM включает выявление, анализ, приоритизацию и устранение уязвимостей. Параллельно необходимо вести учет активов и управлять обновлениями. Но к стандартной команде добавляется функциональный владелец АСУ ТП - человек, отвечающий за SCADA, ПЛК и технологические системы. Без его согласования нельзя менять конфигурацию, запускать сканирование или устанавливать патчи.
Главное правило - не нарушить технологический процесс. Обычный режим активного пентеста, особенно с проверкой всех портов и сервисов, для промышленной инфраструктуры может оказаться опасным. Специализированное ПО способно некорректно обработать неожиданный запрос, зависнуть или остановить критичный компонент. Поэтому перед первой проверкой изучают архитектуру, определяют допустимые методы и заранее готовят сценарий отката.
В АСУ ТП особенно важен показатель Safety из CVSS 4.0. Здесь последствием эксплуатации может стать не только утечка информации, но и повреждение оборудования, авария или угроза жизни людей. Данные об уязвимостях собирают из БДУ ФСТЭК, NVD и бюллетеней производителей промышленного оборудования. Мониторинг должен быть постоянным, но максимально щадящим.
Для проверки предпочтителен режим Audit с использованием учетных данных, а не черный ящик. Windows-системы нужно проверять соответствующими профилями, не применяя к ним шаблоны для Linux. Всю сеть целиком сканировать не следует: план составляют по конкретным системам и IP-адресам. Если нет уверенности, что устройство выдержит проверку, его сначала переводят в резерв или исследуют на копии.
Обновления устанавливают только в технологические окна. До этого патч проверяют вручную, тестируют на цифровом двойнике или изолированном стенде, готовят утвержденный план отката и убеждаются в работоспособности резервирования. В крупной инфраструктуре изменения вносят поэтапно, сегмент за сегментом.
Устаревшие системы со статусом EoL или EoS часто невозможно обновить: производитель больше не выпускает исправления. Тогда применяют компенсирующие меры - изоляцию, ограничение доступа, фильтрацию трафика, отключение ненужных функций и усиленный мониторинг. Решение о допустимом снижении функциональности принимает владелец технологической системы. Полный вывод актива из эксплуатации остается крайней мерой.
После устранения выполняют повторную проверку, сверяют версии программного обеспечения и контролируют состояние цифрового двойника. Если во время сканирования остановился сервис, необходимо определить конкретный плагин или запрос, вызвавший сбой, и передать информацию производителю АСУ ТП.
Сетевое оборудование и сегментация
Одна из самых распространенных проблем - отсутствие сегментации или ошибки в ее реализации. Между технологическими, офисными и административными зонами не должно быть свободного маршрута. Сети разделяют с помощью VLAN и других механизмов, а взаимодействие между сегментами разрешают только через межсетевые экраны.
Правило должно быть простым: открыты только действительно необходимые порты, все остальные соединения запрещены. Контроллер домена целесообразно разместить в отдельном сегменте. Исходящие соединения от него следует блокировать, оставляя лишь заранее зафиксированные исключения. Доступ к портам назначают по RBAC - только конкретным пользователям и устройствам, прошедшим аутентификацию и авторизацию.
ACL на маршрутизаторах и коммутаторах нельзя считать разовой настройкой. Их нужно регулярно пересматривать после изменений топологии, вывода оборудования и появления новых сервисов. Неиспользуемые правила, временные разрешения и широкие диапазоны адресов постепенно превращаются в постоянные уязвимости.
Отдельное внимание требуется SNMP. На многих устройствах он включен по умолчанию, а стандартные community strings вроде `public` и `private` давно известны злоумышленникам. SNMPv1 и SNMPv2c не обеспечивают полноценной защиты передаваемых данных, поэтому при возможности следует переходить на SNMPv3 с аутентификацией и шифрованием. Если замена невозможна, доступ к SNMP ограничивают выделенными адресами управления и фильтрами на firewall.
IoT: устройства, которые никто не обновляет
Интернет вещей часто состоит из большого числа недорогих устройств, установленных в удаленных или труднодоступных местах. Они могут работать годами, иметь слабую защиту, устаревшую прошивку и ограниченные вычислительные ресурсы. Типовые проблемы - заводские пароли, открытые сервисы, отсутствие безопасного механизма обновления и невозможность установить агент для инвентаризации.
Для IoT особенно важен точный реестр: модель, серийный номер, версия прошивки, сетевой адрес, место установки, владелец и назначение устройства. Без этих данных невозможно понять, затрагивает ли конкретная уязвимость инфраструктуру и какие действия допустимы.
Если обновление доступно, его проверяют на отдельной группе устройств, затем распространяют поэтапно. Для критичных объектов заранее готовят возможность возврата на предыдущую прошивку. Когда исправления нет, применяют сетевую изоляцию, закрывают ненужные порты, запрещают прямой выход в интернет и разрешают связь только с необходимыми серверами.
При закупке новых устройств следует заранее проверять наличие поддержки, срок выпуска обновлений, возможность смены пароля, защищенный протокол управления и механизм безопасной загрузки. Цена устройства не должна быть единственным критерием: стоимость последующего сопровождения и замены часто оказывается выше первоначальной экономии.
Мобильные устройства
В мобильной среде контроль уязвимостей строится вокруг MDM/UEM-платформы. Она позволяет отслеживать версии операционной системы, применять политики шифрования, блокировать рутованные устройства, удаленно стирать корпоративные данные и контролировать установку приложений.
Важно разделять личную и рабочую информацию. Контейнеризация корпоративных данных снижает последствия потери смартфона и не требует полного контроля над личным содержимым пользователя. Доступ к корпоративным сервисам стоит связывать с состоянием устройства: устаревшая система, отключенное шифрование или нарушение политики должны приводить к ограничению доступа.
Железо и прошивки
Уязвимости могут находиться ниже уровня операционной системы - в BIOS, UEFI, контроллерах управления, микрокоде процессора, сетевых адаптерах и другой микропрограмме. Такие проблемы сложнее обнаружить стандартным сканером, потому что версия прошивки не всегда корректно определяется удаленно.
Инвентаризация должна включать модель оборудования, версии BIOS и firmware, параметры безопасной загрузки и сведения о включенных аппаратных интерфейсах. Обновления выполняют только пакетами, полученными из доверенного канала, предварительно проверяя совместимость и наличие процедуры восстановления. Для критичных серверов желательно иметь запасной узел, чтобы обновлять оборудование без остановки сервиса.
Системы машинного обучения
В ML уязвимость может быть связана не только с инфраструктурой, но и с данными. Опасность представляют отравление обучающей выборки, внедрение скрытых триггеров, утечка информации через модель, небезопасные зависимости и неправильная настройка API.
Необходимо разделять хранилища исходных данных, обучающих наборов, моделей и результатов экспериментов. Доступ к ним ограничивают по ролям, а версии датасетов и моделей фиксируют. Для каждого релиза полезно проводить проверку на аномальные примеры, неожиданные изменения точности и попытки извлечения конфиденциальных данных.
Модель нельзя считать безопасной только потому, что она работает в изолированном контейнере. Нужно защищать весь конвейер: репозитории, серверы обучения, реестры моделей, ключи доступа и интерфейсы инференса. После изменений обязательны повторное тестирование и контроль дрейфа поведения.
Общий принцип для нетипичных сред
Во всех перечисленных случаях VM начинается не со сканера, а с понимания среды. Нужно знать, какие активы существуют, кто отвечает за каждый из них, какие изменения допустимы и как восстановить систему после неудачи. Чем выше цена простоя или физического инцидента, тем осторожнее должны быть проверки.
Главный результат зрелого процесса - не максимальное число найденных CVE, а управляемое снижение риска. Иногда лучшим решением становится патч, иногда - сегментация, ограничение доступа, компенсационная мера или замена устаревшего устройства. Важно, чтобы выбор был зафиксирован, согласован с владельцем системы и подтвержден повторным контролем.