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

Куда я попал?

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

Подробнее

Наш канал

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

Framework

Организационно-распорядительная документация

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

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

PreStageSDL
Процесс: Планирование
Практика: Организационно-распорядительная документация
Инициатива: Политика безопасной разработки
Описание:
Политика безопасной разработки — документ, регламентирующий деятельность организации в области обеспечения безопасности разрабатываемого программного обеспечения. Этот документ устанавливает систему правил, принципов и практик, направленных на интеграцию мер безопасности во все этапы жизненного цикла разработки ПО. Ключевая цель политики заключается в формировании устойчивой культуры безопасности, обеспечивающей минимизацию уязвимостей и рисков на всех этапах создания и эксплуатации программных продуктов.
В документе:
- Особое внимание уделяется принципам безопасной эксплуатации приложений в соответствии с установленными нормативными требованиями [TMR3].
Шаги реализации:
1. Определить цели, задачи и области действия политики.
2. Сформировать рабочую группу с участием представителей команд разработки, безопасности, юристов и других заинтересованных сторон.
3. Изучить отраслевые стандарты и рекомендации, релевантные для организации.
4. Описать основные принципы, цели и обязательства компании в области безопасности ПО.
5. Детализировать требования к различным практикам SSDL, включая:
  управление рисками безопасности;
  безопасное проектирование и разработку;
  тестирование безопасности на всех этапах;
  управление уязвимостями;
  реагирование на инциденты безопасности и т. д.
