DAF_MLSO_public_RU.md

Контроль ИБ артефактов, зависимостей и образов

Контроль использования сторонних компонентов [T-ADI-DEP]

ID	Описание
T-ADI-DEP-0-1	Управление зависимостями (Dependencies) в исходном коде осуществляется в каком-либо виде.
T-ADI-DEP-1-1	Существуют (формализованы) единые правила, определяющие возможность использования тех или иных зависимостей в коде. Например, есть утвержденный документ, и/или страница в базе знаний, описывающие порядок использования зависимостей в коде.
T-ADI-DEP-1-2	Обновление существующих зависимостей выполняется вручную. Например, если возникла необходимость использовать новую версию библиотеки в коде, то ее вручную выгружают и добавляют в проект.
T-ADI-DEP-1-3	Существует (описан, формализован) план реагирования на события ИБ, связанных с зависимостями.
T-ADI-DEP-1-4	Выполняется харденинг (безопасная настройка) файлов конфигураций используемых пакетов OSS (Open Source Software). Например, nuget.config, .npmrc, pip.conf, pom.xml, etc.
T-ADI-DEP-1-5	Зависимости с тэгом "latest" не применяются.
T-ADI-DEP-2-1	Разработчики получают и используют OSS компоненты, применяя только стандартизованные (формализованные и утвержденные) методы.
T-ADI-DEP-2-2	Контролируется и регулируется использование новых (моложе 60 дней) и старых (неактуальных, заброшенных, старше 365 дней) OSS. Например, настроен OSS firewall на предупреждение (или запрет) использования OSS, выпущенных и/или актуализированных более 365 дней назад и менее чем 60 дней.
T-ADI-DEP-3-1	Выполняется инвентаризация используемых зависимостей. Например, создан внутренний репозиторий.
T-ADI-DEP-3-2	При выполнении запросов на слияние (PR/MR) предоставляется список всех уязвимостей используемых зависимостей. Это может быть реализовано с помощью SCA решения.
T-ADI-DEP-3-3	Выполняется автоматическое обновление используемых зависимостей. Это может быть реализовано с помощью специальных утилит для обновления зависимостей.
T-ADI-DEP-4-1	Выполняется верификация цифровой подписи SBOM перед использованием зависимостей в сборке. Это может быть реализовано с помощью SCA решения.
T-ADI-DEP-4-2	Выполняется самостоятельная сборка необходимых зависимостей в доверенной среде.

Управление артефактами [T-ADI-ART]

ID	Описание
T-ADI-ART-0-1	Управление артефактами разработки присутствует в каком-либо виде.
T-ADI-ART-1-1	Все артефакты разработки хранятся в доверенных registry. Например, используется внутренний реестр.
T-ADI-ART-1-2	Строго ограниченный перечень лиц может помещать артефакты в registry. Внутри registry настроены правила разграничения доступа.
T-ADI-ART-1-3	Для аутентификации в registry используются внешние сервисы. Например, выполнена интеграция с LDAP или другим IdM, локальные учетные записи не используются.
T-ADI-ART-1-4	Отключен анонимный доступ в registry.
T-ADI-ART-1-5	Настроен и включен аудит любых изменений конфигурации хранилищ артефактов.
T-ADI-ART-2-1	Разработчики получают артефакты для дальнейшей работы только из внутренних репозиториев.
T-ADI-ART-2-2	Для взаимодействия с registry используются webhook с использованием TLS версии не ниже 1.2.
T-ADI-ART-ML-2-3	Проводится регулярная инвентаризация обучающих, валидационных и тестовых данных, создаются "карточки" данных: идентификаторы, версии наборов данных, статистические метрики, отметки о наличии конфиденциальной информации, время хранения данных (например, инструмент DVC).
T-ADI-ART-ML-2-4	Проводится регулярная инвентаризация метаданных обучения: код обучения, SBOM, гиперпараметры, метрики качества ML-модели, журналы обучения (например, инструмент MLflow).
T-ADI-ART-ML-2-5	Проводится регулярная инвентаризация метаданных ML-модели, создаются "карточки" ML-моделей: происхождение ML-модели, ссылка на наборы данных, на которых обучались ML-модели, архитектура ML-моделей, ограничения использования ML-моделей, формат входных и выходных данных, идентификаторы и версии ML-моделей, пути к ML-моделям, хэш-суммы файлов ML-моделей, требования к оборудованию, контактная информация разработчиков ML-моделей (например, инструмент MLflow).
T-ADI-ART-3-1	Для всех артефактов создается SBOM.
T-ADI-ART-3-2	Используется многофакторная аутентификация для доступа к registry.
T-ADI-ART-ML-3-3	Для всех артефактов системы ИИ создается ML-BOM.
T-ADI-ART-4-1	Конвейер сборки (build pipeline) подписывает все артефакты, которые он создает.
T-ADI-ART-4-2	Выполняется шифрование всех артефактов в registry.
T-ADI-ART-4-3	Выполняется создание цифровых подписей артефактов после проверок безопасности и перед их отправкой в доверенный registry.
T-ADI-ART-4-4	Выполняется создание хэш-сумм артефактов перед отправкой их в registry, а также их проверка при сборке.

Защита окружения разработки

Защита рабочих мест разработчика [T-DEV-COMP]

ID	Описание
T-DEV-COMP-0-1	Применяются практики защиты рабочих мест разработчиков.
T-DEV-COMP-1-1	Утверждены и применяются базовые требования к ПО и настройкам на корпоративных рабочих местах разработчиков. Например, требования к антивирусу, обновлениям ОС, требования к паролям.
T-DEV-COMP-1-2	Удаленный доступ с некорпоративных и, как следствие, ненастроенных устройств к инструментам разработки возможен только для ограниченного (небольшого) числа устройств.
T-DEV-COMP-2-1	Удаленный доступ к инструментам разработки возможен либо с корпоративных устройств с использованием MDM, либо через промежуточные\проксирующие системы, например, VDI или PAM.

Защита секретов [T-DEV-SM]

ID	Описание
T-DEV-SM-0-1	Существует практика управления секретами.
T-DEV-SM-1-1	Секреты в среде разработки защищаются встроенными механизмами инструментов разработки, например, CI/CD системы, без применения Secret Management систем.
T-DEV-SM-1-2	Инциденты ИБ, связанные с использованием секретов в среде разработки, обрабатываются службой ИБ совместно с разработчиками.
T-DEV-SM-2-1	Секреты окружения разработки хранятся в Secret Management инструменте, например, Hashicorp Vault.
T-DEV-SM-2-2	Разработчики и инженеры обмениваются секретами с помощью инструмента Secret Management, например, Hashicorp Vault.
T-DEV-SM-3-1	Секреты всех сред и инструментов (за исключением рабочих станций разработчиков и подобных adhoc сред) хранятся в SM (например, Vault), количество hardcoded секретов минимально. Случаи использования hardcoded секретов известны команде ИБ и запланирован отказ от их использования.
T-DEV-SM-3-2	Сформирована и применяется политика ротации секретов окружений разработки.
T-DEV-SM-4-1	Используются динамические секреты с ограничением доступа для сред.

Защита Build-среды [T-DEV-BLD]

ID	Описание
T-DEV-BLD-0-1	Применяются практики защиты инфраструктуры сборки ПО.
T-DEV-BLD-1-1	Доступ к среде сборки (build) (оркестратор, worker-узлы и т.д.) ограничен (настроен RBAC).
T-DEV-BLD-1-2	Для всех узлов сборки (build worker) используется подход push (вместо pull) для передачи параметров.
T-DEV-BLD-1-3	Каждый узел сборки (build worker) имеет минимально необходимые сетевые доступы (для связи только с нужными сервисами и только по определенным портам\протоколам).
T-DEV-BLD-1-4	Выполняется централизованное хранение журналов (логов) сборки, включающее изменение настроек.
T-DEV-BLD-2-1	Осуществляется мониторинг и реагирование на инциденты для узлов сборки в части потребления вычислительных ресурсов (CPU, RAM, HDD и пр).
T-DEV-BLD-3-1	Каждый узел сборки (build worker) имеет отдельную роль (например, тестирование, компиляция, отправка артефактов), прочие задачи на нем не выполняются.
T-DEV-BLD-3-2	Реализована настройка механизмов безопасности для узлов сборки.
T-DEV-BLD-3-3	Все настройки узлов сборки (build worker) централизованно хранятся в системе хранения исходного кода.
T-DEV-BLD-4-1	Создание среды сборки (build environment) выполняется автоматизировано (IaC).

Защита source code management (SCM) [T-DEV-SCM]

