Соответствие требованиям

Куда я попал?

SECURITM это SGRC система, автоматизирующая процессы в службах информационной безопасности. SECURITM помогает построить и управлять ИСПДн, КИИ, ГИС, СМИБ/СУИБ, банковскими системами защиты.
А еще SECURITM это место для обмена опытом и наработками для служб безопасности.

Подробнее

Наш канал

AppSec Table Top: методология безопасной разработки от Positive Technologies

Framework

Сборка

Для проведения оценки соответствия по документу войдите в систему.

Список требований

MainStageSDL
Процесс: Сборка
Практика: Компонентный анализ
Инициатива: Использование инструментов SCA
Описание:
Инструмент компонентного анализа (SCA) позволяет проверить все компоненты и внешние зависимости приложения на этапе сборки на предмет наличия уязвимостей. Для корректной проверки формируется SBOM-файл (Software Bill of Materials) [SCA5] из исходного кода, в котором описываются все Open Source и другие сторонние компоненты, использующиеся в кодовой базе.
SBOM содержит информацию о версиях, лицензиях, уязвимостях, происхождении, дочерних зависимостях и других контекстных данных. Это позволяет идентифицировать уязвимые компоненты, проверить соблюдение лицензионных соглашений и управлять рисками, связанными с использованием сторонних компонент.
Шаги реализации:
1. Выбрать наиболее подходящий инструмент SCA с учетом функциональности, поддержки языков программирования и пакетных менеджеров, интеграции с существующими технологическим стеком, стоимости и соответствия требованиям.
2. Провести пилотирование выбранного инструмента, чтобы оценить его эффективность, удобство использования, соответствие требованиям.
3. Определить сотрудников, ответственных за внедрение, работу с инструментом и разбор результатов.
4. Установить и настроить инструмент SCA.
5. Интегрировать SCA в ограниченном количестве проектов (для первичного анализа и проверки работы инструмента).
6. Определить процессы разбора результатов: политики безопасности, исключения, периодичность проведения сканирования.
7. Провести первичное сканирования в заранее определенных проектах.
8. По результатам сканирования сформировать и разобрать технический долг.
9. Разработать регламент работы с инструментом (или дополнить регламент безопасной разработки), в которым будут описаны концепция работы и преимущества инструмента, инструкции и материалы по его использованию и т. д.
10. Довести регламент до сотрудников и разместить на внутреннем портале.
Зона ответственности: Appsec/ИТ
Инструмент: OSA/SCA
Артефакт: Регламент безопасной разработки
Инициатива: Кастомные правила SCA
Описание:
Для оптимизации работы с результатами сканирования SCA и повышения качества работы инструмента рекомендуется настроить кастомные правила проверки. Настройка исключений позволит игнорировать уязвимости, которые не применимы к конкретному приложению или не критичны для его функционирования (например, уязвимость, присутствующая в незаменимой компоненте).
В то же время политики безопасности позволяют внести дополнительные ограничения при проверке компонент, заточенные под специфику приложения (по дате обновления или имени автора). Такой подход позволяет сфокусировать внимание на действительно важных уязвимостях.
Шаги реализации:
Анализировать результаты сканирования SCA и идентифицировать уязвимости, которые не применимы к проверяемому приложению, или компоненты, которые не могут быть заменены без серьезных последствий.
Создать политики безопасности, которые вводят дополнительные требования к компонентам: требование обновления компонент до определенной версии или исключение компонент от конкретных разработчиков.
Создать правила исключения для конкретных уязвимостей или компонент, которые не применимы к проверяемому приложению.
Внедрить настроенные правила в процесс сканирования SCA.
Зона ответственности: Appsec/ИТ
Инструмент: OSA/SCA
Артефакт: -
Инициатива: SCA в пайплайне
Описание:
Необходимо интегрировать SCA-инструмент в CI/CD-конвейер в качестве обязательного этапа пайплайна. Автоматизация проверок SCA позволит сэкономить время сотрудников, гарантируя выполнение этого этапа тестирования при каждом релизе [PA3] и тем самым способствуя тиражированию стратегии [SSDL4]. Дополнительно к этому, использование Quality Gate [VC1] позволит задать четкие критерии качества кода, которые должны быть выполнены перед релизом, что поможет избежать выпуска уязвимого ПО в продакшн.
Шаги реализации:
1. Добавить SCA-инструмент как обязательный шаг в CI/CD-конвейер.
2. Определить триггеры для запуска SСA-инструмента: например, после каждого запуска сборки.
3. Установить правила и пороговые значения для SСA-анализа: например, уровень серьезности уязвимостей, которые должны быть исправлены.
4. Внедрить Quality Gate в CI/CD-пайплайн для оповещений при выявлении критических уязвимостей.
5. Связать инструмент SCA с дефект-трекером для автоматического создания задач по исправлению уязвимостей.
6. Установить SLA на устранение дефектов.
7. Дополнить регламент работы с инструментом (или регламент безопасной разработки).
8. Довести регламент до сотрудников и разместить на внутреннем портале.
9. На более зрелом этапе развития перевести QG из режима оповещений в режим блокировки.
Зона ответственности: Appsec/ИТ
Инструмент: OSA/SCA, CI/CD
Артефакт: Регламент безопасной разработки
Инициатива: Оркестрация SCA
Описание:
Оркестратор позволяет автоматизировать и централизовать запуск всех инструментальных практик безопасной разработки, предоставляя единый интерфейс для управления и удобный доступ к найденным дефектам [VM1]. Это позволяет упростить процесс и создать единый «пункт управления» для всех инструментов безопасности. Кроме того, многие решения ASOC (Application Security Orchestration and Correlation) позволяют собирать метрики о работе инструментов [RM3], что помогает оценивать эффективность и повышать качество безопасности приложений.
Шаги реализации:
1. Провести анализ текущих инструментов БР, их функциональности, интеграционных возможностей и существующих проблем.
2. Определить ключевые задачи, которые должен решать оркестратор: автоматизация запуска, централизованный доступ к результатам, создание отчетов, интеграция с системами CI/CD.
3. Выбрать наиболее подходящий инструмент ASOC с учетом функциональности, интеграции с существующими технологическим стеком и инструментами безопасной разработки, стоимости и соответствия требованиям.
4. Провести пилотирование выбранного инструмента, чтобы оценить его эффективность, удобство использования, соответствие требованиям.
5. Определить сотрудников, ответственных за внедрение, работу с инструментом и разбор результатов.
6. Установить выбранный оркестратор и настроить интеграцию с инструментами БР.
7. Создать правила и политики для автоматизации запуска инструментов.
8. Интегрировать ASOC в CI/CD-пайплайн и определить тригеры для запуска инструментов.
9. Интегрировать ASOC с средствами разработки: Git, репозитории, артефактории и т. д.
10. Настроить систему сбора и анализа данных о работе инструментов и результатах сканирования.
11. Создать документацию по работе с инструментом, дополнить регламент безопасной разработки.
12. Довести документацию до сотрудников и разместить на внутреннем портале.
Зона ответственности: Appsec/ИТ
Инструмент: OSA/SCA, ASOC
Артефакт: Регламент безопасной разработки
Инициатива: Требования к инвентаризации
Описание:
Инвентаризация используемых компонент и зависимостей (как собственных, так и сторонних) проводится в масштабах всей организации и отдельных приложений. Инвентаризация дает полное представление обо всех используемых компонентах и способствует стандартизации их использования (что упрощает разработку и поддерживает повторное использование проверенных компонент).
Инвентаризация создает основу для быстрого и эффективного компонентного анализа [SCA1]. Кроме того, она позволяет эффективно управлять зависимостями между компонентами и предотвращать конфликты версий или нежелательные взаимодействия.
Шаги реализации:
1. Выбрать инструмент для инвентаризации: существуют различные решения, включая инструменты SCA и другие специализированные варианты.
2. Создать централизованное хранилище информации о всех используемых компонентах, включая их версии, лицензии и иные релевантные данные.
3. Автоматизировать обновление инвентаризации, чтобы она была актуальной и отражала все изменения в используемых компонентах.
4. Использовать результаты инвентаризации как документацию по разрабатываемым приложениям (паспорт системы).
5. Довести документацию до сотрудников и разместить на внутреннем портале.
Зона ответственности: ИТ
Инструмент: OSA/SCA
Артефакт: SBOM
Практика: Безопасность сборки
Инициатива: Подпись артефактов
Описание:
Подпись артефактов гарантирует целостность артефакта и подтверждает его происхождение.
Ключевые аспекты подписи артефактов:
Целостность: подпись артефакта позволяет убедиться, что он не был изменен с момента его создания.
Происхождение: подпись артефакта содержит информацию о его происхождении (кем, где, когда и как он был создан и модифицирован).
Доверие: подпись артефакта повышает доверие к нему, так как подтверждает его аутентичность и целостность.
Подпись, как правило, осуществляется на этапе сборки (например, при создании пакета приложения) и используется в дальнейшем на этапе развертывания.
Шаги реализации:
Выбрать алгоритм подписи в зависимости от требований ИБ и используемого технологического стека.
Выбрать и настроить инструмент подписи в соответствии с алгоритмом.
Подготовить артефакт к подписанию — это может включать в себя сжатие, хеширование или другие операции.
Сгенерировать секретный ключ — он должен быть надежно защищен от несанкционированного доступа, рекомендуется использовать специализированные системы управления ключами.
На этапе развертывания проверять артефакт, используя публичный ключ, связанный с секретным (проверка подписи позволяет убедиться, что артефакт не был изменен с момента его подписания).
Интегрировать подпись артефактов в пайплайн разработки для автоматизации процесса.
Задокументировать процесс создания и проверки подписи, включая используемые инструменты и шаги.
Довести документацию до сотрудников и разместить на внутреннем портале.
Зона ответственности: ИТ
Инструмент: Платформа сборки
Артефакт: Артефакты процесса разработки
Инициатива: Настройка платформы сборки
Описание:
Платформа сборки может состоять из репозиториев исходного кода, артефакториев, процессов непрерывной интеграции/доставки и т. д. Каждая система в конвейере может содержать уязвимости или иметь неправильную конфигурацию [CNFG1], что повышает риск атак на цепочку поставок.
Для обеспечения безопасности сборки платформа должна:
- Предоставлять возможность подписи артефактов [SCS1].
- Хранить подробную информацию о сборках (включая список использованных зависимостей, коммиты исходного кода, конфигурацию сборки).
- Выполнять все сборки в новой изолированной среде, чтобы в случае компрометации одной сборки она не влияла на остальные.
Шаги реализации:
1. Изучить требования к безопасности платформы сборки, включая требования к подписи артефактов, хранению информации о сборках, использованию изолированных сред и т. д.
2. Обозначить правила и процедуры безопасности платформы сборки.
3. Выбрать подходящие инструменты для обеспечения сборки и настроить их в соответствии с требованиями безопасности.
4. Создать хранилище для хранения информации о сборках, включая метаданные, логи и артефакты.
5. Убедиться, что доступ к платформе сборки имеют только авторизованные пользователи.
6. Регулярно обновлять платформу сборки и ее компоненты для устранения уязвимостей и обеспечения актуальности защитных мер.
7. Задокументировать процесс сборки и настройки конфигурации платформы сборки.
8. Довести документацию до сотрудников и разместить на внутреннем портале.
Зона ответственности: ИТ
Инструмент: Платформа сборки
Артефакт: Артефакты процесса разработки

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