Оценка рисков ИИ для инженеров машинного обучения

Несмотря на убедительные причины для защиты систем машинного обучения, опрос Майкрософт, охватывающий 28 предприятий, обнаружил, что большинство отраслевых практиков еще не смирились с состязательной машинной машинной обучения (ML). Двадцать пять из 28 предприятий указали, что у них нет правильных инструментов для защиты своих систем машинного обучения. Кроме того, они явно ищут рекомендации. Мы обнаружили, что отсутствие подготовки не ограничивается небольшими организациями — они варьируются от компаний Fortune 500, правительств до некоммерческих организаций. Клиенты признают необходимость защиты систем ИИ, но просто не знают, как.

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

Для этого документа существует три цели:

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

Мы разработали его вместе с заинтересованными лицами корпорации Майкрософт, представителями службы "Безопасность Azure", ответственной стратегией искусственного интеллекта в области инженерии, Центра реагирования на безопасность Майкрософт, безопасность Azure и ИИ, этику и эффекты в области инженерных и исследовательских исследований (Aether).

Введение

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

Мы рассмотрим следующие области, связанные с системами ИИ.

Мы адаптировали существующую платформу элементов управления и политик из популярного стандарта ISO27001:2013 и сопоставили ее в процессе сборки системы ИИ — от этапа сбора данных до реагирования на угрозы системам ИИ. Организации могут иметь некоторые или все существующие элементы управления, реализованные в ISO27001:2013 или уже соответствуют нескольким платформам риска (NIST 800-53, PCI-DSS, FedRamp и т. д.) в рамках существующих усилий по обеспечению информационной безопасности.

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

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

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

Рекомендуемая степень серьезности, вероятность, влияние

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

Важность

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

Рекомендуемый уровень серьезности

Рекомендуемый как критически важный

• Если модель ИИ обучена, а также прием конфиденциальных персональных данных, классифицированных данных или данных, управляемых требованиями соответствия требованиям, такими как PCI, HIPAA, GLBA и т. д.
• Если модель искусственного интеллекта используется в критически важных для бизнеса приложениях или системах, таких как компрометация может оказать большое негативное влияние на бизнес-операции.
• Если модель ИИ используется в приложениях, где физическое или вредное или смерть являются возможным результатом
• Если модель ИИ используется в системе, поддерживающей критически важную инфраструктуру (например, воду, мощность, работоспособность)

Рекомендуемый как высокий

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

Предлагаемый как средний

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

Предлагаемое как низкое

• Если модель искусственного интеллекта обучена на данных, которые не используются в рабочей среде
• Если модель ИИ не используется в рабочей среде и не имеет сведений о рабочих моделях

Предлагаемое как информационное

• Если данные не классифицируются из проверенного источника
• Если модель ИИ не используется в рабочей среде

Вероятность

Вероятность имеет два основных компонента, доступность модели и доступность методов. Чтобы снизить вероятность атаки, организация должна реализовать элементы управления, которые:

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

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

Воздействие

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

Матрица серьезности

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

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

Базовое использование

Остальная часть документа соответствует этой структуре:

• Элемент управления риска содержит описание области, которую охватывает элемент управления.
• Цель элемента управления и то, что он должен достичь.
• Заявление об угрозах , которое содержит описание риска, который устраняется.
• Руководство по реализации элемента управления. Мы понимаем, что не все рекомендации могут быть реализованы по законным бизнес-причинам. Мы рекомендуем документировать рекомендации, которые не могут быть реализованы.

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

Оценка безопасности машинного обучения

Перед началом работы

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

1. Сбор сведений о текущем состоянии безопасности искусственного интеллекта в организации.
2. Выполните анализ пробелов и создайте план реализации рекомендаций.
3. Отслеживайте прогресс безопасности, выполняя эту оценку ежегодно или в два года.

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

сбор данных

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

Цель. Обеспечение целостности данных, собранных в системах ИИ.

Источники данных

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

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

Руководство.

1. Входные данные следует проверять и доверять с помощью утверждения управления перед использованием в системе ИИ.
2. Данные, собранные для системы ИИ, должны быть проверены перед использованием или хранением.
3. При необходимости собранные данные должны быть удалены из нежелательных записей.
4. Источник данных должен быть задокументирован и сохранен с данными.
5. Данные вывода, используемые для обучения модели, не должны быть неявно доверенными и должны рассматриваться как новые данные.
6. Необходимо задокументировать и проверить усилия по сбору данных. Собранные данные должны иметь владельца, ответственного за соблюдение документированных политик.

