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

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

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

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

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

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

Знакомство

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

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

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

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

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

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

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

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

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

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

Суровость

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

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

Предложено считать критически важным

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

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

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

предлагается как средний

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

предлагается как низкий уровень

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

предложено как информационное

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

Вероятность

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

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

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

Удар

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

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

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

Тип атаки	Вероятность	Удар	Эксплойтируемость
Извлечения	Высокий	Низкий	Высокий
Уклонение	Высокий	Средний	Высокий
вывод	Средний	Средний	Средний
Инверсии	Средний	Высокий	Средний
отравление	Низкий	Высокий	Низкий

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

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

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

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

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

пример элемента управления

Как прочитать его

1. Сбор данных

Основная категория

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

Описывает элементы управления в этой категории на высоком уровне.

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

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

Цель. Обеспечение целостности собранных данных, используемых для обученных моделей.

Следует описать риск, который снижается с помощью элементов управления.

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

Заявление, описывающее результат не внедрения контроля.

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

Конкретные формулировки, описывающие лучшие практики для элемента управления.

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

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

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

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

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

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

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

Если у организации нет программы безопасности, эта оценка не является местом для начала. Перед реализацией рекомендаций в этой оценке организация должна иметь существующую программу информационной безопасности. Дополнительные сведения см. в статье 'Azure Security Guidance' в рамках 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. Данные должны отслеживаться в течение всего жизненного цикла; это отслеживание включает подмножества больших наборов данных. Необходимо, чтобы модель можно отследить обратно к данным, на которые она была обучена. Кроме того, копия этих данных должна существовать в полном объеме.

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

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

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

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

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

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

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

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

элемент управления: код обучения модели проверяется ответственной стороной.

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

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

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

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

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

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

Руководство

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

Выбор модели

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

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

Заявление об угрозе: модели переобученные для обучающего набора данных и (или) одного набора данных проверки, что делает их более уязвимыми к режимам отказа.

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

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

Версионирование моделей

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ссылки

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

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

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