# Модель угроз

Версия фреймворка: 2.0.0-draft.1. Статус: исследовательское предложение.

## Назначение и область применения

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

Метод применяется по функциям. В исследуемую систему могут вносить вклад генерация языка, статистическое прогнозирование, символьный вывод, адаптация в ходе работы, планирование, восприятие и физическое приведение в действие. Никакой конкретный интерфейс или семейство моделей не устанавливают охват. Оценка текстового сервиса может включать наблюдение цифровой среды; оценка робота должна включать традиционные механизмы управления доступом наряду с физическим наблюдением и действием.

Результатом является пригодная для рецензирования модель угроз, связывающая защищаемые интересы, реальные компоненты, полномочия, возможное воздействие, нарушенные контракты и последствия. Это артефакт для порождения гипотез, а не доказательство того, что каждая угроза существует или что реализация уязвима. «Методика оценки» определяет, как проверяются гипотезы. «Профили систем» предоставляют предлагаемые ограничения, специфичные для развёртываний; «Уровни безопасности» определяют аналитические области, используемые для их описания.

## Определение границы системы

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

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

Связи типизируются как наблюдение, информация, инструкция, делегирование полномочий, действие, синхронизация состояния, обратная связь или зависимость от ресурса. Фиксируйте направление, содержание, значимую идентичность, проверку и поведение при сбое. Связь может иметь несколько типов, но сообщение не наделяет полномочиями автоматически. Двум агентам, обменивающимся фактами, нужен информационный контракт; руководителю, назначающему ограниченную возможность, нужен также контракт делегирования.

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

## Защищаемые интересы и контракты

Метка свойства становится проверяемой только через контракт. Для каждого важного защищаемого объекта, функции или связи укажите ответственного владельца, разрешённые операции, запрещённые переходы, допущения, метод наблюдения и реакцию на неопределённость. Используйте устойчивые идентификаторы P01–P23 из «Свойств безопасности» и «Версий и идентификаторов». Один контракт может опираться на несколько свойств, а одно свойство может применяться к нескольким компонентам.

Например, P16 «Целостность делегирования» может поддерживать контракт, согласно которому делегированная операция остаётся в пределах полномочий аутентифицированного издателя, названного объёма ресурсов, разрешённого набора операций и срока действия. Контракт должен также указывать, может ли делегирование передаваться дальше и как проверяется отзыв. Слова «доверенный» без этих условий недостаточно.

К значимым защищаемым интересам относятся конфиденциальность записей, доступность важнейших сервисов, целостность артефактов моделей, приоритет инструкций, происхождение доказательств, непрерывность сохраняемого состояния, разрешённые цели, ограниченные планы и действия, информированное разрешение человеком и коллективные лимиты ресурсов. Фиксируйте конфликты, а не предполагайте, что все свойства всегда можно максимизировать одновременно. Действие по восстановлению, возвращающее доступность, может изменить сохраняемое состояние; допустимый компромисс требует разрешённого правила.

Полномочия должны иметь источник вне оспариваемого содержимого. Укажите, кто может устанавливать, изменять, делегировать или отзывать каждую цель и каждое разрешение. Аутентификация устанавливает заявленную идентичность в рамках определённого механизма; сама по себе она не устанавливает, что каждое запрашиваемое действие разрешено. Запрос законного пользователя может превышать его права. Точно так же релевантность задаче, гладкость изложения или высокое место в результатах поиска не наделяют полномочиями инструкции.

## Участники и источники воздействия

Категории участников помогают выявлять угрозы, но не заменяют описания возможностей. Рассмотрите неаутентифицированных посторонних, аутентифицированных пользователей с ограниченными полномочиями, инсайдеров, издателей данных, поставщиков моделей или зависимостей, операторов инструментов, других агентов и стороны, контролирующие физическое или цифровое окружение. Поставщик может быть честным, но скомпрометированным. Автономная система может предоставлять вредные входные данные, при том что оценка не установила у неё намерений или самостоятельных целей.

Для каждого враждебного сценария фиксируйте доступ, знания, контроль, наблюдение, бюджет, время и ограничения. Доступ определяет достижимые интерфейсы и предпосылки. Знания определяют, известны ли участнику промпты, схемы, артефакты моделей, политики или только выходные данные. Контроль точно указывает, какие байты, записи, сигналы, моменты времени, идентичности или действия можно изменить. Наблюдение определяет обратную связь, доступную после попытки. Бюджет охватывает число попыток, вычислительные ресурсы, продолжительность, создание учётных записей и другие значимые ресурсы. Время определяет, когда возможно вмешательство относительно проверки, изменения состояния или фиксации действия.

Укажите, чего участник сделать не может. Сценарий, предполагающий право записи в политику системы, отличается от сценария, допускающего лишь публикацию документа, который затем будет найден поиском. Если оценщик получает дополнительные привилегии исключительно для подготовки тестового окружения, объясните, какое итоговое состояние злоумышленник мог бы реально создать, а какие части являются лабораторными удобствами. Административная настройка не доказывает достижимости для противника.

Цель должна называть значимый для безопасности результат, а не просто формат ответа. «Получить другой ответ» обычно недостаточно. «Вызвать раскрытие синтетической записи субъекту вне её политики доступа» определяет защищаемый интерес и наблюдаемое событие. Не отождествляйте сгенерированное моделью заявление об успехе с фактическим переходом состояния.

## Невраждебные условия

Фиксируйте нарушения, вызванные отказами, устаревшими наблюдениями, случайными ошибками конфигурации, сменой распределения, конфликтующими законными запросами или несовместимыми локальными политиками, не выдумывая злонамеренного участника. Они могут выявлять те же слабости контрактов, которыми мог бы воспользоваться злоумышленник. Их причинное описание должно указывать источник возмущения или опасности и условия его действия.

