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

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

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

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

Вариант использования: модерация контента

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

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

То, что означает быть безопасным, может различаться в зависимости от проекта. Для конкретного проекта требования безопасности (также называемые политиками безопасности) определяют, что ожидается от проекта. Затем ответственный инженер спроектирует систему таким образом, чтобы эти требования безопасности, вероятно, выполнялись даже в присутствии злоумышленников, которые пытаются намеренно подорвать их. Большинство требований безопасности подпадают под несколько общих категорий, и большинство систем имеют требования из всех этих категорий, чтобы считаться безопасными. Наиболее распространенным способом классификации требований безопасности является конфиденциальность, целостность и доступность (триада CIA), которые часто имеют отношение к системе.

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

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

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

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

Требования к доступности. Злоумышленники могут попытаться отключить всю систему или сделать ее настолько медленной или неточной, что она станет практически бесполезной, что может привести к остановке критически важных служб, на которые полагаются пользователи. Например, злоумышленник может попытаться отправить много изображений, чтобы перегрузить службу модерации контента, чтобы другой проблемный контент оставался на сайте дольше, или он может попытаться отключить весь сайт в отместку за приостановку действия учетной записи. Классические распределенные атаки типа "отказ в обслуживании" (DDoS), когда злоумышленники наводняют систему запросами от множества захваченных компьютеров, являются типичным примером попыток подорвать требования к доступности.

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

Атаки и защита

Дискуссия о безопасности начинается с мысли о том, что существуют злоумышленники (злоумышленники), которые хотят вмешаться в нашу систему. Злоумышленники могут быть мотивированы самыми разными причинами. Например, злоумышленники могут попытаться найти и продать личную информацию о клиентах, такую ​​как номера кредитных карт; они могут пытаться шантажировать пользователей или компании на основе личной информации, найденной в системе, такой как личные фотографии, предполагающие роман; они могут размещать незаконные материалы в учетной записи пользователя, чтобы его арестовали; или они могут попытаться снизить общее качество обслуживания, чтобы привлечь пользователей к конкуренту. Атаки могут быть вызваны исключительно денежными стимулами, такими как продажа частной информации, программы-вымогатели, шантаж и подрыв конкурентов, но атаки также могут быть формой активности, например раскрытием внутренних документов гнусных организаций и привлечением внимания к загрязнению или изменению климата. .

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

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

Обратите внимание, что у нас есть проблема мира и машины (см. главу Сбор требований): мы можем рассуждать только о машинном представлении (например, учетных записях пользователей), но не о реальном мире (например, людях). помимо того, что опосредовано датчиками (например, входы, сетевой трафик, биометрия). Целостное решение по обеспечению безопасности должно учитывать мир за пределами машины, например, как люди могут влиять на входные данные системы (например, подделка отпечатков пальцев), как информация передается в физическом мире (например, может ли кто-то подслушать незашифрованные соединение TCP/IP), как информация может передаваться в реальном мире (например, запись пароля, использование имени партнера в качестве пароля) и даже есть ли у кого-то физический доступ к машине (например, отключение и прямое копирование данных с жесткого диска). водить машину).

Атаки, специфичные для машинного обучения

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

Атаки уклонения (состязательные примеры)

Наиболее часто обсуждаемыми атаками на модели с машинным обучением являются атаки уклонения, широко известные как состязательные примеры. В двух словах, при атаке уклонения злоумышленник обрабатывает входные данные (данные логического вывода для модели) таким образом, чтобы модель выдавала желаемый прогноз во время логического вывода. Обычно входные данные создаются таким образом, что они выглядят невинными для наблюдателя-человека, но обманывают модель в «неправильном» прогнозе — то есть человек и модель расходятся во мнениях относительно правильного результата. Например, злоумышленник, знающий модель модерации контента, может создать адаптированное изображение, которое для людей явно содержит призыв к насилию, но которое модель классифицирует как безобидное. Атаки с уклонением часто используются для обхода требований безопасности, например, для публикации запрещенного контента со сценами насилия. Если модель используется для самого контроля доступа, например, для распознавания лиц при входе в телефон, состязательная атака также может нарушить требования конфиденциальности.

Состязательные примеры работают, потому что модели с машинным обучением обычно не узнают точно предполагаемую границу решения для проблемы, если бы мы вообще могли указать эту границу решения в первую очередь. То есть есть входы, где модели будут ошибаться, и атаки со стороны противника специально ищут такие ошибки. В простейшем случае мы просто ищем входные данные i, для которых модель f дает желаемый прогноз o: f(i) = o, но чаще всего мы ищем небольшую модификацию δ существующих входных данных x, где модификация достаточно мала, чтобы быть едва заметной для человека. , но достаточно, чтобы изменить предсказание модели на желаемый результат o: f(x+δ)=o.

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

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