Типы конфиденциальных данных

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

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

Руководство.

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

Хранилище данных

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

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

Руководство

1. Убедитесь, что системы разработки или исследования ИИ или учетные записи не имеют доступа к рабочим базам данных и наоборот.
2. Данные, используемые в системах ИИ, должны быть классифицированы и защищены в соответствии с документированной политикой классификации.
3. Данные, используемые в системах ИИ, отслеживаются в соответствии с документируемой политикой управления активами.
4. Данные, используемые для конфиденциальных вариантов использования ИИ, хранятся в утвержденных и управляемых системах.
5. Доступ к данным должен быть проверен, и пользователи, запрашивающие доступ, должны пройти формальный процесс контроля доступа, включающий утверждение управления.
6. Данные, используемые в процессах машинного обучения, не должны предоставляться в Интернете.
7. Данные, извлекаемые из Интернета (или других ненадежных источников), должны пройти процесс фильтрации, включающий утверждение управления.
8. Наборы данных должны быть версиями с помощью формальных процессов управления изменениями.

Доступ к данным

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

Оператор угрозы: наборы данных изменяются без авторизации.

Руководство.

1. Необходимо применить управление доступом на основе ролей для наборов данных.
2. Выполняйте регулярные аудиты доступа, чтобы учетные записи с доступом к наборам данных имели доступ к наборам данных. Убедитесь, что каждая учетная запись работает в пределах обычных границ.
3. Если центральная платформа отслеживания не используется, необходимо проверить доступ к данным через необработанные журналы доступа. Убедитесь, что каждая учетная запись работает в пределах обычных границ.
4. Сторонние поставщики ресурсов, подрядчики или другие внешние стороны не должны иметь избыточный или недопустимый доступ к ресурсам обучения или тестирования данных компании без контрактов.

Целостность данных

Элемент управления. Наборы данных должны быть доверенными и оставаться доверенными на протяжении всего жизненного цикла системы ИИ.

Оператор угрозы: наборы данных изменяются во время жизненного цикла ИИ без возможности аудита или отслеживания изменений.

Руководство.

1. Наборы данных должны быть однозначно идентифицированы таким образом, что несанкционированные изменения в утвержденный набор данных приведет к просмотру набора данных.
2. Наборы данных и их криптографические описания должны отслеживаться в центральном расположении. Необходимо проверить доступ к набору данных.
3. Изменения в наборе данных должны включать обновленные криптографические описания и утверждение управления перед отправкой в центральную службу отслеживания.

Обработка данных

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

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

Обработка конвейеров

Контроль. Обработка конвейеров должна быть достаточно безопасной.

Оператор угрозы: субъект угроз может вносить несанкционированные изменения в систему, изменяя конвейеры обработки данных.

Руководство.

1. Не все данные, перемещаемые через рабочую систему, относятся к усилиям по обработке и анализу данных. Важно проанализировать только необходимые данные и убедиться, что все данные, перемещаемые из безопасного рабочего параметра в параметр разработки, правильно отслеживаются. Рассмотрим, что некоторые типы данных могут не быть перемещены в среду разработки. Может потребоваться обработка и анализ данных в безопасной промежуточной среде.
2. Важно правильное аудит доступа к данным на протяжении всего жизненного цикла обработки данных. Без отдельных учетных записей невозможно выполнить достаточный аудит доступа. Кроме того, возможность реагирования на инцидент не может произойти без потенциального влияния на бизнес-процессы. Компрометация одной учетной записи приведет к компрометации всех данных, покидающих безопасную рабочую среду.
3. Для обработки и анализа данных могут потребоваться ресурсы, которые находятся вне строгой границы соответствия.
4. Процессы обработки и анализа данных всегда должны соответствовать существующим требованиям. Этот процесс может включать перемещение ресурсов и процессов обработки и анализа данных в соответствующую среду.
5. Данные должны отслеживаться в течение всего жизненного цикла; это отслеживание включает подмножества больших наборов данных. Необходимо, чтобы модель можно отследить обратно к данным, на которые она была обучена. Кроме того, копия этих данных должна существовать в полном объеме.

Диафрагма набора данных

Контроль. Чтобы обеспечить подмножества (например, темпоральные, категориальные срезы) данных, включенных в сборку моделей и как это может привести к рискам безопасности (утечка конфиденциальности, отравление и целостность через чрезмерный срез обратной связи и т. д.).

