ФСТЭК обновляет БДУ угроз 2023: ИИ-компоненты и облако в новых позициях

Банк данных угроз ФСТЭК (БДУ) пополнился новыми позициями. Это происходит регулярно, но не каждое обновление заставляет пересматривать документацию объектов КИИ - это заставляет. Среди новых угроз появились позиции, которые явно написаны под системы с ИИ-компонентами и под облачную инфраструктуру. Для тех, кто уже сдал перечни и модели угроз регулятору или готовит их сейчас, - это не абстрактное пополнение базы.

Что добавили

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

Угрозы для систем машинного обучения и ИИ-компонентов. БДУ теперь включает угрозы, связанные с атаками на модели - компрометацию обучающих данных (data poisoning), атаки на вывод модели, извлечение информации через запросы к инференс-сервису. Отдельно появляются угрозы манипуляции с промптами применительно к LLM-системам, хотя формулировки там пока достаточно общие. Всё это в рамках методики ФСТЭК 2021 теперь необходимо рассматривать как потенциальные объекты воздействия, если в инфраструктуре есть что-то с ML-компонентом.

Угрозы для облачных и мультиарендных сред. Новые позиции покрывают атаки, специфичные для виртуализированных окружений: несанкционированный доступ к данным соседних арендаторов через side-channel, компрометацию оркестратора (в том числе явно упоминается управляющая плоскость Kubernetes), угрозы целостности образов контейнеров в реестре, атаки на API управления облачными ресурсами.

Угрозы цепочки поставок программного обеспечения. Это не совсем новая тема для БДУ, но новые формулировки стали точнее - компрометация CI/CD-пайплайна, подмена зависимостей, атаки на реестры пакетов как вектор доставки вредоносного кода в продуктивную среду.

Почему это меняет модель угроз

Логика методики ФСТЭК 2021 такая: список актуальных угроз формируется путём пересечения угроз из БДУ с реальной архитектурой объекта. Если угрозы в БДУ нет - её можно не рассматривать. Теперь она есть. Это означает, что модели угроз, написанные до этого обновления, технически стали неполными.

Практически это выглядит так. Возьмём типовую корпоративную инфраструктуру, которую мы видим у клиентов: on-prem-серверы с виртуализацией (VMware, Proxmox или уже Zvirt), часть сервисов в российском облаке (Yandex Cloud, VK Cloud, Selectel), CI/CD на GitLab, и - всё чаще - какой-нибудь ИИ-инструмент внутри: корпоративный поиск на эмбеддингах, чат-бот над базой знаний, автоматизация категоризации документов.

До обновления БДУ для ИИ-компонента в модели угроз достаточно было написать «угрозы несанкционированного доступа к данным» - и это более-менее закрывало раздел. Теперь появились специфические угрозы, которые относятся именно к ML-системе как объекту: атака на модель может не трогать базу данных напрямую, но компрометировать выводы, которые система генерирует. Это другой вектор, другой нарушитель, другие меры нейтрализации.

Для облачных компонентов картина аналогичная. Если Kubernetes-кластер аттестован как часть инфраструктуры объекта КИИ, управляющая плоскость теперь явно названа объектом воздействия. Etcd, kube-apiserver, процессы обновления узлов - всё это входит в зону интереса при оценке актуальности.

Что конкретно нужно пересмотреть в документации

Мы прошлись по нескольким текущим проектам и сформулировали минимальный список того, что надо проверить:

• Перечень компонент объекта КИИ. Если в инфраструктуре есть ML-сервис или инференс-эндпоинт - он должен быть в перечне компонент с описанием роли в информационном потоке. Если его там нет - это пробел, который новые угрозы делают видимым.

• Раздел с нарушителями. Для атак на ML-модели характерен нарушитель с возможностями, которые отличаются от классического взломщика периметра: ему не нужен доступ к инфраструктуре, достаточно возможности делать запросы к публично доступному или внутреннему инференс-API. Профиль нарушителя меняется.

• Список угроз с оценкой актуальности. Новые позиции БДУ придётся либо обосновать как неактуальные (с конкретной аргументацией - какие меры их нейтрализуют), либо включить в актуальные и под каждую прописать организационные и технические меры. Шаблон «угроза неактуальна» без обоснования здесь не пройдёт - по опыту с категорированием это именно то, на что ФСТЭК обращает внимание в первую очередь.

• Меры защиты для облачных компонентов. Если объект использует облачную инфраструктуру, нужно описать меры применительно к новым угрозам: изоляция tenant-окружений, защита API управления, контроль целостности образов. Ссылки на стандартные меры приказа 239 здесь нужно сопроводить конкретикой - как именно они реализованы для мультиарендной среды.

Насколько срочно

Регулятор не объявлял формального дедлайна на пересмотр моделей угроз после обновления БДУ. Только вот если придёт плановая проверка или потребуется согласование изменений в составе объекта, актуальность модели угроз будут оценивать на дату проверки, а не на дату последнего обновления документа. Разрыв между тем, что в БДУ, и тем, что в модели угроз - это готовое замечание.

На наш взгляд, разумный горизонт - закрыть пробелы до конца второго квартала. Для объектов, где ML-инструменты и облако уже есть в продуктиве, - скорее раньше.

Если нужна оценка того, насколько существующая модель угроз объекта КИИ покрывает новые позиции БДУ - мы делаем это в рамках аудита: смотрим документацию, сравниваем с актуальным составом инфраструктуры, фиксируем пробелы и помогаем с формулировками для регулятора.