На момент написания этой статьи неясно, какое реальное влияние оказывают враждебные примеры. С одной стороны, даже с первых дней появления спам-фильтров спамеры пытались обойти модели спам-фильтров, искажая слова, связанные со спамом, и вставляя слова, связанные с моделью, в сообщения, не являющиеся спамом (часто методом проб и ошибок). злоумышленниками, а не путем анализа фактических границ модели). Злоумышленники также адаптировали вредоносные сетевые сообщения для обхода систем обнаружения вторжений. С другой стороны, практически все примеры и тревожные новости о изощренных состязательных атаках на конкретные модели исходят от ученых, демонстрирующих осуществимость, а не реальные атаки злоумышленников, включая грим и очки для уклонения от биометрических моделей лица, атаки с присоединением наклейки на физические дорожные знаки, чтобы вызвать неправильную классификацию классификаторов дорожных знаков или направить автомобиль на встречную полосу, и объекты, напечатанные на 3D-принтере, чтобы обмануть модели обнаружения объектов.

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

  • Улучшение границ принятия решений. Все, что улучшает границы принятия решений модели, в первую очередь уменьшает возможность появления состязательных примеров. Это включает в себя сбор более качественных обучающих данных и оценку модели для ускоренного обучения (см. главу Качество модели). Однако, как обсуждалось на протяжении всей этой книги, ни одна модель не бывает идеальной, поэтому мы вряд ли когда-либо полностью предотвратим враждебные примеры.
  • Состязательное обучение.Используйте состязательные примеры, чтобы укрепить модель и улучшить границы принятия решений. Распространенной стратегией является поиск вредоносных примеров, обычно начиная с обучающих данных или данных телеметрии в качестве отправной точки, и добавление найденных вредоносных примеров с правильными метками к обучающим данным. Таким образом, мы постепенно уточняем обучающие данные вблизи границы решения.
  • Очистка входных данных. В некоторых случаях можно использовать знание предметной области (или информацию о прошлых атаках) для выявления частей входного пространства, которые не имеют отношения к проблеме и которые можно очистить при обучении и выводе. время. Например, уменьшение глубины цвета и пространственное сглаживание данных изображения могут удалить артефакты, которые могут быть использованы в модели и которые злоумышленник может использовать при создании враждебных примеров. При уменьшении объема информации, поступающей в модель, модель может стать более надежной, но при этом будет меньше сигналов для принятия решений, что, возможно, приведет к снижению точности.
  • Ограничение доступа к модели. Ограничение доступа к модели, ограничение количества запросов на вывод и отсутствие (точных) оценок достоверности — все это делает поиск состязательных атак более дорогостоящим. Хотя некоторые атаки все еще возможны, вместо высокоэффективного поиска по градиентам модели злоумышленникам, возможно, придется полагаться на несколько образцов для обучения и несколько атак, чтобы попробовать.
  • Избыточные модели. Множественные модели с меньшей вероятностью изучат одни и те же границы решений, подверженные одним и тем же состязательным примерам. Злоумышленникам может стать дороже обманывать несколько моделей одновременно, а расхождения между прогнозами моделей могут предупредить нас о ненадежных прогнозах и возможных атаках злоумышленников.
  • Излишняя информация. В некоторых сценариях информация может быть закодирована избыточно, что затрудняет одновременную атаку на модели для каждой кодировки. Например, кассовый сканер может полагаться как на штрих-код, так и на визуальное восприятие объекта при обнаружении товара (например, следить за тем, чтобы штрих-код на пакете с миндалем не был заменен штрих-кодом для более дешевых бананов). В качестве аналогичного примера были сделаны предложения по внедрению инфракрасных интеллектуальных кодов в дорожные знаки в качестве второй формы кодирования информации.
  • Проверка надежности: проверки устойчивости во время вывода (см. главу «Безопасность») могут оценить, находится ли полученный ввод очень близко к границе решения и, следовательно, может быть атакой. Проверки устойчивости, как правило, очень дороги и требуют тщательного рассмотрения соответствующей метрики расстояния, в пределах которого могут происходить атаки.

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

Отравляющие атаки

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

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

Есть много реальных примеров отравления данных, хотя в основном они не очень изощренные: в 2015 году антивирусная компания, собиравшая вирусные файлы на веб-портале, утверждала, что конкурент загрузил безобидные файлы как вирусы, чтобы ухудшить качество продукта до момент ложных срабатываний, которые раздражали и беспокоили пользователей. Бомбардировка обзоров — это явление, при котором один человек с большим количеством учетных записей или группа людей плохо оценивают фильм, видеоигру или продукт из-за предполагаемых политических заявлений, таких как бомбардировка обзоров серии Amazon Prime 2022 года The Rings of Power над его разнообразным составом — если ему не противостоять бомбардировке отзывов, это повлияет на рейтинги и системы рекомендаций. Неудачный чат-бот Microsoft 2016 года Tay извлек уроки из взаимодействия с пользователями, и в ходе того, что Microsoft назвала скоординированной атакой, некоторые пользователи успешно передали данные, которые привели к тому, что Tay произнесла антисемитские заявления в течение 24 часов после его выпуска.

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

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

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

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

