Методика оценки

OSAFIS 2.0.0-draft.1 · Исследовательское предложение · 12 мин чтения

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

Назначение и дисциплина утверждений

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

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

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

Область и разрешения

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

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

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

Вопрос и эксплуатационный контракт

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

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

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

Дизайн и контроли

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

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

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

Единицы и планирование выборки

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

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

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

Конфигурация и происхождение

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

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

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

Выполнение и причинные проверки

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

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

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

Временная и адаптивная проверка

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

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

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

Проверка с участием людей и физических систем

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

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

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

Коллективная проверка

Для L9 «Коллективное и системное взаимодействие» определите коллективный контракт и граф или подграф, к которому он применяется. Фиксируйте участников, общие ресурсы, планирование, семантику сообщений, начальные состояния и связи. Измеряйте предполагаемое распространение или усиление относительно сопоставимого базового уровня, указывая знаменатель и временное окно.

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

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

Анализ и неопределённость

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

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

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

Фальсификация и классификация

Активно проверяйте альтернативные объяснения. Проверьте, не демонстрирует ли базовое условие то же нарушение, не изменило ли вмешательство разрешения, не истолковал ли оракул безобидный вывод неверно и не объясняют ли результат скрытое состояние или поведение тестовой обвязки. Гипотеза о конкретном механизме может не подтвердиться, тогда как реальная уязвимость сохранится. Документируйте оба исхода.

Соотносите точки входа, нарушенные контракты, распространение и последствия раздельно. Используйте канонические названия L1–L9 и устойчивые идентификаторы M01–M12 и D1–D7. Само по себе прохождение через область не устанавливает её нарушения. Допускайте несколько причинных нарушений, составную классификацию, неоднозначность и непредставленные случаи. Навязанный основной уровень может скрыть самую информативную часть находки.

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

Дескрипторы доказательств

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

Для каждой грани фиксируйте supported, unsupported, not_tested, inconclusive или not_applicable со ссылками на доказательства и обоснованием. Unsupported означает, что приведённая проверка не подтверждает эту грань, а не что уязвимости нет. Грань с отметкой supported должна указывать точное утверждение и проверенный охват. Независимость включает зависимости по авторству, анализу, данным и выполнению; рецензентам следует раскрывать, какие из них общие.

Используйте исходы оценки supported, refuted, inconclusive, quality_issue, hazard_only или out_of_scope с указанием причины и ссылки на утверждение. Эти исходы отделены от статуса рассмотрения в реестре. Смешанные находки могут содержать несколько утверждений с разными исходами. E0–E6 не являются числовыми оценками уверенности, и их идентификаторы нельзя усреднять.

Серьёзность и эксплуатационные решения

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

Обратимость — контекстное свойство действия или последствия. Фиксируйте, возможны ли восстановление, локализация или компенсация, кем, какой ценой и в какие сроки. Компенсация не обязательно отменяет раскрытие или травму. Смешанная последовательность может включать обратимые внутренние изменения и необратимые внешние последствия.

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

Пакет доказательств и передача

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

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

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

Проверка самого фреймворка

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

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

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