Безопасность машинного обучения долгое время была нишевой темой: несколько исследовательских групп, десяток публикаций в год, минимум практических инструментов. Пару лет назад LLM и агентные системы вышли в промышленную эксплуатацию, и это привело к появлению новых регуляторных требований и инструментов для их выполнения.
Мы запускаем цикл статей, в котором расскажем о базовом объеме знаний, необходимом каждому специалисту по безопасности ИИ-систем в 2026 году. Мы последовательно раскроем нормативную базу и ключевые методологии, техники атак на ИИ-системы, доступные открытые и коммерческие инструменты для red team и защиты, а также обсудим подходы к выстраиванию защиты от УЦСБ.
Первая статья посвящена нормативно-правовому регулированию. В ней мы разберем, как устроена нормативная база в России, Китае, ЕС и США, рассмотрим ключевые методологии защиты ИИ-систем, среди которых как зарубежные STRIDE и OWASP, так и отечественные AI-SAFE и SAIMM.
Этот материал — сокращенная и немного актуализированная версия соответствующего раздела выпуска «Безопасность ИИ-систем» нашего же авторства. Если здесь что-то показалось раскрытым недостаточно глубоко, приглашаем к чтению полной версии.
Российские НПА по ИБ ИИ
Общее устройство НПА по ИБ ИИ в России
С 1 марта 2026 года в России действует Приказ ФСТЭК № 117, устанавливающий обязательные требования для ИИ-систем в составе ГИС, иных информационных систем госорганов, значимых объектов КИИ, а также для подрядных организаций, обеспечивающих разработку и эксплуатацию таких систем. Приказу предшествовал ряд документов стратегического уровня, не влияющих напрямую на бизнес, но определяющих терминологию и основу для требований к защите.
Российское регулирование безопасности ИИ-систем выстроено иерархически:
стратегия — требования — инструменты
Верхний уровень (Указ Президента) задает стратегическую рамку, средний (Приказы ФСТЭК, ГОСТы) вводит обязательные требования, нижний (методики ФСТЭК) дает инструменты для их выполнения.
Указ Президента № 490
Указ Президента РФ от 10.10.2019 № 490 (с изменениями от 15.02.2024) закрепляет стратегию развития ИИ и вводит ключевые для безопасности понятия. Безопасность определена как отсутствие неприемлемого риска. Риск — как сочетание вероятности причинения вреда и тяжести этого вреда. Дополнительно в пункте 5(ц) появляется термин «доверенные технологии ИИ» — технологии, исключающие возможность причинения вреда, реализованные безопасно.
Указ не содержит конкретных требований к защите, но фиксирует принципы недопустимости злонамеренного применения ИИ и необходимости минимизации рисков, а также прямо включает информационную безопасность в направления развития ИИ (п. 51).
Практическая ценность Указа состоит в создании терминологической базы: при согласовании мер защиты со смежными подразделениями и заказчиками ссылка на определения из Указа снимает значительную часть споров о том, что считать безопасной ИИ-системой.
Проект закона о регулировании ИИ
В марте 2026 года Минцифры опубликовало проект федерального закона «Об основах государственного регулирования сфер применения технологий ИИ». Если его примут, он вступит в силу с сентября 2027 года.
Из основных положений можно выделить появление реестра доверенных ИИ и введение ответственности операторов за безопасность моделей. Отдельно прописана возможность обучения суверенных моделей на государственных данных после согласования с ФСТЭК и ФСБ. Закон распределяет роли: разработчик, оператор, владелец, пользователь ИИ-системы, и для каждой роли указывает свои обязанности.
Документ пока находится в статусе проекта, но в целом подсвечивает движение государства в сторону контроля доверенных моделей и данных, на которых они обучаются.
На примере ГИС: приказ ФСТЭК № 117
Приказ утвержден 11 апреля 2025 года, вступил в силу 1 марта 2026 и устанавливает требования к защите информации в ГИС и иных системах госорганов. Приказ № 117 не является самостоятельным «законом об ИИ» — это документ ФСТЭК России в области защиты информации, внутри которого появились специальные требования к ИИ-системам.
К ИИ-системам имеют прямое отношение три пункта:
Пункт 34(т) выделяет отдельное мероприятие: «защита информации при использовании ИИ-систем».
Пункт 60 определяет, что надо защищать: наборы данных, модель, параметры, процессы обработки данных и поиска решений. И, несмотря на очевидность требования и его связанность с частью обработки данных, явно подчеркивается требование не передавать разработчику ИИ-модели информацию ограниченного доступа. На практике это означает необходимость контролировать использование внешних ИИ-сервисов сотрудниками и исключать передачу им информации ограниченного доступа без правового и технического основания.
Пункт 61 описывает требования в зависимости от типа ИИ-системы. Для шаблонных запросов нужно зафиксировать шаблоны и контролировать соответствие, для свободного текста (а это любые LLM) нужно определить допустимые тематики и контролировать их соблюдение. Для всех ИИ-систем требуется выявлять недостоверные ответы по установленным критериям и реагировать на них, вплоть до ограничения функций.
В таблице ниже приведены требования, соответствующие им действия и типовые артефакты. Разбивка по пунктам основана на разборе Бориса Захира, в котором толково описаны варианты действий для реализации 117 Приказа для ИИ-систем — для подробного ознакомления стоит заглянуть в исходник.
Приказ требует применения доверенных технологий ИИ, однако их конкретный состав определяется национальными стандартами. Хотя приказ определяет требования только для ГИС, на него можно ориентироваться при формировании ожиданий и по требованиям для других систем.
Детализация 117 приказа в части анализа защищенности — методика анализа защищенности от ФСТЭК
ФСТЭК опубликовал методический документ 25 ноября 2025 года, в котором описан порядок проверки выполнения требований приказа № 117. Документ содержит набор проверок, применимых к ИИ-системам.
Методика предлагает разобраться в устройстве системы (мера ИНП.9), провести внешнюю оценку защищенности (интерфейсы «запрос-ответ») и затем внутреннюю (инфраструктура обучения, датасеты, доступ к модели). Результаты описываются в формате, напоминающем DREAD: критичность, условия эксплуатации, затрагиваемые активы, компенсирующие меры.
Описание предлагаемых в методике мер, с учетом проведенного другими исследователями анализа, представлено в таблице.
Для внешнего анализа уязвимостей существуют специализированные redteam-инструменты, о которых расскажем в следующих статьях, а для внутреннего требуется в основном привлечение экспертизы и человеческого ресурса.
Методика вписывает оценку защищенности ИИ-систем в существующую логику: аудит, поиск уязвимостей, описание рисков, меры защиты.
Детализация 117 приказа в части реализации защиты: мероприятия и меры по защите информации от ФСТЭК
Методический документ «Состав и содержание мероприятий и мер по защите информации, содержащейся в информационных системах» утвержден ФСТЭК России 12 апреля 2026 года. Документ детализирует требования Приказа №117.
Защита ИИ-систем описана в пункте 3.18 «Обеспечение защиты информации при использовании искусственного интеллекта».
Требования сгруппированы по этапам жизненного цикла:
выделение инфраструктуры разработки в изолированный сегмент с классом защищенности не ниже класса защищенности информационной системы оператора;
отказ от небезопасных форматов (pickle) в пользу безопасных (ONNX, protobuf);
приоритетное использование наборов данных из доверенных источников;
антивирусная проверка обучающих данных;
обеспечение целостности ПО и данных;
анализ уязвимостей входных моделей и программного обеспечения;
состязательное обучение моделей и тестирование на промпт-атаки (усиленные меры).
При эксплуатации требуется фильтрация входных и выходных данных, мониторинг и квотирование запросов, регистрация событий безопасности, обеспечение целостности параметров модели и конфигурации, изоляция системы ИИ, защита от вредоносного ПО, ограничение и контроль функциональности.
Инфраструктура, используемая для эксплуатации, должна соответствовать классу защищенности не ниже класса защищенности информационной системы оператора, в том числе если ИИ предоставляется подрядчиком как внешний сервис.
Отдельно методика выделяет случай, когда в системе ИИ обрабатываются персональные данные или информация ограниченного доступа, либо система выполняет значимые для оператора функции. В этом случае дополнительно требуется обеспечить безопасную разработку по ГОСТ Р 56939-2024 и сертификацию ПО, реализующего систему ИИ.
Здесь стоит отметить, что в настоящее время ведется подготовка обновления ГОСТ Р 56939, которое будет учитывать особенности безопасной разработки с применением технологий ИИ. Методика сертификации ПО с технологиями ИИ ФСТЭК на текущий момент не утверждена, поэтому до ее выхода оператор может опираться на классическую сертификацию ПО по общим критериям и аттестацию информационной системы.
Подробный разбор документа приведен в статье Альбины Аскеровой (Swordfish Security).
Одновременно с этим в БДУ ФСТЭК был опубликован раздел угроз безопасности ИИ-систем, угрозы в нем разделены на две группы: для разработчика и для оператора ИИ-системы. Раздел может использоваться как основа для построения модели угроз конкретной системы. При этом следует учитывать, что угрозы, связанные с качеством моделей ИИ (галлюцинации, дрейф, объяснимость решений), в данном разделе БДУ не рассматриваются. Это отражает фундаментальное разграничение:
ИБ-угроза предполагает злоумышленника и ущерб от нарушения конфиденциальности, целостности или доступности;
дефект модели (галлюцинация, дрейф) ведет к неправильному решению, но не всегда является ИБ-угрозой.
Оба сценария могут приводить к одинаковому бизнес-ущербу, но требуют разных моделей угроз и разных контролей.Национальные стандарты
Вообще, стандартов больше 150. Остановимся на трех, которые формируют технический фундамент под требования регуляторов и влияют на широкий спектр систем. Остальные — не менее важные, но более специализированные и привязаны к конкретным доменам: медицине, образованию и т.д.
ПНСТ 836-2023 (функциональная безопасность ИИ) — адаптация ISO/IEC DTR 5469. Разделяет технологию ИИ на уровни (данные, модель, инфраструктура, приложение) и для каждого описывает подходящие концепции безопасности. По структуре близок к Google SAIF.
ПНСТ 847-2023 (происхождение данных) — требования к прослеживаемости данных на всех этапах: от сбора до использования в обучении. Кто создал, когда, применялась ли предобработка, как обеспечивалась легальность. Стандарт описывает меры, позволяющие избежать включения в модель дезинформации или чувствительных сведений.
ПНСТ 1046-2026 — проект будущего ГОСТ «ИИ в КИИ». Стандарт определяет весь жизненный цикл ИИ-системы от классификации системы до реагирования на инциденты, и вводит четыре категории ИИ-систем по уровню влияния ошибок на объект КИИ: от «ошибки не нарушают функций» до «ошибки приводят к тяжелым последствиям». Для категорий 1-2 (“легких”) достаточно мониторинга и правил восстановления. Для 3-4 (“тяжелых”) добавляются непрерывность функционирования и комплексное реагирование на инциденты.
Связь документов
Иерархия российских документов по безопасности ИИ-систем в целом сформирована: от стратегического видения (Указ № 490) через обязательные требования (Приказ № 117, методика, БДУ) до принятых документов и стандартов, развивающих эти требования.
НПА других стран
Китай
Китай использует сходную с российской модель технических стандартов и госнадзора, однако реализация отличается скоростью внедрения и тем, насколько быстро стандарты конвертируются в рынок инструментов.
В Китае действуют три ключевых стандарта, охватывающих различные аспекты безопасности ИИ-систем.
TC260-003 определяет базовые требования к безопасности генеративного ИИ на трех уровнях:
обучающие данные — фильтрация, защита интеллектуальной собственности;
эксплуатация моделей — защита от атак с перечислением типов;
обработка контента — фильтрация вредоносного, маркировка сгенерированного.
Этот стандарт стал катализатором рынка услуг аудита и консалтинга в области ИИ.
GB/T 45909-2025, в том числе, про маркировку контента, созданного ИИ. Требует использования как явных, так и невидимых водяных знаков, которые при этом должны быть устойчивы к сжатию, кадрированию, перекодированию.
AI Security Governance Framework 2.0 — ответ на развитие агентного ИИ. Вводит обязательные kill-switch’и для автономных агентов. Требует human-in-the-loop для критически важных решений.
Показателен пример стандарта AIIA/PG 0163-2026 по защите ИИ-агентов, принятого в марте 2026 года на фоне быстрого распространения агентных ИИ-систем и, в частности, инструментов класса OpenClaw. Этот стандарт, как и TC260-003, описывает трехуровневую модель, но разделяет несколько иначе:
· безопасность базовой среды — изоляция, конфигурация, уязвимости;
· безопасность данных — минимальные привилегии, двойная аутентификация;
· безопасность приложений — защита от инъекций, контроль вызова инструментов.
К середине 2026 года ряд крупных китайских поставщиков (QAX, Tencent, Venustech, NSFOCUS, Ant Group) уже прошли оценку соответствия — путь от принятия документа до сертификации продуктов занял один месяц.
Сертификацию проводит CAICT (China Academy of Information and Communications Technology), государственный исследовательский институт при Министерстве промышленности и информатизации. По функциям это близкий аналог российского ФСТЭК России, но с собственной испытательной лабораторной базой.
При этом CrowdStrike исследовала модели DeepSeek и обнаружила, что запросы с геополитическими триггерами (Тайвань, Тибет, уйгуры) приводят к заметному снижению безопасности генерируемого кода. Поэтому нельзя говорить, что следование стандартам однозначно делает ИИ-системы лучше — иногда политические требования к модели и техническая безопасность могут входить в противоречие, и калибровка этого баланса представляет собой отдельную инженерную задачу.
Условный Запад: ЕС, США, Великобритания
За пределами России и Китая регулирование строится преимущественно на юридических рамках и отраслевом саморегулировании.
Европейский союз: AI Act
В 2024 году ЕС принял Регламент 2024/1689, известный как AI Act. Документ классифицирует ИИ-системы по четырем уровням риска:
неприемлемый,
высокий,
ограниченный,
минимальный.
Общие положения действуют с августа 2026 года, однако требования к high-risk системам были сдвинуты актом 2026/1744 (AI Omnibus):
для систем из Annex III (биометрия, КИИ, образование, занятость) — 2 декабря 2027;
для ИИ в составе регулируемых продуктов (Annex I) — 2 августа 2028.
Системы неприемлемого риска запрещены. Высокорисковые (найм, кредитный скоринг, критическая инфраструктура) обязаны иметь систему управления рисками на протяжении всего жизненного цикла. Набор обязанностей зависит от категории системы и роли участника: требования к качеству данных, документации, мониторингу и реагированию на инциденты распределены по уровням риска неравномерно.
Практические рекомендации по реализации требований AI Act выпускает технический комитет ETSI по безопасности ИИ (ETSI TC SAI). На текущий момент опубликовано 10 документов, покрывающих вопросы от базовых требований до gap-анализа с AI Act.
США: регулирование на уровне штатов
В США единого федерального регулирования безопасности ИИ-систем сейчас нет. Указ Президента Байдена № 14110 (октябрь 2023), требовавший от провайдеров ИИ процедур оценки данных и моделей, был отменен Трампом. В результате законы принимаются на уровне штатов, и ландшафт стал неоднородным.
Фактическим стандартом для бизнеса остается NIST AI Risk Management Framework. Он не обязателен, но используется как ориентир при построении процессов управления рисками ИИ-систем.
Параллельно развиваются частные инициативы. Компания Artificial Intelligence Underwriting Company разрабатывает стандарт AUIC-1 для сертификации ИИ-провайдеров. Сертификация добровольная. Предполагается, что ее прохождение будет повышать доверие к поставщикам ИИ-услуг и позволит страховать связанные с ИИ-системами риски.
Остальные страны
Великобритания пошла по пути отраслевого регулирования: единого закона об ИИ нет. В 2023 году опубликован доклад «AI regulation: a pro-innovation approach», который задает общие принципы (безопасность, прозрачность, справедливость, подотчетность), но их реализация зависит от конкретного отраслевого регулятора.
Сингапур запустил добровольную программу AI Verify: организации могут пройти независимое тестирование ИИ-систем и опубликовать результаты. Отдельных законов для ИИ-систем не предусмотрено, регулирование опирается на существующие нормы.
TL;DR по НПА
Итак, давайте резюмируем. Россия и Китай опираются на технические стандарты и государственный надзор в критических сферах: ГИС, КИИ, госсектор. Евросоюз строит систему на классификации рисков с обязательными требованиями для всех. США в текущий момент движутся по пути отраслевого и штатного регулирования, где NIST служит добровольным ориентиром.
В последние два года особое внимание уделяется регулированию агентных систем. ИИ-агенты, способные самостоятельно вызывать API, читать файлы и принимать решения без участия человека, создают риск, не покрываемый традиционными подходами к защите. Китай и ЕС уже ввели для них обязательные kill-switch’и и human-in-the-loop. Российский методический документ «Мероприятия и меры по защите информации» идет в том же направлении: требования к гардрейлам и контролю вызова инструментов, предусмотренные методическим документом, фактически реализуют аналогичный подход.
Методологии: от оценки рисков до организации защиты
Нормативные требования определяют, что подлежит защите, но не описывают конкретные методы и контрмеры. Для этого существуют методологии — фреймворки, разработанные экспертным сообществом. Ниже методологии сгруппированы по доменам от оценки рисков до комплексной организации защиты.
Оценка рисков
Оценка рисков — первый шаг в построении защиты. Методологии этого домена помогают определить, какие компоненты ИИ-системы находятся под угрозой и насколько критичны эти угрозы.
Применение STRIDE к AI/ML-системам (известное как STRIDE-AI) — адаптация классического threat modeling (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) под системы с ИИ. Рассматриваются подстановка, подделка, отказ от авторства, раскрытие информации, отказ в обслуживании, повышение привилегий, проецируя каждую категорию на компоненты AI-контура.
Например, Spoofing применительно к LLM — это подмена источника данных в системном промпте или эмуляция легитимного пользователя через prompt injection. Для модели классификации это создание экземпляра, который обходит порог уверенности. Следует учитывать, что STRIDE не содержит готовых контрмер, а лишь предоставляет схему для их поиска. Для построения модели угроз используется методология анализа отказов FMEA: с ее помощью выявляются возможные сбои ИИ-активов и сопоставляются с категориями STRIDE. При необходимости STRIDE-AI может дополняться фреймворком LINDDUN, который детальнее оценивает угрозы конфиденциальности.
Методика распространена благодаря простоте и знакомой ИБ-специалистам терминологии. При этом STRIDE подразумевает, что модель угроз уже построена, а для ИИ-систем это отдельная задача. Более подробная информация приведена в спецификации Microsoft.
Методика CSA CBRA, также относящаяся к оценке рисков, рассматривается ниже в разделе 2.4 вместе с другими фреймворками Cloud Security Alliance.
Уязвимости
Если оценка рисков дает общую картину угроз, то следующий шаг — понять, через какие конкретные уязвимости атакующий может их реализовать. Этому посвящены методологии домена уязвимостей.
OWASP Top 10 for LLM Applications (обновился совсем недавно, в начале августа 2026) — практический чек-лист угроз для систем на базе больших языковых моделей. Десять позиций, от prompt injection (LLM01) до неправильной обработки выходных данных (LLM10).
Ниже рассмотрены три позиции, наиболее часто встречающиеся на практике.
LLM01: Prompt Injection. Атакующий добавляет в промпт инструкции, заставляющие модель обойти ограничения. Выделяют два типа таких атак: прямой и косвенный. При прямой атаке пользователь явно прописывает вредоносную инструкцию, при косвенной — прячет ее во внешнем документе, который обрабатывается моделью. В версии 2026 область расширена: добавлены кросс-модальные атаки, при которых инструкция скрывается внутри изображения или аудиофайла. В качестве противодействия может быть изоляция промпта, разграничение системных и пользовательских инструкций, гардрейлы на входе и выходе.
LLM02: Sensitive Information Disclosure. Модель выучивает конфиденциальные данные в процессе обучения и может выдать их в ответе. Базовая мера противодействия — фильтрация обучающих данных, гардрейлы на выходе, контроль интеграции с внешними источниками.
LLM04: Supply Chain. Уязвимости в зависимостях: от pickle-файлов до сторонних весов модели. За последние два года зафиксирован ряд supply chain-атак на инструменты экосистемы ИИ (Ultralytics, pytorch, litellm и другие). В версии 2026 добавлены риски, связанные с доверием к артефактам модели, когда загруженные веса не соответствуют заявленным. Противодействие: сканирование моделей, проверка контрольных сумм, политика обновлений.
Среди наиболее заметных изменений версии 2026 — актуализация и выход на третье место Excessive Agency (LLM03), отражающее рост рисков, связанных с агентными системами.
В 2025 году OWASP также запустила Agentic Security Initiative: расширение подхода на агентные системы с собственным перечнем угроз и руководством по защите. Дополнительно проектом OWASP GenAI Security Project выпущен MCP Top 10, описывающий угрозы, связанные с Model Context Protocol.
Тактики и техники атак
OWASP перечисляет уязвимости, но чтобы увидеть полную картину действий атакующего от разведки до достижения цели, нужен более высокий уровень абстракции, методологии тактик и техник.
MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) — матрица тактик и техник атак на ИИ-системы, построенная по той же модели, что и MITRE ATT&CK. Для каждой угрозы описаны шаги атакующего, примеры инцидентов и возможные меры защиты. Есть case studies на реальных атаках.
ATLAS представляет собой готовую таксономию тактик и техник. ИБ-специалистам, привыкшим к ATT&CK, не нужно осваивать новый формат: та же матрица, те же принципы группировки, просто другие тактики (ML Model Access, ML Supply Chain Compromise, Evade ML Model) и техники. В матрице доступен фильтр зрелости техник: Feasible (академическое доказательство реализуемости), Demonstrative (подтверждено на практике) и Realized (использовано в известных атаках). При ограниченном бюджете на защиту целесообразно сосредоточиться на техниках с уровнем Realized.
ATLAS описывает угрозы, OWASP — уязвимости. Связку между ними и конкретными контрмерами обеспечивает COMPASS. Он берет угрозы из ATLAS, уязвимости из OWASP и кроме связи дает ссылки на контрмеры.
Организация защиты
Фреймворки оценки рисков, уязвимостей и тактик атак отвечают на вопрос «что может пойти не так», но не описывают целостную систему защиты, за это отвечает следующий домен.
CSA CBRA — методика оценки рисков для ИИ-систем и AI-сервисов, особенно полезная при оценке внешних поставщиков. В ее основе лежит формула оценки риска: Risk = Criticality × Autonomy × Permission × Impact. Оцениваются последствия некорректной работы ИИ, наличие технических или организационных ограничений, права доступа (по аналогии с пользователем) и максимальный возможный ущерб при реализации риска. CBRA Применима для организаций, использующих облачное развертывание ИИ-систем: классификация данных, оценка доступов, специфические риски облачных провайдеров.
CBRA напрямую сопоставлена с AICM и может использоваться совместно с ним. Сам CSA AICM — комплексный фреймворк контрольных точек на всем жизненном цикле ИИ-систем. Это наиболее детальная международная методология по полноте охвата, но и наиболее сложная для освоения. Фреймворк содержит более 250 контрольных мероприятий, распределенных по ролям участников процесса защиты ИИ — разработчик, оператор, владелец и другие. Предусмотрен опросник для аудита ИИ-системы, позволяющий оценить текущий уровень защищенности и определить направления улучшения. AICM также сопоставляет меры защиты с известными стандартами.
Также существует методология Google SAIF, которая, в отличие от детального AICM, предлагает подход на уровне общих принципов. SAIF включает 6 элементов защиты: Secure Foundations, Supply Chain, Detection & Response, Auto-Protection, Harmonized Controls, Adaptive Controls. Каждый элемент описан на уровне принципа, без пошаговой реализации, поэтому может служить ориентиром при выстраивании стратегии защиты, однако конкретные шаги потребуется разработать самостоятельно.
Российские отраслевые методологии
Российские методики идут дальше общих принципов и учитывают специфику национальных НПА. Yandex AI-SAFE — российская методика от Яндекса. Учитывает требования ФСТЭК, описывает роли, меры защиты по этапам жизненного цикла, но, как и SAIF, представляет собой общую рамку, определяя лишь направление и требуя доработки под конкретную систему.
Если AI-SAFE задает общую рамку, то Swordfish SAIMM от Swordfish Security предлагает более конкретную привязку к техникам и регуляторным требованиям — по сути, таксономию угроз и контрмер с дополнительными метаданными. Есть и прямая привязка к российским НПА, поэтому для организаций, выстраивающих защиту в соответствии с требованиями ФСТЭК, это наиболее релевантная отправная точка.
Выбор методологии и практическая полнота
Выбор методологии зависит от этапа, на котором находится организация. В целом, общий порядок действий:
аудит (есть ли вообще, что защищать);
составление модели угроз (от чего защищаемся);
подбор мер (как защищаемся);
конкретных инструментов (что используем).
И в идеале редтиминг до и после реализации мер защиты.
Существующие методологии не заменяют, а дополняют друг друга, при этом зачастую только описывают, что требуется сделать, но не дают пошагового плана.
STRIDE-AI, OWASP, MITRE ATLAS служат отправной точкой для моделирования угроз, однако их преобразование в конкретные действия и артефакты соответствия требует самостоятельной работы. COMPASS связывает угрозы с контрмерами на уровне ссылок, но не дает готового плана. SAIF формулирует 6 элементов на уровне принципов, без конкретных шагов. CBRA ограничена облачными сценариями.
CSA AICM — одна из наиболее детализированных международных методологий, претендующая на полноту реализации: контрольные точки на всем жизненном цикле. Однако ее структура сложна, и освоение требует предварительного изучения. SAIMM предлагает толковую таксономию угроз и практических мер, но не помогает составить конкретный план действий.
Столкнувшись с этим противоречием, мы внутри УЦСБ как интегратора ИБ разработали для себя методику защиты ИИ-систем, опирающуюся на существующие, но позволяющую инженеру-внедренцу двигаться по понятному плану. Обзор этой методики — пошаговой, с артефактами и привязкой к российским НПА — будет представлен в следующих публикациях.
Заключение
Китайский опыт показывает, что регулирование эффективнее при наличии развитого рынка инструментов: гардрейлы, сканеры моделей, средства мониторинга появляются в ответ на требования регуляторов. Базовый контур регулирования безопасности ИИ-систем в России уже определен, однако он продолжает быстро развиваться и детализироваться. Рынок инструментов для защиты при этом находится в стадии формирования. Приказ ФСТЭК России №117 действует, методика анализа защищенности определяет порядок проверки, БДУ ФСТЭК содержит описание угроз, мероприятия и меры по защите информации утверждены. Сопоставление с международными методологиями позволяет опереться на существующие наработки: ATLAS дает модель угроз, OWASP — перечень уязвимостей, SAIMM — детализацию таксономии и привязку мер защиты к пунктам НПА.
Автор:
Алексей Синадский, к.т.н., ведущий исследователь Исследовательского центра УЦСБ