Куда я попал?
AppSec Table Top: методология безопасной разработки от Positive Technologies
Framework
Стратегия SSDL
Для проведения оценки соответствия по документу войдите в систему.
Список требований
-
Инициатива: Определение перечня внедряемых практик
Описание:
Для внедрения безопасной разработки формируется перечень необходимых практик. Он составляется на основе анализа:- Технического задания (ТЗ) или технических требований (ТТ): требований к безопасности, заложенных в самом проекте.
- Существующих инициатив: какие практики безопасности уже применяются в организации.
- Целевого состояния SSDL [SSDL1]: желаемый уровень зрелости процессов БР.
При выборе практик важно учитывать покрытие слабых мест компании, специфику разработки, особенности принятых процессов, а также возможности с точки зрения бюджета, времени и компетенций.
Сформированный перечень практик служит основой для составления дорожной карты [SSDL3] по внедрению БР. Важно отметить, что этот перечень не статичен и может корректироваться по мере развития организации и изменения требований к безопасности [SSDL5].
Шаги реализации:- Изучить требования к безопасности, заложенные в ТЗ и (или) ТТ проекта.
- Определить специфические требования к безопасности, связанные с обработкой данных, средой эксплуатации, законодательными нормами.
- Составить перечень практик безопасности, которые уже применяются в организации.
- Оценить степень их формализации, покрытие этапов разработки и эффективность.
- Изучить описание целевого уровня зрелости процессов БР.
- Определить, какие практики необходимы для достижения этого уровня.
- Сформировать полный список практик, релевантных для организации.
- Оценить риски, связанные с каждой практикой (например, стоимость внедрения, сложность, влияние на сроки разработки).
- Учесть специфику разработки и ограничения: актуальность для компании, технологический стек, доступные ресурсы.
- Сформировать итоговый документ с описанием выбранных практик, их приоритетом, обоснованием выбора, а также планом по их внедрению (дорожная карта).
- Запланировать периодический пересмотр и корректировку перечня внедряемых практик с учетом изменений в бизнесе, технологиях, угрозах и других факторах.
Зона ответственности: AppSec
Инструмент: -
Артефакт: - -
Инициатива: Разработка дорожной карты
Описание:
Создание дорожной карты внедрения безопасной разработки основывается на нескольких ключевых факторах:- Ресурсы: доступные возможности организации, включая бюджет, время и персонал.
- Уровень экспертизы: оценивается текущий уровень знаний и навыков команды в области безопасности, чтобы определить необходимость в обучении или привлечении экспертов.
- Перечень практик [SSDL2]: используется сформированный ранее список практик, необходимых для достижения целевого уровня безопасности.
- Целевое состояние [SSDL1]: дорожная карта должна вести к достижению желаемого уровня зрелости процессов SSDL.
Формируется детальный календарный план, включающий:- Очередность задач: определяется последовательность внедрения практик с учетом их приоритета и взаимозависимости.
- Зоны ответственности: четко распределяются роли и зоны ответственности по каждой задаче.
- Трудозатраты: оценивается время, необходимое для реализации каждой задачи, что позволяет планировать ресурсы и сроки.
Шаги реализации:- Проанализировать доступный бюджет, временные рамки и количество специалистов, которые могут быть задействованы во внедрении БР.
- Учесть как прямые затраты (например, на приобретение инструментов), так и косвенные (время сотрудников на обучение).
- Проанализировать уровень компетенций команды разработки в области безопасности.
- Изучить сформированный ранее перечень внедряемых практик, их приоритет и взаимосвязи.
- Еще раз обратиться к описанию целевого уровня зрелости процессов SSDL и определить, каких конкретных результатов необходимо достичь.
- Разбить процесс внедрения на этапы, учитывая сложность практик, доступность ресурсов и взаимозависимости между ними.
- Для каждого этапа определить реалистичные сроки выполнения, принимая во внимание результаты оценки ресурсов и уровня экспертизы.
- Разбить каждый этап на конкретные задачи.
- Назначить ответственных за выполнение каждой задачи, обеспечив четкое распределение ролей.
- Представить дорожную карту в наглядном виде, используя диаграммы Ганта, таблицы или другие подходящие форматы.
- Для каждой задачи кратко описать ее суть, сроки, ответственных, ресурсы и ожидаемые результаты.
- Регулярно информировать всех участников о ходе реализации дорожной карты, отслеживать прогресс и вносить необходимые коррективы.
Зона ответственности: AppSec
Инструмент: -
Артефакт: Дорожная карта -
Инициатива: Тиражирование практик безопасной разработки
Описание:
Внедрение практик безопасной разработки не обязательно должно (и далеко не всегда может) происходить одномоментно во всех проектах организации. Для определения стратегии составляются границы тиражирования, где учитываются:- скоуп охватываемых приложений и проектов;
- целевое состояние [SSDL1]: желаемый уровень зрелости процессов БР в организации;
- уровень критичности приложений [OAD2].
Границы тиражирования описывают очередность внедрения практик: приоритет отдается приложениям, где риски от уязвимостей наиболее высоки. Процесс тиражирования можно отразить в дорожной карте [SSDL3], где будут описаны динамика, поэтапный подход и условия «подключения» новых приложений и проектов. Целевое состояние может различаться для разных категорий приложений. Для некоторых достаточно базового набора практик и какие-то активности будут избыточными, а для других — необходимыми. Идеальный, но не всегда достижимый сценарий — охват 100%. Реальная картина будет зависеть от ресурсов и ограничений организации.
Важно помнить, что внедрение БР — это не одноразовая акция, а непрерывный процесс, который может быть оптимизирован [SSDL5]. Процесс тиражирования должен быть гибким, чтобы адаптироваться к изменениям
в ресурсах, приоритетах и требованиях безопасности.
Шаги реализации:- Создать полный список приложений и проектов, которые потенциально могут быть охвачены стратегией БР.
- Разделить приложения на группы по типу, назначению, технологическому стеку и другим критериям, которые могут влиять на подход к обеспечению БР.
- Распределить приложения по категориям критичности (например, критические, высокой, средней и низкой критичности).
- Определить целевое состояние для каждой категории.
- Определить последовательность «подключения» приложений к системе БР, начиная с наиболее критичных.
- Запланировать поэтапное расширение охвата приложений практиками БР, постепенно повышая общий уровень зрелости SSDL в организации.
- Регулярно отслеживать ход внедрения практик и достижение целевых показателей для каждой категории приложений, при необходимости корректировать план тиражирования.
Зона ответственности: AppSec
Инструмент: -
Артефакт: Границы тиражирования -
Инициатива: Корректировка стратегии SSDL
Описание:
В процессе реализации стратегии важно отслеживать ее актуальность и результативность, поскольку могут возникнуть предпосылки для ее корректировки.
Ключевые факторы, требующие пересмотра стратегии:- Метрики [RM4]: анализ метрик безопасности поможет оценить результативность внедренных практик и выявить области для доработки.
- Возникающие инциденты [MI4]: каждый инцидент — это урок, который может привести к корректировке стратегии для предотвращения подобных случаев в будущем.
- Анализ соответствия плану реализации [SSDL3]: отслеживание хода внедрения и соответствия плану позволяет своевременно вносить необходимые коррективы.
Внешние и внутренние изменения, влияющие на стратегию:- Бизнес-цели организации: изменения в бизнесе могут потребовать пересмотра приоритетов безопасности и внесения изменений в стратегию SSDL.
- Внешние регуляторы [TMR3]: новые законы, стандарты и отраслевые рекомендации могут выдвигать дополнительные требования к безопасности разработки.
- Технические изменения: развитие технологического стека [ТР1], изменения в инфраструктуре, новые угрозы — все это должно учитываться при актуализации стратегии.
Шаги реализации:- Определить ключевые показатели эффективности (KPI) для оценки результативности стратегии: количество уязвимостей, обнаруженных на разных этапах, время устранения уязвимостей, покрытие кода тестами безопасности и др.
- Регулярно собирать и анализировать данные по KPI, чтобы оценить динамику и выявить области, требующие внимания.
- Внедрить процесс учета и анализа всех инцидентов безопасности, связанных с разрабатываемым ПО. Для каждого инцидента определять причины, которые помогут предотвратить подобные случаи в будущем.
- Регулярно отслеживать ход внедрения практик безопасной разработки в соответствии с дорожной картой. Анализировать отклонения от плана и выявлять причины задержек или трудностей.
- Отслеживать изменения в бизнес-стратегии организации и оценивать их потенциальное влияние на требования к безопасности разработки.
- Отслеживать изменения в законодательстве и стандартах.
- Отслеживать изменения в технологическом стеке организации, появление новых угроз, уязвимостей и атак.
- На основании полученных данных определить, необходима ли корректировка стратегии внедрения БР.
- При необходимости внести изменения в стратегию, дорожную карту, перечень внедряемых практик, а также в процессы и инструменты, используемые для обеспечения безопасности.
Зона ответственности: AppSec
Инструмент: -
Артефакт: Дорожная карта
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.