ID	Описание
T-DEV-SCM-0-1	Применяются практики защиты репозитория кода.
T-DEV-SCM-1-1	Создавать и удалять репозитории могут только определенные пользователи (например, настроен RBAC).
T-DEV-SCM-1-2	Удалять issues могут только определенные пользователи (например, настроен RBAC).
T-DEV-SCM-1-3	Создавать teams/groups могут только определенные пользователи (например, настроен RBAC).
T-DEV-SCM-1-4	Количество администраторов SCM ограничено и регулярно проверяется.
T-DEV-SCM-1-5	Управление доступом к системе контроля версий осуществляется с использованием ролевой модели, созданной на основе принципа минимальных привилегий. Модель регулирует как минимум: - Возможности по созданию репозиториев - Возможности по удалению репозиториев - Возможности по изменению видимости репозиториев
T-DEV-SCM-1-6	Непривилегированным пользователям доступно создание только приватных репозиториев.
T-DEV-SCM-1-7	При установке любых приложений и дополнений в Source code management системах (SCM) запрашивается одобрение (approval) администратора.
T-DEV-SCM-2-1	У всех копий (forks) кода включен аудит, а также назначен ответственный.
T-DEV-SCM-2-2	Регулярно осуществляется анализ и удаление неактивных пользователей из проекта.
T-DEV-SCM-2-3	Почтовые уведомления могут направляться только на доверенные (проверенные) домены.
T-DEV-SCM-2-4	Неактивные (ненужные) приложения (applications, плагины или дополнения) удаляются из SCM системы.
T-DEV-SCM-2-5	Для каждого репозитория по умолчанию установлены минимальные привилегии пользователей.
T-DEV-SCM-2-6	Для добавления нового пользователя в SCM используются только корпоративные email.
T-DEV-SCM-3-1	Все изменения видимости проекта отслеживаются.
T-DEV-SCM-3-2	Осуществляется идентификация неиспользуемых репозиториев и их архивирование.
T-DEV-SCM-3-3	Доступ к SCM осуществляется с использованием многофакторной аутентификации.
T-DEV-SCM-3-4	Доступ к SCM осуществляется только с разрешенных IP-адресов.
T-DEV-SCM-4-1	Проводится анализ кода на наличие аномалий, релевантных организации (например, commit содержит слишком значительные изменения объемов кода или commit'ов слишком много в определенный промежуток времени).
T-DEV-SCM-4-2	Доступ разработчиков к репозиторию осуществляется с применением сертификатов, созданных только на основе внутреннего CA (центр сертификации) компании (а не самоподписанные сертификаты) в качестве дополнительного фактора аутентификации.
T-DEV-SCM-4-3	Автоматизированный харденинг настроек проектов в SCM через API или dev. platform eng. с сравнением состояния.

Контроль внесения изменений в исходный код [T-DEV-SRC]

ID	Описание
T-DEV-SRC-0-1	Применяются практики контроля внесения изменений в исходный код.
T-DEV-SRC-1-1	Все изменения в исходном коде отслеживаются с использованием системы контроля версий (SCM).
T-DEV-SRC-1-2	Круг согласования запроса на слияние исходного кода начинается заново при внесении новых предложений по изменению.
T-DEV-SRC-1-3	Разработчики не обладают правами "dismiss code change review", позволяющими обходить стандартную процедуру проверки кода.
T-DEV-SRC-1-4	Для всех репозиториев включена опция linear history. В качестве вариантов merge доступны только squash и rebase merge.
T-DEV-SRC-1-5	Используется защита веток (branch protection).
T-DEV-SRC-2-1	Осуществляется регулярный анализ и удаление неиспользуемых веток (branches).
T-DEV-SRC-2-2	Запрос на слияние (PR/MR) реализуется только при успешном прохождении всех проверок.
T-DEV-SRC-2-3	Все открытые ветки (branches) обновляются перед отправкой запросов на слияние.
T-DEV-SRC-2-4	Слияние изменений в исходном коде разрешены только в случае отсутствия открытых комментариев и обсуждений.
T-DEV-SRC-2-5	Запрос на слияние осуществляется только при условии привязки соответствующей задачи на разработку (task, тикет) в системе управления задачами (task maganement system).
T-DEV-SRC-2-6	Правила защиты, применяемые к веткам (branch protection rules), применяются в том числе к УЗ администраторов.
T-DEV-SRC-3-1	Для наиболее важных файлов определены и назначены Code Owners.
T-DEV-SRC-3-2	Code Owners согласовывают изменения файлов, которые им "принадлежат".
T-DEV-SRC-3-3	Только подписанные commits (signed commit) допускаются к запросам на слияние (MR/PR) (особенно в main-ветку).
T-DEV-SRC-3-4	Каждое изменение в исходном коде (запрос на слияние (MR/PR)) согласовывается как минимум двумя аутентифицированными пользователями.
T-DEV-SRC-3-5	Осуществляется контроль за удалением защищенных веток (protected branch).
T-DEV-SRC-3-6	Осуществляется контроль за тем, как сканеры безопасности (SAST,SCA,Secrets) игнорируют "skip/ignore scan" inline комментарии и ignore файлы (.aiignore, .gitleaksignore и т.д.).
T-DEV-SRC-4-1	Для всех репозиториев функция "force push" доступна только для владельца.

Защита конвейера сборки [T-DEV-CICD]

ID	Описание
T-DEV-CICD-0-1	Применяются практики защиты конвейера сборки ПО.
T-DEV-CICD-1-1	Доступ к конвейеру сборки ограничен (настроен RBAC).
T-DEV-CICD-1-2	Выполняется централизованное хранение журналов событий конвейеров сборки.
T-DEV-CICD-1-3	Используется подход "CICD as a code" при создании конвейера разработки.
T-DEV-CICD-1-4	Используется защита тегов (protected tags).
T-DEV-CICD-1-5	Запрет использования обхода запуска пайплайна на коммит [skip ci] pre-commit хуками.
T-DEV-CICD-2-1	Для каждого этапа сборки строго определены входные и выходные параметры и результаты.
T-DEV-CICD-2-2	Изменение конфигурационных файлов CI\CD (конвейеров сборки) непрерывно отслеживается.
T-DEV-CICD-3-1	Выполняется централизованное хранение всех логов стадии сборки (Build).
T-DEV-CICD-4-1	Каждый пайплайн имеет единственное предназначение (например, тестирование, компиляция, отправка артефактов), прочие задачи на нем не выполняются.

Анализ и защита данных

Анализ и защита обучающих, валидационных, тестовых данных, баз знаний [T-MLDATA-DT]

ID	Описание
T-MLDATA-DT-0-1	Проводится анализ происхождения обучающих, валидационных и тестовых данных перед их использованием для обучения ML-моделей. Данные загружаются из имеющих отличную репутацию источников.
T-MLDATA-DT-1-1	Проводится регулярный анализ обучающих, валидационных и тестовых данных, баз знаний для RAG на предмет наличия в них конфиденциальной информации без производственной необходимости и её удаление по результатам анализа.
T-MLDATA-DT-1-2	Проводится регулярный анализ обучающих, валидационных и тестовых данных на предмет наличия отравленных данных: некорректные метки, в том числе в сочетании с подозрительными шаблонами (бэкдор-триггерами).
T-MLDATA-DT-1-3	Права доступа к средам обучения, обучающим, валидационным и тестовым данным, векторным представлениям данных, базам знаний для RAG минимально необходимы и контролируются, используется управление доступом на основе ролей (RBAC).
T-MLDATA-DT-2-1	База знаний, использующаяся как источник для RAG-системы, регулярно проверяется на наличие jailbreak, prompt injection, command injection.
T-MLDATA-DT-2-2	При сборе данных от пользователей для обучения ML-моделей используются методы, обеспечивающие анонимизацию данных (например, маскирование, федеративное обучение).
T-MLDATA-DT-2-3	Инструменты поиска и удаления конфиденциальной информации применяются к обучающим, валидационным и тестовым данным (например, Presidio, ARX).
T-MLDATA-DT-2-4	Инструменты обнаружения ошибочных, отравленных данных, статистических выбросов применяются к обучающим, валидационным и тестовым данным, проводится очистка данных (например, Alibi Detect, Pandas, Seaborn, детектор RONI в ART).
T-MLDATA-DT-2-5	Инструменты обнаружения состязательных атак применяются к обучающим, валидационным и тестовым данным (например, детектор Binary Input в ART).
T-MLDATA-DT-2-6	Инструменты предобработки данных применяются к обучающим, валидационным и тестовым данным с целью снижения воздействия данных, отравленных состязательными атаками (например, метод Gaussian Augmentation в ART).
T-MLDATA-DT-3-1	Настроена интеграция инструментов обнаружения и очистки конфиденциальной информации с ML-конвейером.
T-MLDATA-DT-3-2	Настроена интеграция инструментов обнаружения ошибочных, отравленных данных, статистических выбросов с ML-конвейером.
T-MLDATA-DT-3-3	Настроена интеграция инструментов обнаружения состязательных атак с ML-конвейером.
T-MLDATA-DT-3-4	Настроена интеграция инструментов предобработки данных с целью снижения воздействия данных, отравленных состязательными атаками, с ML-конвейером.
T-MLDATA-DT-4-1	Сборки в CI/CD блокируются при найденной конфиденциальной информации в обучающих, валидационных, тестовых данных.
T-MLDATA-DT-4-2	Сборки в CI/CD блокируются при найденных ошибочных, отравленных данных, статистических выбросах.
T-MLDATA-DT-4-3	Сборки в CI/CD блокируются при найденных состязательных атаках.

Инструментальный анализ на наличие дефектов ИБ

Безопасность заказной разработки [T-CODE-SPC]

ID	Описание
T-CODE-SPC-0-1	Предъявляются требования к подрядчикам в части заказной разработки.
T-CODE-SPC-1-1	Предъявляются базовые функциональные требования по ИБ к разрабатываемому подрядчиками ПО.
T-CODE-SPC-1-2	При выборе подрядчика, осуществляющего заказную разработку, учитываются его возможности, опыт, существующие у подрядчика мероприятия, связанные с безопасной разработкой ПО.
T-CODE-SPC-ML-1-3	Удаленный доступ подрядчиков, обрабатывающих данные для обучения, валидации и тестирования, разрабатывающих, тестирующих и сопровождающих системы ИИ регламентирован, права минимально необходимы и контролируются.
T-CODE-SPC-2-1	Для критичных приложений, разработанных подрядчиками, регулярно проводятся пентесты/исходный код проверяется своими силами или другими специализированными подрядчиками.
T-CODE-SPC-2-2	Разработаны и учитываются при выборе подрядчика детальные критерии в части безопасной разработки: - Требования к наличию и использованию анализаторов кода и компонентов при разработке ПО; - Требования к предоставлению отчетов об отсутствии и\или исправлении уязвимостей в разрабатываемом ПО; и др.
T-CODE-SPC-2-3	В Компании разработаны и применяются процедуры для выявления и контроля устранения выявленных уязвимостей в разрабатываемом подрядчиком ПО.
T-CODE-SPC-2-4	В контракты на разработку подрядчиком ПО включаются формулировки, требующие предоставление компании-заказчику спецификаций программного обеспечения (Software Bill of Materials, SBOM) для каждой версии ПО. Определены механизмы получения SBOM.
T-CODE-SPC-ML-2-5	Подрядчик предоставляет доказательства, что проводится анализ обучающих, валидационных, тестовых данных на наличие отравленных данных, статистических выбросов, конфиденциальной информации (при отсутствии производственной необходимости в ее использовании) и очистка указанных данных.
T-CODE-SPC-ML-2-6	Подрядчик предоставляет доказательства, что используются статические сканеры безопасности ML-моделей для анализа файлов ML-моделей на наличие вредоносного кода, выполняемого при десериализации ML-моделей (например, Modelscan, Modelaudit).
T-CODE-SPC-ML-2-7	Подрядчик предоставляет доказательства, что проводится сканирование на уязвимости LLM для обнаружения возможности успешного проведения атак, в том числе многошаговых, типа jailbreak, prompt injection, command injection, вывода нежелательных данных (конфиденциальная информация, избыточная точность, нежелательные ответы, действия, галлюцинации, ложная информация, введение в заблуждение и т.д.).
T-CODE-SPC-ML-2-8	Подрядчик предоставляет доказательства, что проводится сканирование на уязвимости ML-моделей к состязательным атакам (например, на возможность обхода логики ML-модели, распознающие предметы на изображениях).
T-CODE-SPC-ML-2-9	В контракты на разработку подрядчиком ПО включаются формулировки, требующие предоставление компании-заказчику спецификаций машинного обучения (Machine Learning Bill of Materials, ML-BOM) для каждой версии системы ИИ. Определены состав и механизмы получения ML-BOM.
T-CODE-SPC-3-1	Внутри компании-заказчика проводится композиционный анализ разработанного подрядчиками на заказ ПО.
T-CODE-SPC-3-2	Для всех приложений, разработанных подрядчиками ПО, проводятся пентесты/проходит проверку исходный код (в случае его предоставления) внутренними силами или при помощи специализированных подрядчиков.
T-CODE-SPC-3-3	Все предоставляемые подрядчиком (разработчиком ПО) артефакты (включая SBOM) подписываются электронной подписью. В компании-заказчике внедрен процесс проверки подписей предоставляемых артефактов.
T-CODE-SPC-3-4	В контракты на разработку подрядчиком ПО включаются формулировки, требующие предоставление всего исходного кода разрабатываемого ПО.
T-CODE-SPC-3-5	Проводится статический анализ исходного кода для разработанного поставщиком ПО, выполняется анализ полученных результатов.
T-CODE-SPC-ML-3-6	Для всех ML-моделей, разработанных подрядчиками ПО, проводятся пентесты и проверка исходных кодов, предназначенных для обучения ML-моделей, внутренними силами или при помощи специализированных подрядчиков.
T-CODE-SPC-ML-3-7	Все предоставляемые подрядчиком (разработчиком ПО) артефакты (включая ML-BOM) подписываются электронной подписью. В компании-заказчике внедрен процесс проверки подписей предоставляемых артефактов.
T-CODE-SPC-ML-3-8	В контракты на разработку подрядчиком ML-моделей включаются формулировки, требующие предоставление всех обучающих, валидационных, тестовых данных, исходного кода, предназначенного для обучения ML-моделей.
T-CODE-SPC-4-1	Вся заказная разработка ПО ведется подрядчиками (разработчиками ПО) в инфраструктуре компании-заказчика, с использованием всех инструментов безопасной разработки (SAST, DAST, OSA\SCA, Container security и др.) и в соответствии с процессами компании-заказчика.
T-CODE-SPC-ML-4-2	Вся заказная разработка ПО ведется подрядчиками (разработчиками ML-моделей) в инфраструктуре компании-заказчика, с использованием всех инструментов безопасной разработки ML-моделей (сканеров уязвимости LLM, инструментов проведения состязательных атак и др.) и в соответствии с процессами компании-заказчика.

Статический анализ (SAST) [T-CODE-SST]

ID	Описание
T-CODE-SST-0-1	Выполняется статический анализ исходного кода разрабатываемого ПО.
T-CODE-SST-ML-0-2	Выполняется статический анализ исходного кода, предназначенного для обучения ML-модели.
T-CODE-SST-1-1	Анализ исходного кода применяется, как минимум, ситуативно.
T-CODE-SST-1-2	В SAST используются, как минимум, правила по умолчанию.
T-CODE-SST-2-1	Выполняется регулярное сканирование отдельных частей кода, например: - изменений в коде по результатам спринтов - код разработанных framework - и т.д.
T-CODE-SST-2-2	Неиспользуемые правила анализа в SAST отключены.
T-CODE-SST-2-3	Выполнена интеграция SAST в CI (отдельный скрипт для каждой команды).
T-CODE-SST-2-4	Используются плагины SAST в IDE [при их наличии].
T-CODE-SST-3-1	Выполняется регулярное сканирование SAST полной кодовой базы.
T-CODE-SST-3-2	Используются кастомизированные правила.
T-CODE-SST-3-3	Выполнена интеграция SAST с инструментом code quality (например, SonarQube).
T-CODE-SST-4-1	Выполняется сканирование исходного кода open source компонентов (сканирование на malware, protestware и т.д.).

Композиционный анализ (SCA) [T-CODE-SC]

ID	Описание
T-CODE-SC-0-1	Выполняется композиционный анализ разрабатываемого ПО.
T-CODE-SC-1-1	В SCA используются, как минимум, политики анализа по умолчанию.
T-CODE-SC-1-2	Применяется выборочная блокировка подключаемых библиотек вручную при выявлении дефектов ИБ.
T-CODE-SC-1-3	В SCA сохраняется история всех используемых (использованных) библиотек.
T-CODE-SC-2-1	Библиотеки с уязвимостями с высоким рейтингом, включая RCE, блокируются по договоренности между ИБ и разработчиками.
T-CODE-SC-2-2	Осуществляется контроль получения образов (получение только из доверенных репозиториев).
T-CODE-SC-2-3	Выполняется проверка цифровых подписей и хэшей компонентов.
T-CODE-SC-2-4	Настроена интеграция SCA в CI/CD.
T-CODE-SC-2-5	Выполняется проверка на лицензионную чистоту.
T-CODE-SC-3-1	Подключение всех возможных open source feeds.
T-CODE-SC-3-2	Совмещение практик SAST и SCA для идентификации уязвимостей в коде (effective usage analysis. Например, библиотека уязвима, но при этом НЕ используется уязвимый метод).
T-CODE-SC-3-3	Используются SCA плагины для IDE для pre-commit hooks.
T-CODE-SC-3-4	Библиотеки со статусом End of life блокируются по договоренности между ИБ и разработчиками.
T-CODE-SC-4-1	Использование платных feeds, обогащающих результаты анализа open source компонентов.

Анализ образов контейнеров [T-CODE-IMG]

ID	Описание
T-CODE-IMG-0-1	Выполняется сканирование образов контейнеров на наличие уязвимостей.
T-CODE-IMG-1-1	Сканирование образов контейнеров на наличие уязвимостей регламентировано и выполняется стандартизированным набором инструментов.
T-CODE-IMG-1-2	Выполняется сканирование образов контейнеров. Запуск сканирования происходит в ручном режиме.
T-CODE-IMG-1-3	Применяется выборочная блокировка образов контейнеров вручную при выявлении дефектов ИБ.
T-CODE-IMG-2-1	Выполняется сканирование образов контейнеров в CI/CD на наличие уязвимостей.
T-CODE-IMG-2-2	Выполняется периодическое сканирование образов контейнеров, размещенных во внутренних репозиториях, на наличие уязвимостей.
T-CODE-IMG-2-3	При обнаружении дефектов ИБ в образах контейнеров автоматизированно создаются задачи на их устранение в тикет-системе.
T-CODE-IMG-3-1	Non-compliant ресурсы блокируются по договоренности между ИБ и разработчиками.
T-CODE-IMG-4-1	Выполняется проверка цифровых подписей образов контейнеров.
T-CODE-IMG-4-2	Сборки в CI/CD блокируются при найденных уязвимостях в образах контейнеров по договоренности между ИБ и разработчиками.

Идентификация секретов [T-CODE-SECDN]

ID	Описание
T-CODE-SECDN-0-1	Применяются практики поиска секретов.
T-CODE-SECDN-1-1	Механизмы идентификации секретов применяются как минимум в SCM системах.
T-CODE-SECDN-1-2	Инструменты идентификации секретов запускаются вручную.
T-CODE-SECDN-1-3	В инструментах идентификации секретов используются настройки поиска секретов, заданные по умолчанию.
T-CODE-SECDN-1-4	Инциденты ИБ, связанные с использованием найденных секретов, разрешаются совместно с разработчиками.
T-CODE-SECDN-ML-1-5	Выполняется поиск секретов в системных промптах LLM.
T-CODE-SECDN-2-1	Инструменты идентификации секретов охватывают:   - Все версии кода, хранящиеся в SCM   - Манифесты IaC   - Артефакты:       - Образы Docker,       - Все репозитории       - Облачную инфраструктуру       - Сканирование и блокирование секретов во время стадий pull/Merge
T-CODE-SECDN-2-2	В инструментах идентификации секретов используются кастомизированные настройки и правила поиска секретов.
T-CODE-SECDN-2-3	При обработке событий ИБ, связанных с найденными секретами используется приоритизация.
T-CODE-SECDN-3-1	При наличии в коде секретов commit'ы блокируются по договоренности между ИБ и разработчиками.
T-CODE-SECDN-3-2	Сканирование секретов также включает в себя: - Рабочие станции разработчиков и любые adhoc среды - Логи сборок (Build logs)
T-CODE-SECDN-3-3	Используются инструменты авто-валидации секретов.
T-CODE-SECDN-4-1	Hardcoded секреты отсутствуют (при этом выполняется поиск секретов различными инструментами и за продолжительное время (например, полгода) не выявлен ни один hardcoded секрет).

Контроль безопасности Dockerfile’ов [T-CODE-DOCKERFS]

ID	Описание
T-CODE-DOCKERFS-0-1	Применяются практики безопасного написания Dockerfiles.
T-CODE-DOCKERFS-1-1	Разработан регламент по безопасному написанию Dockerfiles.
T-CODE-DOCKERFS-1-2	Выполняется ручной контроль безопасности Dockerfile.
T-CODE-DOCKERFS-2-1	Dockerfiles проверяются автоматизировано в pipeline.

Анализ ПО в режиме runtime - Preprod

Динамический анализ приложений (DAST) в PREPROD среде [T-PREPROD-DAST]

ID	Описание
T-PREPROD-DAST-0-1	Применяются практики динамического тестирования (DAST).
T-PREPROD-DAST-1-1	Динамическое сканирование используется как минимум для пользовательского интерфейса.
T-PREPROD-DAST-1-2	Динамическое сканирование выполняется вручную.
T-PREPROD-DAST-2-1	Отключены неиспользуемые в сканере правила.
T-PREPROD-DAST-2-2	Выполняется сканирование без аутентификации (с полным покрытием пользовательского интерфейса): -  Spider- сканирование (https://www.zaproxy.org/docs/desktop/addons/spider/) -  Сканирование зависимостей
T-PREPROD-DAST-2-3	Выполняется сканирование с аутентификацией:  - Выполняется сканирование зависимостей  - При сканировании происходит использование всех возможных ролей и пользовательских типов  - Поддержка существующих сессий  - При сканировании используются функции log in/log out  - Выполняется Spider-сканирование после аутентификации
T-PREPROD-DAST-2-4	Настроена интеграция сканера с инструментами CI/CD.
T-PREPROD-DAST-3-1	Выполняется сканирование в том числе скрытых путей.
T-PREPROD-DAST-3-2	Используются доработанные (кастомизированные) параметры при сканировании для максимального покрытия входных параметров.
T-PREPROD-DAST-3-3	При сканировании используется бизнес-логика сканируемого приложения. Например, выполняется login, вносятся изменения в учетную запись, выполняется добавление товара в корзину и др.
T-PREPROD-DAST-3-4	Выполняется раздельное сканирование backend и frontend, включая: - Сканирование SOAP сервисов - Сканирование сервисов proxy, которые передают запросы между frontend и backend - fuzzing XML и JSON данных, которые передаются в API сервисы
T-PREPROD-DAST-4-1	Выполняется сканирование всех путей и взаимодействий (в т.ч. с backend).
T-PREPROD-DAST-4-2	Используется несколько сканеров для увеличения поверхности сканирования и получения пересекающихся результатов.
T-PREPROD-DAST-4-3	Используются custom профили для динамического тестирования с повышенной интенсивностью и тяжестью для критичных частей приложения.

Тестирование на проникновение перед внедрением приложений в продуктив [T-PREPROD-PENTEST]

ID	Описание
T-PREPROD-PENTEST-0-1	Применяется тестирование на проникновение в среде Preprod.
T-PREPROD-PENTEST-1-1	Тестирование на проникновение в среде Preprod проводится регулярно.
T-PREPROD-PENTEST-1-2	Проводятся пентесты Preprod среды методом "черный ящик" (пентестер не знает ничего об атакуемой Preprod среде, кроме базовой информации о ней - доменные имена, ip-адреса).
T-PREPROD-PENTEST-1-3	Проводятся пентесты методом "серый ящик" (пентестер знает все об атакуемой Preprod среде - архитектуру среды и анализируемого ПО, их версии, имеет доступ к исходному коду ПО и пр.).
T-PREPROD-PENTEST-2-1	Разработан и применяется регламент, описывающий проведение тестирования на проникновение в среде Preprod.
T-PREPROD-PENTEST-4-1	Проводится анализ безопасности инструментов безопасной разработки (анализируются, например, инструменты SAST или OSA\SCA на предмет наличия в них уязвимостей или дефектов - можно ли без авторизации "украсть" отчеты, конфиги и пр).
T-PREPROD-PENTEST-ML-4-2	Проводятся тестирования на проникновение на системы ИИ методами состязательных атак в режимах "белого", "серого", "черного" ящиков ручным и автоматизированным способами с учетом анализа актуальных угроз.
T-PREPROD-PENTEST-ML-4-3	Проводится анализ безопасности инструментов обеспечения ИБ ML-моделей (анализируются, например, сканеры уязвимости LLM, инструменты проведения состязательных атак (например, ART) на предмет наличия в них уязвимостей или дефектов).

Функциональное ИБ-тестирование [T-PREPROD-SECTEST]

ID	Описание
T-PREPROD-SECTEST-0-1	Выполняется тестирование ИБ функционала разрабатываемого ПО.
T-PREPROD-SECTEST-1-1	Функциональное ИБ-тестирование проводится (ситуативно, нерегламентированно).
T-PREPROD-SECTEST-2-1	Разработан и применяется регламент, описывающий проведение функционального ИБ-тестирования.
T-PREPROD-SECTEST-2-2	Не менее 5% функциональных ИБ-тестов автоматизированы.
T-PREPROD-SECTEST-3-1	Более 20 % тестов функций ИБ-тестирования автоматизированы.

Анализ инфраструктуры PREPROD среды на уязвимости [T-PREPROD-VULN]

ID	Описание
T-PREPROD-VULN-0-1	Сканирование инфраструктуры PREPROD (среды тестирования и разработки ПО) на уязвимости производится в каком бы то ни было виде.
T-PREPROD-VULN-1-1	Сканирование инфраструктуры PREPROD (среды тестирования и разработки ПО) на уязвимости производится периодически в ручном режиме при помощи инструментов автоматизации или скриптов. (ситуативно нерегламентированно).
T-PREPROD-VULN-1-2	Производится установка обновлений на элементы инфраструктуры, в т.ч. устранение выявленных уязвимостей.
T-PREPROD-VULN-2-1	Выполняется регулярное сканирование наиболее критических компонентов инфраструктуры PREPROD (среды тестирования и разработки ПО) на уязвимости, а также выстроен процесс по их исправлению.
T-PREPROD-VULN-2-2	Выполняется регулярное выполнение задач инвентаризации активов PREPROD (среды тестирования и разработки ПО) сред автоматизированными средствами.
T-PREPROD-VULN-2-3	Обновления безопасности регулярно устанавливаются на основные элементы инфраструктуры PREPROD (среды тестирования и разработки ПО). Например, оркестратор и операционные системы серверов.
T-PREPROD-VULN-3-1	Выполняется регулярное сканирование всех компонентов инфраструктуры PREPROD (среды тестирования и разработки ПО), а также выстроен процесс по их исправлению.
T-PREPROD-VULN-3-2	Выполняется автоматизированная проверка основных компонентов инфраструктуры PREPROD (среды тестирования и разработки ПО) (например, оркестратора и операционных систем серверов) на соответствие лучшим практикам, а также организован процесс по исправлению несоответствий.
T-PREPROD-VULN-3-3	Выполняется регулярное сканирование на уязвимости инфраструктуры PREPROD (среды тестирования и разработки ПО) автоматизированными средствами в режиме пентеста.
T-PREPROD-VULN-3-4	Обновления безопасности регулярно устанавливаются на все элементы инфраструктуры PREPROD (среды тестирования и разработки ПО). Например, оркестратор и операционные системы серверов.
T-PREPROD-VULN-4-1	Выполняется автоматизированная проверка всех компонентов инфраструктуры PREPROD (среды тестирования и разработки ПО) на соответствие лучшим практикам, а также организован процесс по исправлению несоответствий.
T-PREPROD-VULN-4-2	Осуществляется регулярная замена устаревшего неподдерживаемого производителями ПО для компонентов инфраструктуры PREPROD (среды тестирования и разработки ПО).

Контроль безопасности манифестов (k8s, terraform и т.д.) [T-PREPROD-MANSEC]

ID	Описание
T-PREPROD-MANSEC-0-1	Выполняется ИБ тестирование файлов конфигураций (Dockerfiles, K8s manifests, Terraform, etc).
T-PREPROD-MANSEC-1-1	Применяется анализ Dockerfile на наличие дефектов ИБ.
T-PREPROD-MANSEC-2-1	Используется контроль конфигураций (k8s, IaC и т.п.) на наличие дефектов ИБ.

Анализ и защита ML-моделей

Анализ и защита файлов ML-моделей [T-MLMODEL-FILE]

ID	Описание
T-MLMODEL-FILE-0-1	Файлы ML-моделей загружаются из имеющих отличную репутацию источников. Например, из официальных репозиториев крупнейших игроков на рынке разработки ML-моделей или из репозиториев разработчиков, имеющих значительное количество скачиваний и большое количество положительных отзывов о ML-моделях.
T-MLMODEL-FILE-1-1	Права доступа к файлам ML-моделей минимально необходимы и контролируются, используется управление доступом на основе ролей (RBAC).
T-MLMODEL-FILE-1-2	ML-модели не хранятся на конечных устройствах пользователей без производственной необходимости.
T-MLMODEL-FILE-1-3	Используется формат файлов ML-моделей SafeTensors или файлы ML-моделей приводятся к данному формату перед использованием (при наличии технической возможности).
T-MLMODEL-FILE-1-4	При загрузке файла ML-модели формата SafeTensors проверяется заголовок файла на соответствие формату SafeTensors.
T-MLMODEL-FILE-2-1	Используются статические сканеры безопасности ML-моделей для анализа файлов ML-моделей на наличие вредоносного кода, выполняемого при десериализации ML-моделей (например, Modelscan, Modelaudit).
T-MLMODEL-FILE-2-2	Используются инструменты для контроля целостности файлов ML-моделей (например, Cosign).
T-MLMODEL-FILE-2-3	Настроена интеграция статических сканеров безопасности ML-моделей с ML-конвейером.
T-MLMODEL-FILE-2-4	Настроена интеграция инструментов контроля целостности файлов ML-моделей с ML-конвейером.
T-MLMODEL-FILE-4-1	Сборки в CI/CD блокируются при найденных уязвимостях статическими сканерами безопасности ML-моделей.
T-MLMODEL-FILE-4-2	Сборки в CI/CD блокируются при выявленных нарушениях целостности файлов ML-моделей инструментами контроля целостности файлов ML-моделей.

Анализ ML-моделей на уязвимости [T-MLMODEL-VLN]

ID	Описание
T-MLMODEL-VLN-0-1	Применяются практики динамического тестирования ML-моделей на уязвимости.
T-MLMODEL-VLN-1-1	Собираются актуальные тестовые наборы данных, содержащие вредоносные запросы, и с помощью них проводится ручное или автоматизированное тестирование безопасности ML-моделей (например, HarmBench для LLM).
T-MLMODEL-VLN-2-1	Используются динамические сканеры безопасности ML-моделей модальностей "изображение", "аудио", "структурированные данные" для обнаружения возможности успешного проведения состязательных атак на ML-модели (например, ART на возможность обхода логики ML-модели, распознающей предметы на изображениях).
T-MLMODEL-VLN-2-2	Используются динамические сканеры безопасности ML-моделей модальности "текст" (сканеры уязвимости LLM) для обнаружения возможности успешного проведения атак, в том числе многошаговых, типа jailbreak, prompt injection, command injection, вывода нежелательных данных (конфиденциальная информация, избыточная точность, нежелательные ответы, действия, галлюцинации, ложная информация, введение в заблуждение и т.д.) (например, HiveTraceRed, Garak, LLAMATOR).
T-MLMODEL-VLN-3-1	Используется несколько динамических сканеров безопасности ML-моделей для увеличения поверхности сканирования и получения пересекающихся результатов.
T-MLMODEL-VLN-3-2	Настроена интеграция динамических сканеров безопасности ML-моделей с ML-конвейером.
T-MLMODEL-VLN-4-1	Используются инструменты аудита возможности извлечения конфиденциальности информации в ML-моделях (например, Privacy Meter для обнаружения возможности успешного проведения атаки с выводом о принадлежности).
T-MLMODEL-VLN-4-2	Используются инструменты для обнаружения отравления обучающих данных на уровне анализа ML-моделей (например, детектор отравления методом активационных кластеров, определение уровня энтропии методом STRIP в ART).
T-MLMODEL-VLN-4-3	Настроена интеграция инструментов аудита конфиденциальности информации в ML-моделях с ML-конвейером.
T-MLMODEL-VLN-4-4	Настроена интеграция инструментов для обнаружения отравления обучающих данных на уровне анализа ML-моделей с ML-конвейером.
T-MLMODEL-VLN-4-5	Сборки в CI/CD блокируются при найденных уязвимостях динамическими сканерами безопасности ML-моделей по договоренности между ИБ и разработчиками при превышении определенного порога успешных атак (ASR) или при срабатывании на заранее собранном проверочном наборе вредоносных запросов на приоритетные запрещенные темы.
T-MLMODEL-VLN-4-6	Сборки в CI/CD блокируются при превышении определенного порога коэффициента извлечения конфиденциальной информации из ML-моделей.
T-MLMODEL-VLN-4-7	Сборки в CI/CD блокируются при обнаружении отравления обучающих данных на уровне анализа ML-моделей.

Увеличение робастности ML-моделей [T-MLMODEL-ROB]

ID	Описание
T-MLMODEL-ROB-0-1	Используются ML-модели, изначально прошедшие процедуру "выравнивания" (alignment).
T-MLMODEL-ROB-1-1	ML-модели не обучаются на данных, полученных от пользователей, без производственной необходимости.
T-MLMODEL-ROB-2-1	В системах ИИ используется ансамбль ML-моделей для повышения устойчивости к состязательным атакам (например, bagging, boosting, stacking).
T-MLMODEL-ROB-3-1	Используются инструменты для сокращения влияния отравления обучающих данных с применением добавления шумов, обрезки и переобучения моделей (например, методы Neural Cleanse в ART).
T-MLMODEL-ROB-3-2	Проводится состязательное обучение ML-моделей (например, методом PGD в ART).
T-MLMODEL-ROB-3-3	Во время обучения ML-моделей используются инструменты анонимизации информации, обеспечивающие дифференциальную приватность, при наличии конфиденциальной информации в обучающих данных (например, Opacus, Diffprivlib).
T-MLMODEL-ROB-4-1	Применяется защитная дистилляция ML-модели (например, методом защитной дистилляции в ART).
T-MLMODEL-ROB-4-2	Настроена интеграция инструментов состязательного обучения ML-моделей с ML-конвейером.
T-MLMODEL-ROB-4-3	Настроена интеграция инструментов для сокращения влияния отравления обучающих данных с применением добавления шумов, обрезки и переобучения моделей, с ML-конвейером.
T-MLMODEL-ROB-4-4	Настроена интеграция инструментов анонимизации информации, обеспечивающих дифференциальную приватность, с ML-конвейером.
T-MLMODEL-ROB-4-5	Используются методы "сертифицированной" робастности, предоставляющие математически доказанную гарантия того, что предсказание ML-модели не изменится при любых малых возмущениях входных данных в пределах определенного радиуса (например, метод Randomized Smoothing в ART).

Защита ПО и инфраструктуры в режиме runtime

Управление секретами [T-PROD-SM]

ID	Описание
T-PROD-SM-0-1	Применяются практики управления секретами и защиты секретов.
T-PROD-SM-1-1	Для управления секретами частично применяются встроенные механизмы ПО. Инструменты по управлению секретами не используются.
T-PROD-SM-1-2	Инциденты ИБ, связанные с использованием секретов, разрешаются совместно с владельцами систем.
T-PROD-SM-2-1	Используются инструменты по управлению секретами, но их использование не регламентировано.
T-PROD-SM-2-2	При разборе событий ИБ, связанных с секретами, используется приоритизация (ранжирование) этих событий. Например, событию A присваивается более высокий приоритет при обработке, чем событию B. Правила приоритизации событий ИБ формализованы.
T-PROD-SM-3-1	Секреты всех сред  (за исключением Dev сред) хранятся в  системе управления секретами (допускается ситуативное использование hardcoded-секретов).
T-PROD-SM-3-2	Регламентирована и осуществляется автоматизированная ротация всех секретов (как по расписанию, так и по событию\запросу).
T-PROD-SM-3-3	Разработаны и применяются регламенты по использованию инструментов по управлению секретами.
T-PROD-SM-4-1	Используются динамические секреты, генерируемые под каждую сессию взаимодействия систем.
T-PROD-SM-4-2	Hardcoded секреты отсутствуют в продуктивной среде.
T-PROD-SM-4-3	Осуществляется регулярный мониторинг общедоступных баз, систем, информационных каналов и других источников в Интернете (и даркнете) на наличие утекших секретов Компании.

Тестирование на проникновение продуктивной среды [T-PROD-PENTEST]

ID	Описание
T-PROD-PENTEST-0-1	Проводится тестирование на проникновение в среде Prod.
T-PROD-PENTEST-1-1	Проводятся пентесты Prod среды методом "черный ящик" (пентестер не знает ничего об атакуемой Prod среде, кроме базовой информации о ней - доменные имена, ip-адреса).
T-PROD-PENTEST-1-2	Тестирование на проникновение в среде Prod проводится регулярно.
T-PROD-PENTEST-1-3	Проводятся пентесты методом "серый ящик" (пентестер знает все об атакуемой Prod среде - архитектуру среды и анализируемого ПО, их версии, имеет доступ к исходному коду ПО и пр.).
T-PROD-PENTEST-2-1	Разработан регламент, описывающий критерии и частоту проведения тестов на проникновение в среде PROD.
T-PROD-PENTEST-3-1	Разработана и внедрена программа Bug Bounty.
T-PROD-PENTEST-4-1	Проводятся пентесты вида "социальная инженерия", направленные и адаптированные на разработчиков.
T-PROD-PENTEST-4-2	Проводятся Red Team \ Purple Team учения с привлечением разработчиков.
T-PROD-PENTEST-ML-4-3	Проводятся тестирования на проникновение на системы ИИ методами состязательных атак в режимах "белого", "серого", "черного" ящиков ручным и автоматизированным способами с учетом анализа актуальных угроз.
T-PROD-PENTEST-ML-4-4	Проводится анализ безопасности инструментов обеспечения ИБ ML-моделей (анализируются, например, сканеры уязвимости LLM, инструменты проведения состязательных атак (например, ART) на предмет наличия в них уязвимостей или дефектов).

Динамический анализ приложений (DAST) в продуктивной среде [T-PROD-DAST]

ID	Описание
T-PROD-DAST-0-1	Применяются практики динамического тестирования (DAST).
T-PROD-DAST-1-1	Динамическое сканирование используется как минимум для пользовательского интерфейса.
T-PROD-DAST-1-2	Используется пассивное сканирование с помощью зеркалирования трафика.
T-PROD-DAST-1-3	Динамическое сканирование выполняется вручную.
T-PROD-DAST-2-1	Используются механизмы активного и пассивного сканирования.
T-PROD-DAST-2-2	Выполняется сканирование без аутентификации (с полным покрытием пользовательского интерфейса): -  Spider- сканирование (https://www.zaproxy.org/docs/desktop/addons/spider/) -  Сканирование зависимостей
T-PROD-DAST-2-3	Выполняется сканирование с аутентификацией:  - Выполняется сканирование зависимостей  - При сканировании происходит использование всех возможных ролей и пользовательских типов  - Поддержка существующих сессий  - При сканировании используются функции log in/log out  - Выполняется Spider-сканирование после аутентификации
T-PROD-DAST-2-5	Отключены неиспользуемые в сканере правила.
T-PROD-DAST-3-1	Выполняется сканирование в том числе скрытых путей.
T-PROD-DAST-3-2	Используются доработанные (кастомизированные) параметры при сканировании для максимального покрытия входных параметров.
T-PROD-DAST-3-3	При сканировании используется бизнес-логика сканируемого приложения. Например, выполняется login, вносятся изменения в учетную запись, выполняется добавление товара в корзину и др.
T-PROD-DAST-3-4	Выполняется раздельное сканирование backend и frontend, включая: - Сканирование SOAP сервисов - Сканирование сервисов proxy, которые передают запросы между frontend и backend - fuzzing XML и JSON данных, которые передаются в API сервисы
T-PROD-DAST-4-1	Выполняется сканирование всех путей и взаимодействий (в т.ч. с backend).
T-PROD-DAST-4-2	Используется несколько сканеров для увеличения поверхности сканирования и получения пересекающихся результатов.
T-PROD-DAST-4-3	Используются custom профили для динамического тестирования с повышенной интенсивностью и тяжестью для критичных частей приложения.

Управление изменениями инфраструктуры и доступом к ней [T-PROD-ACCESS]

ID	Описание
T-PROD-ACCESS-0-1	Применяются практики автоматизации жизненного цикла инфраструктуры (например, подход IaC), а также необходимые меры защиты.
T-PROD-ACCESS-1-1	Код инфраструктуры (IaC) хранится, в том числе, за пределами централизованного хранилища кода (SCM-системы).
T-PROD-ACCESS-1-2	Использование концепции Infrastructure as code. Продуктивная среда описана в виде кода, регулярно актуализируется и является воспроизводимой.
T-PROD-ACCESS-1-3	Реализован процесс контроля версий конфигурации инфраструктуры в виде кода (IaC).
T-PROD-ACCESS-1-4	Доступ к продуктивной среде предоставлен ограниченному числу доверенных пользователей.
T-PROD-ACCESS-1-5	Запрещено использование паролей по умолчанию.
T-PROD-ACCESS-ML-1-6	Права доступа к ML-моделям, средам обучения, обучающим, валидационным и тестовым данным, векторным представлениям данных, базах знаний для RAG минимально необходимы и контролируются, используется управление доступом на основе ролей (RBAC).
T-PROD-ACCESS-2-1	Доступ к коду конфигурации инфраструктуры (файлам, описывающим IaC) предоставлен ограниченному числу пользователей.
T-PROD-ACCESS-2-2	Настроен, включен и обрабатывается аудит любых изменений для конфигураций внедрения в любые среды.
T-PROD-ACCESS-3-1	Автоматизация внедрения в любые непродуктивные среды.
T-PROD-ACCESS-4-1	Автоматизация внедрения в любые продуктивные среды.

Контроль сетевого трафика (L4-L7) [T-PROD-NETWORK]

ID	Описание
T-PROD-NETWORK-0-1	Выполняется контроль сетевого трафика в PROD сегменте.
T-PROD-NETWORK-1-1	Выполняется контроль сетевого трафика на уровне межсетевых экранов (L3/L4) в PROD сегменте.
T-PROD-NETWORK-1-2	PROD инфраструктура находится в выделенном сетевом сегменте.
T-PROD-NETWORK-ML-1-3	Сетевая связность между агентами и ИС, инструментами и другими агентами ограничена минимально необходимым взаимодействием.
T-PROD-NETWORK-ML-1-4	Системы ИИ не предоставляют общедоступный API без производственной необходимости.
T-PROD-NETWORK-2-1	Настроены и используются глобальные сетевые политики на уровне сред контейнеризации.
T-PROD-NETWORK-2-2	Настроены и используются L7 сетевые политики контроля трафика.
T-PROD-NETWORK-ML-2-3	Системы ИИ запускаются в ограниченной изолированной среде ("песочнице") с минимально необходимыми правами доступа.
T-PROD-NETWORK-ML-2-4	Взаимодействие систем ИИ с пользователями, другими системами ИИ, ИС и сервисами происходит с использованием криптографически стойких алгоритмов шифрования.
T-PROD-NETWORK-3-1	Настроены и используются кастомизированные сетевые политики для различных микросервисов (namespace).

Контроль выполняемых и процессов и их прав доступа [T-PROD-RUN]

ID	Описание
T-PROD-RUN-0-1	Выполняется контроль и защита исполняемых процессов.
T-PROD-RUN-1-1	Используются средства контроля Runtime для сред контейнеризации (Kyverno, OPA gatekeeper, pod security admission, другие валидаторы) со стандартными настройками.
T-PROD-RUN-ML-1-1	Системы ИИ не запускаются с привилегированными правами. Доступ систем ИИ (в том числе агентов и мультиагентных систем) к БД, файловым хранилищам, другим ИС или системам ИИ (в том числе с использованием плагинов, API, механизмов function calling, протоколов MCP, A2A и фреймворков LangChain, LangGraph и аналогичных им), выполнение команд и программного кода, управление ОС ограничены согласно принципу минимальных привилегий и во времени (например, краткосрочные токены доступа).
T-PROD-RUN-ML-1-2	Агенты не могут динамически делегировать роли и создавать других агентов.
T-PROD-RUN-ML-1-3	Критичные действия агентов перед выполнением проходят обязательное одобрение человеком (подход human-in-the-loop).
T-PROD-RUN-2-1	Используются кастомизированные политики Runtime для сред контейнеризации, как минимум уровня всего кластера.
T-PROD-RUN-ML-2-2	Выходные данные LLM ограничиваются и корректно обрабатываются: не передаются напрямую в system shell, в функции exec или eval и аналогичные им, происходит очистка от последовательностей CRLF, выполняется параметризация SQL-запросов, блокируются XSS, CSRF, SSRF-атаки и т.д.
T-PROD-RUN-ML-2-3	Взаимодействие систем ИИ с другими системами ИИ, ИС и сервисами происходит с использованием обязательных идентификации, аутентификации, авторизации (например, mTLS, OAuth2).
T-PROD-RUN-ML-2-4	Доступ агентов к API минимально необходим и контролируется (например, OAuth2).
T-PROD-RUN-3-1	Настроены и используются кастомизированные Runtime политики для отдельных контейнерных приложений.

Анализ инфраструктуры PROD среды на уязвимости [T-PROD-VULN]

ID	Описание
T-PROD-VULN-0-1	Применяется сканирование инфраструктуры на уязвимости в Prod сегменте.
T-PROD-VULN-1-1	Сканирование инфраструктуры на уязвимости проводится, как минимум, вручную и ситуативно.
T-PROD-VULN-1-2	Производится установка обновлений на элементы инфраструктуры, в т.ч. устранение выявленных уязвимостей.
T-PROD-VULN-2-1	Выполняется регулярное сканирование компонентов инфраструктуры PROD, обеспечивающей доступ пользователем из сети Интернет на уязвимости, а также выстроен процесс по их исправлению.
T-PROD-VULN-2-2	Выполняется регулярное выполнение задач инвентаризации активов PROD автоматизированными средствами.
T-PROD-VULN-2-3	Обновления безопасности регулярно устанавливаются на основные элементы инфраструктуры PROD (например, оркестратор и операционные систем серверов).
T-PROD-VULN-3-1	Выполняется регулярное сканирование всех компонентов инфраструктуры PROD, а также выстроен процесс по их исправлению.
T-PROD-VULN-3-2	Выполняется автоматизированная проверка основных компонентов инфраструктуры PROD (например, оркестратора и операционных систем серверов) на соответствие лучшим практикам, а также организован процесс по исправлению несоответствий.
T-PROD-VULN-3-3	Выполняется регулярное сканирование на уязвимости инфраструктуры PROD автоматизированными средствами в режиме пентеста.
T-PROD-VULN-3-4	Обновления безопасности регулярно устанавливаются на все элементы инфраструктуры PROD (например, оркестратор и операционные систем серверов).
T-PROD-VULN-4-1	Выполняется автоматизированная проверка всех компонентов инфраструктуры PROD на соответствие лучшим практикам, а также организован процесс по исправлению несоответствий.
T-PROD-VULN-4-2	Осуществляется регулярная замена устаревшего неподдерживаемого производителями ПО в инфраструктуре PROD.

Анализ событий информационной безопасности [T-PROD-EVENTS]

ID	Описание
T-PROD-EVENTS-0-1	Собираются (хоть какие-то) события от элементов PROD инфраструктуры.
T-PROD-EVENTS-ML-0-2	Контролируются показатели производительности систем ИИ, качества и целостности данных, дрейфа данных, корректность работы систем ИИ регулярно оценивается. Настроена автоматическая отправка оповещений ответственным лицам о подозрительном изменении в выдаваемых системами ИИ результатах (например, Evidently, Prometheus, Grafana).
T-PROD-EVENTS-ML-0-3	Осуществляется реагирование на деградацию производительности систем ИИ.
T-PROD-EVENTS-ML-0-4	Запросы и ответы LLM журналируются.
T-PROD-EVENTS-2-1	Разработана и применяется политика аудита в PROD инфраструктуре  (например, Kubernetes Audit policy) Логи собираются, но не обрабатываются (например, хранятся внутри кластера Kubernetes).
T-PROD-EVENTS-ML-2-2	Перед журналированием запросы и ответы модели очищаются от конфиденциальной информации с помощью инструментов обнаружения и очистки конфиденциальной информации.
T-PROD-EVENTS-3-1	Все логи PROD инфраструктуры (например, Kubernetes) обрабатываются в SIEM, созданы правила корреляции в SIEM для идентификации инцидентов.
T-PROD-EVENTS-ML-3-2	События изменения файлов и атрибутов безопасности ML-моделей, обучающих, валидационных и тестовых данных, векторных представлений данных, баз знаний для RAG отслеживаются, централизованно хранятся, передаются в SIEM, созданы правила корреляции в SIEM для идентификации инцидентов, настроены оповещения подразделения ИБ о подозрительных событиях ИБ.
T-PROD-EVENTS-ML-3-3	Осуществляется трассировка взаимодействия агентов, вызова инструментов агентами, события передаются в SIEM, созданы правила корреляции в SIEM для идентификации инцидентов, настроены оповещения подразделения ИБ о подозрительных событиях ИБ.
T-PROD-EVENTS-ML-3-4	События от инструментов установки ограждений (guardrails, например, LLM Guard, NeMo Guardrails), обнаружения состязательных атак (например, детектор Binary Input в ART) передаются в SIEM-систему, настроены оповещения подразделения ИБ о подозрительных событиях ИБ, созданы правила корреляции в SIEM для идентификации инцидентов.
T-PROD-EVENTS-ML-3-5	Определены, журналируются и отправляются в SIEM-систему все критичные события ИБ систем ИИ, в том числе о множественных запросах от одной учетной записи/IP-адреса в короткий период времени, множественных длинных запросов, запросах на нецелевых языках, нестандартных шаблонах поведения и запросов пользователей, созданы правила корреляции в SIEM для идентификации инцидентов, настроены оповещения подразделения ИБ о подозрительных событиях ИБ.
T-PROD-EVENTS-ML-3-6	Обеспечивается постоянный мониторинг сети Интернет (в том числе Darknet и Telegram-каналов) на предмет утечки сведений о тестовых, валидационных и обучающих данных, архитектуре ML-моделей и гиперпараметрах обучения систем ИИ Компании.
T-PROD-EVENTS-ML-3-7	Осуществляется реагирование на связанные с ML-системами инциденты ИБ в автоматическом режиме.

Анализ и защита систем ИИ в режиме Runtime

Анализ ML-моделей на уязвимости в PROD среде [T-MLGUARD-VLN]

ID	Описание
T-MLGUARD-VLN-0-1	Применяются практики динамического тестирования ML-моделей на уязвимости.
T-MLGUARD-VLN-1-1	Собираются актуальные тестовые наборы данных, содержащие вредоносные запросы, и с помощью них проводится ручное или автоматизированное тестирование безопасности ML-моделей (например, HarmBench, StrongReject для LLM).
T-MLGUARD-VLN-2-1	Используются динамические сканеры безопасности ML-моделей модальностей "изображение", "аудио", "структурированные данные" для обнаружения возможности успешного проведения состязательных атак на ML-модели (например, ART на возможность обхода логики ML-модели, распознающей предметы на изображениях).
T-MLGUARD-VLN-2-2	Используются динамические сканеры безопасности ML-моделей модальности "текст" (сканеры уязвимости LLM) для обнаружение возможности успешного проведения атак, в том числе многошаговых, типа jailbreak, prompt injection, command injection, вывода нежелательных данных (конфиденциальная информация, избыточная точность, нежелательные ответы, действия, галлюцинации, ложная информация, введение в заблуждение и т.д.) (например, HiveTraceRed, Garak, LLAMATOR).
T-MLGUARD-VLN-3-1	Используется несколько динамических сканеров безопасности ML-моделей для увеличения поверхности сканирования и получения пересекающихся результатов.

Защитные механизмы и ограждения (guardrails) [T-MLGUARD-DEF]

ID	Описание
T-MLGUARD-DEF-0-1	Прописаны ограничения и правила в системном промпте LLM (является слабым защитным механизмом).
T-MLGUARD-DEF-1-1	При написании системного промпта LLM используются такие защитные техники как, например, "few shot prompting", "prompt sandwich" (являются слабыми защитными механизмами).
T-MLGUARD-DEF-1-2	Ограничивается ввод и вывод данных LLM длиной символов (минимально возможная длина сообщения для корректной работы подавляющего большинства пользователей), набором допустимых символов (исключаются абсолютно все нетребуемые для работы символы: специальные символы, редкие юникод-символы, невидимые управляющие символы и т.д.), в том числе символов целевого алфавита (например, ограничение ввода и вывода информации только на русском языке или преимущественно на русском с определением порога по количеству символов на другом языке), форматами, форматированием.
T-MLGUARD-DEF-1-3	Взаимодействие пользователей с системой ИИ происходит с использованием идентификации, аутентификации, авторизации (RBAC, OIDC).
T-MLGUARD-DEF-1-4	Ограничиваются количество и скорость запросов к системам ИИ от пользователей и ИС через API, а также между агентами.
T-MLGUARD-DEF-1-5	Долгосрочная и краткосрочные памяти агентов должны быть уникальными (не разделяемыми), изолированными для каждого пользователя, агента и ограничены по времени жизни.
T-MLGUARD-DEF-2-1	Запросы к сторонним LLM проходят через инструменты поиска и удаления конфиденциальной информации (например, Presidio).
T-MLGUARD-DEF-2-2	Используются инструменты установки ограждений (guardrails, например, LLM Guard, NeMo Guardrails или как альтернатива многоуровневая система модерации ML-моделями (LLM-as-a-judge)) входящих запросов, файлов, вызова инструментов и исходящих ответов от LLM, а также между агентами, для защиты от прямых и косвенных атак типа jailbreak, prompt injection, command injection, наличия нежелательных выходных данных (конфиденциальная информация, избыточная точность, нежелательные ответы, генерация кода, действия, галлюцинации, ложная информация, введение в заблуждение и т.д.).
T-MLGUARD-DEF-2-3	Используются инструменты для контроля целостности файлов манифестов и схем инструментов на MCP-сервере (например, Cosign). Агенты проверяют подписи до использования инструментов.
T-MLGUARD-DEF-2-4	Используется прокси-сервер между агентом и MCP-сервером, передающий схемы и манифесты только разрешенных инструментов MCP-сервера (например, metatool-ai/metamcp, respawn-app/tool-filter-mcp).
T-MLGUARD-DEF-2-5	Время и характер ответа LLM на легитимные запросы и на запросы, которые не прошли фильтрацию инструментов установки ограждений (guardrails), не отличаются друг от друга (защита от атак по побочным каналам, позволяющих выявить наличие и архитектуру защитных механизмов).
T-MLGUARD-DEF-2-6	Изменяются параметры входных и выходных данных системы ИИ (пред- и постобработка) для повышения устойчивости к атакам, т.к. в этом случае злоумышленник не сможет определить, какие реальные данные подаются в ML-модель и какие она выдает в ответ или с какой вероятностью ML-модель уверена в своем ответе (например, метод постобработки Gaussian Noise в ART).
T-MLGUARD-DEF-3-1	Мультимодальные системы ИИ защищаются для каждой модальности отдельно, учитывая, что атака может быть проведена не в основной модальности ML-модели (например, мультимодальная LLM может быть атакована через изображение, на котором содержится текст с атакующим промптом, также атакующий промпт может быть внедрен в метаданные изображения и т.д.).

Обучение и база знаний

Обучение специалистов [P-EDU-AWR]

ID	Описание
P-EDU-AWR-0-1	Производится обучение разработчиков в части ИБ.
P-EDU-AWR-1-1	В Компании есть базовый тренинг по ИБ.
P-EDU-AWR-1-2	Обучение по ИБ для команд разработки осуществляется ситуативно.
P-EDU-AWR-2-1	Проводятся регулярные тренинги по ИБ для всех разработчиков (внешний, внутренний, электронный тренинг).
P-EDU-AWR-2-2	Процесс обучения для разработчиков формализован (например, существует Регламент повышения осведомленности в области безопасной разработки).
P-EDU-AWR-2-3	Проводятся специализированные тренинги по ИБ для Security Champion.
P-EDU-AWR-2-4	Внедрена и используется специализированная централизованная платформа для проведения обучения по ИБ.
P-EDU-AWR-ML-2-5	Проводится обучение пользователей и разработчиков систем ИИ актуальным уязвимостям ML-моделей и агентов, правилам безопасного использования ML-моделей и агентов, ограничениям, связанным с работой ML-моделей и агентов, важности проверки выдаваемых ML-моделями и агентами результатов.
P-EDU-AWR-3-1	В Компании внедрена и работает программа поощрения внутреннего обмена опытом.
P-EDU-AWR-3-2	В Компании разработана и внедрена система мотивации сотрудников за прохождение ИБ обучения.
P-EDU-AWR-4-1	Команда ИБ регулярно участвует в CTF-like соревнованиях (или тренируется в кибер-полигоне) в контексте Web, SSDLC.

Управление базой знаний DSO [P-EDU-KB]

ID	Описание
P-EDU-KB-0-1	Существуют внутренние информационные ресурсы (базы знаний) с правилами и рекомендациями по безопасной разработке.
P-EDU-KB-1-1	Существуют локальные базы знаний у участников разработки в рамках одной команды.
P-EDU-KB-2-1	Существует централизованный ресурс (общая база знаний), хранящий базовые правила и рекомендации по безопасной разработке.
P-EDU-KB-2-3	Единая база знаний обновляется (нерегулярно, ответственные формально не выделены, QA не проводится).
P-EDU-KB-3-1	Централизованный ресурс (общая база знаний), хранит единые детальные правила и рекомендации по безопасной разработке, относящиеся, как к компании в целом, так и к отдельным командам разработки.
P-EDU-KB-3-2	Единая база знаний обновляется регулярно, назначены ответственные за ее обновление как внутри команд, так и в компании, выполняется QA созданных материалов в базе знаний.
P-EDU-KB-3-3	База знаний наполняется реальными примерами и сложными кейсами, которые были найдены на пентестах, багбаунти, в результате триажа AppSec`ами (например нарушения бизнес-логики).
P-EDU-KB-4-1	Разработаны и внедрены стандарты написания документации, единая база знаний следует таким стандартам и содержит необходимый комплект документов и информации к разрабатываемому ПО.
P-EDU-KB-4-2	В базе знаний подробно описаны кейсы с техническими подробностями и копией стенда (CTF like) для возможности тренинга.

Управление базой знаний MLSecOps [P-MLEDU-KB]

ID	Описание
P-MLEDU-KB-0-1	Существуют внутренние информационные ресурсы (базы знаний) с правилами и рекомендациями MLSecOps.
P-MLEDU-KB-1-1	Существуют локальные базы знаний у участников разработки в рамках одной команды.
P-MLEDU-KB-2-1	Существует централизованный ресурс (общая база знаний), хранящий базовые правила и рекомендации MLSecOps.
P-MLEDU-KB-2-3	Единая база знаний обновляется (нерегулярно, ответственные формально не выделены, QA не проводится).
P-MLEDU-KB-3-1	Централизованный ресурс (общая база знаний), хранит единые детальные правила и рекомендации MLSecOps, относящиеся, как к компании в целом, так и к отдельным командам разработки.
P-MLEDU-KB-3-2	Единая база знаний обновляется регулярно, назначены ответственные за ее обновление как внутри команд, так и в компании, выполняется QA созданные материалов в базе знаний.
P-MLEDU-KB-3-3	База знаний наполняется реальными примерами, которые были найдены на пентестах, багбаунти, триажа с сложными кейсами (н/р нарушения бизнес-логики).
P-MLEDU-KB-4-1	Разработаны и внедрены стандарты написания документации, единая база знаний следует таким стандартам и содержит необходимый комплект документов и информации к процессу MLSecOps.
P-MLEDU-KB-4-2	В базе знаний подробно описаны кейсы с техническими подробностями и копией стенда (CTF like) для возможности тренинга.

Контроль и формирование требований ИБ к ПО

Оценка критичности приложений и моделирование угроз [P-REQ-TM]

ID	Описание
P-REQ-TM-0-1	Выполняется оценка критичности и/или моделирование угроз для разрабатываемых приложений.
P-REQ-TM-ML-0-2	Проводится моделирование угроз для систем ИИ.
P-REQ-TM-1-1	Проводится моделирование угроз по требованиям compliance (например, для ПО для ЗОКИИ) или для наиболее критичных.
P-REQ-TM-1-2	Определены формальные критерии критичности приложений.
P-REQ-TM-1-3	Для всех новых разрабатываемых приложений проводится оценка критичности.
P-REQ-TM-ML-1-4	Определяются наиболее актуальные цели и темы атак на LLM, реализуемые с помощью актуальных угроз LLM, для использования их в сканерах безопасности LLM, ручном и автоматизированном тестировании на проникновение.
P-REQ-TM-2-1	Модели угроз разрабатываются в том числе и для технических средств.
P-REQ-TM-2-2	Моделирование угроз осуществляется для ВСЕХ НОВЫХ приложений.
P-REQ-TM-2-3	Оценка критичности выполняется для всех приложений.
P-REQ-TM-ML-2-4	Применяются меры по управлению риском чрезмерного доверия к выдаваемым результатам системы ИИ: регулярное отслеживание и анализ результатов работы ML-моделей (в том числе автоматическое), информирование пользователей об особенностях работы ML-моделей, способности ML-моделей искажать или выдумывать информацию, использование подхода human-in-the-loop.
P-REQ-TM-3-1	Модели угроз разрабатываются в том числе и для бизнес-процессов.
P-REQ-TM-3-2	Процесс моделирования угроз для разрабатываемого ПО стандартизован (есть шаблоны МУиМН, определены подходы к актуализации угроз и пр).
P-REQ-TM-3-3	Модели угроз регулярно пересматриваются.
P-REQ-TM-ML-3-4	Процесс моделирования угроз для систем ИИ стандартизован (есть шаблоны МУиМН, определены подходы к актуализации угроз и пр).
P-REQ-TM-ML-3-5	Модели угроз систем ИИ регулярно пересматриваются.
P-REQ-TM-4-1	К каждому разрабатываемому ПО определены "Abuse cases" (сценарии нелегитимного использования ПО), такие кейсы учитываются при моделировании угроз и доработке ПО.
P-REQ-TM-ML-4-2	Проводится оценка, регулярный мониторинг и переоценка рисков ИБ систем ИИ (например, ISO 27005, методологии OWASP Risk rating, DREAD) и выявляются актуальные риски.
P-REQ-TM-ML-4-3	Выявленные актуальные риски ИБ систем ИИ обрабатываются (снижение, принятие, предотвращение или передача третьей стороне).

Определение требований ИБ, предъявляемых к ПО [P-REQ-RD]

ID	Описание
P-REQ-RD-0-1	К разрабатываемым приложениям предъявляются требования по ИБ.
P-REQ-RD-ML-0-2	К обучающим, валидационным, тестовым данным, базам знаний для RAG, векторным представлениям данных, ML-моделям предъявляются требования по ИБ.
P-REQ-RD-1-1	Разработаны и предъявляются базовые требования по ИБ к разрабатываемому ПО.
P-REQ-RD-1-2	Подразделение ИБ одобряет\согласовывает решения, которые влияют на уровень ИБ разрабатываемого приложения.
P-REQ-RD-2-1	Дополнительные требования по ИБ формируются с учетом актуальных угроз по результатам моделирования угроз.
P-REQ-RD-2-2	Требования по ИБ стандартизованы (например, разработаны чеклисты).
P-REQ-RD-2-3	Подразделения ИБ участвуют в создании архитектуры разрабатываемого ПО.
P-REQ-RD-3-1	Дополнительные требования по ИБ формируются с учетом актуальных угроз для бизнес-функций (по результатам соответствующего моделирования угроз).
P-REQ-RD-3-2	Дополнительные требования по ИБ формируются с учетом результатов анализа рисков.
P-REQ-RD-3-3	Ключевые решения, которые влияют на уровень ИБ разрабатываемого приложения, принимаются на архитектурном комитете.
P-REQ-RD-4-1	Все фичи проходят согласование через подразделение ИБ на этапе планирования.

Контроль выполнения требований ИБ [P-REQ-CR]

ID	Описание
P-REQ-CR-0-1	Контролируется выполнение требований ИБ к разрабатываемому ПО.
P-REQ-CR-ML-0-2	Контролируется выполнение требований ИБ к обучающим, валидационным, тестовым данным, базам знаний для RAG, векторным представлениям данных, ML-моделям.
P-REQ-CR-1-1	Требования ИБ к разрабатываемому ПО проверяются на этапе выпуска ПО в продуктовую среду.
P-REQ-CR-2-1	Осуществляется контроль выполнения требований ИБ к разрабатываемому ПО посредством функциональных тестирований ИБ и тестирований на проникновение.
P-REQ-CR-3-1	Производится валидация отсутствия уязвимостей в программном коде ПО (например, применение Quality gates, которые зафиксированы в документе).
P-REQ-CR-4-1	Производится проверка и согласование технического задания и проекта архитектуры, разработанных с учетом требований ИБ.

Разработка стандартов конфигураций разрабатываемого ПО [P-REQ-STDR-App]

ID	Описание
P-REQ-STDR-App-0-1	Создаются стандарты конфигурирования разрабатываемого ПО.
P-REQ-STDR-App-1-1	Стандарты конфигурирования разрабатываемого ПО есть, но не формализованы (т.е. это НЕ стандарты, а рекомендации или легаси настройки).
P-REQ-STDR-App-1-2	Стандарты конфигурирования (рекомендации, легаси настройки) разрабатываемого ПО применяются вручную.
P-REQ-STDR-App-2-1	Стандарты конфигурирования разрабатываемого ПО разработаны для ключевых систем.
P-REQ-STDR-App-3-1	Стандарты конфигурирования разработаны и применяются для всех систем.
P-REQ-STDR-App-3-2	Используется подход IaC для контроля конфигурации разрабатываемого ПО.
P-REQ-STDR-App-4-1	Выполняется регулярное обновление профилей конфигурирования с учетом risk-based approach.

Разработка стандартов конфигураций для компонентов инфраструктуры [P-REQ-STDR-Infr]

ID	Описание
P-REQ-STDR-Infr-0-1	Создаются стандарты конфигурирования компонентов инфраструктуры (СККИ).
P-REQ-STDR-Infr-1-1	СККИ есть, но не формализованы (т.е. это НЕ стандарты, а рекомендации или легаси настройки).
P-REQ-STDR-Infr-1-2	СККИ (рекомендации, легаси настройки) применяются вручную.
P-REQ-STDR-Infr-2-1	СККИ разработаны для ключевых инфраструктурных систем.
P-REQ-STDR-Infr-2-2	Производится выборочный контроль применения СККИ (без использования средств автоматизации).
P-REQ-STDR-Infr-3-1	СККИ разработаны и применяются для всех систем.
P-REQ-STDR-Infr-3-2	Используются автоматизированные средства контроля применения СККИ.
P-REQ-STDR-Infr-3-3	Используется подход IaC для контроля конфигурации компонентов инфраструктуры.
P-REQ-STDR-Infr-4-1	Регулярное обновление СККИ с учетом risk-based approach.

Управление ИБ дефектами

Обработка дефектов ИБ [P-DEFECT-MNG]

ID	Описание
P-DEFECT-MNG-0-1	Выполняется контроль устранения дефектов ИБ.
P-DEFECT-MNG-1-1	Обработка дефектов разрабатываемого ПО осуществляется при необходимости (onDemand, ситуативно, отсутствует системный подход).
P-DEFECT-MNG-2-1	Все дефекты критического уровня обрабатываются в приоритетном порядке.
P-DEFECT-MNG-2-2	Поиск дефектов автоматизирован и является частью CI\CD.
P-DEFECT-MNG-3-1	Для каждого дефекта ИБ создается задача (task, тикет) в системе управления задачами (task maganement system). Осуществляется контроль устранения дефекта (выполнения задачи).
P-DEFECT-MNG-3-2	Внедрен и контролируется SLA по исправлению дефектов ИБ.
P-DEFECT-MNG-3-3	На QG проверяется отсутствие дефектов заданного уровня критичности (и это является критерием прохождения QG).
P-DEFECT-MNG-4-1	Дефекты обрабатываются в соответствии с risk-based approach.

Консолидация дефектов ИБ [P-DEFECT-CNS]

ID	Описание
P-DEFECT-CNS-0-1	Выполняется централизованное хранение и обработка отчетности по найденным дефектам ИБ.
P-DEFECT-CNS-1-1	Внедрено и используется централизованное хранилище отчетов по дефектам ИБ разрабатываемого ПО.
P-DEFECT-CNS-1-2	Отчетность выгружается и хранится централизовано для ряда проверок\инструментов.
P-DEFECT-CNS-2-1	Отчетность выгружается и хранится централизовано для всех проверок\инструментов, которые есть в Компании и которые анализируют разрабатываемое ПО.
P-DEFECT-CNS-3-1	Внедрена и используется SGRC для управления отчетами.
P-DEFECT-CNS-3-2	Отчеты загружаются в SGRC в ручном режиме.
P-DEFECT-CNS-4-1	Отчеты загружаются в SGRC в автоматическом режиме.
P-DEFECT-CNS-4-2	Существует перечень ответственных за работу с дефектами ИБ, описаны пути эскалаций устранения дефектов ИБ.

Домен. Оценка эффективности процессов

Управление набором метрик ИБ [P-MET-SET]

ID	Описание
P-MET-SET-0-1	Разработаны метрики процессов DSO.
P-MET-SET-ML-0-2	Разработаны метрики процессов MLSecOps.
P-MET-SET-2-1	Определены, описаны и отслеживаются метрики процессов DSO.
P-MET-SET-2-2	Определены целевые значения по каждой метрике процессов DSO.
P-MET-SET-ML-2-3	Определены, описаны и отслеживаются метрики процессов MLSecOps.
P-MET-SET-ML-2-4	Определены целевые значения по каждой метрике процессов MLSecOps.
P-MET-SET-3-1	Выполняется регулярный пересмотр собираемых метрик процессов DSO.
P-MET-SET-3-2	Выполняется регулярная корректировка целевых значений.
P-MET-SET-ML-3-3	Выполняется регулярный пересмотр собираемых метрик процессов MLSecOps.
P-MET-SET-ML-3-4	Выполняется регулярная корректировка целевых значений метрик процессов MLSecOps.

Контроль исполнения метрик [P-MET-EX]

ID	Описание
P-MET-EX-0-1	Выполняется контроль метрик DSO.
P-MET-EX-ML-0-2	Выполняется контроль метрик процессов MLSecOps.
P-MET-EX-2-1	Выполняется сбор и анализ метрик процессов DSO.
P-MET-EX-2-2	Выполняется формирование отчетов и сравнение результатов метрик процессов DSO с целевыми показателями.
P-MET-EX-ML-2-2	Выполняется сбор и анализ метрик процессов MLSecOps.
P-MET-EX-ML-2-3	Выполняется формирование отчетов и сравнение результатов метрик процессов MLSecOps с целевыми показателями.
P-MET-EX-3-1	Сбор и анализ метрик для всех команд.
P-MET-EX-3-2	Проводится регулярная оценка эффективности реализуемых мероприятий на основе собираемых метрик процессов DSO.
P-MET-EX-3-3	Выполняется визуализация результатов сбора метрик процессов DSO (формирование дашбордов. Например, в Grafana).
P-MET-EX-ML-3-3	Сбор и анализ метрик для всех команд.
P-MET-EX-ML-3-4	Проводится регулярная оценка эффективности реализуемых мероприятий на основе собираемых метрик процессов MLSecOps.
P-MET-EX-ML-3-5	Выполняется визуализация результатов сбора метрик процессов MLSecOps (формирование дашбордов. Например, в Grafana).
P-MET-EX-4-1	Производится модернизация и совершенствование бизнес-процессов на основании собираемых метрик процессов DSO. Есть такие примеры (или же описан где-то такой процесс).
P-MET-EX-ML-4-2	Производится модернизация и совершенствование бизнес-процессов на основании собираемых метрик процессов MLSecOps. Есть такие примеры (или же описан где-то такой процесс).

Функциональные роли

Security Champions [P-ROLE-SC]

ID	Описание
P-ROLE-SC-0-1	Используются практики Security Champion - регулярное взаимодействие с командами разработки по вопросам ИБ.
P-ROLE-SC-1-1	Функции Security Champion выполняются, как минимум, специалистами ИБ
P-ROLE-SC-2-1	В команде\проекте есть выделенный security champion
P-ROLE-SC-2-2	Security Champion продвигает внутри команды лучшие практики в части безопасной разработки, делится с командами AppSec данными об уязвимостях и новых методах и практиках ИБ
P-ROLE-SC-3-1	Security Champion проводит R&D работу в части использования новых инструментов ИБ и отчитывается о результатах AppSec команде
P-ROLE-SC-3-2	Security Champion поддерживает используемые в цикле безопасной разработки инструменты ИБ в актуальном состоянии
P-ROLE-SC-3-3	Security Champion проводит проверку безопасности кода в своей области экспертизы
P-ROLE-SC-3-4	Security Champion участвует в разработке PoC и тестировании новых инструментов ИБ
P-ROLE-SC-4-1	Security Champion проводит тренинги по безопасной разработке и ИБ в целом для новых разработчиков
P-ROLE-SC-4-2	Security Champion работает до 3х месяцев в команде AppSec в рамках практик ротации работников
P-ROLE-SC-4-3	Security champion проводит проверки (review) моделей угроз, безопасного дизайна, а также peer-review работ, выполненных другими security champion
P-ROLE-SC-4-4	Security champion выполняет PoC для новых эксплойтов, а также проверку приложений на выполнение требований по ИБ

Разграничение ролей процесса DSO [P-ROLE-RESP]

ID	Описание
P-ROLE-RESP-0-1	Существует разграничение ролей процесса безопасной разработки
P-ROLE-RESP-1-1	В подразделении ИБ определены специалисты, отвечающие за безопасность разрабатываемого ПО (в дополнение к другой деятельности)
P-ROLE-RESP-1-2	Обязанности и ответственность за безопасность разрабатываемого ПО закреплены формально (приказ, должностная инструкция и пр.)
P-ROLE-RESP-2-1	Выделены сотрудники ИБ (роли), основной обязанностью которых является безопасность разработки (DSO)
P-ROLE-RESP-2-2	Сформирована матрица ролей в части DSO
P-ROLE-RESP-2-3	Разработан и введен в действие регламент безопасной разработки
P-ROLE-RESP-2-4	Существует и согласована дорожная карта развития DevSecOps
P-ROLE-RESP-3-1	Разработана и используется RACI-матрица для всего процесса DSO
P-ROLE-RESP-3-2	Постоянный пересмотр и актуализация дорожной карты DevSecOps с учетом бизнес-целей организации и внешних факторов

Разграничение ролей процесса MLSecOps [P-MLROLE-RESP]

ID	Описание
P-MLROLE-RESP-0-1	Существует разграничение ролей процесса MLSecOps.
P-MLROLE-RESP-1-1	В подразделении ИБ определены специалисты, отвечающие за MLSecOps (в дополнение к другой деятельности).
P-MLROLE-RESP-1-2	Обязанности и ответственность за MLSecOps закреплены формально (приказ, должностная инструкция и пр.).
P-MLROLE-RESP-2-1	Выделены сотрудники ИБ (роли), основной обязанностью которых является MLSecOps.
P-MLROLE-RESP-2-2	Сформирована матрица ролей в части MLSecOps.
P-MLROLE-RESP-2-3	Разработан и введен в действие регламент MLSecOps.
P-MLROLE-RESP-2-4	Существует и согласована дорожная карта развития MLSecOps.
P-MLROLE-RESP-3-1	Разработана и используется RACI-матрица для всего процесса MLSecOps.
P-MLROLE-RESP-3-2	Постоянный пересмотр и актуализация дорожной карты MLSecOps с учетом бизнес-целей организации и внешних факторов.