Куда я попал?
AppSec Table Top: методология безопасной разработки от Positive Technologies
Framework
Планирование
Для проведения оценки соответствия по документу войдите в систему.
Список требований
-
Инициатива: Определение перечня внедряемых практик
Описание:
Для внедрения безопасной разработки формируется перечень необходимых практик. Он составляется на основе анализа:- Технического задания (ТЗ) или технических требований (ТТ): требований к безопасности, заложенных в самом проекте.
- Существующих инициатив: какие практики безопасности уже применяются в организации.
- Целевого состояния 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
Инструмент: -
Артефакт: Дорожная карта -
Инициатива: Политика безопасной разработки
Описание:
Политика безопасной разработки — документ, регламентирующий деятельность организации в области обеспечения безопасности разрабатываемого программного обеспечения. Этот документ устанавливает систему правил, принципов и практик, направленных на интеграцию мер безопасности во все этапы жизненного цикла разработки ПО. Ключевая цель политики заключается в формировании устойчивой культуры безопасности, обеспечивающей минимизацию уязвимостей и рисков на всех этапах создания и эксплуатации программных продуктов.
В документе:- Детализируются процессы разработки с фокусом на безопасности.
- Регламентируются обязательные инженерные практики и методы тестирования безопасности.
- Определяются процедуры выявления и устранения уязвимостей.
- Особое внимание уделяется принципам безопасной эксплуатации приложений в соответствии с установленными нормативными требованиями [TMR3].
Шаги реализации:- Определить цели, задачи и области действия политики.
- Сформировать рабочую группу с участием представителей команд разработки, безопасности, юристов и других заинтересованных сторон.
- Изучить отраслевые стандарты и рекомендации, релевантные для организации.
- Описать основные принципы, цели и обязательства компании в области безопасности ПО.
- Детализировать требования к различным практикам SSDL, включая:
- управление рисками безопасности;
- безопасное проектирование и разработку;
- тестирование безопасности на всех этапах;
- управление уязвимостями;
- реагирование на инциденты безопасности и т. д.
- Четко определить роли и ответственных за выполнение требований.
- Согласовать и обеспечить официальное утверждение политики руководством организации.
- Довести политику до сотрудников и разместить ее описание на внутреннем портале.
- Провести анализ существующих процессов разработки, выявить и внедрить необходимые изменения для соответствия политике.
- Разработать или адаптировать шаблоны документации (например, модель угроз) для соответствия требованиям политики.
- Внедрить метрики для оценки эффективности политики и отслеживания прогресса.
- Пересматривать и актуализировать политику не реже одного раза в год или при значительных изменениях в законодательстве, технологиях, угрозах безопасности.
Зона ответственности: AppSec
Инструмент: -
Артефакт: Политика безопасной разработки -
Инициатива: Категоризация ИС
Описание:
Методика ранжирования ПО обеспечивает структурированную классификацию приложений по уровню критичности и их категоризацию на основе определенных критериев и особенностей (влияние на бизнес, обрабатываемые данные, количество пользователей и т. д.). Данный подход служит инструментом для целенаправленного применения стратегии безопасной разработки и ее поэтапного тиражирования [SSDL4], а также способствует повышению осведомленности сотрудников о специфике разрабатываемых приложений. Четкое понимание характеристик, критичности и потенциальных рисков, связанных с каждым приложением, позволяет сосредоточить усилия на наиболее уязвимых местах и принять оптимальные решения для обеспечения
безопасности.
Информация, полученная в результате ранжирования, может быть включена в паспорт системы [IA1] для обеспечения централизованного хранения и доступа к данным о профилях безопасности приложений.
Шаги реализации:- Четко сформулировать цели классификации приложений: оптимизация ресурсов на безопасность, приоритизация внедрения практик SSDL и т. д.
- Определить критерии, на основе которых будет проводиться ранжирование.
- Разработать шкалу критичности: низкий, средний, высокий, критический уровень и т. п.
- Описать характеристики приложений, соответствующие каждому уровню критичности.
- При необходимости разработать дополнительные категории для группировки приложений по специфике (фронтенд/бэкенд, мобильные/веб-приложения и др.).
- Формализовать и задокументировать методику ранжирования как пошаговую инструкцию по оценке и классификации приложений.
- Определить ответственных за проведение ранжирования.
- Протестировать методику на небольшом количестве приложений для выявления недостатков и корректировки.
- Провести обучение сотрудников по применению методики.
- Осуществить ранжирование всех приложений, подпадающих под действие стратегии БР.
- Включить информацию о критичности приложений в паспорт системы.
- Довести информацию до сотрудников и разместить ее на внутреннем портале.
- Использовать данные ранжирования при планировании и реализации мероприятий по обеспечению безопасности разработки.
- Периодически пересматривать и актуализировать методику с учетом изменений в бизнесе, технологиях и требованиях безопасности.
Зона ответственности: AppSec
Инструмент: -
Артефакт: Методика критичности/ приоритизации приложений -
Инициатива: Регламент безопасной разработки
Описание:
Регламент безопасной разработки выступает в качестве практического руководства, детализирующего положения и принципы, определенные в политике БР [OAD1]. Если политика отвечает на вопрос «Что нужно делать?», то регламент раскрывает, как именно это делать. В документе подробно описываются конкретные шаги, последовательность действий, взаимосвязь практик, распределение ролей и ответственности.
Для наглядности и полноты изложения регламент может дополняться описанием практик и задач, процессными картами, инструкциями и другими приложениями, облегчающими внедрение и соблюдение требований безопасности.
Шаги реализации:- Проанализировать политику безопасной разработки, чтобы четко понимать контекст, цели и общие требования к БР.
- Определить, для кого предназначен регламент (разработчики, тестировщики, специалисты по безопасности, руководители проектов и т. д.), чтобы адаптировать язык и уровень детализации.
- Продумать логическую структуру документа, чтобы обеспечить его доступность и удобство использования.
- Разделить каждый процесс, обозначенный в политике, на конкретные шаги и описать их.
- Определить ролевую модель и четко указать, кто и за что отвечает в каждом процессе.
- Предоставить информацию об инструментах и технологиях для реализации практик безопасности.
- Дополнить текстовое описание схемами, диаграммами, таблицами и другими визуальными элементами для лучшего восприятия материала (например, наглядными процессными картами, отражающими последовательность действий и взаимодействие участников в рамках БР).
- Разработать шаблоны документов (плана тестирования безопасности и т. п.) и чек-листы, которые помогут сотрудникам следовать требованиям регламента.
- Дополнить внутренний портал безопасности вспомогательной информацией, примерами, рекомендациями по БР.
- Довести регламент до сотрудников и разместить его на внутреннем портале.
- Утвердить документ и внедрить процедуры контроля за соблюдением требований регламента — например, в рамках внутренних аудитов.
- Установить периодичность пересмотра и актуализации регламента с учетом изменений в законодательстве, стандартах, технологиях и угрозах безопасности.
Зона ответственности: AppSec
Инструмент: -
Артефакт: Регламент безопасной разработки -
Инициатива: Документирование процесса
Описание:
Четкая структуризация позволяет выстроить процесс разработки предсказуемым, управляемым и безопасным. Единые инструкции, регламенты, описания методологий и этапов разработки [TP3] сделают процесс прозрачным и понятным для всех участников, упростят анализ, аудит и контроль, а также минимизируют риски за счет устранения хаоса и внедрения единых стандартов. Более того, формализация способствует автоматизации и ускорению разработки, а также облегчает внедрение изменений, в том числе новых практик безопасной разработки [SSDL2].
Шаги реализации:- Проанализировать, как организована разработка в настоящее время, какие методологии и инструменты применяются.
- Оценить, насколько в целом формализован текущий процесс разработки и какие его аспекты требуют внимания в первую очередь.
- Детально описать каждый этап процесса разработки, включая цели, входные и выходные данные, ответственных, сроки и критерии успешного завершения.
- Разработать документацию, регламентирующую выполнение каждого этапа, — например, инструкции по написанию кода, проведению тестирования, управлению версиями.
- Использовать схемы, диаграммы, модели для наглядного представления процесса разработки и взаимосвязи между этапами.
- Поэтапно внедрять формализованный процесс, начиная с отдельных команд или проектов, и по мере готовности распространять его на всю организацию.
- Максимально автоматизировать рутинные операции и процессы: сбор требований, тестирование, сборку и развертывание ПО и т. д.
- Довести информацию до сотрудников и разместить ее на внутреннем портале.
- Внедрить механизмы контроля за соблюдением формализованного процесса разработки (регулярные аудиты, чек-листы, анализ метрик и др.).
Зона ответственности: ИТ
Инструмент: -
Артефакт: Артефакты процесса разработки. Описание конфигураций инфраструктуры
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.