	A	B	C	D	E	F
1	Домен	Описание домена	Практика	Описание практики	Активность	Описание активности
2	Управление данными	Домен описывает практики, связанные с обработкой и использованием данных, применяемых для обучения моделей машинного обучения	Обеспечение организованного контроля доступа к данным	Доступ к конфиденциальным и чувствительным данным, используемым во время обучения, должен быть ограничен.	Внедрение модели контроля доступа	Для обеспечения безопасности конфиденциальных и чувствительных данных необходимо внедрение модели управления доступом, ограничивающей взаимодействие субъектов данных с информационными ресурсами Организации. Реализуемая модель должна основываться на следующих принципах: - Управление доступом на основе ролей: формирование системы ролей и групп пользователей, наделенных определенными правами доступа, которые назначаются каждому субъекту данных в соответствии с его функциями и обязанностями - Принцип минимальных привилегий: доступ к объекту по умолчанию запрещен, за исключением случаев, явно предусмотренных Моделью. - Принцип необходимости: каждый субъект обладает ограниченным набором прав доступа, необходимым исключительно для выполнения функций, определенных Моделью. - Аудит: все события, связанные с управлением доступом, подлежат регистрации, включая неудачные попытки авторизации. Модель управления доступом должна быть формализована в документе, утвержденном в установленном порядке. Данный документ должен содержать исчерпывающее описание всех ролей и соответствующих им прав доступа. Его положения обязательны для исполнения всеми субъектами данных. Модель подлежит регулярному пересмотру и актуализации с целью оптимизации и отмены неиспользуемых прав доступа.
3					Реализация механизмов аутентификации	Для обеспечения эффективного контроля доступа к данным необходимо реализовать программные механизмы, ограничивающие взаимодействие субъектов с информацией в соответствии с утвержденной моделью управления доступом. Система хранения и обработки данных должна быть оснащена надежной системой аутентификации. Для достижения максимального уровня безопасности рекомендуется внедрить многофакторную аутентификацию, которая предполагает предоставление пользователем двух или более независимых идентификационных факторов для подтверждения личности. Данный подход существенно повышает уровень защищенности, поскольку затрудняет несанкционированный доступ к системе даже при компрометации одного из факторов аутентификации, например, пароля.
4					Внедрение решений класса DLP	DLP (Data Loss Prevention) представляет собой комплекс технологических решений, предназначенных для предотвращения утечек конфиденциальной и чувствительной информации. DLP-системы осуществляют мониторинг и анализ данных, находящихся в хранилищах, а также передаваемых по сети. В рамках DLP-системы задаются параметры конфиденциальности данных, определяются каналы передачи данных, подлежащие мониторингу, и настраиваются политики безопасности, которые автоматически применяются при обнаружении потенциальных утечек информации.
5			Классификация и управление данными	Необходимо проводить классификацию всех данных для определения степени их критичности и для каждой категории критичности организовать процесс управления этими данные.	Классификация данных	Необходимо реализовать процесс классификации/категоризации данных таким образом, чтобы к ним можно было применить различные уровни контроля защищённости информации. Например, персональные данные пользователей, которые могут поступать на обработку, должны соблюдать требования регуляторов о хранении персональных данных и иметь модель доступа к ним на основе ролей. В зависимости от поступаемого типа данных будут применятся меры обеспечения их защиты.
6					Контроль качества данных	Процесс установления критериев и параметров для исходных необработанных данных, который зависит от конкретных задач и целей использования данных. В процессе разработки этих требований осуществляется оценка и контроль за тем, чтобы данные были репрезентативны, актуальны и корректны.
7					Обеспечение качества оценочных данных	Не секрет, что поступаемые данные не целиком используются для обучения модели - какая-то их часть входит в оценочный набор, который, в дальнейшем, будет использоваться для определения степени точности и эффективности модели. Набор данных, используемый при оценке моделей, должен быть максимально репрезентативный, актуальный и корректный, но самое главное, чтобы данные, которые проводились для обучения модели, были отличными от оценочного набора.
8					Безопасное хранение данных	Система управления и хранения данных представляет собой набор инструментов и методологий, используемых для сбора, хранения и поддержки данных в структурированном и доступном виде. Данная система включает в себя базы данных и хранилища данных, такие как даталейки (data lake) и склады данных (data warehouse), которые обеспечивают централизованное хранение разнообразных данных. Процесс хранения данных регламентирован набором политик, правил и процедур, которые формализуют методы работы с данными, включая их загрузку, обновление, резервирование и удаление. В зависимости от уровня критичности и чувствительности данных, они могут храниться по-разному. Конфиденциальные или критически важные данные обычно требуют более строгих мер контроля доступа.
9					Реализация отдельных паплайнов для обработки данных разного уровня критичности	В зависимости от классификации данных для каждой категории необходимо построить отдельный пайплайн обработки, в котором будет учтено какие требования необходимо соблюдать, где их можно использовать, какие дополнительные мероприятия проводить (обезличивание и т.д.)
10			Отслеживание происхождения данных	Организация процесса отслеживания данных в течение всего ЖЦ: источник данных, все этапы их модификации и т.д.	Определение формата информации о происхождении	На данном этапе необходимо реализовать проверку происхождения данных. Она включает в себя информацию о том, откуда взялись данные, как они были созданы, кто их создал и как они изменялись с течением времени. Данная проверка важна для обеспечения качества и целостности данных, а также для соблюдения правил защиты данных. Информация о происхождении также может использоваться для соблюдения требований по защите данных, таких как GDPR и CCPA, обеспечивая запись того, как данные были собраны, обработаны и сохранены.
11					Использование данных из проверенных источников	Проверенный источник – это источник, признанный достоверным и прозрачным в отношении происхождения данных, соответствующим стандартам и содержащим полную необходимую информацию. Если источник непроверенный и существуют сомнения в его достоверности, но данные оттуда необходимы, следует: - Провести детальные проверки данных на точность и полноту. - Сравнить с информацией из надежных источников для верификации.(Если таковые имеются) - Использовать данные из непроверенного источника только если после проверок информация покажется достоверной и полной. - Принять возможные риски при использовании данных из непроверенных источников.
12					Контроль модификации данных (дополнение информации о происхождении)	Необходимо на каждом этапе преобразования данных производить журналирование и контроль того кем и когда были изменены эти данные. В случае отравления или модификации со стороны злоумышленника это поможет понять кем было совершенно изменение и на каком из этапов при обработке данных.
13			Защита от отравления данных	Отравление данных - влияние на обучающую выборку с целью получения смещенной модели.	Контроль целостности данных	На всём цикле обработки данных необъходимо осуществлять проверку их целостности. Случайная или преднамеренная модификация или подмена меток может проивести к их отравлению.
14			Защита от отравления данных		Внедрение алгоритмов обнаружения аномалий и предотвращения атак	Внедрение алгоритмов обнаружения аномалий для выявления подозрительных закономерностей в данных, которые могут указывать на попытки отравления.
15			Защита извлечённых признаков от манипулирования	Риск манипулирования извлеченными из данных признаками (фичами) может привести к нарушению функционирования модели.	Использование шума во время извлечения признаков	Это необходимо для усложнения процесса реверс-инжиниринга исходных данных со стороны злоумышленника. А также это позволит сократить риски связанные с инверсией модели и улучшить обощающую способность модели.
16			Защита извлечённых признаков от манипулирования		Организация безопасного хранилища признаков	Необходимо реализовать или использовать безопасное хранилище признаков где признаки каталогизированы и организованы для непосредственного доступа операторам для выполнения различных задач, связанных с данными, от визуализации данных до прогнозирования, обучения моделей машинного обучения и запуска выводов на уже обученных моделях.
17			Платформа управления данными	Организация процесса управления данными, их автоматизированной и безопасной обработке, а также внедрение ограниченного или конфигурируемого доступа к данным.	Организация безопасной цепочки поставок	Необходимо реализовать комплекс мер, направленных на обеспечение безопасности данных, кода и инфраструктуры на всех этапах создания и использования моделей машинного обучения из публичных источников, включая сбор данных, обучение, тестирование, развертывание и эксплуатацию, для предотвращения вмешательства, кражи данных и других угроз.
18					Шифрование данных при хранении и передаче	Процесс шифрования данных при хранении обеспечивает защищённость данных от определённых лиц, а также позволяет не нарушать целостность данных при передачи их между процессами. В рамках этой активности необходимо произвести шифрование модели или встроенных векторов при передачи их в базу.
19					Доверенная база компонентов	Создание доверенного хранилища внутренних и внешних библиотек, инструментов и других средств для предварительной обработки данных, которые прошли тестирование на безопасность, а так же регулярно обновляются и проверяются. Такой репозиторий нужен для возможности переиспользования кода обработки данных и извлечения признаков на всём ЖЦ разработки. Использование уязвимых конструкций в процессе обработки данных может привести к нарушению целостности данных и другим проблемам безопасности.
20					Создание руководств по безопасной работе с данными	Для организации зрелого и безопасного процесса обработки данных необходимо формализовать и стандартизировать работы с данными в виде специального руководства, описывающего все требования и необходимые активности, включая, например: 1.Обеспечение контроля доступа к данным; 2.Обеспечение безопасности при для хранении данных (Databases, Data Lake); 3.Безопасная передача данных; 4.Порядок работы при предобработке данных; 5.Подходы к классификации данных; 6.Защита целостности; 7.Необходимые шаги и проверки. Такой артефакт необходимо сделать обязательным к исполнению и осуществлять контроль за выполнением всех изложенных в нём требований.
21					Автоматизация конвейера по обработке данных	Создание конвеера для автоматизированной обработки данных поможет сократить затраты на ручной труд, ускоряя использование данных, повышая их качество и упрощая процесс доставки самих данных для исследований. Это может включать в себя разнообразные этапы, такие как сбор данных, очистка и предварительная обработка данных, преобразование, интеграция с различными источниками, хранение, анализ, анонимизация и визуализация. Использование всех инструментов и программного кода должно сопровождаться обязательным требованием к их качеству и подлежать учёту.
22					Формализация всего ЖЦ обработки данных	Необходимо выполнить структурированное описание всех этапов, через которые проходят данные от их сбора до обучения с использованием их и окончания их использования. Такая формализация помогает обеспечить качество и целостность данных на протяжении всего их жизненного цикла и позволяет отслеживать все изменения и операции, выполняемые с данными.
23	Развёртывание и обслуживание модели	Домен описывает практики, связанные с развертыванием моделей, их обслуживанием и мониторингом	Контроль и воспроизводимость проводимых экспериментов	Эксперименты в ML моделях заключаются в сравнении результатов обучения моделей с разными параметрами. Необходимо выстроить и формализовать процесс учёта и документирования проведенных экспериментов. В противном случае, его отсутствие может привести к невозможности повторения успешных экспериментов, проблемам с отладкой модели при сбоях и неэффективному использованию рабочих ресурсов.	Документирование проводимых экспериментов	При проведении экспериментов необходимо тщательно отслеживать и документировать как сам процесс проведения эксперимента, так и входные/выходные данные, используемые в эксперименте. Подробный протокол необходим, чтобы, во-первых, результаты эксперимента не были потеряны, во-вторых, можно было проверить гипотезу, проведя повторный эксперимент и сравнив результаты. Анализ проведённых экспериментов может помочь значительно улучшить разрабатываемую модель и сократить риск того, что она будет некорректно работать или иметь ошибки безопасности.
24					Стандартизация инструментов управления экспериментами	Все инструменты и другие вспомогательные средства должны быть описаны и стандартизированы для того, чтобы эксперимент был воспроизводим, а процесс проведения экспериментов был простым и занимал меньше времени.
25					Использование контейнеризации для упрощения репликации эксперимента	Системы контейнеризации позволяют реализовать версионирование при проведении эксперимента для конкретной модели машинного обучения, делая среду изолированной а также портируемой. Контейнеры также позволяют гибко настроить среду для проведения экспериментов.
26			Использование одобренных компонент в процессе обучения модели	В процессе разработки ML-модели должны использоваться одобренные компоненты, такие как библиотеки, инструменты или преодобученные модели. Потенциальные злоумышленники могут встраивать бэкдоры в используемые компоненты, что позволяет им получить доступ к пайплайну обучения или манипулировать результатами модели при определенных условиях.	Создание доверенной базы компонентов	В процессе разработки ML модели необходимо использовать только одобренные компоненты, которые прошли необходимые проверки и являются безопасными. Необходимо создать репозиторий, который будет выступать, с одной стороны, как хранилище безопасных компонент, которые можно использовать, и средство обеспечения стандартизации кода на всём ЖЦ разработки.
27					Ограничение на использование сторонних компонент	Для предотвращения попадания в контур разработки ML модели уязвимых компонент, все сторонние библиотеки должны подлежать обязательному анализу и использоваться лишь в том случае, когда они будут идентифицированы и безопасны. Все одобренные компоненты должны попадать в хранилище одобренных компонент и, в то же время, в процессе разработки должны использоваться лишь те компоненты, которые содержатся в этом хранилище.
28					Использование инструментальных проверок	Все внешние компоненты, артефакты исходного кода и экземпляры модели должны подвергаться инструментальному анализу. Сюда входит как стандартные инструменты анализа защищённости классов SAST, DAST, SCA, так и специфичные заточенные под ML проверки. Такие как уязвимости десериализации, недостатки предвзятости модели, нарушение дифференциальной приватности а также иные недостатки приводящие к атакам типа model inversion, model hijacking и др. Проведение подобных проверок должно быть обязательным шагом пайплайна разработки, а результаты должны удовлетворять заранее настроенным политикам безопасности.
29					Регламент безопасной разработки (ранее - регламент использования сторонних библиотек)	Необходимой задачей для организации процесса безопасной разработки ML моделей и обеспечения обязательства использовать только одобренные компоненты будет составление документа, описывающего порядок работы со сторонними библиотеками, инструментальными проверками и хранилищем одобренных компонентов.
30			Защита активов модели	Минимизация риска несанкционированного или непреднамеренное раскрытия и/или модификации активов (например, параметров модели, обученных моделей, кода и т.д.)	Контроль доступа	Для защиты активов модели необходимо обеспечить ограниченный доступ в контур разработки и ко всем ресурсам модели. Для внедрения такого контроля нужна ролевая модель и обеспечение принципа минимальных привилегий. Если структура организации такое позволяет, можно расширить модель доступа, разработанную на этапе обработки данных. Так же необходимо организовать сегментацию сети для разделения dev test и prod сред.
31					Использование шифрования при хранении и передаче активов	Процесс шифрования данных при хранении обеспечивает защищённость данных от третьих лиц, а также позволяет не нарушать целостность данных при передачи их между процессами. В рамках этой активности необходимо произвести шифрование модели или встроенных векторов при передачи их в базу.
32					Контроль аномальной активности	Внедрение инструментальных средств мониторинга инфраструктуры разработки Модели обеспечит непрерывный мониторинг и позволит детектировать аномальную активность, что может сигнализировать о проблемах с безопасностью, в т.ч несанкционированному доступу к контуру разработки, возможности модификации Модели, влияние на её обучение и другим угрозам безопасности. Работа инструментов мониторинга должна сопровождаться сбором заранее определённых метрик для отслеживания точки входа нарушителя или уязвимых мест в процессе разработки.
33					Создание центрального хранилища для моделей с контролем доступа	Хранилище поможет контролировать состояние целостности для модели, защитить его от кражи при взаимодействии с подрядчиками а также мониторить или разграничивать доступы для определённых групп лиц.
34					Внедрение в активы цифрового водяного знака	Необходимо внедрить водяные знаки в данные, которые могут быть использованы для обучения с целью защиты от кражи интеллектуальной собственности. Также, необходимо реализовать алгоритм нанесения водяных знаков на генерируемый контент.
35			Оценка модели	Практика ориентированная на контроль результатов модели.	Анализ защищённости модели	На данном этапе необходимо реализовать проверку модели методом тестирования Black-box на различные атаки такие как Evasion, Poisoning, Extraction, Inference, Prompt leaking, Prompt Injection.
36					Внедрение методов интерпретации результатов модели	Интерпретация результатов моделей машинного обучения важна для понимания того, как модель принимает решения, что увеличивает доверие к модели и позволяет обнаружить возможные предвзятости или ошибки.
37					Оценка точности модели	Оценка точности ML модели играет критическую роль в обеспечении безопасности, поскольку неточные модели более уязвимы к атакам, принимают ненадежные решения и могут скрывать другие уязвимости. Пренебрежение оценкой точности может привести к непредсказуемым последствиям, особенно в критичных областях. Поэтому в рамках разработки важно оценивать точность модели, чтобы выявлять уязвимости, повышать ее устойчивость к атакам и гарантировать надежность принимаемых решений.
38					Внедрение формализованного процесса для ПСИ	Перед использованием ML модели в промышленной среде или передаче заказчику, необходимо убедиться, что ML модель соответствует всем установленным требованиям и прошла все необходимые этапы разработки (включая инструментальные проверки). Для реализации такого мероприятия необходимо разработать и формализовать чёткий процесс приёмо-сдаточных испытаний, прохождение которых будет обязательным шагом перед релизом модели или развёртыванием на мощностях Заказчика.
39			Платформа управления разработкой	Реализация формализованного процесса управления разработкой с использованием инструментальных средств для управления всеми элементами разработки и автоматизацией всего процесса.	Хранилище обученных моделей	Хранилище для обученных моделей также может помочь контролировать состояние целостности для модели, защитить его от кражи при взаимодействии с подрядчиками а также мониторить или разграничивать доступы для определённых групп лиц.
40					Контроль версий	Внедрение средств и соответствующих политик для контроля версий это критически важный аспект процесса разработки программного обеспечения, который управляет изменениями в коде модели, данных, конфигурациях и других документах, связанных с проектом. Основная цель контроля версий — обеспечить организованное и безопасное хранение всех версий проекта и возможность быстро возвращаться к предыдущим состояниям системы, когда это необходимо.
41					Разработка политик и руководств для процесса разработки	Это этап для создания структурированных документов, которые предписывают нормы, правила и методы работы команды разработчиков по отношению к коду, модели и данным. Эти документы помогают установить общие стандарты и процедуры, обеспечивающие согласованность действий и качество продукта.
42					Автоматизация конвейера разработки модели	Создание конвеера для автоматизированной обработке данных поможет сократить затраты на ручной труд, ускоряя использование данных, повышая их качество и упрощая процесс доставки самих данных для исследований. Это может включать в себя разнообразные этапы, такие как сбор данных, очистка и предварительная обработка данных, преобразование, интеграция с различными источниками, хранение, анализ, анонимизация и визуализация.
43					Формализация всего ЖЦ разработки модели	Необходимо выполнить структурированное описание всех этапов, через которые проходят данные от их сбора до обучения с использованием их и окончания их использования. Такая формализация помогает обеспечить качество и целостность данных на протяжении всего их "жизненного пути" и позволяет отслеживать все изменения и операции, выполняемые с данными.
44					Организация безопасной цепочки поставок	Безопасная цепочка поставок позволяет разработчикам быть уверенным в том, что все компоненты используемые при разработке - не были подвержены модификации со стороны злоумышленника. Например если при разработке используется предобученная модель взятая из модельхаба то необходимо удостоверится в том, что в саму модель не был внедрён вредоносный код, позволяющий к примеру реализовывать полноценный бэкдор для выполнения комманд на конечной точке или функционал, искажающий результаты модели.
45			Процесс развёртывания	Реализация процесса развёртывания модели с использованием CI/CD для непрерывной работы.	Обеспечение безопасности цепочки поставок	Безопасная цепочка поставок позволяет разработчикам быть уверенным в том, что все компоненты используемые при разработке - не были подвержены модификации со стороны злоумышленника.
46					Минимизация или полное исключение варианта развёртывания на конечной точке заказчика	Стремимся к централизованному развёртыванию модели, например, через API. Это требуется, чтобы снизить риски, связанные с доступом, контролем версий и защитой модели на множестве устройств. Также такой подход упрощает обновление модели и контроль безопасности.
47					Автоматизация процесса развёртывания и обновления	Активность подразумевает внедрение CI/CD-пайплайнов для автоматизации развёртывания и обновления моделей, что уменьшает вероятность человеческих ошибок и обеспечивает согласованность и воспроизводимость процесса. Автоматизация позволяет быстро реагировать на инциденты безопасности и оперативно доставлять обновления безопасности.
48					Формализация процесса доставки	Внедрение стандартизированного и документированного процесса доставки и развертывания, описанного в утвержденном регламенте, с четкими инструкциями по каждому этапу. Формализация, наряду с автоматизацией, обеспечит прозрачность, ускорит доставку приложения, минимизирует ошибки и создаст основу для зрелого CD, лежащего в основе MLSecOps.
49			Защита приложения на конечной точке	Практика целью которой является защита модели машинного обучения при развёртывании на конечной точке от различных атак, которые приводят к краже или потере доступности к модели.	Сегментация сети и контроль доступа	Разделение сети на более мелкие, изолированные сегменты, чтобы ограничить радиус действия потенциальной атаки. А также применение строгих политик контроля доступа, для обеспечения доступа к модели и данным только авторизованных пользователей и приложений.
50					Использование инструментов IDS/IPS	Внедрение систем обнаружения и предотвращения вторжений (IDS/IPS) для отслеживания подозрительной сетевой активности. Необходимо настроить IDS/IPS для выявления и блокировки известных атак, направленных на ML-системы. Такие решения защищают от несанкционированного доступа, позволяя своевременно оповещать сотрудников безопасности и предпринимать необходимые меры по минимизации рисков ущерба от вторжения.
51					Защита модели от копирования (кражи)	При передаче и развёртывании приложения на конечной точке Заказчика присутствует риск копирования (кражи) модели как самим Заказчиком, так и злоумышленником в контуре Заказчика. Необходимо внедрить меры, позволяющие защитить приложение и модель.
52					Внедрение водяных знаков	Одним из методов защиты модели от кражи является внедрение водяных знаков, что позволяет идентифицировать владельца модели и подтверждать его авторское право. Принцип работы водяных знаков заключается в добавлении в исходный код файлов дополнительной метки с сохранением информативности. Отметка водяными знаками применима для различных видов входных данных. Внедрение водяных знаков должно осуществляться таким образом, чтобы при попытке злоумышленника удалить метку (в случае, если он знает о её наличии) значительно ухудшалась работа ML модели (что сделает условия работы без водяных знаков невозможным).
53					Мониторинг и регулирование ресурсов	Для обеспечения бесперебойной и корректной работы приложения следует отслеживать его состояние, анализуя используемые ресурсы (например, ЦП, памяти, задержек) и, при необходимости, осуществлять динамическую настройку параметров инфраструктуры для предотвращения перегрузки, сбоя и других нежелательных последствий, также возможнга установка лимитов использования ресурсов для предотвращения атак типа "отказ в обслуживании" (DoS). Такой подход позволит обеспечить доступность приложения во время различных атак.
54					Создание защищённых интерфейсов	Разработка API и интерфейсов взаимодействия с моделью с учетом принципов безопасности. Взаимодействия программного интерфейса с пользователем должен быть настроен таким образом, чтобы иметь превентивную защиту от недопустимых событий. Для этого при проектировании интерфейса нужно заложить следующие принципы: - использование защищённых криптопротоколов; - запрет доступа неавторизованным пользователям; - реализация аутентификации и контроля доступа в соответствии с вышеупомнятыми бестпрактис - реализация мер по контролю запросов к системе
55					Оптимизация на уровне оборудования	Изучение и внедрение специализированного оборудования, которое может эффективно выполнять трудоёмкие операции или обнаруживать и обходить аномальные закономерности.
56					Реализация принципа наименьших привелегий для моделей, которые могут взаимодействовать с самой информационной системой.	Предоставление модели API-токенов, чтобы она могла подключаться к дополнительным возможностям или получать дополнительные данные, при этом предоставив ей только те права, которые необходимы для ее работы, чтобы она не могла иметь излишний доступ.
57					Мониторинг аномальной активности	Приложение должно сопровождаться инструментами мониторинга сетевого и пользовательского взаимодействия. Сюда входит защита API, использование инструментов класса WAF, организация правил сетевого взаимодействия и настройка инфраструктуры в соответствии с ними. Мониторинг позволит детектировать аномалии, которые являются признаками потенциальных атак на приложение, и своевременно осуществлять необходимые меры.
58			Контроль входных/выходных данных	Практика для реализации контроля вводимых данных, которые могут привести к возникновению рисков.	Проверка и нормализация вводимых данных	Для защиты ML модели от атак, связанных с манипулированием входных данных (например, Prompt-инъекции) необходимо стандартизировать формат вводимых значений и реализовать шаги предварительной обработки запросов, чтобы они соответствовали заданному формату и отклонялись в случае обнаружения подозрительных данных. Такую проверку можно реализовать на основе статистических или строгих правил.
59					Логирование и мониторинг входных/выходных данных	Систематическое сохранение и анализ логов входных и выходных данных модели для отслеживания ее работы и выявления аномалий. Данная активность позволяет обеспечить регулярный аудит модели, обнаружение атак и подозрительных паттернов, а также упростить процесс отладки и анализ производительности.
60					Определение формата выходных значений	Минимизация полноты выходных значений, чтобы не было лишней информации, которая, с одной стороны, не нужна пользователю, с другой стороны, поможет злоумышленнику. У получаемых в результате работы модели результатов должен быть определённый формат, который ограничивает выводимые данные лишь необходимыми в рамках выполнения моделью своих функциональных требований.
61					Проверка и фильтрация выходных значений	Все результаты модели должны проходить проверку и обработку. Результат должен соответсвовать вышеописанному формату и не содержать недопустимых значений. Данная активность позволяет повысить надежность и безопасность системы, а также защитить от атак, направленных на манипуляцию результатами модели.
62					Установка границ доверия между моделью, внешними источниками и расширяемой функциональностью (например, плагинами или последующими функциями).	Необходимо воспринимать модель (изначально) как непроверенного пользователя и не предоставлять ей полный контроль над тем, как принимаются решения. Если модель будет нарушена, то злоумышленник при помощи неё может оказать воздействие на процесс обмена данными между приложением и пользователем. так, чтобы пользователь мог легко увидеть, какие ответы модели могут быть ненадежными.
63	MLOps	Данный домен описывает практики, которые непосредственно связаны с самим процессом ЖЦ разработки	Построение процесса управления уязвимостями в платформе разработки	Практика связанная с оценкой уязвимостей и реагирования на них в контексте работы ML-OPS пайплайна.	Внедрение периодического сканирования платформы для выявления потенциальных уязвимостей.	Необходимо регулярно проводить сканирование операционной системы, библиотек и платформ, во время всего ЖЦ разработки. Данная активность подразумевает единый для всего конвейера центра анализа уязвимостей
64					Управление рисками и дефектами	Необходимо формализовать работу с обнаруженными дефектами как в процессе разработки, так и в процессе эксплуатации ML-приложений. Выделить зоны ответственности по отработке и триажу дефектов, выстроить процессы передачи дефектов разработчикам, эскалации дефектов. Кроме того, разработать подходы для оценки и приоритезации дефектов, которые будут регламентировать очерёдность, критичность и допустимость эксплойта. Очень важно использовать централизованное место разбора дефектов (например, дефект-трекер или инструмент оркестрации).
65					Управление исправлениями/обновлениями	Необходимо выстроить работу по исправлению дефектов, доработкой модели и ML сервисов, а так же выпуском обновлений и патчей. Это включает в себя как формализованный процесс распределения и решения задач, автоматизации CD процесса и т.д.
66			Построение процесса реагирования на инциденты безопасности	Практика целью которой является: идентифицировать, устранить и минимизировать воздействие угроз на системы машинного обучения, а также предотвратить их повторение в будущем.	Мониторг платформы для обнаружения подозрительной активности	Внедрение системы непрерывного мониторинга всех этапов разработки модели машинного обучения, начиная от сбора данных и заканчивая развертыванием и эксплуатацией. Это позволит выявлять аномалии и подозрительную активность, которая может свидетельствовать о долгосрочных атаках, направленных на манипуляцию моделью или хищение данных.
67					Управление инцидентами	Формирование группы экстренного реагирования на инциденты, пути эскалации, основные принципы реагирования и т.д. Кроме того, стоит измерять все инциденты метриками и вести учёт всех удачных и неудачных атак.
68					Техподдержка	Необходимо внедрить группу сотрудников, которые будут заниматься сопровождением и технической поддержкой ML-приложений и ML-моделей. Эти сотрудники будут ответственными за связь и отработку заявок от пользователей и заказчиков, эскалацию возникших инцидентов и обнаруженных уязвимостей.
69					Разработка политики реагирования на инциденты безопаности	Процесс реагирования на инциденты можно дополнить политикой реагирования, в котором будут описаны какие могут возникнуть недопустимые события и план поведения в случае их возникновения. Это позволит иметь конкретную инструкцию к действию в случае появления инцидентов, что ускорит время устранения инцидента и слаженность действий сотрудников. При написании плейбука в первую очередь можно руководствоваться уже совершёнными инцидентами и реакцией на них, а так же стоит сразу учитывать потенциально недопустимые события.
70					Проведение обучения и учений по реагированию на инциденты	Для оценки процессов реагирования на инциденты рекомендуется проводить киберучения, симулирующие настоящие атаки и недопустимые события. Для составления плана такого вида обучения можно руководствоваться уже совершёнными инцидентами и путями эксплойта. По результатам такого мероприятия можно оценивать эффективность принятых мер, работы сотрудников и корректировать политику реагирования.
71			Анализ защищённости	Практика, целью которой является выявление рисков и уязвимостей, когда модель машинного обучения уже работает в production.	Тестирование на проникновение	Тестирование на проникновение - имитирует атаки злоумышленника, позволяя оценить защищённость приложения методом поиска и экспулатации уязвимостей. Цель такого тестирования - обнаружить недостатки и слабые места в системе, которые могут привести к недопустимым событиям. Пентесты можно проводить внутренними силами или подрядчиками. Следует определить периодичность пентестами и сделать их обязательными для всех приложений .
72					Внедрение программы BugBounty	Программа вознаграждения за обнаружение ошибок (баг баунти) - это инициатива, в рамках которой Организация предлагают вознаграждение исследователям в области безопасности за обнаружение уязвимостей в разрабатываемых продуктах. Баг-баунти поощряют людей раскрывать уязвимости, а не эксплуатировать их, что повышает защищённость разрабатываемого ПО. Вознаграждение может варьироваться в зависимости от серьезности уязвимости и политики конкретной программы.
73					Анализ инцидентов и не только	Возникшие инциденты, а так же информацию об обнаруженных уязвимостях, результаты работы инструментальных проверок и собираемые метрики можно использовать в качестве оценки MLOps-процесса. На основе получаемых данных можно проводить ретроспективу, оценивать причины и последствия инцидентов, выявлять слабые места и, при необходимости, корректировать MLOps-процесс.
74					Аудиты	Аудит - формализованный процесс проверки соответствия требованиям и стандартам, применяемым к данным, ML-моделям и приложению. Аудит можно проводить внутренними силами организации, что позволит проводить более глубокий анализ за счёт большей осведомлённости аудиторами приложения и проверки не только внешних регуляторов, но и внутренней ОРД. Для стандартизации и ускорения процесса можно разработать собственную методику проверки. Следует определить периодичность аудитов и сделать их обязательными.
75					Исследовательская группа	Определение исследовательской группы сотрудников, которые будут заниматься поиском уязвимостей и слабых мест. Исследования подразумевают как анализ самого приложения так и изучение известных и новых уязвимостей, опыта других организаций, событий в отрасли ML и т.д. Чтобы упорядочить работу исследовательской группы нужно определить сотрудников, зоны ответственности и периодичность подобных работ. Можно внедрить некоторый исследовательский коммитет, который будет состоять из сотрудников разных отделов, что позволит учитывать разные аспекты безопасности приложения, но основные действующие лица - аппсеки.
76					Моделирование угроз для каждого разрабатываемого приложения и платформы разработки	Модель угроз используется для анализа и понимания рисков и потенциальных угроз безопасности. В рамках моделирования угроз проводится анализ уязвимостей, которые могут быть использованы злоумышленниками для получения несанкционированного доступа к системе или данным, определение возможных методов атак, а так же оценки возможных последствия их реализации.
77			Построение MLOps-конвейера	Целью данной практики является построение конвеера для автоматизации процессов разработки и обучения модели.	Формализация и построение всего MLOPS конвейера	Выше уже писали про построение платформы управления данными, разработки ML-моделей и эксплуатации приложений. Необходимо выстроить, стандартизировать и формализовать (включая написание регламентирующей документации) полноценный процесс всего MLOps-конвейера, который объединяет все лучшие практики безопасной разработки всего жизненного цикла модели. Конвейер MLOPS должен автоматизировать процесс разработки, проверки безопасности, оценку уязвимостей и мониторинг моделей. Определить все необходимые шаги, роли, используемые инструменты, работы по сопровождению и организационные аспекты.
78					Внедрение автоматизированных инструментальных проверок безопасности в MLOPS конвейер	Каждый этап MLOPS должен сопровождаться инструментальными проверками: анализ данных, статический анализ исходного кода, динамический анализ приложения, компонентный анализ и другие специфичные для машинного обучения и/или специфики разрабатываемых активов инструменты. Для максимально результативной работы все проверки должны быть автоматизированы и встроены в качестве обязательных шагов в ML-процессы. Хорошей практикой будет внедрить полноценную платформу (инструмент оркестрации) для управления всеми проверками и создания единого интерфейса, которые будет агрегировать все результаты.
79					Организация взаимодействия между специалистами по обработке данных, инженерами по безопасности и эксплуатационными группами	Для построения полноценного MLOps-конвейера жизненно необходимо организовать слаженную работу между специалистами по обработке данных, инженерами по безопасности, разработчиками и эксплуатационными группами и смежными отделами. Продумать орг.структуру, определить должностные функции и выполняемые задачи, определоить точки пересечения зон интересов и порядок взаимодействия.