Атаки извлечения модели

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

Нам не известно о многих общедоступных реальных примерах атак с извлечением моделей, но мы не удивимся, если они будут распространены среди конкурентов и часто останутся незамеченными. В 2011 году Google обвинил Microsoft в краже результатов поиска, обучая свои собственные модели поисковых систем на результатах поиска Google. В ходе спецоперации они установили поддельные результаты для некоторых конкретных синтетических запросов (например, hiybbprqag) и обнаружили, что поиск Microsoft вернул те же результаты для этих запросов несколько недель спустя.

Защита. Кража модели может быть затруднена путем ограничения того, как модель может быть запрошена. Если модель используется только внутри продукта, злоумышленникам сложнее запрашивать и наблюдать. Например, прогнозы модели модерации контента могут быть показаны модераторам только после того, как пользователи сообщили об опубликованном изображении, вместо того, чтобы раскрывать прогноз модели непосредственно пользователю, загружающему изображение. Если прогнозы модели тщательно обрабатываются перед показом результатов пользователям (см. главу Планирование ошибок), злоумышленники могут узнать только о поведении всей системы, но им может быть сложнее определить конкретное поведение внутренней модели.

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

Атаки с инверсией модели и выводом о членстве

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

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

Атаки с инверсией модели и выводом о членстве основаны на внутренних механизмах того, как алгоритмы машинного обучения учатся на данных и, возможно, подгоняют обучающие данные. Модели с машинным обучением часто могут по существу запоминать и воспроизводить части обучающих данных, что было очень заметно, когда GitHub Copilot воспроизводил большие куски открытого исходного кода дословно при определенных запросах. Поскольку модель обычно более уверена в прогнозах, близких к обучающим данным, ключевая идея этих атак заключается в поиске входных данных, для которых модель может с высокой степенью достоверности выдать прогноз. Существует множество различных технических подходов к проведению таких атак; Что касается атак уклонения и отравления, они обычно более эффективны при доступе к внутренним компонентам модели, но также работают при наличии доступа только к API.

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

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

Гонка вооружений в сфере безопасности ML

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

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

Моделирование угроз

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

Хотя существуют различные виды моделирования угроз, они обычно проходят примерно через пять этапов: (1) понимание целей и возможностей злоумышленника, (2) понимание структуры системы, (3) анализ структуры системы на наличие угроз безопасности, (4) оценка риска и разработка защитных механизмов и (5) внедрение и тестирование защитных механизмов.

Понимание целей и возможностей злоумышленника

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

Понимание структуры системы

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

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

Анализ структуры системы на наличие угроз безопасности

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

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

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

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

Оценка риска и разработка защитных механизмов

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

Угрозы обычно расставляются по приоритетам путем оценки связанных рисков, где риск представляет собой комбинацию вероятности атаки и критичности с точки зрения ущерба, причиняемого в случае успеха атаки. Хотя существуют определенные методы, большинство из них полагаются на то, что разработчики или эксперты по безопасности просят приблизительно оценить вероятность и критичность угроз по простой шкале (например, низкая-средняя-высокая или 1). до 10), чтобы затем ранжировать угрозы по произведению этих баллов. Конкретные значения этих показателей не имеют значения, пока риски оцениваются относительно друг друга.

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

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

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

Внедрение и тестирование защитных механизмов

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

Проектирование для обеспечения безопасности

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

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

Принципы безопасного проектирования

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

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

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

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

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

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

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

Обнаружение и мониторинг

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

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

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

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

Безопасное кодирование и анализ безопасности

Хотя многие уязвимости в системе безопасности связаны с недостатками проектирования, которые лучше всего устраняются с помощью моделирования угроз, некоторые уязвимости возникают из-за ошибок в коде. Многие общие проблемы проектирования и кодирования хорошо изучены и собраны в списки, такие как список OWASP top 10 угроз безопасности веб-приложений или Common Weakness Enumerations (CWE) Mitre, включая ошибки кодирования, такие как неправильное использование криптографических библиотек, неправильное распределение памяти, приводящее к переполнению буфера, или недостаточная санация пользовательских входных данных, позволяющая внедрять SQL-инъекции или атаки с использованием межсайтовых сценариев.

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

Интеграция процессов

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

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

Конфиденциальность данных

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

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

Угрозы конфиденциальности от машинного обучения

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

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

Значение данных

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

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

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

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

Политики конфиденциальности, элементы управления конфиденциальностью и согласие

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

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

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

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

Дизайн для конфиденциальности

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

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

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

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

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

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

Краткое содержание

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

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

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

Дальнейшие чтения

Как и все главы, этот текст выпущен под лицензией Creative Commons 4.0 BY-SA.