# Основные понятия

OSAFIS 2.0.0-draft.1 | Исследовательское предложение | 7 сентября 2026 г.

## Назначение и статус

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

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

## Интеллектуальные системы и граница оценки

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

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

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

## Контракты безопасности и защищаемые свойства

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

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

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

## Разрешённые цели и спорные задачи

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

Авторизация касается как права, так и объёма. Запрос подлинного пользователя не обязательно разрешает любые средства его выполнения или любое воздействие на ресурсы другого человека. Найденный контент, запомненные высказывания и сообщение другого агента не могут изменить цель лишь потому, что ссылаются на срочность или полномочия. И наоборот, законное разрешённое изменение не является нарушением целостности только потому, что задача изменилась.

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

## Угрозы, уязвимости, атаки и инциденты

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

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

Техника атаки — это способ оказания воздействия с целью эксплуатации слабости. Эксплойт — это конкретное выполнение или реализация такой техники против заданной цели. Механизм описывает, как действует воздействие, на полезном уровне абстракции. «Таксономия атак» разделяет механизмы, семейства, техники и модификаторы; идентификаторы M01–M12 сохраняют свои канонические значения. Указание механизма не доказывает существования уязвимости, её новизны или возможности её эксплуатации.

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

## Области, измерения, жизненный цикл и последствия

Унаследованный термин «уровень» сохранён в идентификаторах L1–L9, но обозначает предварительную аналитическую область безопасности. Область объединяет защищаемые объекты, функции или связи со взаимосвязанными контрактами. Области таковы: Модели и вычисления; Программное обеспечение и инфраструктура; Данные и знания; Восприятие и представление мира; Интерпретация и цели; Память и непрерывность состояния; Планирование и действие; Взаимодействие человека и системы; Коллективное и системное взаимодействие.

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

Сквозное измерение — это ракурс, который может влиять на контракты в нескольких областях. D1 — Идентификация, доверие и авторизация; D2 — Управление и подотчётность; D3 — Цепочка поставок и происхождение; D4 — Приватность и безопасность людей; D5 — Жизненный цикл и управление изменениями; D6 — Наблюдаемость, журналирование и аудируемость; D7 — Устойчивость и восстановление. Применимость и доказательства зависят от контекста. Измерения не заменяют классификацию по областям и не образуют дополнительных уровней.

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

## Причинные пути и композиция

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

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

Рассмотрим иллюстративный, не выполнявшийся сценарий: найденный отчёт содержит ложную инструкцию изменить получателя сводки. Отчёт поступает как информация; интерпретатор воспринимает его как полномочие; предлагаемая операция отправки проходит неадекватную проверку получателя. Точка входа — отчёт. Потенциальное нарушение полномочий инструкций относится к L5, а независимо неадекватная проверка действия — к L7. Простое извлечение и передача отчёта не доказывают нарушения в L3. Корректная проверка получателя прервала бы путь, даже если бы нарушение интерпретации сохранилось.

## Доказательства и утверждения оценки

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

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

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

## Риск, серьёзность, обратимость и меры защиты

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

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

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

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

## Развитие и цитирование

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

Каждая классификация должна ссылаться на версию фреймворка и устойчивые идентификаторы. Изменения и миграцию регулирует документ «Версии и идентификаторы». Исходный корпус с меткой 1.0 задаёт историческую отправную точку; эта метка не доказывает публичного выпуска. Данная редакция меняет границы областей и потому требует проверки человеком затронутых прежних классификаций. Научная ценность зависит от сохранения того, что действительно подтверждают доказательства, включая неопределённость, а не от сохранения видимости полной таксономии.