Контроль использования сторонних компонентов
ID Описание Уровень зрелости BSIMM SAMM T-ADI-DEP-0-1 Управление зависимостями (Dependencies) в исходном коде осуществляется в каком-либо виде 0 - - T-ADI-DEP-1-1 Существуют (формализованы) единые правила, определяющие возможность использования тех или иных зависимостей в коде. Например, есть утвержденный документ, и/или страница в базе знаний, описывающие порядок использования зависимостей в коде 2 - SB-B-2 T-ADI-DEP-1-2 Обновление существующих зависимостей выполняется вручную. Например, если возникла необходимость использовать новую версию библиотеки в коде, то ее вручную выгружают и добавляют в проект 2 - - T-ADI-DEP-1-3 Существует (описан, формализован) план реагирования на события ИБ, связанных с зависимостями 2 SR2.7 OM-B-2 T-ADI-DEP-1-4 Выполняется харденинг (безопасная настройка) файлов конфигураций используемых пакетов open source software - OSS (например, nuget.config, .npmrc, pip.conf, pom.xml, etc.) 2 - - T-ADI-DEP-1-5 Зависимости с тэгом "latest" не применяются 2 - - T-ADI-DEP-2-1 Разработчики получают и используют OSS компоненты, применяя только стандартизованные (формализованные и утвержденные) методы 3 SR2.7 - T-ADI-DEP-2-2 Контролируется и регулируется использование новых (моложе 60 дней) и старых (неактуальных, заброшенных, старше 365 дней) OSS. Например, настроен OSS firewall на предупреждение (или запрет) использования OSS, выпущенных\актуализированных более 365 дней назад и менее чем 60 дней 3 - OM-B-1, OM-B-2 T-ADI-DEP-3-1 Выполняется инвентаризация используемых зависимостей. Например, создан внутренний репозиторий 4 SR1.5 SB-B-2 (+-) T-ADI-DEP-3-2 При выполнении Pull/Merge request предоставляется список всех уязвимостей используемых зависимостей. Это может быть реализовано с помощью SCA решения 4 - SB-B-3 T-ADI-DEP-3-3 Выполняется верификация цифровой подписи SBOM перед использованием зависимостей в сборке. Это может быть реализовано с помощью SCA решения 4 - - T-ADI-DEP-3-4 Выполняется автоматическое обновление используемых зависимостей. Это может быть реализовано с помощью специальных утилит для обновления зависимостей 4 - - T-ADI-DEP-4-1 Выполняется самостоятельная сборка необходимых зависимостей в доверенной среде 6 - - T-ADI-DEP-4-2 Выполняется создание и проверка цифровой подписи собранных зависимостей. Например, с помощью Cosign 6 SE2.4 - T-ADI-DEP-4-3 Выполняется создание и проверка цифровой подписи на SBOM для собранных зависимостей. Например, с помощью Cosign 6 - -
Управление артефактами
ID Описание Уровень зрелости BSIMM SAMM T-ADI-ART-0-1 Управление артефактами разработки присутствует в каком-либо виде 0 - - T-ADI-ART-1-1 Все артефакты разработки хранятся в доверенных registry. Например, используется внутренний реестр 1 - - T-ADI-ART-1-2 Строго ограниченный перечень лиц может помещать артефакты в registry. Внутри registry настроены правила разграничения доступа 1 - - T-ADI-ART-1-3 Для аутентификации в registry используются внешние сервисы. Например, выполнена интеграция с LDAP или другим IdM, локальные учетные записи не используются 1 - - T-ADI-ART-1-4 Отключен анонимный доступ в registry 1 - - T-ADI-ART-1-5 Настроен и включен аудит любых изменений конфигурации хранилищ артефактов 1 - - T-ADI-ART-2-1 Разработчики получают артефакты для дальнейшей работы только из внутренних репозиториев 3 - - T-ADI-ART-2-2 Выполняется создание хэш сумм артефактов перед отправкой их в registry, а также их проверка при сборке 3 - SB-A-2 T-ADI-ART-2-3 Для взаимодействия с registry используются webhook с использованием TLS версии не ниже 1.2 3 - - T-ADI-ART-3-1 Выполняется создание цифровых подписей всех артефактов перед их отправкой в registry 4 SE2.4 SD-A-3 T-ADI-ART-3-2 Для всех артефактов создается SBOM 4 SR1.5
SE3.6SB-B-1 T-ADI-ART-3-3 Используется многофакторная аутентификация для доступа к registry 4 - - T-ADI-ART-3-4 Конвейер сборки (build pipeline) подписывает все артефакты, которые он создает 4 SE2.4 SD-A-3 T-ADI-ART-4-1 Выполняется шифрование всех артефактов в registry 5 - -
Защита рабочих мест разработчика
ID Описание Уровень зрелости BSIMM SAMM T-DEV-COMP-0-1 Применяются практики защиты рабочих мест разработчиков 0 - - T-DEV-COMP-1-1 Утверждены и применяются базовые требования к ПО и настройкам на корпоративных рабочих местах разработчиков. Например, требования к антивирусу, обновлениям ОС, требования к паролям 1 - - T-DEV-COMP-1-2 Удаленный доступ с некорпоративных (и, соответственно, ненастроенных) устройств к инструментам разработки возможен только для ограниченного (небольшого) числа устройств 1 - - T-DEV-COMP-2-1 Удаленный доступ к инструментам разработки возможен либо с корпоративных устройств с использованием MDM, либо через промежуточные\проксирующие системы, например, VDI или PAM 3 - -
Защита секретов
ID Описание Уровень зрелости BSIMM SAMM T-DEV-SM-0-1 Существует практика управления секретами 0 - - T-DEV-SM-1-1 Секреты в среде разработки защищаются встроенными механизмами инструментов разработки, например, CI/CD системы, без применения Secret Management систем 1 - SB-A-3 T-DEV-SM-1-2 Инциденты ИБ, связанные с использованием секретов в среде разработки, обрабатываются службой ИБ совместно с разработчиками 1 CMVM1.1 - T-DEV-SM-2-1 Секреты окружения разработки хранятся в Secret Management инструменте, например, Hashicorp Vault 2 - - T-DEV-SM-2-2 Разработчики и инженеры обмениваются секретамис помощью инструмента Secret Management, например, Hashicorp Vault 2 - SD-B-1 T-DEV-SM-3-1 Секреты всех сред и инструментов (за исключением рабочих станций разработчиков и подобных adhoc сред) хранятся в SM (например, Vault), количество hardcoded секретов минимально. Случаи использования hardcoded секретов известны команде ИБ и запланирован отказ от их использования 3 - SD-B-1 T-DEV-SM-3-2 Сформирована и применяется политика ротации секретов окружений разработки 3 - SD-B-3 T-DEV-SM-4-1 Используются динамические секреты с ограничением доступа для сред 6 - -
Защита Build-среды
ID Описание Уровень зрелости BSIMM SAMM T-DEV-BLD-0-1 Применяются практики защиты инфраструктуры сборки ПО 0 - - T-DEV-BLD-1-1 Доступ к среде сборки (build) (оркестратор, worker-узлы итд) ограничен (настроен RBAC) 2 - - T-DEV-BLD-1-2 Для всех узлов сборки (build worker) используется подход push (вместо pull) для передачи параметров 2 - - T-DEV-BLD-1-3 Каждый узел сборки (build worker) имеет минимально необходимые сетевые доступы (для связи только с нужными сервисами и только по определенным портам\протоколам) 2 - - T-DEV-BLD-1-4 Выполняется централизованное хранение журналов (логов) сборки, включающее изменение настроек 2 - SB-A-3 T-DEV-BLD-2-1 Осуществляется мониторинг и реагирование на инциденты для узлов сборки в части потребления вычислительных ресурсов (CPU, RAM, HDD и пр). 3 CMVM1.1 Incident Detection T-DEV-BLD-3-1 Каждый узел сборки (build worker) имеет отдельную роль (например, тестирование, компиляция, отправка артефактов), прочие задачи на нем не выполняются 5 - - T-DEV-BLD-3-2 Реализована настройка механизмов безопасности для узлов сборки 5 - SB-A-1
SB-A-2T-DEV-BLD-3-3 Все настройки узлов сборки (build worker) централизованно хранятся в системе хранения исходного кода 5 - - T-DEV-BLD-4-1 Создание среды сборки (build environment) выполняется автоматизировано (IaC) 6 - -
Защита source code management (SCM)
ID Описание Уровень зрелости BSIMM SAMM T-DEV-SCM-0-1 Применяются практики защиты репозитория кода 0 - - T-DEV-SCM-1-1 Создавать и удалять репозитории могут только определенные пользователи (например, настроен RBAC) 2 - - T-DEV-SCM-1-2 Удалять issues могут только определенные пользователи (например, настроен RBAC) 2 - - T-DEV-SCM-1-3 Создавать teams/groups могут только определенные пользователи (например, настроен RBAC) 2 - - T-DEV-SCM-1-4 Количество администраторов VCS ограничено и регулярно проверяется 2 - - T-DEV-SCM-1-5 Управление доступом к системе контроля версий осуществляется с использованием ролевой модели, созданной на основе принципа минимальных привилегий. Модель регулирует как минимум:
- Возможности по созданию репозиториев
- Возможности по удалению репозиториев
- Возможности по изменению видимости репозиториев2 - - T-DEV-SCM-1-6 Непривилегированным пользователям доступно создание только приватных репозиториев 2 - - T-DEV-SCM-1-7 При установке любых приложений и дополнений в Source code management системах (SCM) запрашивается одобрение (approval) администратора 2 - - T-DEV-SCM-2-1 У всех копий (forks) кода включен аудит, а также назначен ответственный 3 - - T-DEV-SCM-2-2 Регулярно осуществляется анализ и удаление неактивных пользователей из проекта 3 - - T-DEV-SCM-2-3 Почтовые уведомления могут направляться только на доверенные (проверенные) домены# 3 - - T-DEV-SCM-2-4 Неактивные (ненужные) приложения (applications или дополнения) удаляются из SCM системы 3 - - T-DEV-SCM-2-5 Для каждого репозитория по умолчанию установлены минимальные привилегии пользователей 3 - - T-DEV-SCM-2-6 Для добавления нового пользователя в VCS используются только корпоративные email 3 - - T-DEV-SCM-3-1 Все изменения видимости проекта отслеживаются 4 - - T-DEV-SCM-3-2 Осуществляется идентификация неиспользуемых репозиториев и их архивирование 4 - - T-DEV-SCM-3-3 Доступ к SCM осуществляется с использованием многофакторной аутентификации 4 - - T-DEV-SCM-3-4 Доступ к VCS системам осуществляется только с разрешенных IP-адресов 4 - - T-DEV-SCM-4-1 Проводится анализ кода на наличие аномалий, релевантных организации (например, commit содержит слишком значительные изменения объемов кода или в commit'ов слишком много в определенный промежуток времени) 6 - - T-DEV-SCM-4-2 Доступ разработчиков к репозиторию осуществляется с использованием сертификатов, созданных только с использованием внутреннего CA (центр сертификации) компании (а не самоподписанные сертификаты) в качестве дополнительного фактора аутентификации 6 - -
Контроль внесения изменений в исходный код
ID Описание Уровень зрелости BSIMM SAMM T-DEV-SRC-0-1 Применяются практики контроля внесения изменений в исходный код 0 - - T-DEV-SRC-1-1 Все изменения в исходном коде отслеживаются с использованием системы контроля версий (SCM) 1 - - T-DEV-SRC-1-2 Круг согласования запроса на слияние исходного кода начинается заново при внесении новых предложений по изменению 1 - - T-DEV-SRC-1-3 Разработчики не обладают правами "dismiss code change review", позволяющими обходить стандартную процедуру проверки кода 1 - - T-DEV-SRC-1-4 Для всех репозиториев включена опция linear history. В качестве вариантов merge доступны только squash и rebase merge 1 - - T-DEV-SRC-1-5 Используется защита веток (branch protection) 1 - - T-DEV-SRC-2-1 Осуществляется регулярный анализ и удаление неиспользуемых веток (branches) 3 - - T-DEV-SRC-2-2 Запрос на слияние (merge request) реализуется только при успешном прохождении всех проверок 3 ST3.6 - T-DEV-SRC-2-3 Все открытые ветки (branches) обновляются перед отправкой запроса на merge 3 - - T-DEV-SRC-2-4 Слияние изменений в исходном коде разрешены только в случае отсутствия открытых комментариев и обсуждений 3 - - T-DEV-SRC-2-5 Для каждого изменения исходного кода есть соответствующий тикет в системе управления заданиями (task maganement system, например, jira) 3 - - T-DEV-SRC-2-6 Правила защиты, применяемые к веткам (branch protection rules), применяются в том числе к УЗ администраторов 3 - - T-DEV-SRC-3-1 Для наиболее важных файлов определены и назначены Code Owners 4 - - T-DEV-SRC-3-2 Code Owners согласовывают изменения файлов, которые им "принадлежат" 4 - - T-DEV-SRC-3-3 Только подписанные commits (signed commit) допускаются к merge requests (особенно в main-ветку) 4 SE2.4 - T-DEV-SRC-3-4 Каждое изменение в исходном коде (каждый commit) согласовывается как минимум двумя аутентифицированными пользователями 4 - - T-DEV-SRC-3-5 Осуществляется контроль за удалением защищенных веток (protected branch) 4 - - T-DEV-SRC-4-1 Для всех репозиториев функция "force push" доступна только для владельца 6 - -
Защита конвейера сборки
ID Описание Уровень зрелости BSIMM SAMM T-DEV-CICD-0-1 Применяются практики защиты конвейера сборки ПО 0 - BP-A-2
SB-A-2 (Актуальное название)T-DEV-CICD-1-1 Доступ к конвейеру сборки ограничен (настроен RBAC) 1 - SB-A-2 T-DEV-CICD-1-2 Выполняется централизованное хранение журналов событий конвейеров сборки 1 - SB-A-3 T-DEV-CICD-1-3 Используется подход "CICD as a code" при создании конвейера разработки 1 SM3.4 - T-DEV-CICD-2-1 Для каждого этапа сборки строго определены входные и выходные параметры и результаты 3 - - T-DEV-CICD-2-2 Изменение конфигурационных файлов CI\CD (конвейеров сборки) непрерывно отслеживается 3 - - T-DEV-CICD-3-1 Выполняется централизованное хранение всех логов стадии сборки (Build) 4 - SB-A-3 T-DEV-CICD-4-1 Каждый конвейер (CICD), используемый для сборки, имеет единственное предназначение (например, тестирование, компиляция, отправка артефактов), прочие задачи на нем не выполняются 5 - -
Статический анализ (SAST)
ID Описание Уровень зрелости BSIMM SAMM T-CODE-SST-0-1 Выполняется статический анализ исходного кода разрабатываемого ПО 0 - ST-A-1 T-CODE-SST-1-1 Анализ исходного кода применяется, как минимум, ситуативно. 2 CR1.2 - T-CODE-SST-1-2 В SAST используются, как минимум, правила по умолчанию 2 - - T-CODE-SST-2-1 Выполняется регулярное сканирование отдельных частей кода, например:
- изменений в коде по результатам спринтов
- код разработанных framework
- итд3 - - T-CODE-SST-2-2 Неиспользуемые правила анализа в SAST отключены 3 - - T-CODE-SST-2-3 Выполнена интеграция SAST в CI (отдельный скрипт для каждой команды) 3 SM3.4
CR1.4
CR1.5ST-A-3 T-CODE-SST-2-4 Используются плагины SAST в IDE [при их наличии] 3 - ST-A-2 T-CODE-SST-3-1 Выполняется регулярное сканирование SAST полной кодовой базы 4 - - T-CODE-SST-3-2 Используются кастомизированные правила 4 CR2.6 ST-A-2 T-CODE-SST-3-3 Выполнена интеграция SAST с инструментом code quality (например, SonarQube) 4 - - T-CODE-SST-4-1 Выполняется сканирование исходного кода open source компонентов (сканирование на malware, protestware и т.д.) 7 - SB-B-3
Композиционный анализ (SCA)
ID Описание Уровень зрелости BSIMM SAMM T-CODE-SC-0-1 Выполняется композиционный анализ разрабатываемого ПО 0 SM3.5 ST-A-1
SB-B-3T-CODE-SC-1-1 В SCA используются, как минимум, политики анализа по умолчанию 1 SE3.8 - T-CODE-SC-1-2 Применяется выборочная блокировка подключаемых библиотек вручную при выявлении дефектов ИБ 1 - - T-CODE-SC-1-3 В SCA сохраняется история всех используемых (использованных) библиотек 1 SR1.5 SB-B-2 T-CODE-SC-2-1 Библиотеки с уязвимостями с высоким рейтингом, включая RCE, блокируются по договоренности между ИБ и разработчиками 2 - - T-CODE-SC-2-2 Осуществляется контроль получения образов (получение только из доверенных репозиториев) 2 - - T-CODE-SC-2-3 Выполняется проверка цифровых подписей и хэшей компонентов 2 SE2.4 SB-A-1 (+-) T-CODE-SC-2-4 Настроена интеграция SCA в CI/CD 2 SM3.4
CR1.4
CR1.5ST-A-3 T-CODE-SC-2-5 Выполняется проверка на лицензионную чистоту 2 SR2.7 SB-B-2 T-CODE-SC-3-1 Подключение всех возможных open source feeds 4 - - T-CODE-SC-3-2 Совмещение практик SAST и SCA для идентификации уязвимостей в коде (effective usage analyse. Например, библиотека уязвима, но при этом НЕ используется уязвимый метод) 4 CR3.2 - T-CODE-SC-3-3 Используются SCA плагины для IDE для pre-commit hooks 4 - ST-A-2 T-CODE-SC-3-4 Библиотеки со статусом End of life блокируются по договоренности между ИБ и разработчиками 4 - - T-CODE-SC-4-1 Использование платных feeds, обогащающих результаты анализа open source компонентов 6 - -
Анализ образов контейнеров
ID Описание Уровень зрелости BSIMM SAMM T-CODE-IMG-0-1 Выполняется сканирование образов контейнеров на наличие уязвимостей 0 - Scalable Baseline T-CODE-IMG-1-1 Сканирование образов контейнеров на наличие уязвимостей регламентировано и выполняется стандартизированным набором инструментов 1 - - T-CODE-IMG-1-2 Выполняется сканирование образов контейнеров. Запуск сканирования происходит в ручном режиме 1 - - T-CODE-IMG-1-3 Применяется выборочная блокировка образов контейнеров вручную при выявлении дефектов ИБ 1 - - T-CODE-IMG-2-1 Выполняется сканирование образов контейнеров в CI/CD на наличие уязвимостей 2 SM3.4 - T-CODE-IMG-2-2 Выполняется периодическое сканирование образов контейнеров, размещенных во внутренних репозиториях, на наличие уязвимостей 2 - - T-CODE-IMG-2-3 При обнаружении дефектов ИБ в образах контейнеров автоматизированно создаются задачи на их устранение в тикет-системе 2 - - T-CODE-IMG-3-1 Выполняется проверка цифровых подписей образов контейнеров 3 SE2.4 - T-CODE-IMG-3-2 Non-compliant ресурсы блокируются по договоренности между ИБ и разработчиками 3 - - T-CODE-IMG-4-1 Сборки в CI/CD блокируются при найденных уязвимостях в образах контейнеров по договоренности между ИБ и разработчиками 4 - -
Идентификация секретов
ID Описание Уровень зрелости BSIMM SAMM T-CODE-SECDN-0-1 Применяются практики поиска секретов 0 - Scalable Baseline T-CODE-SECDN-1-1 Механизмы идентификации секретов применяются как минимум в SCM системах 1 - - T-CODE-SECDN-1-2 Инструменты идентификации секретов запускаются вручную 1 - - T-CODE-SECDN-1-3 В инструментах идентификации секретов используются настройки поиска секретов, заданные по умолчанию 1 - - T-CODE-SECDN-1-4 Инциденты ИБ, связанные с использованием найденных секретов, разрешаются совместно с разработчиками 1 CMVM1.1 IM-A-2 T-CODE-SECDN-2-1 Инструменты идентификации секретов охватывают:
- Все версии кода, хранящиеся в SCM
- Манифесты IaC
- Артефакты: — образы Docker, — Все репозитории — Облачную инфраструктуру — Сканирование и блокирование секретов во время стадий pull/Merge2 - - T-CODE-SECDN-2-2 В инструментах идентификации секретов используются кастомизированные настройки поиска секретов 2 CR2.6 - T-CODE-SECDN-2-3 При обработке событий ИБ, связанных с найденными секретами используется приоритизация 2 - IM-B-2 T-CODE-SECDN-3-1 При наличии в коде секретов commit'ы блокируются по договоренности между ИБ и разработчиками 3 - - T-CODE-SECDN-3-2 Сканирование секретов также включает в себя:
- Рабочие станции разработчиков и любые adhoc среды
- Логи сборок (Build logs)3 - - T-CODE-SECDN-4-1 Hardcoded секреты отсутствуют 5 - SD-B-2
Контроль безопасности Dockerfile’ов
ID Описание Уровень зрелости BSIMM SAMM T-CODE-DOCKERFS-0-1 Применяются практики безопасного написания Dockerfiles 0 - - T-CODE-DOCKERFS-1-1 Разработан регламент по безопасному написанию Dockerfiles 1 - - T-CODE-DOCKERFS-1-2 Выполняется ручной контроль безопасности Dockerfile 1 - - T-CODE-DOCKERFS-2-1 Dockerfiles проверяются автоматизировано в pipeline 2 - -
Динамический анализ приложений (DAST) в PREPROD среде
ID Описание Уровень зрелости BSIMM SAMM T-PREPROD-DAST-0-1 Применяются практики динамического тестирования (DAST) 0 - - T-PREPROD-DAST-1-1 Динамическое сканирование используется как минимум для пользовательского интерфейса 3 - - T-PREPROD-DAST-1-2 Динамическое сканирование выполняется вручную 3 - - T-PREPROD-DAST-2-1 Отключены неиспользуемые в сканере правила 4 - - T-PREPROD-DAST-2-2 Выполняется сканирование без аутентификации (с полным покрытием пользовательского интерфейса):
- Spider- сканирование (https://www.zaproxy.org/docs/desktop/addons/spider/)
- Сканирование зависимостей4 ST1.4 - T-PREPROD-DAST-2-3 Выполняется сканирование с аутентификацией:
- Выполняется сканирование зависимостей
- При сканировании происходит использование всех возможных ролей и пользовательских типов
- Поддержка существующих сессий
- При сканировании используются функции log in/log out
- Выполняется Spider-сканирование после аутентификации4 ST1.4 - T-PREPROD-DAST-2-4 Настроена интеграция сканера с инструментами CI/CD 4 - - T-PREPROD-DAST-3-1 Выполняется сканирование в том числе скрытых путей 5 - - T-PREPROD-DAST-3-2 Используются доработанные (кастомизированные) параметры при сканировании для максимального покрытия входных параметров 5 - - T-PREPROD-DAST-3-3 При сканировании используется бизнес-логика сканируемого приложения. Например, выполняется login, вносятся изменения в учетную запись, выполняется добавление товара в корзину и др. 5 - - T-PREPROD-DAST-3-4 Выполняется раздельное сканирование backend и frontend, включая:
- Сканирование SOAP сервисов
- Сканирование сервисов proxy, которые передают запросы между frontend и backend
- fuzzing XML и JSON данных, которые передаются в API сервисы5 ST2.6 - T-PREPROD-DAST-4-1 Выполняется сканирование всех путей и взаимодействий (в т.ч. с backend) 6 - - T-PREPROD-DAST-4-2 Используется несколько сканеров для увеличения поверхности сканирования и получения пересекающихся результатов 6 - - T-PREPROD-DAST-4-3 Используются custom профили для динамического тестирования с повышенной интенсивностью и тяжестью для критичных частей приложения 6 - -
Тестирование на проникновение перед внедрением приложений в продуктив
ID Описание Уровень зрелости BSIMM SAMM T-PREPROD-PENTEST-0-1 Применяется тестирование на проникновение в среде Preprod 0 - - T-PREPROD-PENTEST-1-1 Тестирование на проникновение в среде Preprod проводится регулярно 1 - ST-B-2 T-PREPROD-PENTEST-1-2 Проводятся пентесты Preprod среды методом "черный ящик" (пентестер не знает ничего об атакуемой Preprod среде, кроме базовой информации о ней - # доменные имена, ip-адреса) 1 - - T-PREPROD-PENTEST-1-3 Проводятся пентесты методом "серый ящик" (пентестер знает все об атакуемой Preprod среде - архитектуру среды и анализируемого ПО, их версии, имеет доступ к исходному коду ПО и пр.) 1 PT2.2 - T-PREPROD-PENTEST-2-1 Разработан и применяется регламент, описывающий проведение тестирования на проникновение в среде Preprod 2 - - T-PREPROD-PENTEST-4-1 Проводится анализ безопасности инструментов безопасной разработки (анализируются, например, инструменты SAST или OSA\SCA на предмет наличия в них уязвимостей или дефектов - можно ли без авторизации "украсть" отчеты, конфиги и пр) 6 - ST-B-1
Функциональное ИБ-тестирование
ID Описание Уровень зрелости BSIMM SAMM T-PREPROD-SECTEST-0-1 Выполняется тестирование ИБ функционала разрабатываемого ПО 0 - - T-PREPROD-SECTEST-1-1 Функциональное ИБ-тестирование проводится (ситуативно, нерегламентированно) 1 - RT-A-1 T-PREPROD-SECTEST-2-1 Разработан и применяется регламент, описывающий проведение функционального ИБ-тестирования 2 ST1.1 - T-PREPROD-SECTEST-2-2 Не менее 5% функциональных ИБ-тестов автоматизированы 2 ST2.5 RT-A-2 T-PREPROD-SECTEST-3-1 Более 20 % тестов функций ИБ-тестирования автоматизированы 6 ST2.5 -
Анализ инфраструктуры PREPROD среды на уязвимости
ID Описание Уровень зрелости BSIMM SAMM T-PREPROD-VULN-0-1 Сканирование инфраструктуры PREPROD (среды тестирования и разработки ПО) на уязвимости производится в каком бы то ни было виде 0 - Scalable Baseline T-PREPROD-VULN-1-1 Сканирование инфраструктуры PREPROD (среды тестирования и разработки ПО) на уязвимости производится периодически в ручном режиме при помощи инструментов автоматизации или скриптов. (ситуативно нерегламентированно) 2 - - T-PREPROD-VULN-1-2 Производится установка обновлений на элементы инфраструктуры, в т.ч. устранение выявленных уязвимостей 2 - - T-PREPROD-VULN-2-1 Выполняется регулярное сканирование наиболее критических компонентов инфраструктуры PREPROD (среды тестирования и разработки ПО) на уязвимости, а также выстроен процесс по их исправлению 4 - - T-PREPROD-VULN-2-2 Выполняется регулярное выполнение задач инвентаризации активов PREPROD (среды тестирования и разработки ПО) сред автоматизированными средствами 4 SM3.1
AM2.9- T-PREPROD-VULN-2-3 Обновления безопасности регулярно устанавливаются на основные элементы инфраструктуры PREPROD (среды тестирования и разработки ПО) (например, оркестратор и операционные систем серверов) 4 - - T-PREPROD-VULN-3-1 Выполняется регулярное сканирование всех компонентов инфраструктуры PREPROD (среды тестирования и разработки ПО), а также выстроен процесс по их исправлению 5 - - T-PREPROD-VULN-3-2 Выполняется автоматизированная проверка основных компонентов инфраструктуры PREPROD (среды тестирования и разработки ПО) (например, оркестратора и операционных систем серверов) на соответствие лучшим практикам, а также организован процесс по исправлению несоответствий 5 - - T-PREPROD-VULN-3-3 Выполняется регулярное сканирование на уязвимости инфраструктуры PREPROD (среды тестирования и разработки ПО) автоматизированными средствами в режиме пентеста 5 - - T-PREPROD-VULN-3-4 Обновления безопасности регулярно устанавливаются на все элементы инфраструктуры PREPROD (среды тестирования и разработки ПО) (например, оркестратор и операционные систем серверов) 5 - - T-PREPROD-VULN-4-1 Выполняется автоматизированная проверка всех компонентов инфраструктуры PREPROD (среды тестирования и разработки ПО) на соответствие лучшим практикам , а также организован процесс по исправлению несоответствий 7 - - T-PREPROD-VULN-4-2 Осуществляется регулярная замена устаревшего неподдерживаемого производителями ПО для компонентов инфраструктуры PREPROD (среды тестирования и разработки ПО) 7 - -
Контроль безопасности манифестов (k8s, terraform и т.д.)
ID Описание Уровень зрелости BSIMM SAMM T-PREPROD-MANSEC-0-1 Выполняется ИБ тестирование файлов конфигураций (Dockerfiles, K8s manifests, Terraform, etc) 0 - - T-PREPROD-MANSEC-1-1 Применяется анализ Dockerfile на наличие дефектов ИБ 2 - - T-PREPROD-MANSEC-2-1 Используется контроль конфигураций (k8s, IaC и т.п.) на наличие дефектов ИБ 3 SE2.2 -
Управление секретами
ID Описание Уровень зрелости BSIMM SAMM T-PROD-SM-0-1 Применяются практики управления секретами и защиты секретов 0 - - T-PROD-SM-1-1 Для управления секретами частично применяются встроенные механизмы ПО. Инструменты по управлению секретами не используются. 1 - - T-PROD-SM-1-2 Инциденты ИБ, связанные с использованием секретов, разрешаются совместно с владельцами систем. 1 CMVM1.1 - T-PROD-SM-2-1 Используются инструменты по управлению секретами, но их использование не регламентировано. 2 - - T-PROD-SM-2-2 При разборе событий ИБ, связанных с секретами, используется приоритизация (ранжирование) этих событий. Например, событию A присваивается более высокий приоритет при обработке, чем событию B. Правила приоритизации событий ИБ формализованы. 2 - - T-PROD-SM-3-1 Секреты всех сред (за исключением Dev сред) хранятся в системе управления секретами (допускается ситуативное использование hardcoded-секретов) 3 - - T-PROD-SM-3-2 Используется автоматизированная ротация секретов. 3 - - T-PROD-SM-3-3 Разработаны и применяются регламенты по использованию инструментов по управлению секретами 3 - - T-PROD-SM-4-1 Используются динамические секреты, генерируемые под каждую сессию взаимодействия систем 5 - - T-PROD-SM-4-2 Hardcoded секреты отсутствуют в продуктивной среде 5 - -
Тестирование на проникновение продуктивной среды
ID Описание Уровень зрелости BSIMM SAMM T-PROD-PENTEST-0-1 Проводится тестирование на проникновение в среде Prod 0 - - T-PROD-PENTEST-1-1 Проводятся пентесты Prod среды методом "черный ящик" (пентестер не знает ничего об атакуемой Prod среде, кроме базовой информации о ней - доменные имена, ip-адреса) 2 - - T-PROD-PENTEST-1-2 Тестирование на проникновение в среде Prod проводится регулярно 2 PT1.1 - T-PROD-PENTEST-1-3 Проводятся пентесты методом "серый ящик" (пентестер знает все об атакуемой Prod среде - архитектуру среды и анализируемого ПО, их версии, имеет доступ к исходному коду ПО и пр.) 2 PT2.2 - T-PROD-PENTEST-2-1 Разработан регламент, описывающий критерии и частоту проведения тестов на проникновение в среде PROD 3 - - T-PROD-PENTEST-3-1 Разработана и внедрена программа Bug bounty 4 CMVM3.4 - T-PROD-PENTEST-4-1 Проводятся пентесты вида "социальная инженерия", направленные и адаптированные на разработчиков 7 - - T-PROD-PENTEST-4-2 Проводятся Red Team \ Purple Team учения с привлечением разработчиков 7 PT3.1
CMVM3.3-
Динамический анализ приложений (DAST) в продуктивной среде
ID Описание Уровень зрелости BSIMM SAMM T-PROD-DAST-0-1 Применяются практики динамического тестирования (DAST) 0 - - T-PROD-DAST-1-1 Динамическое сканирование используется как минимум для пользовательского интерфейса 4 - - T-PROD-DAST-1-2 Используется пассивное сканирование с помощью зеркалирования трафика 4 - - T-PROD-DAST-1-3 Динамическое сканирование выполняется вручную 4 - - T-PROD-DAST-2-1 Используются механизмы активного и пассивного сканирования 5 - - T-PROD-DAST-2-2 Выполняется сканирование без аутентификации (с полным покрытием пользовательского интерфейса):
- Spider- сканирование (https://www.zaproxy.org/docs/desktop/addons/spider/)
- Сканирование зависимостей5 - - T-PROD-DAST-2-3 Выполняется сканирование с аутентификацией:
- Выполняется сканирование зависимостей
- При сканировании происходит использование всех возможных ролей и пользовательских типов
- Поддержка существующих сессий
- При сканировании используются функции log in/log out
- Выполняется Spider-сканирование после аутентификации5 - - T-PROD-DAST-2-4 Настроена интеграция сканера с инструментами CI/CD 5 - - T-PROD-DAST-2-5 Отключены неиспользуемые в сканере правила 5 - - T-PROD-DAST-3-1 Выполняется сканирование в том числе скрытых путей 6 - - T-PROD-DAST-3-2 Используются доработанные (кастомизированные) параметры при сканировании для максимального покрытия входных параметров 6 - - T-PROD-DAST-3-3 При сканировании используется бизнес-логика сканируемого приложения. Например, выполняется login, вносятся изменения в учетную запись, выполняется добавление товара в корзину и др. 6 - - T-PROD-DAST-3-4 Выполняется раздельное сканирование backend и frontend, включая:
- Сканирование SOAP сервисов
- Сканирование сервисов proxy, которые передают запросы между frontend и backend
- fuzzing XML и JSON данных, которые передаются в API сервисы6 ST2.6 - T-PROD-DAST-4-1 Выполняется сканирование всех путей и взаимодействий (в т.ч. с backend) 7 - - T-PROD-DAST-4-2 Используется несколько сканеров для увеличения поверхности сканирования и получения пересекающихся результатов 7 - - T-PROD-DAST-4-3 Используются custom профили для динамического тестирования с повышенной интенсивностью и тяжестью для критичных частей приложения 7 - -
Управление изменениями инфраструктуры и доступом к ней
ID Описание Уровень зрелости BSIMM SAMM T-PROD-ACCESS-0-1 Применяются практики автоматизации жизненного цикла инфраструктуры (например, подход IaC), а также необходимые меры защиты 0 - - T-PROD-ACCESS-1-1 Код инфраструктуры (IaC) хранится, в том числе, за пределами централизованного хранилища кода (SCM-системы) 1 - - T-PROD-ACCESS-1-2 Использование концепции Infrastructure as code. Продуктивная среда описана в виде кода, регулярно актуализируется и является воспроизводимой. 1 - - T-PROD-ACCESS-1-3 Реализован процесс контроля версий конфигурации инфраструктуры в виде кода (IaC) 1 - - T-PROD-ACCESS-1-4 Доступ к продуктивной среде предоставлен ограниченному числу доверенных пользователей 1 - - T-PROD-ACCESS-1-5 Запрещено использование паролей по умолчанию 1 - - T-PROD-ACCESS-2-1 Доступ к коду конфигурации инфраструктуры (файлам, описывающим IaC) предоставлен ограниченному числу пользователей 3 - - T-PROD-ACCESS-2-2 Настроен, включен и обрабатывается аудит любых изменений для конфигураций внедрения в любые среды 3 - - T-PROD-ACCESS-3-1 Автоматизация внедрения в любые непродуктивные среды 4 - - T-PROD-ACCESS-4-1 Автоматизация внедрения в любые продуктивные среды 7 - -
Контроль сетевого трафика (L4-L7)
ID Описание Уровень зрелости BSIMM SAMM T-PROD-NETWORK-0-1 Выполняется контроль сетевого трафика в PROD сегменте 0 - - T-PROD-NETWORK-1-1 Выполняется контроль сетевого трафика на уровне межсетевых экранов (L3/L4) в PROD сегменте 1 SE1.2 - T-PROD-NETWORK-1-2 PROD инфраструктура находится в выделенном сетевом сегменте 1 - - T-PROD-NETWORK-2-1 Настроены и используются глобальные сетевые политики на уровне сред контейнеризации 2 - - T-PROD-NETWORK-2-2 Настроены и используются L7 сетевые политики контроля трафика 2 SE1.1 - T-PROD-NETWORK-3-1 Настроены и используются кастомизированные сетевые политики для различных микросервисов (namespace) 3 - -
Контроль выполняемых и процессов и их прав доступа
ID Описание Уровень зрелости BSIMM SAMM T-PROD-RUN-0-1 Выполняется контроль и защита исполняемых процессов 0 - - T-PROD-RUN-1-1 Используются средства контроля Runtime для сред контейнеризации (Kyverno, OPA gatekeeper, pod security admission, другие валидаторы) со стандартными настройками 2 - - T-PROD-RUN-2-1 Используются кастомизированные политики Runtime для сред контейнеризации, как минимум уровня всего кластера 3 - - T-PROD-RUN-3-1 Настроены и используются кастомизированные Runtime политики для отдельных контейнерных приложений 5 SE3.3 -
Анализ инфраструктуры PROD среды на уязвимости
ID Описание Уровень зрелости BSIMM SAMM T-PROD-VULN-0-1 Применяется сканирование инфраструктуры на уязвимости в Prod сегменте 0 - - T-PROD-VULN-1-1 Сканирование инфраструктуры на уязвимости проводится, как минимум, вручную и ситуативно 1 - - T-PROD-VULN-1-2 Производится установка обновлений на элементы инфраструктуры, в т.ч. устранение выявленных уязвимостей 1 - - T-PROD-VULN-2-1 Выполняется регулярное сканирование компонентов инфраструктуры PROD, обеспечивающей доступ пользователем из сети Интернет на уязвимости, а также выстроен процесс по их исправлению 2 - - T-PROD-VULN-2-2 Выполняется регулярное выполнение задач инвентаризации активов PROD автоматизированными средствами 2 SM3.1
AM2.9
CMVM2.3- T-PROD-VULN-2-3 Обновления безопасности регулярно устанавливаются на основные элементы инфраструктуры PROD (например, оркестратор и операционные систем серверов) 2 - - T-PROD-VULN-3-1 Выполняется регулярное сканирование всех компонентов инфраструктуры PROD, а также выстроен процесс по их исправлению 3 CMVM3.5 - T-PROD-VULN-3-2 Выполняется автоматизированная проверка основных компонентов инфраструктуры PROD (например, оркестратора и операционных систем серверов) на соответствие лучшим практикам, а также организован процесс по исправлению несоответствий 3 CMVM3.5 - T-PROD-VULN-3-3 Выполняется регулярное сканирование на уязвимости инфраструктуры PROD автоматизированными средствами в режиме пентеста 3 CMVM3.5 - T-PROD-VULN-3-4 Обновления безопасности регулярно устанавливаются на все элементы инфраструктуры PROD (например, оркестратор и операционные систем серверов) 3 - - T-PROD-VULN-4-1 Выполняется автоматизированная проверка всех компонентов инфраструктуры PROD на соответствие лучшим практикам, а также организован процесс по исправлению несоответствий 5 CMVM3.5 - T-PROD-VULN-4-2 Осуществляется регулярная замена устаревшего неподдерживаемого производителями ПО в инфраструктуре PROD 5 - -
Анализ событий информационной безопасности
ID Описание Уровень зрелости BSIMM SAMM T-PROD-EVENTS-0-1 Собираются (хоть какие-то) события от элементов PROD инфраструктуры 0 - - T-PROD-EVENTS-2-1 Разработана и применяется политика аудита в PROD инфраструктуре (например, Kubernetes Audit policy). Логи собираются, но не обрабатываются (например, хранятся внутри кластера Kubernetes) 2 - - T-PROD-EVENTS-3-1 Все логи PROD инфраструктуры (например, Kubernetes) обрабатываются в SIEM, созданы правила корреляции в SIEM для идентификации инцидентов 3 SE3.3
CMVM1.1-
Обучение специалистов
ID Описание Уровень зрелости BSIMM SAMM P-EDU-AWR-0-1 Производится обучение разработчиков в части ИБ 0 - Training and Awareness
Organization and CultureP-EDU-AWR-1-1 В Компании есть базовый тренинг по ИБ 1 - TA-A-1 P-EDU-AWR-1-2 Обучение по ИБ для команд разработки осуществляется ситуативно 1 - - P-EDU-AWR-2-1 Проводятся регулярные тренинги по ИБ для всех разработчиков (внешний, внутренний, электронный тренинг) 3 T1.1
T2.9- P-EDU-AWR-2-2 Процесс обучения для разработчиков формализован (например, существует Регламент повышения осведомленности в области безопасной разработки) 3 - - P-EDU-AWR-2-3 Проводятся специализированные тренинги по ИБ для Security Champion 3 T2.5
T2.9- P-EDU-AWR-2-4 Внедрена и используется специализированная централизованная платформа для проведения обучения по ИБ 3 - TA-A-3 (+-) P-EDU-AWR-3-1 В Компании внедрена и работает программа поощрения внутреннего обмена опытом 5 T2.12 TA-B-3 P-EDU-AWR-3-2 В Компании разработана и внедрена система мотивации сотрудников за прохождение ИБ обучения 5 T3.1 - P-EDU-AWR-4-1 Команда ИБ регулярно участвует в CTF-like соревнованиях (или тренируется в кибер-полигоне) в контексте Web, SSDLC 6 - -
Управление базой знаний DSO
ID Описание Уровень зрелости BSIMM SAMM P-EDU-KB-0-1 Существуют внутренние информационные ресурсы (базы знаний) с правилами и рекомендациями по безопасной разработке 0 - Architecture Design P-EDU-KB-1-1 Существуют локальные базы знаний у участников разработки в рамках одной команды 1 - - P-EDU-KB-2-1 Существует централизованный ресурс (общая база знаний), хранящий базовые правила и рекомендации по безопасной разработке 3 SM1.1
SR1.1
SR1.2- P-EDU-KB-2-3 Единая база знаний обновляется (нерегулярно, ответственные формально не выделены, QA не проводится) 3 SR1.1
SR1.2- P-EDU-KB-3-1 Централизованный ресурс (общая база знаний), хранит единые детальные правила и рекомендации по безопасной разработке, относящиеся, как к компании в целом, так и к отдельным командам разработки 4 SR1.2
SR3.3- P-EDU-KB-3-2 Единая база знаний обновляется регулярно, назначены ответственные за ее обновление как внутри команд, так и в компании, выполняется QA созданные материалов в базе знаний 4 SR1.2
SR2.2- P-EDU-KB-4-1 Разработаны и внедрены стандарты написания документации, единая база знаний следует таким стандартам и содержит необходимый комплект документов и информации к разрабатываемому ПО 5 - -
Оценка критичности приложений и моделирование угроз
ID Описание Уровень зрелости BSIMM SAMM P-REQ-TM-0-1 Выполняется оценка критичности и/или моделирование угроз для разрабатываемых приложений 0 - Threat Modeling
Architecture MitigationP-REQ-TM-1-1 Проводится моделирование угроз по требованиям compliance (например, для ПО для ЗОКИИ) или для наиболее критичных 2 - ARP-B-1
TA-B-1 (новое название)P-REQ-TM-1-2 Определены формальные критерии критичности приложений 2 AA1.4 ARP-A-1, ARP-B-2 P-REQ-TM-1-3 Для всех новых разрабатываемых приложений проводится оценка критичности 2 AA1.4 - P-REQ-TM-2-1 Модели угроз разрабатываются в том числе и для технических средств 3 - - P-REQ-TM-2-2 Моделирование угроз осуществляется для ВСЕХ НОВЫХ приложений 3 AA1.1 - P-REQ-TM-2-3 Оценка критичности выполняется для всех приложений 3 AA1.4 ARP-A-2 P-REQ-TM-3-1 Модели угроз разрабатываются в том числе и для бизнес-процессов 4 - - P-REQ-TM-3-2 Процесс моделирования угроз для разрабатываемого ПО стандартизован (есть шаблоны МУиМН, определены подходы к актуализации угроз и пр) 4 AM1.3
AA2.1
AA2.2- P-REQ-TM-3-3 Модели угроз регулярно пересматриваются 4 - ARP-A-3
TA-B-3 (новое название)P-REQ-TM-4-1 К каждому разрабатываемому ПО определены "Abuse cases" (сценарии нелегитимного использования ПО), такие кейсы учитываются при моделировании угроз и доработке ПО 5 AM2.1 RT-B-2
Определение требований ИБ, предъявляемых к ПО
ID Описание Уровень зрелости BSIMM SAMM P-REQ-RD-0-1 К разрабатываемым приложениям предъявляются требования по информационной безопасности 0 - - P-REQ-RD-1-1 Разработаны и предъявляются базовые требования по ИБ к разрабатываемому ПО 1 - RT-A-1 P-REQ-RD-1-2 Подразделение ИБ одобряет\согласовывает решения, которые влияют на уровень ИБ разрабатываемого приложения 1 - - P-REQ-RD-2-1 Дополнительные требования по ИБ формируются с учетом актуальных угроз по результатам моделирования угроз 2 - - P-REQ-RD-2-2 Требования по ИБ стандартизованы (например, разработаны чеклисты) 2 - SA-A-1 P-REQ-RD-2-3 Подразделения ИБ участвуют в создании архитектуры разрабатываемого ПО 2 SFD1.2 - P-REQ-RD-3-1 Дополнительные требования по ИБ формируются с учетом актуальных угроз для бизнес-функций (по результатам соответствующего моделирования угроз) 4 - - P-REQ-RD-3-2 Дополнительные требования по ИБ формируются с учетом результатов анализа рисков 4 - - P-REQ-RD-3-3 Ключевые решения, которые влияют на уровень ИБ разрабатываемого приложения, принимаются на архитектурном комитете 4 - -
Контроль выполнения требований ИБ
ID Описание Уровень зрелости BSIMM SAMM P-REQ-CR-0-1 Контролируется выполнение требований ИБ к разрабатываемому ПО 0 CP2.3 Software Requirements
Architecture ValidationP-REQ-CR-1-1 Требования ИБ к разрабатываемому ПО проверяются на этапе выпуска ПО в продуктовую среду 1 SM1.4
CP2.3- P-REQ-CR-2-1 Осуществляется контроль выполнения требований ИБ к разрабатываемому ПО посредством функциональных тестирований ИБ и тестирований на проникновение 2 SM1.4
CP2.3
ST1.3- P-REQ-CR-3-1 Производится валидация отсутствия уязвимостей в программном коде ПО (например, применение Quality gates, которые зафиксированы в документе) 5 SM1.4
SM2.2- P-REQ-CR-4-1 Производится проверка и согласование технического задания и проекта архитектуры, разработанных с учетом требований ИБ 6 SM1.4 -
Разработка стандартов конфигураций разрабатываемого ПО
ID Описание Уровень зрелости BSIMM SAMM P-REQ-STDR-App-0-1 Создаются стандарты конфигурирования разрабатываемого ПО 0 - Configuration Hardening P-REQ-STDR-App-1-1 Стандарты конфигурирования разрабатываемого ПО есть, но не формализованы (т.е. это НЕ стандарты, а рекомендации или легаси настройки) 3 - - P-REQ-STDR-App-1-2 Стандарты конфигурирования (рекомендации, легаси настройки) разрабатываемого ПО применяются вручную 3 - - P-REQ-STDR-App-2-1 Стандарты конфигурирования разрабатываемого ПО разработаны для ключевых систем 4 - - P-REQ-STDR-App-3-1 Разработаны и применяются для всех систем 5 - - P-REQ-STDR-App-3-3 Использование подхода IaC 5 - - P-REQ-STDR-App-4-1 Выполняется регулярное обновление профилей конфигурирования с учетом risk-based approach 6 - -
Разработка стандартов конфигураций для компонентов инфраструктуры
ID Описание Уровень зрелости BSIMM SAMM P-REQ-STDR-Infr-0-1 Создаются стандарты конфигурирования компонентов инфраструктуры 0 - Configuration Hardening P-REQ-STDR-Infr-1-1 СККИ есть, но не формализованы (т.е. это НЕ стандарты, а рекомендации или легаси настройки) 1 - - P-REQ-STDR-Infr-1-2 СККИ (рекомендации, легаси настройки) применяются вручную 1 - - P-REQ-STDR-Infr-2-1 СККИ разработаны для ключевых инфраструктурных систем 2 SR3.4 - P-REQ-STDR-Infr-2-2 Производится выборочный контроль применения СККИ (без использования средств автоматизации) 2 - - P-REQ-STDR-Infr-3-1 Разработаны и применяются для всех систем 3 SR3.4 - P-REQ-STDR-Infr-3-2 Используются автоматизированные средства контроля применения СККИ 3 - - P-REQ-STDR-Infr-3-3 Использование подхода IaC 3 - - P-REQ-STDR-Infr-4-1 Регулярное обновление СККИ с учетом risk-based approach 5 - -
Обработка дефектов ИБ
ID Описание Уровень зрелости BSIMM SAMM P-DEFECT-MNG-0-1 Выполняется контроль устранения дефектов ИБ 0 - Defect Tracking P-DEFECT-MNG-1-1 Обработка дефектов разрабатываемого ПО осуществляется при необходимости (onDemand, ситуативно, отсутствует системный подход) 1 - - P-DEFECT-MNG-2-1 Все дефекты критического уровня обрабатываются в приоритетном порядке 2 - - P-DEFECT-MNG-2-2 Поиск дефектов автоматизирован и является частью CI\CD 2 SM3.4 BP-A-3 P-DEFECT-MNG-3-1 Для каждого дефекта ИБ создается задача в Task tracker (например, в Jira). Осуществляется контроль устранения дефекта (выполнения задачи) 3 PT1.2
CMVM1.3
CMVM3.1Incident Detection
Incident ResponseP-DEFECT-MNG-3-2 Внедрен и контролируется SLA по исправлению дефектов ИБ 3 - - P-DEFECT-MNG-3-3 На QG проверяется отсутствие дефектов заданного уровня критичности (и это является критерием прохождения QG) 3 SM2.2 - P-DEFECT-MNG-4-1 Дефекты обрабатываются в соответствии с risk-based approach 7 - -
Консолидация дефектов ИБ
ID Описание Уровень зрелости BSIMM SAMM P-DEFECT-CNS-0-1 Выполняется централизованное хранение и обработка отчетности по найденным дефектам ИБ 0 - - P-DEFECT-CNS-1-1 Внедрено и используется централизованное хранилище отчетов по дефектам ИБ разрабатываемого ПО 3 CR2.8 - P-DEFECT-CNS-1-2 Отчетность выгружается и хранится централизовано для ряда проверок\инструментов 3 - - P-DEFECT-CNS-2-1 Отчетность выгружается и хранится централизовано для всех проверок\инструментов, которые есть в Компании и которые анализируют разрабатываемое ПО 4 CR2.8 - P-DEFECT-CNS-3-1 Внедрена и используется SGRC для управления отчетами 5 SM3.1 - P-DEFECT-CNS-3-2 Отчеты загружаются в SGRC в ручном режиме 5 SM3.1
CR2.8- P-DEFECT-CNS-4-1 Отчеты загружаются в SGRC в автоматическом режиме 6 SM3.1
CR2.8- P-DEFECT-CNS-4-2 Существует перечень ответственных за работу с дефектами, описаны пути эскалаций устранения дефектов ИБ 6 - -
Управление набором метрик ИБ
ID Описание Уровень зрелости BSIMM SAMM P-MET-SET-0-1 Метрики процессов DSO не разработаны 0 - Measure and Improve P-MET-SET-2-1 Определены и описаны метрики процессов DSO 3 SM3.3 SM-B-1 P-MET-SET-2-2 Определены целевые значения по каждой метрике процессов DSO 3 - SM-B-2 P-MET-SET-3-1 Выполняется регулярный пересмотр собираемых метрик процессов DSO 4 SM3.3 - P-MET-SET-3-2 Выполняется регулярная корректировка целевых значений 4 - -
Контроль исполнения метрик
ID Описание Уровень зрелости BSIMM SAMM P-MET-EX-0-1 Выполняется контроль метрик DSO 0 - Metrics and Feedback P-MET-EX-2-1 Выполняется сбор и анализ метрик процессов DSO 3 SM3.3 - P-MET-EX-2-2 Выполняется формирование отчетов и сравнение результатов метрик процессов DSO с целевыми показателями 3 - SM-B-3 P-MET-EX-3-1 Сбор и анализ метрик для всех команд 4 - - P-MET-EX-3-2 Проводится регулярная оценка эффективности реализуемых мероприятий на основе собираемых метрик процессов DSO 4 - - P-MET-EX-3-3 Выполняется визуализация результатов сбора метрик процессов DSO (формирование дашбордов. Например, в Grafana) 4 SM2.1 - P-MET-EX-4-1 Производится модернизация и совершенствование бизнес-процессов на основании собираемых метрик процессов DSO. Есть такие примеры (или же описан где-то такой процесс) 6 CP3.3 -
Security Champions
ID Описание Уровень зрелости BSIMM SAMM P-ROLE-SC-0-1 Используются практики Security Champion - регулярное взаимодействие с командами разработки по вопросам ИБ 0 SM2.3 Training and Awareness
Organization and CultureP-ROLE-SC-1-1 Функции Security Champion выполняются, как минимум, специалистами ИБ 1 - - P-ROLE-SC-2-1 В команде\проекте есть выделенный security champion 3 - TA-B-1 P-ROLE-SC-2-2 Security Champion продвигает внутри команды лучшие практики в части безопасной разработки, делится с командами AppSec данными об уязвимостях и новых методах и практиках ИБ 3 - - P-ROLE-SC-3-1 Security Champion проводит R&D работу в части использования новых инструментов ИБ и отчитывается о результатах AppSec команде 4 - - P-ROLE-SC-3-2 Security Champion поддерживает используемые в цикле безопасной разработки инструменты ИБ в актуальном состоянии 4 CR1.7 - P-ROLE-SC-3-3 Security Champion проводит проверку безопасности кода в своей области экспертизы 4 - - P-ROLE-SC-3-4 Security Champion участвует в разработке PoC и тестировании новых инструментов ИБ 4 - - P-ROLE-SC-4-1 Security Champion проводит тренинги по безопасной разработке и ИБ в целом для новых разработчиков 7 Т1.8 - P-ROLE-SC-4-2 Security Champion работает до 3х месяцев в команде AppSec в рамках практик ротации работников 7 - - P-ROLE-SC-4-3 Security champion проводит проверки (review) моделей угроз, безопасного дизайна, а также peer-review работ, выполненных другими security champion 7 - - P-ROLE-SC-4-4 Security champion выполняет PoC для новых эксплойтов, а также проверку приложений на выполнение требований по ИБ 7 - -
Разграничение ролей процесса DSO
ID Описание Уровень зрелости BSIMM SAMM P-ROLE-RESP-0-1 Существует разграничение ролей процесса безопасной разработки 0 - - P-ROLE-RESP-1-1 В подразделении ИБ определены специалисты, отвечающие за безопасность разрабатываемого ПО (в дополнение к другой деятельности) 1 - - P-ROLE-RESP-1-2 Обязанности и ответственность за безопасность разрабатываемого ПО закреплены формально (приказ, должностная инструкция и пр.) 1 - - P-ROLE-RESP-2-1 Выделены сотрудники ИБ (роли), основной обязанностью которых является безопасность разработки (DSO) 3 - - P-ROLE-RESP-2-2 Сформирована матрица ролей в части DSO 3 - - P-ROLE-RESP-2-3 Разработан и введен в действие регламент безопасной разработки 3 - - P-ROLE-RESP-3-1 Разработана и используется RACI-матрица для всего процесса DSO 4 - -