Исследовательское видение OSAFIS
В этом документе
OSAFIS предлагает общее представление для анализа нарушений безопасности в интеллектуальных системах. Его цель — связать нарушенный контракт безопасности с вовлечённым компонентом или связью, механизмом воздействия, доказательствами, на которых основана находка, и последствиями в пределах объявленной границы системы. Исследователи могут использовать это представление для сравнения находок. Инженеры могут использовать его для определения мер защиты и обязательств по оценке. Ни одно из этих применений не доказывает, что представление полно или что система защищена.
Текущая версия спецификации — 2.0.0-draft.1. Она определяет исследовательский метод и предлагаемый словарь. Независимая проверка надёжности классификации, полезности оценки и полноты охвата по-прежнему необходима. OSAFIS не претендует на признание в качестве стандарта, на право сертифицировать системы, на наличие действующего публичного реестра или на устоявшееся отраслевое применение.
Решаемая проблема
Интеллектуальная система не сводится к обученной модели. Развёртывание может объединять прикладной код, обучающие данные и данные для поиска, наблюдения, сохраняемое состояние, доступ к инструментам, одобрение человеком и зависимости, общие с другими системами. Её безопасность зависит как от контрактов между этими функциями, так и от целостности каждого компонента. Действительные учётные данные могут разрешить операцию, которую пользователь никогда не запрашивал. Найденный документ может служить полезным доказательством, не обладая никакими полномочиями изменить задачу. Точное наблюдение может содержать текст, который система не должна воспринимать как инструкцию.
Эти различия требуют описания полномочий и предполагаемого использования. Традиционное управление доступом, безопасность программного обеспечения и управление операционными рисками остаются частью такого описания. Существующие работы по безопасности ИИ уже предлагают терминологию, знания об угрозах и рекомендации по снижению рисков. Исследовательская возможность для OSAFIS состоит в том, чтобы проверить, облегчает ли согласованное представление, построенное вокруг контрактов, анализ связи между этими ресурсами и конкретной системой.
Предложение сосредоточено на идентифицируемых нарушениях и обоснованных доказательствах. Правдоподобное описание атаки не доказывает, что система её допускает. Неожиданный вывод модели сам по себе не доказывает наличие уязвимости. Нарушение, продемонстрированное в одной конфигурации, не доказывает его распространённость среди продуктов. Каждое утверждение должно сохранять допущения и наблюдения, которые придают ему смысл.
Область применения и целевые пользователи
Предполагаемая область охватывает обученные и символьные модели, языковые и мультимодальные приложения, поисковые системы, адаптивные сервисы, агентов, использующих инструменты, воплощённые системы и взаимодействующие развёртывания. Применимость определяется функциями, реально присутствующими в оцениваемой системе. Цифровой агент может наблюдать среду и оценивать её состояние без физического датчика. Прогнозный сервис может вовсе не иметь постоянной памяти задач. Система, продвигаемая как автономная, может тем не менее содержать границы одобрения человеком, которые определяют её фактические полномочия.
Исследователям безопасности нужны устойчивые понятия, примеры и опровержимые правила классификации. Разработчикам систем нужны контракты безопасности с наблюдаемыми критериями приёмки и ответственными владельцами мер защиты. Оценщикам нужен пакет доказательств, отделяющий наблюдаемое от выведенного. Отраслевым специалистам нужен способ адаптировать тесты к реальным опасностям, пользователям и эксплуатационным ограничениям. Затрагиваемым людям нужно, чтобы их интересы и возможности оспаривания были представлены, когда оценка делает утверждения, касающиеся их.
Фреймворк может описывать нарушения, значимые для безопасности людей и окружения (safety), включая случайные, если они касаются объявленного контракта безопасности или существенной связи с интеллектуальной системой. Он не заменяет отраслевую оценку безопасности, клиническое исследование, юридический анализ или общее описание социального вреда. Чисто человеческие организационные проблемы, не имеющие существенной связи с интеллектуальной системой, лежат вне этой области. Неясные случаи явно остаются нерешёнными, пока граница оценки не будет обоснована.
Предлагаемое представление
Девять предварительных аналитических областей описывают обязанности по безопасности. Это L1 Модели и вычисления, L2 Программное обеспечение и инфраструктура, L3 Данные и знания, L4 Восприятие и представление мира, L5 Интерпретация и цели, L6 Память и непрерывность состояния, L7 Планирование и действие, L8 Взаимодействие человека и системы и L9 Коллективное и системное взаимодействие. Номера служат лишь идентификаторами. Они не задают порядок выполнения, рост интеллекта, степень серьёзности или расширение последствий.
Двадцать три идентификатора свойств описывают обязательства, которые могут применяться более чем в одной области. Двенадцать идентификаторов механизмов дают пересекающиеся дескрипторы враждебного воздействия. Семь сквозных измерений побуждают рассматривать идентификацию и полномочия, управление, происхождение, приватность и безопасность людей, управление изменениями, наблюдаемость и восстановление. Эти числа описывают текущий словарь. Их оптимальность не доказана.
Отдельный граф фиксирует реальные компоненты, людей и общие ресурсы с типизированными связями. Один компонент может реализовывать несколько областей. Общая модель должна отображаться как общий компонент, когда несколько агентов действительно зависят от одного и того же артефакта, а не как вымышленные независимые копии. Наблюдения, обмен информацией и синхронизация состояния не передают полномочия автоматически. Коллективные контракты могут касаться группы или цикла обратной связи, не сводясь к одной дефектной парной связи.
Находки разделяют точки входа, нарушенные контракты, участвующие области, распространение и последствия. Область, расположенная дальше по цепочке, не становится уязвимой автоматически лишь потому, что до неё дошла атака. Широкие последствия сами по себе не являются находкой в L9. Оценщики могут выявить несколько причинных нарушений или оставить классификацию неоднозначной, не навязывая искусственный основной уровень.
Принципы исследования
Определения должны помогать принимать решения. Каждая область должна указывать защищаемую функцию или связь и объяснять, чем она отличается от соседних. Каждое свойство должно задавать обязательство, которое можно конкретизировать в виде проверяемого контракта. Название свойства, например «целостность» или «доверие», недостаточно без предмета, правила разрешённых изменений, соответствующих допущений и наблюдаемого нарушения.
Доказательства должны оставаться прослеживаемыми. Отчёты должны сохранять конфигурацию, версии, происхождение входных данных, границы тестирования, исходы, противоречащие доказательства и ограничения на воспроизведение. Открытость не требует публикации частных данных или опасной полезной нагрузки. Для доказательств с ограниченным доступом должен быть объявлен порядок доступа и ясно указаны последствия для независимой проверки.
Утверждения должны оставаться соразмерными. Полнота классификации, обнаружение атак, эффективность мер снижения риска и остаточный риск — отдельные вопросы. Фреймворк может описывать нарушение, которое он не способен обнаружить автоматически. Мера защиты может блокировать проверенный сценарий, не устраняя более широкого класса. Эмпирическое исследование может подтвердить ограниченный вывод, не доказывая отсутствия будущих нарушений.
Изменения должны быть доступны для проверки. Разногласия свидетельствуют о нечётких границах, конкурирующих причинных объяснениях или различных допущениях об угрозах. Процесс должен сохранять эту информацию. Изменение границ областей требует записи о миграции, а не молчаливой переинтерпретации старых находок. Внешние сопоставления должны сохранять редакцию источника и отличать концептуальную связь от утверждения об эквивалентности.
Результаты работы и их назначение
Документ «Основные понятия» определяет единицу анализа и терминологию, общую для всего корпуса. «Уровни безопасности» определяют девять областей и правила их разграничения. «Свойства безопасности» определяют обязательства, из которых строятся контракты безопасности. «Модель угроз» фиксирует, кто и на что может влиять, при каких условиях знания и доступа. «Таксономия атак» описывает словарь механизмов и его ограничения.
«Методика оценки» определяет, как задавать область оценки, проводить тестирование, интерпретировать результаты и составлять отчёт. «Профили систем» применяют общий метод к предполагаемым классам систем, не изобретая общеотраслевых пороговых значений. «Реестр уязвимостей» определяет записи доказательств и предлагаемый процесс рассмотрения. «Связь с существующими фреймворками» фиксирует сопоставления с указанием источников. «Версии и идентификаторы» регулируют цитирование и миграцию. «Будущее» определяет исследовательские вопросы и поводы для пересмотра. Настоящий документ «Видение» формулирует цель и утверждения, которые проект готов делать.
«Учебные примеры» сопровождают спецификацию как невыполненные учебные случаи. Машиночитаемые определения и проверка записей поддерживают согласованное документирование. Они не являются сканером атак и не служат доказательством существования уязвимости. Веб-сайт и презентация передают тот же материал и никогда не должны создавать впечатление большей зрелости, чем подтверждают исходные доказательства.
Доказательства, необходимые для следующего выпуска
Архитектуру следует проверить на объявленной совокупности случаев, охватывающей различные функции, стадии жизненного цикла и масштабы последствий. Набор для разработки может помочь уточнить определения. Отдельный отложенный набор, классифицированный независимыми рецензентами по замороженным определениям, позволяет проверить, обобщаются ли эти уточнения. Отчёты должны включать неопределённость, разногласия, неоднозначные случаи, непредставленные случаи и усилия, необходимые для получения полезной классификации.
Сравнительные исследования должны проверять конкретные вопросы, например: выявляют ли рецензенты отсутствующие проверки разрешений на действия более согласованно или точнее прослеживают нарушение, связанное с общим ресурсом. Сравнение должно опираться на сопоставимую информацию и условия задачи. Оно не должно оценивать конкурирующие подходы по тому, встречаются ли в их документах названия уровней OSAFIS.
Полезность оценки требует отдельной проверки. Команды должны выяснять, даёт ли метод воспроизводимые контракты и меры защиты, которые устраняют наблюдаемое нарушение, сохраняя разрешённую функциональность. Им следует отслеживать неудачные попытки снижения риска и вновь возникшие виды нарушений. Исследования с участием людей требуют надлежащей защиты участников. Физические или необратимые последствия требуют безопасной тестовой среды и явных эксплуатационных полномочий.
Управление и публикация
Прежде чем представлять реестр как независимо управляемый, проекту нужны назначенный сопровождающий, документированный процесс рассмотрения, порядок урегулирования конфликтов интересов и процедура обжалования. Предлагаемая роль — ещё не назначенный рецензент. Предлагаемая лицензия на публикацию — ещё не принятая лицензия. Пока владелец не примет эти решения, материалы должны описывать намеченное направление открытого справочного ресурса, не предоставляя неопределённых прав и не заявляя об институциональной поддержке.
Успех означал бы, что независимые пользователи могут применять, оспаривать и улучшать это представление, а основанные на нём оценки помогают принимать более обоснованные решения по безопасности в заданных условиях. Чтобы установить такой результат, нужны доказательства, выходящие за рамки завершения документов. Настоящая спецификация делает обязательства и проверки явными, чтобы проект мог добиваться этих доказательств.