6. Четко определить роли и ответственных за выполнение требований.
7. Согласовать и обеспечить официальное утверждение политики руководством организации.
8. Довести политику до сотрудников и разместить ее описание на внутреннем портале.
9. Провести анализ существующих процессов разработки, выявить и внедрить необходимые изменения для соответствия политике.
10. Разработать или адаптировать шаблоны документации (например, модель угроз) для соответствия требованиям политики.
11. Внедрить метрики для оценки эффективности политики и отслеживания прогресса.
12. Пересматривать и актуализировать политику не реже одного раза в год или при значительных изменениях в законодательстве, технологиях, угрозах безопасности.
Зона ответственности: AppSec
Инструмент: -
Артефакт: Политика безопасной разработки
Инициатива: Категоризация ИС
Описание:
Методика ранжирования ПО обеспечивает структурированную классификацию приложений по уровню критичности и их категоризацию на основе определенных критериев и особенностей (влияние на бизнес, обрабатываемые данные, количество пользователей и т. д.). Данный подход служит инструментом для целенаправленного применения стратегии безопасной разработки и ее поэтапного тиражирования [SSDL4], а также способствует повышению осведомленности сотрудников о специфике разрабатываемых приложений. Четкое понимание характеристик, критичности и потенциальных рисков, связанных с каждым приложением, позволяет сосредоточить усилия на наиболее уязвимых местах и принять оптимальные решения для обеспечения
безопасности.
Информация, полученная в результате ранжирования, может быть включена в паспорт системы [IA1] для обеспечения централизованного хранения и доступа к данным о профилях безопасности приложений.
Шаги реализации:
1. Четко сформулировать цели классификации приложений: оптимизация ресурсов на безопасность, приоритизация внедрения практик SSDL и т. д.
2. Определить критерии, на основе которых будет проводиться ранжирование.
3. Разработать шкалу критичности: низкий, средний, высокий, критический уровень и т. п.
4. Описать характеристики приложений, соответствующие каждому уровню критичности.
5. При необходимости разработать дополнительные категории для группировки приложений по специфике (фронтенд/бэкенд, мобильные/веб-приложения и др.).
6. Формализовать и задокументировать методику ранжирования как пошаговую инструкцию по оценке и классификации приложений.
7. Определить ответственных за проведение ранжирования.
8. Протестировать методику на небольшом количестве приложений для выявления недостатков и корректировки.
9. Провести обучение сотрудников по применению методики.
10. Осуществить ранжирование всех приложений, подпадающих под действие стратегии БР.
11. Включить информацию о критичности приложений в паспорт системы.
12. Довести информацию до сотрудников и разместить ее на внутреннем портале.
13. Использовать данные ранжирования при планировании и реализации мероприятий по обеспечению безопасности разработки.
14. Периодически пересматривать и актуализировать методику с учетом изменений в бизнесе, технологиях и требованиях безопасности.
Зона ответственности: AppSec
Инструмент: -
Артефакт: Методика критичности/ приоритизации приложений
Инициатива: Регламент безопасной разработки
Описание:
Регламент безопасной разработки выступает в качестве практического руководства, детализирующего положения и принципы, определенные в политике БР [OAD1]. Если политика отвечает на вопрос «Что нужно делать?», то регламент раскрывает, как именно это делать. В документе подробно описываются конкретные шаги, последовательность действий, взаимосвязь практик, распределение ролей и ответственности.
Для наглядности и полноты изложения регламент может дополняться описанием практик и задач, процессными картами, инструкциями и другими приложениями, облегчающими внедрение и соблюдение требований безопасности.
Шаги реализации:
1. Проанализировать политику безопасной разработки, чтобы четко понимать контекст, цели и общие требования к БР.
2. Определить, для кого предназначен регламент (разработчики, тестировщики, специалисты по безопасности, руководители проектов и т. д.), чтобы адаптировать язык и уровень детализации.
3. Продумать логическую структуру документа, чтобы обеспечить его доступность и удобство использования.
4. Разделить каждый процесс, обозначенный в политике, на конкретные шаги и описать их.
5. Определить ролевую модель и четко указать, кто и за что отвечает в каждом процессе.
6. Предоставить информацию об инструментах и технологиях для реализации практик безопасности.
7. Дополнить текстовое описание схемами, диаграммами, таблицами и другими визуальными элементами для лучшего восприятия материала (например, наглядными процессными картами, отражающими последовательность действий и взаимодействие участников в рамках БР).
8. Разработать шаблоны документов (плана тестирования безопасности и т. п.) и чек-листы, которые помогут сотрудникам следовать требованиям регламента.
9. Дополнить внутренний портал безопасности вспомогательной информацией, примерами, рекомендациями по БР.
10. Довести регламент до сотрудников и разместить его на внутреннем портале.
11. Утвердить документ и внедрить процедуры контроля за соблюдением требований регламента — например, в рамках внутренних аудитов.
12. Установить периодичность пересмотра и актуализации регламента с учетом изменений в законодательстве, стандартах, технологиях и угрозах безопасности.
Зона ответственности: AppSec
Инструмент: -
Артефакт: Регламент безопасной разработки
Инициатива: Документирование процесса
Описание:
Четкая структуризация позволяет выстроить процесс разработки предсказуемым, управляемым и безопасным. Единые инструкции, регламенты, описания методологий и этапов разработки [TP3] сделают процесс прозрачным и понятным для всех участников, упростят анализ, аудит и контроль, а также минимизируют риски за счет устранения хаоса и внедрения единых стандартов. Более того, формализация способствует автоматизации и ускорению разработки, а также облегчает внедрение изменений, в том числе новых практик безопасной разработки [SSDL2].
Шаги реализации:
1. Проанализировать, как организована разработка в настоящее время, какие методологии и инструменты применяются.
2. Оценить, насколько в целом формализован текущий процесс разработки и какие его аспекты требуют внимания в первую очередь.
3. Детально описать каждый этап процесса разработки, включая цели, входные и выходные данные, ответственных, сроки и критерии успешного завершения.
4. Разработать документацию, регламентирующую выполнение каждого этапа, — например, инструкции по написанию кода, проведению тестирования, управлению версиями.
5. Использовать схемы, диаграммы, модели для наглядного представления процесса разработки и взаимосвязи между этапами.
6. Поэтапно внедрять формализованный процесс, начиная с отдельных команд или проектов, и по мере готовности распространять его на всю организацию.
7. Максимально автоматизировать рутинные операции и процессы: сбор требований, тестирование, сборку и развертывание ПО и т. д.
8. Довести информацию до сотрудников и разместить ее на внутреннем портале.
9. Внедрить механизмы контроля за соблюдением формализованного процесса разработки (регулярные аудиты, чек-листы, анализ метрик и др.).
Зона ответственности: ИТ
Инструмент: -
Артефакт: Артефакты процесса разработки. Описание конфигураций инфраструктуры
Инициатива: Контроль соблюдения правил ОРД
Описание:
Для достижения целевого уровня зрелости недостаточно просто разработать организационно-распорядительную документацию (ОРД). Эффективность и результативность обеспечиваются обязательным применением этих документов всеми сотрудниками компании. Необходимо внедрить механизмы контроля за неукоснительным соблюдением установленных правил и процедур на всех уровнях организационной структуры. Только при системном подходе к имплементации и контроле исполнения документация будет способствовать достижению желаемых результатов.
Шаги реализации:
Официально утвердить документы у руководства.
Обеспечить доступность документов для всех сотрудников в удобном формате (например, на внутреннем портале).
Ввести обязательное ознакомление с документами для всех, кого они касаются, с фиксацией в соответствующих журналах или системах.
Интегрировать требования документов в существующие процессы разработки, тестирования, внедрения и эксплуатации ПО.
Настроить используемые инструменты и системы (для управления проектами, версионного контроля и т. п.) таким образом, чтобы они поддерживали выполнение требований.
Разработать шаблоны документов и чек-листы, которые упростят сотрудникам выполнение требований и контроль за их соблюдением.
Отслеживать показатели соблюдения регламентов и требований (например, при помощи аудитов).
Зона ответственности: ИТ/AppSec
Инструмент: -
Артефакт: -

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