Перевод_Google. Состязательное машинное обучение перспективы с точки зрения промышленности
 Скачать 47.74 Kb.
|
|
Состязательное машинное обучение – перспективы с точки зрения промышленности Рам Шанкар Шива Кумар, Магнус Нистрем, Джон Ламберт, Эндрю Маршалл, Марио Герцель, Энди Комиссонеру, Мэтт Суонн и Шэрон Ся Microsoft Редмонд, США Эл. почта: atml@microsoft.com Аннотация. На основе интервью с 28 организациями мы обнаружили что отраслевые специалисты не оснащены тактическими и стратегические инструменты для защиты, обнаружения и реагирования на атаки на их Системы машинного обучения (ML). Мы используем идеи интервью и перечислить пробелы в обеспечении машинного обучения системы в контексте традиционного программного обеспечения развитие безопасности. Мы пишем эту статью с точки зрения двух персонажей: разработчики / инженеры машинного обучения и инцидент безопасности респонденты. Цель данной статьи - составить план исследования, внести поправки в жизненный цикл разработки безопасности для промышленного уровня программное обеспечение в эпоху состязательного машинного обучения. Ключевые слова: состязательное машинное обучение, безопасность программного обеспечения, инженерное дело I. ВВЕДЕНИЕ Соревновательное машинное обучение пришло в индустрия программного обеспечения - например, Google [ 1] , Microsoft [2] и IBM [3 ] заявили, что отдельно от своих обязательств по защиты своих традиционных программных систем, инициативы по защите Системы машинного обучения. В феврале 2019 года Gartner, ведущий отраслевой рынок исследовательская фирма, опубликовала свой первый отчет о состязательной машине обучение [4 ], в котором говорится, что «Руководители приложений должны предвидеть и подготовиться к снижению потенциальных рисков повреждения данных, модели воровства и состязательных образцов ». Мотивация для этого документ предназначен для понимания того, в какой степени организации разные отрасли защищают свои системы машинного обучения от атаки, обнаружение враждебных манипуляций и реагирование атакам на их системы машинного обучения. Есть много причин, по которым организации уже могут быть на опережение в систематической защите своих активов машинного обучения. Во-первых, в последние три года компании, вкладывающие большие средства в сами машинное обучение - Google, Amazon, Microsoft, Тесла - столкнулся с некоторой степенью враждебных атак [ 5] - [8]; лидер роста состязательного машинного обучения. Во-вторых, организации по стандартизации, такие как ISO [9 ], формируют критерии сертификации для оценки безопасности систем машинного обучения и чья поддержка исторически востребована в промышленность [10 ]. Кроме того, правительства демонстрируют признаки того, что отрасли придется создавать безопасные системы машинного обучения, Европейский Союз даже выпустил полный контрольный список для оценки надежность систем машинного обучения [ 11] Наконец, машинное обучение быстро стать основой ценностного предложения организаций (с прогнозируемый годовой темп роста машинного обучения 39% инвестиций в 2020 г. [12 ]), и вполне естественно, что организации вкладывают средства в защиту своей «драгоценности в короне». Мы делаем два вклада в эту статью: 1) Несмотря на веские причины для защиты систем машинного обучения, в ходе опроса, охватывающего 28 различных организаций, мы обнаружил, что большинство отраслевых практиков еще впереди смириться с состязательным машинным обучением. 25 из 28 организаций указали, что у них нет правильные инструменты для защиты своих систем машинного обучения и явно ищу руководства. 2) Перечислим инженерные аспекты безопасности сборки-разработки систем машинного обучения с использованием жизненного цикла разработки безопасности (SDL), де-факто разработчик программного обеспечения, прекращение производства в промышленности. Эта статья представляет собой сборник болевых точек и пробелов в обеспечение безопасности систем машинного обучения, с которыми сталкиваются типичные софтверные организации. Надеемся обратиться к исследованию сообщество, чтобы помочь решить проблему, с которой столкнулись два человека - разработчики программного обеспечения / инженеры машинного обучения и инциденты безопасности респонденты - при защите систем машинного обучения. В цель этой статьи - привлечь исследователей машинного обучения к пересмотру и изменить жизненный цикл разработки безопасности для промышленного уровня программное обеспечение в эпоху состязательного машинного обучения. Работа организована следующим образом: в первой части излагается обзор, методология и выводы. Вторая часть содержит пробелы в обеспечение машинного обучения в три этапа: когда системы машинного обучения спроектированы и разработаны; когда указанная система подготовлена для развертывания, и он находится под атакой. II. Промышленный обзор о состязательном ML Мы опросили 28 организаций из списка Fortune 500, малый и средний бизнес, некоммерческие и государственные организациям, чтобы понять, как они защищают свою машину системы обучения от враждебных атак (см. Таблицу I и Таблица II). ТАБЛИЦА I Размер организации Размер организации Число Крупные организации (> 1000 сотрудников) 18 Малый и средний бизнес 10 22 из 28 были в «чувствительных к безопасности» областях, таких как как финансы, консалтинг, кибербезопасность, здравоохранение, правительство. Остальные 6 организаций представляли аналитику социальных сетей, издательское дело, сельское хозяйство, городское планирование, пищевая промышленность и переводческие услуги (распределение см. в Таблице II). ТАБЛИЦА II. Типы оРГАНИЗАЦИй Организация Число Кибербезопасность 10 Здравоохранение 5 Правительство 4 Консультации 2 Банковское дело 2 Аналитика социальных сетей 1 Издательский 1 сельское хозяйство 1 Городское планирование 1 Переработка пищевых продуктов 1 Перевод 1 В каждой организации мы опросили двух человек: разработчик, отвечающий за построение моделей машин в oрганизации, и сотрудники службы безопасности, которые были на месте для обеспечение безопасности инфраструктуры организации. В зависимости от размера организации, эти два человека были либо в разные команды, одна и та же команда или даже один и тот же человек. Все организации, с которыми мы говорили, были знакомы с системой безопасности. Жизненный цикл разработки по сравнению с традиционным программным обеспечением инженерное дело, хотя степень их выполнения варьировалась - более крупные корпорации, у которых была более формальная, задокументированная процесс, чем малые и средние корпорации. Мы также ограничивается организациями, имеющими относительно зрелое машинное обучение, инвестиций, при этом некоторые из них сосредотачивают свой бизнес вокруг «AI». Эти организации реализовали свою стратегию машинного обучения в множество способов: большинство из них использовали инструменты машинного обучения, такие как Keras, TensorFlow или PyTorch для построения моделей машинного обучения; 10 организации полагались на машинное обучение как услугу, такую как Когнитивный API Microsoft [13 ], Amazon AI Services [14], Google CloudAI [15 ]. Только 2 организации создали системы машинного обучения с нуля и не полагаясь ни на существующие инструменты / ML платформы (см. таблицу III) ТАБЛИЦА III СТРАТЕГИЯ ML S Как вы строите системы машинного обучения Число Использование фреймворков машинного обучения 16 Использование машинного обучения как услуги 10 Создание систем машинного обучения с нуля 2 Ограничения исследования: размер нашей выборки 28 не может представляют все отрасли народонаселения, использующие машины обучение. Например, в исследование не включены стартапы и имеет преимущество перед организациями, чувствительными к безопасности. Мы также не учитывают географическое распространение - большая часть организации работают и имеют головной офис в США, Штаты или Европа. Мы ограничились неудачами, которые вызвано злоумышленником в системе и не исследовать более широкие нарушения безопасности, такие как распространенное повреждение [ 16] , вознаграждение за взлом [17], сдвиги в распределении [18] или, естественно, встречающиеся состязательные примеры [ 19] . А. Выводы: 1) Однако все 28 организаций указали, что безопасность Система искусственного интеллекта важна для продуктивности их бизнеса, упор по-прежнему делается на традиционную безопасность. Как одна безопасность аналитик сказал: «Наш главный вектор угроз - это целевой фишинг. и вредоносное ПО на коробке. Этот [состязательный ML] выглядит футуристический ». Хотя есть большой интерес к состязательному машинное обучение, всего 6 организаций (все крупные организации или правительство) готовы назначить подсчет для решения проблемы 2) Отсутствие ноу-хау состязательного машинного обучения: организации кажутся не хватает тактических знаний для безопасного машинного обучения системы в производстве. Как сказал один из них: «Стандартные программные атаки известны как неизвестные. Нападения на наши модели ML неизвестны». 22 из 25 (3 государственные организации воздержались от ответа удовлетворительно ответили на этот вопрос) организации сказали, что они не имеют нужных инструментов для защиты своего машинного обучения системы и явно нуждаются в руководстве. Также, инженеры по безопасности в основном не имеют возможности обнаруживать и реагировать на атаки на системы машинного обучения (см. Таблицу IV) ТАБЛИЦА IV Состояние cостязательного ML Вы защищаете свои системы машинного обучения сегодня? Число да 3 Нет 22 3) Мы прошли список атак, как указано в [20 ] и попросил их выбрать лучшую атаку, которая повлияет на свой бизнес (см. Таблицу V). Примечание: респонденты были Разрешено выбрать только одну угрозу вместо ранга стека торговый центр. Результат был следующим: ТАБЛИЦА V Топ атак Какая атака больше всего повлияет на вашу организацию? Распределение Отравление (например: [ 21] ) 10 Кража моделей (например: [ 22] ) 6 Инверсия модели (например: [ 23] ) 4 Backdoored ML (например: [ 24] ) 4 Вывод о членстве (например: [ 25] ) 3 Противоречивые примеры (например: [ 26] ) 2 Перепрограммирование системы ML (например: [ 27] ) 0 Состязательный пример в физической сфере (например: [ 5] ) 0 Вредоносный поставщик машинного обучения восстанавливает данные обучения (например: [ 28] ) 0 Атака на цепочку поставок ОД (например: [ 24] ) 0 Использовать зависимости программного обеспечения (например: [ 29] ) 0 Отравление данных привлекло внимание предприятий цены, возможно, из-за культурного значения. Тай, финтех среднего размера сказал об этом так: «Мы используем системы машинного обучения, чтобы предлагать советы и финансовые продукты для наших пользователей. Целостность нашего машинного обучения система имеет большое значение. Беспокоитесь о несоответствии рекомендация наподобие нападения на Тая » • Организации больше всего заботятся об атаках, которые могут привести к потенциальному нарушению конфиденциальности. Как один из банков поставьте это: «Хотите защитить информацию о клиенте, информацию о сотрудниках используется в моделях машинного обучения, но мы не знаем, есть ли у них план на месте" • Кража модели, которая может привести к потере интеллектуального собственность - еще одна проблема. Крупная розничная организация- Тион сказал: «Мы запускаем собственный алгоритм для решения наша проблема, и было бы тревожно, если бы кто-то может перепроектировать его " • Примеры состязательности в физическом мире, совпадают с респондентами, но не занимают высоких позиций в списке. Одна из причин может заключаться в том, что организации мы говорили, не было физического компонента, такого как автомобили или дроны. 4) Для аналитиков безопасности существует несоответствие между бывшими размышления и реальность, когда дело доходит до состязательного ML. Многие аналитики безопасности ожидают, что доступные алгоритмы на таких платформах, как Keras, TensorFlow или PyTorch по своей сути защищены от враждебных манипуляций и уже прошли боевые испытания против враждебных ML-атаки. Возможно, это потому, что аналитики безопасности которые в основном сталкивались с традиционным программным обеспечением, предположим, что библиотеки, выпускаемые крупными организациями такие как Facebook или Google уже были бы прошел стресс-тестирование безопасности. Точно так же организации кажутся продвигать ответственность за безопасность вверх по течению к сервису поставщиков услуг, как сказал один из респондентов: «Мы используем Машинное обучение как услуга и ожидайте от них предоставить эти надежные алгоритмы и платформы » 5) Наконец, аналитики безопасности и разработчики не знают чего ожидать при атаке на системы. Как один из инженеры ML сказали: «Я не ожидаю, что какая-либо система быть защищенным от спуфинга, но мне нужно знать уверенность уровни и ожидаемая производительность; а также потенциал режимы отказа. Если система подделана, что хуже возможный исход? » В следующих разделах статьи, представленных на рис.1., мы прорабатываем пробелы в текущем процессе SDL при создании Системы машинного обучения, поскольку они подготовлены к развертыванию и когда Система ML находится под атакой. Для каждого пробела мы обрисовываем существующие методы в традиционной разработке программного обеспечения и эскиз будущего повестка дня исследований. III. О SDL В июле 2001 г. на Microsoft повлияла компания CodeRed. компьютерный червь, поразивший Internet Information Server (IIS) 4.0 и 5.0 [ 30] . Это произошло из-за ошибки в одной строке в код, работающий по умолчанию в системах IIS4 и IIS5, что позволяет атака переполнения буфера. В январе 2002 года Microsoft прекратила разработку установка любого нового программного обеспечения в течение 2 месяцев, чтобы исправить все известные меры безопасности ошибки в его системе, объединяющие экспертов по безопасности с разработчиками. Благодаря этому тесному взаимодействию систематический процесс предоставления разработано руководство по безопасности, помогающее инженерам искать программное обеспечение недоработки и недоработки реализации. Этот набор практик теперь стали называть жизненным циклом безопасной разработки (SDL). Хотя SDL не устраняет все программные ошибки, они действительно помогают выявлять уязвимости программного обеспечения, которые впоследствии могут быть эксплуатируются, прежде чем они попадут в руки покупателя. Например, после того, как SDL был представлен в Microsoft, число сообщений об уязвимостях между Windows XP и Windows Vista, уменьшенная на 45%, и количество уязвимостей между SQL Server 2000 и SQL Server 2005, снижение на 91% [ 31] . В настоящее время SDL в той или иной форме де-факто является отраслевым процессом. уровень разработки программного обеспечения принят в 122 организациях [32 ], включая Google [33], IBM [34], Facebook [35] и Netflix [ 36] . Основным запросом является изменение и пересмотр SDL процесс, используемый для защиты традиционного программного обеспечения, для защиты машинного обучения. системы против враждебных атак. IV. Разрыв в развитии решений ML A. Курируемый репозиторий атак В традиционной программной безопасности атаки разложены в совместно используемые «тактики и процедуры» и все вместе организована в рамках MITER ATT & CK [37 ] . Этот предоставляет репозиторий атак с возможностью поиска, содержащий атаки исследователями, а также нападавшими на национальные государства. Для каждого атаки, есть описание техники, в которой продвинутый Известно, что постоянная угроза использует его, идеи обнаружения, а также ссылка на публикации с дальнейшим контекстом. В состязательном машинном обучении количество стипендий растет [ 38], но осведомленность разработчиков и аналитиков по безопасности низкая - только 5 из 28 организаций заявили, что у них есть работающие знание состязательного ML. Мы предлагаем, чтобы аналогичный создать рейтинговый репозиторий атак, желательно путем расширения широко используемый существующий фреймворк MITRE. Например, когда состязательные исследователи машинного обучения публикуют новый тип атаки, мы просим их регистрировать свои атаки в рамках MITER, так что аналитики безопасности имеют единый взгляд на традиционные и состязательные атаки ML. Б. Специальные методы безопасного кодирования для состязательного машинного обучения: В традиционных настройках программного обеспечения практика безопасного кодирования позволяет инженерам уменьшить уязвимости в своих программ и позволяет проводить аудит исходного кода другими организациями. инженеры. Например, Python [39 ], Java, C и C ++ [40] имеют четко определенную практику безопасного кодирования по сравнению с традиционными программные ошибки, такие как повреждение памяти. В машинном обучении настройки, конкретные рекомендации по безопасности состязательного машинного обучения немногочисленны. Большинство наборов инструментов предоставляют лучшие практики (TensorFlow [ 41] , Pytorch[42 ], Керас [43]), но TensorFlow - единственный фреймворк, предоставляет сводные рекомендации по традиционному программному обеспечению атаки [ 44] и ссылки на инструменты для тестирования против враждебных атаки [ 45] . Мы считаем, что дальнейшая работа в области состязательного машинного обучения должна быть сосредоточена по предоставлению лучших практик по устранению неопределенной программы поведения и уязвимости, которыми можно воспользоваться. Мы признаем это трудно дать конкретное руководство, потому что поле Рис. 1. Аспекты безопасности машинного обучения. Protean [46 ]. Возможно, одним из направлений было бы перечисление ели руководство, основанное на «последствиях безопасности». Смотреть на мир через SDL позволяет существовать несовершенным решениям. Например, в традиционной программной безопасности устаревшие cryptgenradnom [47 ] не следует использовать для генерации случайные начальные числа для протоколов совместного использования секретов, которые имеют более высокий последствия безопасности), но может использоваться для генерации процесса Идентификаторы в операционной системе (которая имеет более низкий уровень безопасности последствие). Вместо того, чтобы думать о практике безопасного кодирования как о гарантируя надежную гарантию безопасности, хорошее начало было бы чтобы предоставить примеры совместимых с безопасностью и несоответствующих примеры кода. C. Статический анализ и динамический анализ систем машинного обучения В традиционной безопасности программного обеспечения инструменты статического анализа помогают обнаруживать потенциальные ошибки в коде без необходимости выполнения и выявлять нарушения в практике кодирования. Исходный код обычно преобразуется в абстрактное синтаксическое дерево, которое затем используется для создания графа потока управления. Практики кодирования и проверки, которые превращаются в логику, ищутся по граф потока управления, и возникают как ошибки при несогласованности с логикой. В традиционном программном обеспечении, например, в инструментах Python как Pyt [48] обнаруживает традиционные уязвимости безопасности программного обеспечения. С другой стороны, динамический анализ предполагает поиск уязвимости при выполнении определенного пути кода. В области машинного обучения такие инструменты, как cleverhans [ 45] , secml [49], и инструментарий противоборства [50 ], обеспечивающий определенные степень динамического тестирования стиля белого ящика и стиля черного ящика. Дальнейшая область исследований - как расширить анализ на кража модели, инверсия модели и вывод членства стиль атаки. Готовый статический анализ для состязательных ML менее изучен. Один многообещающий ракурс - работа как Code2graph [51 ], который генерирует графы вызовов в платформе ML. и в сочетании с символической казнью может обеспечить первый шаг к инструменту статического анализа. Мы надеемся, что статика инструменты анализа в конечном итоге интегрируются с IDE (интегрированная де среды разработки), чтобы обеспечить аналитическое понимание синтаксис, семантика, чтобы предотвратить введение безопасности уязвимостей до того, как код приложения будет передан в репозиторий кода. D. Аудит и регистрация в системах машинного обучения Если использовать традиционный пример программного обеспечения, важна безопасность регистрируются события в операционной системе, такие как создание процесса в хосте, который затем перенаправляется в Информацию о безопасности и системы управления событиями (SIEM). Позже это позволит, респонденты безопасности для запуска обнаружения аномалий [ 52] , [53] для определить, есть ли аномальный процесс (что является признаком вредоносное ПО) был запущен на машине. Первоначально на аудит в системах машинного обучения указал Papernot [54 ] с эскизами решений для инструментальных сред машинного обучения для захвата телеметрии. Как и в традиционной системе безопасности программного обеспечения, мы рекомендуем разработчикам систем машинного обучения определять «высокий воздействие деятельности »в их системе. Рекомендуем выполнить список атак, которые считаются вредными для организации - и гарантируя, что события, проявляющиеся в телеметрии можно проследить до нападения. Наконец, эти события должны можно экспортировать в традиционные сведения о безопасности и событиях Системы управления, позволяющие аналитикам вести контрольный журнал для будущих исследований. E. Обнаружение и мониторинг систем ML В настоящее время среды машинного обучения непонятны аналитикам безопасности. поскольку они не имеют представления об операционной деятельности. Был проницательный работа, указывающая на хрупкость нынешних враждебных действий. механизмы защиты [ 46] и как их улучшить [19]. В Кроме того, мы предлагаем писать методы обнаружения так, чтобы они легко распространяются среди аналитиков безопасности. Например, в традиционной безопасности программного обеспечения логика обнаружения написана на распространенный формат, наиболее популярным из которых является Sigma [ 55] . Где MITER ATT & CK предоставляет отличное хранилище идей в методах, используемых злоумышленниками, Sigma может превратить понимание защитных действий для многих, предоставляя способ к самодокументированной конкретной логике для обнаружения злоумышленника техники. F. Разрывы при подготовке ML к использованию A. Инструменты автоматизации в конвейере развертывания В типичной традиционной настройке программного обеспечения после того, как разработчик поскольку разработчик выполняет небольшие фрагменты назначенного задача, обычно следует следующая последовательность шагов: во-первых, код привязан к системе контроля версий и непрерывно Интеграция запускает сборку приложений и модульные тесты; однажды эти пройдены, непрерывное развертывание запускает автоматическое развертывание в тестировании, а затем в производство, где он достигает клиент. На каждом этапе «сборки» инструменты безопасности интегрированный. Мы надеемся, что инструменты динамического анализа созданы для состязательных ML интегрированы в непрерывную интеграцию / непрерывную трубопровод доставки. Автоматизация состязательного тестирования ML, поможет исправить проблемы и не перегружает инженеров слишком много инструментов или чужих процессов за пределами их повседневной инженерный опыт. В. Системы машинного обучения Red Teaming Неформально риск атаки на организацию зависит от на два фактора: влияние, которое он оказывает на бизнес, и вероятность возникновения приступа. Моделирование угроз машинного обучения Системы [ 56] , выполненные разработчиками машинного обучения, обращаются к фактор воздействия. Красная команда, преднамеренный процесс эксплуатации систему любыми возможными способами, проводимую независимым постоянная служба безопасности, помогает оценить фактор вероятности. Для критически важные приложения безопасности, красная команда является отраслевым стандартом и требование предоставления программного обеспечения правительствам США [ 57] . Facebook стал первой отраслью, запустившей AI Red Команда [58 ] - неизведанная область в состязательной области машинного обучения. для других. C. Центры прозрачности В традиционной безопасности крупные организации, такие как Kaspersky [ 59 ], Huawei [60] предоставили «центры прозрачности», где участники посещают безопасный объект для проведения глубоких уровней проверки и анализа исходного кода. Участники будут иметь доступ к исходному коду и среде для углубленного осмотр с помощью диагностических инструментов для проверки аспектов безопасности различных продуктов, таких как реализация SSL и TCP / IP или генераторы псевдослучайных чисел. В контексте состязательного машинного обучения будущие центры прозрачности могут необходимо подтвердить более 3 условий: что платформа ML реализовано безопасным способом; что MLaaS реализуется - отметил достижение основных целей безопасности и, наконец, что Модель машинного обучения, встроенная в периферийное устройство (например, модели на мобильные телефоны) отвечает основным целям безопасности. Интересным направлением для будущих исследований является предоставление инструменты / средства тестирования для повышения безопасности продуктов опираясь на формальную проверку, такую как [ 61] , [62], чтобы распространяются на крупномасштабные модели машинного обучения, используемые в промышленности. VI. Разрывы ПРИ АТАКЕ СИСТЕМЫ ML A. Отслеживание и оценка уязвимостей машинного обучения В традиционной безопасности программного обеспечения, когда исследователь обнаруживает уязвимости в системе, ей сначала присваивается уникальный идентификатор. номер регистрации и зарегистрирован в базе данных Common Уязвимости и подверженность [63 ]. Сопровождая эти уязвимости - это рейтинги серьезности, рассчитываемые с использованием Common Система оценки уязвимостей [64 ]. Например, в недавнем нулевой день обнаружен в Internet Explorer, допускающем удаленное выполнение кода [65 ] уязвимость упоминалась как «CVE-2020-0674» и присвоил базовый балл по CVSS 7,5. из 10 [ 66] , что примерно указывает на серьезность ошибки. Это позволяет всей отрасли обращаться к проблеме с помощью тот же язык. В контексте машинного обучения мы просим исследовательскую компанию состязательного машинного обучения: munity для регистрации уязвимостей (особенно затрагивающих большие группы потребителей) в отслеживаемой системе, такой как CVE, чтобы гарантировать что промышленные производители предупреждены. Непонятно как Уязвимости машинного обучения следует оценивать с учетом риска и влияние. Наконец, когда аналитик безопасности видит новости о атаки, в основном сводится к следующему: "Моя организация нападением? » и сегодня организации не могут сканировать среду машинного обучения на предмет известных состязательных специфичных для машинного обучения уязвимости. В. Реагирование на инциденты Когда инженер по безопасности получает уведомление о том, что ML система находится под атакой, и определяет, что атака актуальна для бизнеса, есть два важных шага – выяснение радиус взрыва и подготовка к локализации. Например, в случай с программой-вымогателем, традиционная программная атака, взрыв радиус будет определять другие машины, подключенные к зараженная машина, и сдерживание будет заключаться в удалении машины из сети для криминалистического анализа. Оба шага трудны, потому что системы машинного обучения очень интегрированы в производственную среду, где отказ одного может привести к непредвиденным последствиям [67 ]. Одна интересная линия исследование состоит в том, чтобы определить, возможно ли «контейнерное ize »системы ML, чтобы изолировать бескомпромиссное ML системы от воздействия взломанной системы машинного обучения, просто поскольку антивирусные системы помещают зараженный файл в карантин. C. Криминалистика В традиционной программной безопасности после настройки машины подготовленный для судебно-медицинской экспертизы, чтобы установить первопричину. В этой области есть много открытых вопросов, чтобы осмысленно опрашивать атакованные системы машинного обучения, чтобы установить основная причина отказа: 1) Какие артефакты следует анализировать для каждого ML атака? Файл модели? Запросы, которые были оценены? Данные тренировки? Архитектура? Телеметрия? Аппаратное обеспечение? Все программные приложения, запущенные на атакованной системе тем? Как мы можем использовать происхождение рабочих данных и модель происхождения для криминалистики? 2) Как собирать эти артефакты? Например, для Модели машинного обучения, разработанные в конечной точке или в Интернете Вещи против организаций, использующих машинное обучение как услугу, статья факты, доступные для анализа и методологии приобретения будет иначе. Мы утверждаем, что метод судебной экспертизы машинного обучения - ology зависит от фреймворков машинного обучения (например, PyTorch vs. TensorFlow), парадигмы машинного обучения (например, усиление обучение против обучения с учителем) и среда машинного обучения (работает на хосте против облака против края). 3) Ортогональный шаг, который может быть выполнен, - это киберугроза. атрибуция, при которой аналитик безопасности может предотвратить- мой актер, ответственный за нападение. В традиционных программное обеспечение, это делается путем анализа судебных доказательств например, инфраструктура, используемая для организации атаки, угроза разведка и выяснение инструментов атакующего, тактики и процедуры, использующие установленные рубрики, называемые аналитическими торговое ремесло [68 ]. Неясно, как это будет исправлено. в эпоху состязательного машинного обучения. D. Исправление В традиционной программной безопасности. Вторник часто бывает синонимом - mous с «Патч вторник». Это когда компаниям нравится Microsoft, SAS и Adobe выпускают исправления для уязвимостей. связи в их программном обеспечении, которые затем устанавливаются на основе политика организации по установке исправлений. В контексте машинного обучения, когда Тай был скомпрометирован из-за отравление, оно было приостановлено Microsoft. Это не может быть возможным для всех систем машинного обучения, особенно тех, которые были развернут на краю. Непонятно, для чего нужны рекомендации. исправление системы, уязвимой для модели. На том же строк, непонятно, как проверить, исправлен ли Модель ML будет работать так же хорошо, как и предыдущая, но не подвержены тем же уязвимостям, основанным на Papernot et. Аля [69] результат трансферт. VII. ЗАКЛЮЧЕНИЕ В своем выступлении в 2019 году Николас Карлини [ 70] сравнил состязательное поле ML для «крипто пре-Шеннона» на основе легкость, с которой нарушается защита. Мы расширяем Карлини метафора, выходящая за рамки простого нападения и защиты: через интервью охватывая 28 организаций, мы обнаружили, что большинство инженеров машинного обучения и лица, ответственные за реагирование на инциденты, не оборудованы для защиты отрасли оцените системы машинного обучения против злоумышленников. Мы также перечисляем- есть, как исследователи могут внести свой вклад в развитие безопасности Жизненный цикл (SDL), де-факто процесс создания надежных программное обеспечение, в эпоху состязательного машинного обучения. Мы заключаем, что если ML - это программное обеспечение 2.0 [71 ] , оно также должно соответствовать фундаментальным строгость безопасности от традиционной разработки «программного обеспечения 1.0» процесс. VIII. БЛАГОДАРНОСТИ Мы хотели бы поблагодарить следующих инженеров Microsoft за поддержку: Хайрам Андерсон, Стив Диспенса, Ави Бен- Менахем, Ситараман Харикришнан, Анил Томас, Ефим Худис, Джарек Стэнли, Джеффри Сновер, Кристин Гудвин, Кевин Скотт, Кимберли Прайс, Марк Руссинович, Фараз Фадави, Уолнер Дорт, Стив Мотт, Кришна Сагар Б.В. и члены инженерная группа AETHER Security. Мы также хотели бы поблагодарить Николаса Паперно (Google Brain) и Джастина Гилмера (Google Brain), Майлз Брандейдж (OpenAI), Иван Евтимов (Вашингтонский университет), Фрэнк Нэгл (Гарвардский университет); Кендра Альберт (Гарвардский закон), Джонатон У. Пенни (гражданин Lab) и Брюса Шнайера (Гарвардская школа Кеннеди), Стив Липнер (SAFECode.org), Гэри МакГроу (BIML), Фернандо Черногория и члены AI Safety and Security Working Группа в Центре Интернета и общества Беркмана Кляйна плодотворные дискуссии. Также хотим поблагодарить ML. инженеров и аналитиков безопасности из 28 организаций за их время и идеи. СПИСОК ЛИТЕРАТУРЫ |