Оператор угрозы: субъект угроз может восстановить части данных, реконструируя или восстанавливая подмножества данных.

Руководство.

1. Подмножества данных — это сами наборы данных. Эти подмножества необходимы для того, чтобы к ним были присоединены те же метаданные, что и родительский набор данных, и их следует также проверять для типов конфиденциальных данных.
2. В зависимости от политик, касающихся методик машинного обучения (соглашения об уровне обслуживания, метрик предвзятости и т. д.), любой набор данных (включая подмножества) должен соответствовать минимальному документированным стандарту, окружающему эти метрики, если они используются в построении моделей. Метаданные должны быть всегда присоединены к набору данных.
3. Все наборы данных, которые нарушают существующие политики, должны иметь задокументированные исключения, утвержденные руководством. В исключение следует задокументировать причину исключения в дополнение к необходимым метаданным.
4. Все данные, используемые для построения модели, должны отслеживаться в центральном расположении. Данные должны быть доступны для аудита в любое время. Кроме того, модели, обнаруженные для обучения без отслеживания данных, должны быть извлечены из рабочей среды, пока они не соответствуют известному набору данных с необходимыми метаданными.
5. Наборы данных должны быть соответствующим образом версии, поэтому все метаданные обновляются, а пользователи данных понимают содержимое и статистические свойства. При необходимости необходимо утвердить управление для конфиденциальных вариантов использования.

Обучение модели

Элементы управления и политики, связанные с обучением моделей и алгоритмов.

Проектирование модели

Контроль. Код обучения модели проверяется ответственной стороной.

Заявление об угрозах: неправильный код или уязвимости в коде модели создает риски доступности, целостности или конфиденциальности.

Руководство.

1. Проектирование моделей и исследования должны выполняться в соответствующей среде. Проектирование модели и архитектура могут оказать большое влияние на эффективность модели. Производственные среды не являются местом для исследований или для тестирования непровизируемых утверждений о эффективности дизайна.
2. Выбор модели для рабочей системы должен быть проверен и утвержден руководством. Этот процесс должен выполняться на ранней стадии разработки и отслеживаться с помощью любого доступного механизма (Excel, DevOps, Git и т. д.). Исключения должны быть задокументированы.
3. Модели часто относятся к конкретному предмету, и в организации должна быть соответствующая документация, сопровождающая модель.
4. Убедитесь, что метаданные модели доступны пользователям и неутвержденным использованием моделей документируются и применяются. Пользователь может точно настроить существующую модель до тех пор, пока новые метаданные подключены и отслеживаются соответствующим образом.

Обучение модели

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

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

Руководство

1. Наборы обучения и проверки должны соблюдать естественные темпоральные зависимости. Например, для классификаторов вредоносных программ набор проверки должен содержать только версии программного обеспечения позже, чем те, которые содержатся в наборе обучения.
2. Явным образом добавьте надежность модели путем расширения наборов данных с общими повреждениями, которые могут быть обнаружены в дикой природе.
3. Явно обучать против худших условий с помощью состязательной переобучения.
4. Отслеживайте эксперименты и связанные мета.

выбор модели;

Выбор модели состоит из выбора одной модели из набора кандидатов, где каждый кандидат имеет уникальный набор параметров модели, алгоритм обучения и обучение гиперпараметров. Критерий выбора для выигрышной модели часто основан на одной квантификируемой метрике (например, минимальной потере, максимальной скорости обнаружения), измеряемой на общем наборе данных удержания или в среднем по набору проверки K-fold.

Элемент управления: алгоритм проектирования модели и обучения включает явную или неявную нормализацию модели.

Оператор угроз. Модели переопределяются в обучающий набор данных и (или) один набор данных проверки и более уязвимы к режимам сбоя.

Руководство.

1. Если вычислительно возможно, следует использовать перекрестную проверку K-свертывания, чтобы предотвратить переобучение одного набора удержаний.
2. Убедитесь, что выбранные модели хорошо работают на разрозненных наборах удержаний, чтобы убедиться, что они не переопределяются.
3. Убедитесь, что существуют процессы.

управления версиями моделей;

Управление. Модели постоянно переобучены в качестве новых потоков обучающих данных в конвейеры обучения.

Заявление об угрозах: возникает инцидент, но модель, связанная с ней, не может находиться для расследования.

