В прошлой части мы рассмотрели документы:

• TR 104 066 «Security Testing of AI»,

• TR 104 222 «Mitigation Strategy Report»,

• TR 104 221 «Problem Statement»,

• TR 104 048 «Data Supply Chain Security»,

• TS 104 224 «Explicability & Transparency» –

в которых описываются проблемы тестирования безопасности, предотвращения рисков и объяснимости предиктивных ML‑моделей.

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

Сегодня в программе разбор следующих отчетов ASI группы из ETSI:

TS 104 050 «AI Threat Ontology»

Начнем с документа с философским названием «Онтология ИИ угроз». Авторы серьезно подходят и определению онтологии, с отсылками к математике, фреймворкам описания отношений (например, OWL - Ontology Web Language), но мы эти детали опустим. Тем не менее, бросается в глаза мысль, которая заставляет задуматься: «Доверие асимметрично — ученик доверяет учителю, но от учителя не ожидается такого же доверия к ученику». Утверждение приведено, чтобы показать, что отношения между двумя угрозами двунаправленные и асимметричные.

Проблема документа в его историчности, весь материал основан на книжках 2020 года и не содержит той динамики модели угроз, которая появилась с бумом GenAI. Внутри читатель может даже увидеть какие-то рекомендации вида “моделируйте атаки на каждую фазу ML-конвейера (data, training, deployment, inference)”, но сейчас есть и более простые фреймворки, где можно подойти к созданию MLSecOps-стека. Сложно сказать, зачем ASI выпускает подобную работу, но на первый взгляд получилось так: документ начали писать в январе 22, но потом забросили и спустя три года он был выпущен. Иногда кажется, что не все начатые инициативы стоит завершать. 

В качестве рекомендации, если вы хотите обзор с высоты птичьего полета, посмотрите на Security Matrix от OWASP AI Exchange. 

TS 104 223 «Baseline Cyber‑Security Requirements»

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

Каждое из положений четко направлено на одну из ролей: разработчики систем и моделей, команда эксплуатации (операторы системы/System Operators), владельцы наборов данных (Data Custodians), клиенты и потребители ИИ-систем. Дополнительно вводится роль Affected entities, где указано, что целевая ИИ-система может повилять на другие автономные системы, тем самым TS 104 223 оставляет задел для агентных систем. Может показаться странным, что происходит резкий переход от устаревших документов, с которых я начал статью, к передовым агентным моделям, но объясняется это просто: в рабочей группе TS 104 223 есть участники из нашего стрима OWASP Agentic Innitiative, которые добавляют свой взгляд на тренды в отрасли.

Несколько наиболее интересных положений привел для вас ниже

Во вступлении к первой части, упоминали, что ETSI имеет высокое влияние и именно этот документ будет в будущем влиять на согласование с другими весовыми стандартами ​​CEN и CENELEC. Если вас интересует, как будет выглядеть будущее европейского compliance ИИ-систем, изучите данную спецификацию подробнее. Так же, конечно, стоит обратить внимание на http://code-of-practice.ai, который выходит рядом с EU AI Act.  

TR 104 065 «AI Act mapping & gap analysis» 

Редкий документ, здесь рабочая группа делает детальный маппинг статей EU AI Act на покрытие текущими документами и рекомендациями ETSI. Своего рода это итог работы рабочих групп SAI, которые показывает как закон может приземляться в нормативные документы внутри компаний. 

В приложении B определены все документы группы ETSI TC SAI, с явным указанием New Work Items, то есть направлением их доработки для будущих версий. Сейчас почти документы имеют версию 1, но судя по несоответствию текущих наработок более строгим требованиям AI Act, будущие релизы гарантированы, но судя по скорости анонсов не в ближайшие месяцы. Несколько примеров  маппинга в таблице ниже:

Из интересного выше, анонсирована работа по UCYBEX — Universal Cybersecurity Information Exchange Framework. Это будет открытый формат и набор API для обмена данными о кибер-инцидентах, уязвимостях и «нештатном поведении» ИИ-систем. Цель фреймворка будет обеспечить исполнение статей 72-73 EU AI Act (пост-маркет мониторинг и отчётность о серьёзных инцидентах) и разрабатывать его будут две рабочие группы в ETSI: SAI, документы которой мы разбираем, и CYBER, группы по классическому ИБ.

TR 104 128 «Guide to Cyber‑Security for AI Systems»

Завершает наш обзор последний документ из ETSI. Это практический путеводитель по тому, как выполнять 80 рекомендательных положений из базового стандарта ETSI TS 104 223.

Гайд иллюстрирует выполнение мер на четырёх практических сценариях — для каждого позже приводятся конкретные контроли и ссылки на сторонние стандарты:

Chatbot App – организация использует публичный LLM через API, чтобы сделать чат-бот для внутренних сотрудников или клиентов (приведены варианты: крупная компания, малый e-commerce, больница, муниципалитет) 

ML Fraud Detection – разработчик берёт открытый классификатор, дообучает его и разворачивает систему для выявления мошеннических транзакций, избегая социального скоринга 

LLM Provider – технологическая компания создаёт новый мультимодальный LLM и продаёт доступ к нему по API для разных приложений (виртуальные ассистенты, генерация медиа) 

Open-Access LLM – небольшая организация разрабатывает специализированный LLM и выпускает его как open source (примеры: юр-фирма, организация поддержки фермеров) 

Все последующие примеры мер (например, журналирование промптов или тренинги по AI-рискам) разбиты по тем же четырём сценариям, чтобы показать, как одна и та же норма ETSI TS 104 223 применяется в разных эксплуатационных контекстах.

Отдельно стоит отметить, что в каждом примере для каждой рекомендации даются ссылки на примеры фреймворков таких как NIST или OWASP LLM Top 10.

Гайд-компаньон к 223 спецификации мне понравился, за счёт хорошо проиллюстрированных примеров. Можно даже рекомендации из отчета продлить и на будущие агентные системы и получить соответствие ETSI требованиям:

• Ставьте guardrails вокруг всех межагентных сообщений: защита от джейлбрейков, фильтры PII, лимиты ширины контекста 

• Мониторьте не только I/O, но и внутренние вызовы инструментов – логируйте, какие функции агент дергает, с какими аргументами, и вызывайте оповещение при отклонениях 

• Рассмотрите создание поведенческого анализа агентов: аномальное число вызовов или большой объём данных к одному API — сигнал извлечения данных

Итог

Не смотря на то, что первые документы, с которых мы начали в первой части, вызывают вопросы в области практического применения, качество работ в группе SAI стало гораздо выше. Последние три отчета: 223, 065 и 128 могут успешно применяться на практике и не уступают гайдам того-же OWASP.

Подписывайтесь на мой телеграм-канал и телеграм-канал AI Security Lab, чтобы оставаться в курсе последних обновлений в мире безопасности ИИ