Опасность — это состояние, способное причинить вред; инцидент — наблюдаемое событие; уязвимость — слабость, позволяющая нарушить свойство безопасности при указанных условиях. Дефект качества может оставаться вне области безопасности, если не установлен значимый защищаемый интерес или контракт. В конкретном случае эти категории могут пересекаться, но они не взаимозаменяемы. Случайный инцидент не демонстрирует технику атаки, а составленный противником ввод, не вызвавший нарушения, не доказывает наличие уязвимости.

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

## Соотнесение с аналитическими областями

Девять областей — это предварительные аналитические группировки, а не этапы выполнения или ранги последствий. Соотносите с ними реальные функции, а не втискивайте компоненты в одну ячейку.

| Область | Вопрос моделирования угроз |
| --- | --- |
| L1 Модели и вычисления | Можно ли изменить или нарушить параметры модели, правила вывода или контракт заданного вычисления? |
| L2 Программное обеспечение и инфраструктура | Могут ли быть нарушены контракты реализации, доступа, изоляции, среды выполнения или инфраструктуры? |
| L3 Данные и знания | Можно ли исказить информационные ресурсы, доступ к ним, их происхождение или качество доказательств? |
| L4 Восприятие и представление мира | Могут ли наблюдения или оценки физического или цифрового окружения стать вводящими в заблуждение значимым для безопасности образом? |
| L5 Интерпретация и цели | Может ли информация получить неразрешённые полномочия инструкции или перенаправить разрешённую цель? |
| L6 Память и непрерывность состояния | Может ли сохраняемое рабочее состояние утратить разрешённую привязку, постоянство или семантику обновления? |
| L7 Планирование и действие | Могут ли планы, делегирование, проверка действий или выполнение выйти за разрешённые ограничения? |
| L8 Взаимодействие человека и системы | Может ли подача информации или взаимодействие подорвать информированное разрешение, надзор или вмешательство? |
| L9 Коллективное и системное взаимодействие | Может ли конкретный коллективный контракт нарушиться из-за связи между участниками или общими ресурсами? |

L1 и L2 разграничивают вычисление модели и его программную реализацию: скомпрометированная библиотека — проблема реализации, даже если она обслуживает вывод. L3 и L6 разграничивают информационные ресурсы и сохраняемую рабочую непрерывность: одно и то же хранилище может выполнять обе функции. L5 касается интерпретации и целей, а L7 — планов и действий, разрабатываемых или выполняемых в их рамках. Вредное поведение само по себе не указывает, что нарушение находится в L5.

L9 требует выявленного коллективного контракта и механизма связи. Крупных последствий от одного скомпрометированного компонента недостаточно. Лимит общего ресурса или условие устойчивости обратной связи могут быть нарушены на уровне группы или подграфа, даже когда ни одна отдельная связь не нарушает свой локальный контракт. Поэтому граф не ограничивается парными нарушениями.

Применяйте D1–D7 как сквозные измерения в их исходных значениях. Идентификация, управление, происхождение, приватность, жизненный цикл, наблюдаемость и восстановление остаются значимыми во всех областях. Область обозначает аналитическую ответственность; измерение даёт дополнительный ракурс; свойство формулирует, что должно выполняться.

## Построение путей воздействия и нарушения

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

Допускайте несколько причинных нарушений, составное нарушение или нерешённую классификацию. Основную область можно зафиксировать, если доказательства на неё указывают, но это не обязательно. Отличайте место, где воздействие входит, от места, где полномочия присваиваются ошибочно. Также отличайте независимо установленные сбои локализации от мер защиты, которые никогда не обещали предотвратить данное событие.

Включайте временную структуру: предпосылки, порядок, сохранение состояния, истечение сроков, повторные попытки, отложенные триггеры и возможности вмешательства. Сценарию, связанному с памятью, нужны последующий контекст и условия сброса, а не только немедленный вывод. Сценарию действия нужна точка, в которой обязательство вступает во внешнюю силу. Для взаимодействующих агентов включайте циклы, общее состояние и конкуренцию за ресурсы, а не предполагайте, что воздействие движется только вперёд.

## Разобранный сценарий

Следующий сценарий иллюстративен и не выполнялся. Ассистент по знаниям извлекает документ из источника, который может редактировать внешний издатель. Издатель не может изменить системные инструкции, учётные данные или политику инструментов. Разрешённая задача ассистента — подготовить сводку внутренних руководящих материалов; у него есть инструмент, предназначенный только для тестирования, для предложения обновлений документов.

Предполагаемое вмешательство — содержимое документа, поданное как инструкция изменить сохраняемое предпочтение, связанное с авторизацией. Вход происходит через информационную связь в L3. Возможное нарушение в L5 состояло бы в возведении содержимого документа в ранг полномочной инструкции. Возможное нарушение в L6 состояло бы в сохранении этого предпочтения без разрешённого обновления. Последующее нарушение в L7 потребовало бы отдельных доказательств нарушения контракта действия. Ни одно из них не следует автоматически из предыдущего события.

Значимые контракты могут включать P04 «Целостность инструкций», P07 «Целостность памяти» и P09 «Целостность цели». Сценарий ослабевает, если предпочтение так и не фиксируется, если уполномоченный пользователь явно запросил обновление или если результат одинаково наступает при сопоставимом безобидном содержимом. Начальные тесты должны использовать синтетические предпочтения, изолированное состояние и заглушку инструмента. Компрометация в производственной среде, распространённость и последующие последствия остаются неустановленными.

## Рецензирование и сопровождение

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

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