Куда я попал?
AppSec Table Top: методология безопасной разработки от Positive Technologies
Framework
PreStageSDL
Для проведения оценки соответствия по документу войдите в систему.
Список требований
-
Инициатива: Определение перечня внедряемых практик
Описание:
Для внедрения безопасной разработки формируется перечень необходимых практик. Он составляется на основе анализа:- Технического задания (ТЗ) или технических требований (ТТ): требований к безопасности, заложенных в самом проекте.
- Существующих инициатив: какие практики безопасности уже применяются в организации.
- Целевого состояния 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].
Шаги реализации:- Проанализировать, как организована разработка в настоящее время, какие методологии и инструменты применяются.
- Оценить, насколько в целом формализован текущий процесс разработки и какие его аспекты требуют внимания в первую очередь.
- Детально описать каждый этап процесса разработки, включая цели, входные и выходные данные, ответственных, сроки и критерии успешного завершения.
- Разработать документацию, регламентирующую выполнение каждого этапа, — например, инструкции по написанию кода, проведению тестирования, управлению версиями.
- Использовать схемы, диаграммы, модели для наглядного представления процесса разработки и взаимосвязи между этапами.
- Поэтапно внедрять формализованный процесс, начиная с отдельных команд или проектов, и по мере готовности распространять его на всю организацию.
- Максимально автоматизировать рутинные операции и процессы: сбор требований, тестирование, сборку и развертывание ПО и т. д.
- Довести информацию до сотрудников и разместить ее на внутреннем портале.
- Внедрить механизмы контроля за соблюдением формализованного процесса разработки (регулярные аудиты, чек-листы, анализ метрик и др.).
Зона ответственности: ИТ
Инструмент: -
Артефакт: Артефакты процесса разработки. Описание конфигураций инфраструктуры -
Инициатива: Моделирование угроз в ЖЦ ПО
Описание:
При анализе рисков важно рассматривать угрозы не только в фазе эксплуатации [TMR1], но и на всех этапах разработки ПО, в том числе и на ранних стадиях.
При выпуске приложений в производственную среду модель угроз должна использоваться для оценки остаточных рисков и для принятия решения о необходимости дополнительных мер безопасности.
Регулярное обновление модели (с учетом изменений в системе, угрожающей среде и используемых злоумышленниками методах) позволит обеспечить постоянную защиту от атак и минимизировать риски для бизнеса.
Шаги реализации:- Определить область применения модели угроз, ее границы и ключевые компоненты.
- Определить методологию разрабатываемой модели.
- Определить роли, которые будут участвовать в процессе моделирования угроз.
- Определить защищаемые активы: данные, компоненты приложения, инфраструктура и т. д.
- Распределить активы по уровню критичности: от самых важных до менее важных.
- Определить потенциальных злоумышленников — внутренних (сотрудники, контрагенты) и внешних (хакеры, конкуренты, мошенники).
- Определить мотивацию каждого типа злоумышленника: финансовая выгода, репутационный ущерб, политические мотивы и т. д.
- Провести оценку возможностей злоумышленников: уровень технических знаний, доступ к ресурсам, мотивация.
- Выявить слабые места в используемом ПО, операционных системах, сети, политиках доступа, людях.
- Провести анализ конфигурации (корректность настройки инфраструктуры и программного обеспечения).
- Определить вектор атак — последовательность действий, которые может предпринять злоумышленник, чтобы получить доступ к системе и нанести ущерб.
- Описать потенциальные последствия каждой атаки.
- Оценить риски: определить вероятность и последствия воздействия каждой атаки, а так же уровень риска (как произведение вероятности и воздействия).
- Регулярно обновлять модель угроз с учетом архитектурных и других изменений.
Зона ответственности: ИБ
Инструмент: -
Артефакт: Модель угроз приложения -
Инициатива: Чек-лист внешних регуляторных требований
Описание:
Чек-лист безопасности для организации или отдельного приложения формируется на основе анализа всех применимых регуляторных требований с учетом критичности и категории разрабатываемых продуктов [OAD2]. Его цель — обеспечить соответствие приложения нормативным требованиям и снизить риски безопасности.
Необходимые требования объединяются в один лаконичный документ, который:- Описывает совокупность всех необходимых требований в одном месте.
- Является ценным инструментом при проектировании архитектуры [TMR4].
- Помогает определить необходимые практики безопасности [SSDL2].
- Упрощает проведение аудитов и мероприятий по проверке соответствия требованиям [VC2].
Шаги реализации:- Определить область применения чек-листа: конкретное приложение, вся организация, определенный тип приложений.
- Определить все применимые регуляторы и требования законодательства.
- Провести анализ каждого регулятора и составить список актуальных требований к безопасности приложения или организации.
- Сгруппировать требования по категориям: аутентификация, авторизация, шифрование, безопасность данных, управление уязвимостями и т. д.
- Объединить похожие требования, чтобы избежать дублирования.
- Структурировать чек-лист, разбить его на разделы по категориям требований.
- Сформулировать требования в виде конкретных вопросов или утверждений, на которые можно ответить «да» или «нет».
- Добавить столбцы для проверки соответствия требованиям (например, «Выполнено», «Не выполнено», «В процессе»).
- Использовать чек-лист для учета требований (при проектировании, ПСИ или аудитах).
- Довести документ до сотрудников и разместить на внутреннем портале.
- Отслеживать изменения в регуляторных требованиях и регулярно обновлять чек-лист.
Зона ответственности: ИБ
Инструмент: -
Артефакт: Чек-лист требований -
Инициатива: Требования к инфраструктуре и ПО
Описание:
Базовые требования ИБ устанавливают минимально допустимый уровень защищенности, служат основой для проверок соответствия [VC2] и гарантируют единый подход к обеспечению безопасности. Список требований охватывает всю инфраструктуру, используемое ПО и приложения организации.
Документ включает:- Общие меры защиты для всей инфраструктуры и ПО.
- Специальные меры, учитывающие специфику конкретных приложений и технологий.
- Разработанные требования рекомендуется объединить с чек-листом регуляторных требований [TMR3].
Шаги реализации:- Назначить ответственных за разработку требований ИБ.
- Изучить существующую документацию (политики, стандарты, регламенты) и особенности процесса разработки.
- Ознакомиться с лучшими практиками и стандартами ИБ.
- Определить общие меры защиты, обязательные для всей инфраструктуры и ПО.
- Конкретно, понятно и измеримо сформулировать требования.
- Определить дополнительные меры защиты для каждого типа приложений или технологий с учетом их специфики (веб-приложения, мобильные приложения, облачные сервисы).
- Сгруппировать требования по категориям и области применения.
- Оформить, согласовать и утвердить требования ИБ в виде официального документа.
- Довести требования до всех заинтересованных сторон и сделать их выполнение обязательным.
- Дополнить чек-лист регуляторных требований разработанными требованиями ИБ.
- Обеспечить контроль выполнения требований и регулярное обновление документа.
Зона ответственности: ИБ/ИТ
Инструмент: -
Артефакт: Чек-лист требований. Требования ИБ к ПО -
Инициатива: Меры митигации
Описание:
Меры митигации играют ключевую роль в управлении рисками ИБ. Их основная задача — снизить вероятность реализации угроз и минимизировать потенциальный ущерб для организации. Выбор и реализация мер митигации основываются на результатах моделирования угроз [TMR1] и направлены на противодействие выявленным рискам.
Эффективные меры митигации учитывают специфику организации, особенности ее инфраструктуры, критичность информационных активов и характер потенциальных угроз. Они представляют собой совокупность технических, организационных и административных мероприятий, направленных на:- Проактивную защиту: устранение уязвимостей, блокирование атак, ограничение доступа к конфиденциальной информации.
- Снижение вероятности реализации рисков: повышение сложности доступа к системам, внедрение многофакторной аутентификации, обучение сотрудников.
- Минимизацию последствий реализации рисков: резервное копирование данных, разработка плана действий при инцидентах ИБ.
Шаги реализации:- Проанализировать результаты моделирования угроз для идентификации актуальных рисков.
- Оценить вероятность реализации каждой угрозы и потенциальный ущерб для организации.
- Для каждого выявленного риска определить набор мер, направленных на предотвращение, снижение вероятности реализации или минимизацию последствий.
- Определить план реализации мер митигации: ответственных за реализацию, сроки, ресурсы.
- Внедрять меры в соответствии с разработанным планом.
- Периодически проводить аудиты безопасности для оценки эффективности и корректировки мер митигации.
Зона ответственности: ИБ
Инструмент: -
Артефакт: План митигации -
Инициатива: Выбор метрик
Описание:
Анализ метрик позволяет выявить сильные и слабые стороны в жизненном цикле разработки ПО, определить зоны развития и своевременно оптимизировать процессы.
Для определения целей использования метрик важно разделять их по областям применения:- Бизнес-метрики [RM2]: отражают влияние технологий на бизнес-показатели (ROI, Time to Market и др.).
- Метрики стратегии [SSDL5]: показывают прогресс в реализации стратегии безопасной разработки (например, количество уязвимостей, найденных на разных этапах).
- Операционные метрики: характеризуют эффективность эксплуатации систем (время простоя, количество инцидентов и т. д.).
Метрики должны быть релевантными, измеримыми и собираемыми.
Шаги реализации:- Сформировать цели и задачи для сбора метрик, обозначить области применения: эффективность разработки, безопасность продуктов, ROI и т. д.
- Определить, кому будут транслироваться метрики: руководству, разработчикам, AppSec-специалистам.
- Подобрать метрики, соответствующие выбранным целям и задачам.
- Сформировать перечень метрик для каждой области применения.
Зона ответственности: AppSec
Инструмент: -
Артефакт: Перечень метрик -
Инициатива: Оценка рисков
Описание:
Анализ рисков разрабатываемого приложения/системы проводится на основе бизнес-метрик [RM1] и результатов моделирования угроз [TMR1].
В компании должен быть реализован процесс риск-менеджмента и сформирован перечень недопустимых событий. Это позволит оценить экономическое влияние и эффективность стратегии SSDL [SSDL5] и при необходимости внести изменения.
Шаги реализации:- Определить контекст и цели оценки рисков: какое приложение/система анализируется и какие решения будут приняты на основе анализа.
- Собрать данные о бизнес-метриках и результаты моделирования угроз.
- Определить методологию оценки рисков.
- Связать бизнес-метрики с угрозами, рассчитать потенциальный ущерб от реализации угроз и их вероятность.
- Ранжировать риски по степени их влияния на бизнес.
- Выявить недопустимые события и разработать план по их минимизации.
- Разработать рекомендации по улучшению процессов БР с учетом полученных результатов анализа.
- Разработать артефакты, отражающие результаты анализа (графики, диаграммы, таблицы, отчеты с выводами и рекомендациями и т. д.)
Зона ответственности: AppSec
Инструмент: -
Артефакт: Перечень недопустимых событий. Оценка критичности приложений -
Инициатива: Определение подходов к сбору метрик
Описание:
После определения перечня необходимых метрик [RM1] необходимо разработать план их сбора и определить, откуда и как можно получить данные для расчета. Источники могут быть различными: внутренние (системы контроля версий, баг-трекеры, логи), внешние (отзывы пользователей, аналитика), а также собранные вручную данные (опросы, экспертные оценки).
Для автоматизации сбора можно использовать специальные инструменты:- cистемы мониторинга;
- инструменты автоматического анализа (например, SAST [SPA3]);
- оркестратор [SPA6] и т. д.
Важно определить, на каких этапах жизненного цикла разработки или эксплуатации системы целесообразнее собирать данные для метрик:- на этапе проектирования можно оценивать инфраструктурные мощности и риски [RM2];
- на этапе разработки — количество ошибок в коде;
- на этапе эксплуатации — доступность системы и инциденты [MI4].
Шаги реализации:- Для каждой метрики определить их тип (временные, текстовые, числовые), источники данных и доступность.
- Выбрать и настроить инструменты для автоматизации сбора, исходя из источников и формата данных.
- Разработать и задокументировать процесс сбора и обработки данных для каждой метрики, указав ответственных, периодичность и методику сбора.
- Стандартизировать форматы данных, чтобы их можно было легко объединять и анализировать.
- Периодически анализировать процесс сбора метрик на предмет корректности данных и эффективности работы инструментов сбора.
Зона ответственности: AppSec
Инструмент: ASOC
Артефакт: - -
Инициатива: Анализ метрик
Описание:
Регулярный анализ собранных метрик (особенно данных о дефектах, инцидентах и экономических показателях) играет ключевую роль в развитии системы информационной безопасности. Проведение периодических ретроспектив позволяет оценить эффективность предпринимаемых мер и скорректировать стратегию.
В ходе ретроспективы важно проанализировать:- Динамику: наблюдается ли прогресс в уменьшении количества дефектов/инцидентов и в снижении ущерба?
- Сильные и слабые стороны: какие процессы и практики работают эффективно, а какие требуют улучшения?
- Эффективность инструментов: насколько хорошо инструменты SSDL помогают выявлять и предотвращать проблемы?
- Корреляцию между метриками: есть ли связь между внедрением конкретных практик и изменениями в метриках?
Результаты ретроспективы служат фундаментом для принятия взвешенных решений: корректировки стратегии SSDL [SSDL5] и оптимизации бюджета на ИБ. Также само мероприятие повышает осведомленность сотрудников, помогает донести до них значимость БР и формирования культуры безопасности.
Шаги реализации:- Определить периодичность проведения ретроспектив.
- Сформировать команду экспертов, включая представителей ИБ, разработчиков, тестировщиков и руководство.
- Сформировать отчеты по всем ключевым метрикам за выбранный период.
- Определить формат проведения: рабочая встреча, презентация, онлайн-дискуссия.
- Оценить динамику метрик: позитивные и негативные изменения.
- Проанализировать эффективность процессов и инструментов.
- Выявить корреляцию между метриками и предпринятыми действиями: какие изменения привели к положительным или негативным сдвигам.
- Разработать план и определить конкретные задачи по улучшению процессов разработки и SSDL.
Зона ответственности: Организация
Инструмент: -
Артефакт: - -
Инициатива: Определение технологического стека
Описание:
При выборе инструментов необходимо учитывать не только функциональные требования (ТЗ/ТТ), но и требования к безопасности инфраструктуры и ПО [TMR4]. Важно анализировать уязвимости и риски, связанные с каждым компонентом стека, а также возможности их интеграции с системами безопасности.
Документирование и стандартизация технологического стека — важный шаг к построению эффективной и безопасной системы разработки. Стандартизация упрощает:- Внедрение практик БР [SSDL2] и определение единых требований.
- Анализ защищенности: оценка рисков и уязвимостей становится более структурированной и эффективной.
- Взаимодействие команд: общий технологический стек облегчает коммуникацию и понимание процессов разработки.
Шаги реализации:- Проанализировать требования, существующие процессы и используемые инструменты.
- Сформировать предварительный перечень инструментов и возможных решений для каждого этапа жизненного цикла ПО (разработка, тестирование, развёртывание и т. д.)
- Оценить технические характеристики и аспекты безопасности инструментов.
- Оценить стоимость внедрения и поддержки различных вариантов.
- Провести анализ рисков безопасности и убедиться, что выбранные инструменты имеют достаточный уровень защиты и соответствуют требованиям организации.
- Разработать меры по минимизации рисков — например, настройку безопасных конфигураций.
- Создать документ, описывающий стандартный технологический стек, с указанием версий инструментов, конфигураций и рекомендаций по использованию.
- Описать процессы обновления стека и добавления новых инструментов.
- Внедрить процессы контроля за использованием утвержденных инструментов и соблюдением стандартов.
- Регулярно пересматривать и актуализировать технологический стек с учетом новых технологий, изменений в требованиях безопасности и обратной связи от команд разработки.
Зона ответственности: ИТ
Инструмент: -
Артефакт: Технологический стек -
Инициатива: Порядок контроля используемого ПО
Описание:
Политика использования ПО определяет критерии отбора допустимых программ, процедуры одобрения нового ПО и правила работы с компонентами с открытым исходным кодом. Цель — исключить или минимизировать использование ПО, которое может представлять угрозу безопасности.
Порядок контроля использования ПО охватывает весь жизненный цикл программного обеспечения в организации. Необходимо учитывать не только технологический стек [TP1], но и все компоненты разработки — от операционных систем до библиотек с открытым кодом [SCA5]. При этом важна не только инвентаризация, но и классификация ПО по его критичности, уровню доверия и другим параметрам.
Для эффективного контроля рекомендуется внедрение соответствующих инструментов:- Систем управления активами (ITAM).
- Систем контроля версий [GF1].
- Средств мониторинга безопасности [MI3].
Эти инструменты помогают автоматизировать инвентаризацию, отслеживание лицензий, управление уязвимостями и реагирование на инциденты.
Шаги реализации:- Провести анализ всего ПО, используемого в организации: операционные системы, серверное ПО, приложения, библиотеки, фреймворки, компоненты с открытым исходным кодом (OSS) и др.
- Классифицировать ПО по типу, критичности для бизнеса, уровню доверия.
- Создать реестр с описанием каждой компоненты: название, версия, разработчик, назначение, место использования, информация о поддержке и лицензии.
- Утвердить перечень допустимого ПО и определить критерии отбора: уровень безопасности, наличие поддержки, лицензионная чистота и т. д.
- Установить процедуру одобрения нового ПО: кто и на основании каких критериев может одобрять использование ПО, не входящего в утвержденный перечень.
- Разработать правила использования ПО с открытым исходным кодом (OSS): оценка рисков, проверка лицензий, контроль уязвимостей.
- На основе предыдущих пунктов сформировать политику использования ПО, при необходимости дополнив ее информацией о мерах безопасности при работе с компонентами.
- Довести политику до сотрудников и разместить на внутреннем портале.
- Внедрить инструменты контроля используемого ПО: инвентаризация, отслеживание лицензий, мониторинг безопасности и др.
- Анализировать данные о выявленных уязвимостях и инцидентах безопасности для своевременного принятия мер по их устранению.
Зона ответственности: ИТ
Инструмент: -
Артефакт: Политика использования ПО -
Инициатива: Определение CI/CD-конвейера
Описание:
Только при наличии зрелого и налаженного DevOps-процесса можно говорить об успешном внедрении DevSecOps и интеграции безопасности в каждый этап разработки. В основе эффективного DevOps лежит автоматизация и минимизация рутинных работ.
Ключевым элементом является построение CI/CD-конвейера, что включает:- Определение подходов к сборке и доставке приложения: выбор инструментов и конфигураций.
- Выбор методологии разработки (Agile, Waterfall или гибридные подходы).
- Определение этапов конвейера (сборка, тестирование, развёртывание, мониторинг).
- Внедрение системы контроля качества и безопасности на каждом этапе [VC1].
- Разделение окружений (Dev, Test, Prod) для изоляции каждого этапа.
- Документирование всех процессов и инструментов [OAD5] для обеспечения прозрачности и поддерживаемости.
Шаги реализации:- Определить цели и задачи внедрения CI/CD.
- Определить методологию разработки, этапы, требования безопасности и необходимые меры контроля на каждом этапе.
- Определить технологический стек.
- Настроить инструменты: репозитории кода, системы контроля версий и т. д.
- Создать пайплайны CI/CD для автоматизации этапов сборки, тестирования и развёртывания.
- Настроить окружения (Dev, Test, Prod) и процесс автоматического перемещения кода между ними.
- Задокументировать все этапы и процессы CI/CD-конвейера.
- Довести информацию до сотрудников и разместить ее на внутреннем портале.
- Отслеживать ключевые метрики CI/CD-конвейера (время сборки, частота развертывания, количество ошибок и уязвимостей) и при необходимости вносить коррективы.
Зона ответственности: ИТ
Инструмент: -
Артефакт: Артефакты процесса разработки -
Инициатива: Формирование безопасной архитектуры
Описание:
На этапе проектирования важно принять во внимание устойчивость системы к атакам и меры обеспечения безопасности данных. Архитектура должна учитывать все требования [TMR4], принципы безопасной разработки, используемый технологический стек [TP1], методологию и распределение сред [TP3].
Ключевые принципы проектирования безопасной архитектуры:- Безопасность по умолчанию: система должна быть максимально защищена «из коробки».
- Глубокая защита: использование нескольких уровней защиты для предотвращения несанкционированного доступа.
- Минимизация поверхности атаки [CNFG1]: ограничение количества открытых портов, сервисов и интерфейсов.
- Принцип наименьших привилегий [AC2]: предоставление пользователям и процессам только тех прав доступа, которые необходимы для выполнения их функций.
Эти принципы должны быть заложены в самом начале и учитываться при принятии всех архитектурных решений.
Результатом проектирования становится технический проект — документ, подробно описывающий архитектуру системы, технологический стек, подходы к управлению данными, концепцию обеспечения безопасности, результаты анализа безопасности и меры по минимизации рисков.
Шаги реализации:- Проанализировать требования к архитектуре: функциональные, требования ИБ и т. д.
- Проанализировать ограничения и особенности приложения/системы: архитектура, технологический стек, совместимость компонент стека.
- Сформировать проект архитектуры с учетом всех требований, ограничений и принципов безопасности.
- Провести первичный анализа архитектуры.
- Разработать технический проект, включающий результаты анализа безопасности, а также описание стека, механизмов безопасности и ответственных.
- Проводить периодический анализ и при необходимости пересматривать архитектуру.
Зона ответственности: ИТ/AppSec
Инструмент: -
Артефакт: Технический проект -
Инициатива: Харденинг
Описание:
Харденинг — это безопасная настройка конфигураций для устранения потенциальных уязвимостей и снижения рисков кибератак. В основе активности — тщательная инвентаризация и настройка всех элементов IT-инфраструктуры, анализ конфигураций на соответствие требованиям безопасности [TMR4] и лучшим практикам.
Основные принципы харденинга:- Применение принципа минимальных привилегий: отключение всех ненужных сервисов, протоколов, портов, ограничение прав доступа пользователей и приложений.
- Установка безопасных параметров: настройка аутентификации, авторизации, шифрования, журналирования, резервного копирования.
- Своевременное обновление ПО: установка патчей безопасности, обновление антивирусных баз и т. д.
- Документирование и автоматизация: создание документации по конфигурациям, автоматизация процессов настройки и мониторинга.
Шаги реализации:- Провести инвентаризацию IT-инфраструктуры: сервера, сетевые устройства, рабочие станции, приложения и базы данных.
- Проанализировать существующие настройки безопасности и оценить их соответствие требованиям.
- Разработать план и инструкции по харденингу для каждого типа систем и приложений.
- Внедрить меры харденинга:
- Отключение ненужных сервисов, протоколов, портов.
- Настройка сильных паролей и механизмов аутентификации.
- Журналирование и мониторинг событий безопасности.
- Настройка брандмауэров и других инструментов безопасности.
- Внедрение шифрования данных при хранении и передаче.
- Регулярная установка обновлений и патчей.
- Создать подробную документацию по безопасной настройке конфигураций.
- Довести информацию до сотрудников и разместить на внутреннем портале.
- Регулярно анализировать и актуализировать настройки безопасности с учетом новых угроз и изменений в инфраструктуре.
Зона ответственности: ИТ
Инструмент: -
Артефакт: Описание конфигураций инфраструктуры -
Инициатива: Учёт рисков при настройке инфраструктуры
Описание:
Безопасность инфраструктуры не ограничивается базовым харденингом [CNFG1]. Важно учитывать специфику и слабые места приложений/организации, руководствуясь актуальными рисками. Анализ результатов моделирования угроз [TMR1], разработка мер митигации [TMR5] и следование рекомендациям безопасности выбранного технологического стека [TP1] — ключевые аспекты этого процесса.
Шаги реализации:- Проанализировать актуальные для приложения/инфраструктуры риски и слабые места.
- Ознакомиться с предлагаемыми (по результатам других активностей) мерами митигаций, рекомендациями по контролю ПО и ограничениями технологического стека.
- Проанализировать текущее состояние безопасности конфигураций активов инфраструктуры.
- Выбрать и внедрить меры защиты в существующую IT-инфраструктуру.
- Настроить и протестировать работу новых систем и механизмов безопасности.
- Убедиться, что меры безопасности не влияют на производительность и доступность критически важных приложений.
- Дополнить документацию по безопасной настройке конфигураций.
- Регулярно анализировать и актуализировать настройки безопасности с учетом новых угроз и изменений в инфраструктуре.
Зона ответственности: ИТ
Инструмент: -
Артефакт: Описание конфигураций инфраструктуры
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.