Руководство.

1. Модели версий, такие как каждый раз, когда модель обучена, она назначает новую версию. Квалификаторы, такие как my_model_dev_1.1 или my_model_prod_1.1, должны использоваться для удаления рабочей среды из предварительной модели. Это управление версиями помогает изолировать проблемы с рабочей или предварительной версией. Ссылка на существующие защищенные процессы или политики SDL.

Развертывание модели

Элементы управления и политики, связанные с развертыванием моделей, алгоритмов и вспомогательной инфраструктуры.

Тестирование безопасности

Управление: модели, помещенные в рабочую среду, достаточно защищены.

Заявление об угрозах: системы ИИ не тестируются на наличие уязвимостей до развертывания.

Руководство.

1. Формальные критерии тестирования принятия не определены и документированы для новых систем ИИ, обновлений и новых версий.
2. Новые системы ИИ, обновления или новые версии должны быть реализованы с помощью формального тестирования.
3. Автоматизированные средства должны использоваться для тестирования информационных систем, обновлений или новых версий.
4. Тестовая среда должна точно совпадать с конечной рабочей средой.
5. Следует задокументировать частоту, область и методы для независимых проверок безопасности.

Проверка безопасности и соответствия требованиям

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

Инструкция threat: компрометация системы машинного обучения путем доступа к незащищенной сети.

Руководство.

1. Устройства шлюза в системы машинного обучения должны быть настроены для фильтрации трафика между доменами и блокировки несанкционированного доступа.
2. Соответствующие нормативные, нормативные и договорные требования должны быть четко определены и документированы, а также рассматриваются вместе с конкретными элементами управления и отдельными обязанностями.
3. Кроме того, следует задокументировать, реализовать или проверить рекомендации по безопасной конфигурации.
4. Критерий разделения сетей машинного обучения в домены должен соответствовать политике управления доступом организации или требованиям к доступу организации.
5. Такие механизмы, как безопасный шлюз, VPN, маршрутизация для систем машинного обучения, должны быть реализованы достаточно, чтобы обеспечить выпускный набор элементов управления.
6. Пользователи и инженеры машинного обучения должны использовать или соблюдать требования к реализации элементов управления для правильного разделения и ограничения использования общедоступных систем, внутренних сетей и критически важных ресурсов.

Мониторинг системы

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

Журналы и проверка журналов

Контроль. Ведение журнала и мониторинг жизненно важны для систем машинного обучения по соображениям безопасности.

Заявление об угрозе: во время исследования журналы для систем машинного обучения не найдены.

Руководство.

1. Ведение журнала и мониторинг должны выполняться последовательно во всех системах ИИ и их компонентах, включая хранилище, конвейеры, рабочие серверы и т. д.
2. Журналы событий и безопасности следует регулярно проверять для ненормального поведения.
3. Консолидированные отчеты и оповещения о системном действии должны создаваться и проверяться руководством или представителем безопасности.

Управление инцидентами

Роли и обязанности

Управление. Журналы безопасности должны собираться в центральном расположении.

Заявление об угрозах: во время расследования аналитики безопасности не имеют формализованной сборник схем.

Руководство.

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

Планирование непрерывности бизнес-процессов

Планирование, проверка и результаты

Контроль. Убедитесь, что системы машинного обучения можно исправить и восстановить после инцидента.

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

Руководство.

1. Критически важные ресурсы ИИ должны быть определены и инвентаризации.
2. Организация должна разработать план непрерывности бизнес-процессов (BCP) или аварийное восстановление (АВАРИЙНОе восстановление) перед лицом атак на системы искусственного интеллекта.
3. Организация должна определить приоритеты рисков, связанных с воздействием потери критически важных систем искусственного интеллекта для атак.
4. Организации должны иметь тестирование непрерывности бизнес-процессов, работающее с повторным расписанием критически важных систем ИИ.

Ссылки

• Элементы управления ISO 27001 в приложении A. Обзор (isms.online)
• Официальный сайт Совета безопасности PCI
• Режимы сбоя в Машинное обучение
• Системы и зависимости для моделирования угроз и машинного обучения
• Сводки искусственного интеллекта и машинного обучения на панель ошибок жизненного цикла разработки безопасности
• Системы безопасности и управления корпоративного уровня

Если у вас есть вопросы, комментарии или отзывы, обратитесь atml@microsoft.com.

Скачайте PDF-файл этого документа из нашего репозитория GitHub.