Куда я попал?
AppSec Table Top: методология безопасной разработки от Positive Technologies
Framework
Проектирование архитектуры
Для проведения оценки соответствия по документу войдите в систему.
Список требований
-
Инициатива: Моделирование угроз в ЖЦ ПО
Описание:
При анализе рисков важно рассматривать угрозы не только в фазе эксплуатации [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
Инструмент: -
Артефакт: Технический проект
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.