Обзор Start REQ, системы для управления требованиями по ИБ при разработке ПО

1. Введение
2. Функциональные возможности продукта
   1. 2.1. Требования
   2. 2.2. Моделирование угроз
   3. 2.3. Ролевая модель
3. Интеграции
   1. 3.1. Аналитика
   2. 3.2. Управление знаниями с помощью платформы Start EDU
      1. 3.2.1. Как работает обучение в Start EDU
4. Архитектура продукта
5. Системные требования продукта
6. Сценарии использования продукта
   1. 6.1. Создание списка требований по безопасности приложения
   2. 6.2. Анкета рисков
7. Выводы

Введение

Утечки информации, критические уязвимости и штрафы за невыполнение требований регуляторов — эти проблемы небезопасной разработки можно предотвратить с помощью подходов DevSecOps и Shift-Left Security. 

Основной принцип Shift-Left Security — внедрять проверки безопасности так рано и так часто, как это возможно. Командам разработки дешевле и быстрее исключать предпосылки уязвимостей ещё на этапе проектирования или изменения по функциональным требованиям, чем ликвидировать последствия ошибок. 

Налаживать работу в рамках Shift-Left Security проще, когда у обеих команд — разработки и ИБ — все требования к ПО из разных источников можно собирать, администрировать и обновлять на одной платформе. Такие платформы относятся к классу «управление угрозами и требованиями по безопасности приложений» (Application Security Requirements and Threat Management, ASRTM).

Start REQ — российское решение класса ASRTM. Платформа работает как интерактивная база знаний по безопасной разработке для специалистов по ИБ и разработчиков. 

Start REQ помогает сформировать требования по безопасности к продуктам с учётом актуальных угроз, выбрать самый эффективный и быстрый способ выполнить эти требования, организовать общее рабочее пространство для продуктовых команд и экспертов по ИБ.

Рисунок 1. Технические инструменты часто применяются в самом конце и замедляют выпуск релиза

Функциональные возможности продукта

С помощью Start REQ эксперты по ИБ получают доступ к базе требований, формируют шаблоны опросников и модель угроз. Руководители команд разработки распределяют задачи по ответственным — техническим писателям, разработчикам, администраторам — и синхронизируют требования с бэклогом обучения. 

Рисунок 2. Применение Start REQ в процессах DevSecOps

Давайте рассмотрим основные функциональные возможности платформы.

Требования 

Требования в Start REQ формируются из предустановленной базы знаний платформы. База постоянно расширяется с обновлением требований законодательства, лучших практик и стандартов, а также информационных технологий в целом. Например, одним из последних обновлений стали требования по безопасности контейнеров и оркестраторов.

Рисунок 3. Как выглядят требования в Start REQ

В предустановленной базе хранятся требования из более чем 15 источников. В их числе — международный стандарт PCI DSS, OWASP Foundation, приказы ФСТЭК России № 21 и 239, национальный стандарт ГОСТ Р 57580.1-2017.

Рисунок 4. Структура требований по информационной безопасности в Start REQ

Специалисты Start REQ переводят сложные описания требований регуляторов и лучших практик на понятный язык безопасности и разработки. Так команды получают чёткие и лаконичные требования к каждой системе. Это освобождает людей от долгого разбора канцелярских текстов и уточнений.

Таблица 1. Как эксперты Start REQ переводят требования на язык разработки

Посмотрим основные разделы Start REQ.

Рисунок 5. Раздел «Настройки» Start REQ

На скриншоте выше они показаны в меню слева.

«Проекты» — это продуктовые команды, где участники распределены по ролям.

«Системы» — все автоматизированные системы организации с актуальным статусом соответствия требованиям. 

«Знания» — интерактивное обучение для разработчиков, которое через темы с примерами кода помогает искать решения для выполнения требований.

«Аналитика» — динамика выполнения требований по ИБ в автоматизированных системах и уровень знаний участников команд разработки в виде дашбордов.

Теперь перейдём к настройкам.

«Характеристики АС (автоматизированной системы)» — опросник о продукте, который помогает сформировать требования по безопасности. Администратор отвечает на вопросы об особенностях функционирования приложения, после чего Start REQ формирует список требований по информационной безопасности. 

«Шаблоны требований» — предзагруженные требования по безопасности, которые администратор может расширять и связывать с характеристиками своего приложения.

«Требования внешних регуляторов» — формулировки требований в том виде, в котором они описаны в законе или указе. Отсюда требования можно связывать с упрощёнными формулировками из раздела «Шаблоны требований», чтобы видеть, к какому конкретному разделу относится требование в законодательстве.

«Теги для требований» — с их помощью можно группировать и фильтровать требования, например, по критической значимости или владельцу продукта.

«Статусы» — состояния требований по этапам работ (новое, в работе, выполнено), критической значимости, тестированию, необходимости пояснений. Можно добавлять свои статусы.

«Исполнители требований» — распределение по сотрудникам компании и внешним разработчикам, чтобы разграничить видимость некоторых требований от подрядчиков.

«Дополнительные колонки» — дополнительная информация к требованиям, например методика проверки.

«Интеграции» — соединения с Jira, Active Directory и почтой.

«Управление пользователями» — все пользователи и настройка системных ролей.

«Шаблоны анкет» — предзаполненные опросники для описания архитектуры и особенностей автоматизированной системы.

«Анкета рисков» — анкета с вопросами и ответами о продукте, которые помогают моделировать угрозы и ранжировать их по критической значимости.

«Журналирование» — журнал событий, где можно настроить регулярность выгрузки, видеть авторов изменений и отслеживать изменения по дате и времени.

Моделирование угроз

В разделе «Настройки» → «Анкета рисков» эксперты по ИБ определяют актуальные для системы риски, а бизнес-пользователи оценивают влияние рисков на бизнес-процессы. Оценка со стороны бизнеса напрямую влияет на состав, критическую значимость и способ реализации требований для создаваемой или изменяемой системы. Такими рисками могут быть:

• недоступность продукта из-за кибератак;
• утечка персональных данных или платёжной информации;
• искажение данных;
• мошенничество;
• аварии в ИТ-инфраструктуре организации.

Например, для какой-то компании доступность веб-приложения может быть важнее, чем сохранность обрабатываемых в нём данных. О таких особенностях команда ИБ может и не знать заранее, поэтому анкета рисков помогает совместно зафиксировать все особенности продукта.

Рисунок 6. Настройка анкеты рисков в Start REQ

Критическая значимость требований зависит от того, какие риски для бизнеса приемлемы, а какие — нет. Эту градацию команда ИБ формирует совместно с бизнесом.

Рисунок 7. Как работает анкета рисков в Start REQ

Анкета рисков позволяет ранжировать требования по значимости угроз в каждом продукте. Администратор системы может заполнять предустановленные базовые анкеты или настраивать свои шаблоны.

Ролевая модель

Таблица 2. Как распределяются права по ролям в Start REQ

Рисунок 8. Настраиваемые роли в Start REQ

В разделе «Настройки» → «Управление пользователями» → «Системные роли» можно изменить системные роли или добавить новые с необходимыми правами.

Интеграции

Start REQ интегрирован с Jira — сформированные для продукта требования можно выгружать в таск-трекер как задачи. Обновление статуса по требованиям или комментарии к задаче видны в обеих системах. Количество задач в проекте Jira равно количеству требований. 

Вот ещё несколько функций, которые доступны в интеграции с таск-трекером:

• приоритетность задач указывается исходя из критической значимости рисков в требовании; 
• задачи можно фильтровать с помощью меток;
• удалённые требования в Jira отображаются с пометкой «Требование не актуально»;
• можно создавать уведомления на разных языках.

Рисунок 9. Настройки интеграции Start REQ с Jira

Интеграцию администратор настраивает в анкете автоматизированной системы, в каждом поле выбирая значение из выпадающего списка. 

Ещё одна особенность интеграции — уведомления. Администратор может выбрать в настройках из выпадающего списка уведомления для разных системных ролей — например, менеджер системы узнает об изменениях в анкетах, разработчик всегда будет в курсе новых требований. 

Start REQ информирует команды в Jira о важных событиях, таких как:

• новые угрозы и уязвимости в приложении;
• внутренние изменения, которые влияют на защищённость приложения;

• новые требования регуляторов и стандарты.

Ещё Start REQ можно интегрировать с Active Directory. После указания сервера и групп при создании соединения пользователи из AD интегрируются автоматически и с общесистемными правами. Например, пользователи из группы администраторов в Active Directory получат те же права и в Start REQ. 

Открытый API системы позволяет настраивать интеграцию и с другими внутренними и внешними системами: LDAP, SGRC, SIEM и пр. 

Аналитика

Руководители проектов и администраторы системы могут получать аналитику по процессу управления требованиями. На интерактивном дашборде показаны все изменения работы с требованиями по ИБ. Их можно распределить по дням, месяцам и годам.

Рисунок 10. Интерактивные дашборды для руководителей в Start REQ

По горизонтали на дашборде отображаются месяцы, а по вертикали — количество требований в трёх статусах реализации: «Новое», «В работе» и «Выполнено». 

Управление знаниями с помощью платформы Start EDU

Даже самой наполненной системы работы с требованиями будет недостаточно, если у команды не хватает конкретных знаний и навыков по безопасной разработке. Можно попытаться закрыть эту задачу классическими курсами, но часто они не отражают реальные контексты разработки и не стимулируют команду из-за неструктурированных материалов и скучной подачи. 

Для того чтобы приложения становились безопасными по методу Shift-Left Security, экосистема для продуктовых команд подразумевает использование Start REQ вместе с продуктом Start EDU — платформой интерактивного обучения для разработчиков. Так на одной платформе специалисты по безопасности приложений могут следить за выполнением требований, а тимлиды — назначать обучение по конкретным модулям, следить за уровнем компетенций сотрудников в реальных навыках безопасной разработки.

Start EDU на реальных рабочих ситуациях и контекстах объясняет, как реализовать выставленные требования по безопасности в ПО. Платформа автоматически назначает обучение с каждым новым требованием, собирает статистику обучения и составляет карты компетенций по конкретным уязвимостям и конфигурациям.

Как работает обучение в Start EDU

Шаг 1. Руководитель продуктовой команды заполняет анкету, в которой указывает характеристики ПО и распределяет разработчиков по командам. Заполнение анкеты автоматизированной системы раскрыто в обзоре в пункте «Требования».

Шаг 2. На основе этих данных платформа автоматически подбирает предустановленные обучающие темы (юниты) под уровень знаний разработчика и его рабочие проекты. Несколько юнитов по общей теме группируются в кластеры.

Рисунок 11. Связь требований и обучающих юнитов в Start REQ

С такой интегрированной системой легко отчитываться и видеть прогресс каждого разработчика — под каждым требованием есть связанные юниты и статистика по их прохождению. 

Рисунок 12. Раздел Start EDU показывает прогресс по каждому юниту и кластеру в целом

Обучающие юниты непрерывно обновляются с учётом лучших практик и новых уязвимостей. Кроме того, администраторы могут сами добавлять материалы, задания и лекции в систему. 

Модуль Start EDU также помогает выполнять требования ГОСТ Р 56939-2016. Среди обязательных мер по разработке безопасного ПО указаны обучение сотрудников и анализ программы обучения.

Архитектура продукта

Продукт построен по модульному принципу. Его устройство показано на схеме ниже.

Рисунок 13. Архитектура Start REQ

Системные требования продукта

Требования к окружению представлены в таблицах далее.

Таблица 3. Системные требования к целевой промышленной вычислительной инфраструктуре Start REQ

Таблица 4. Целевые параметры промышленной среды Start REQ

Сценарии использования продукта

Создание списка требований по безопасности приложения

Start REQ формирует требования для автоматизированных систем после заполнения анкеты. Алгоритм зависит от зрелости процессов ИБ. 

Рассмотрим основной сценарий работы. 

Рисунок 14. Расширенные настройки требований в Start REQ

Этап 1. Администратор определяет ключевые характеристики для всех систем организации. В разделе «Настройки» → «Характеристики АС» он составляет список всех параметров приложения, которые будут влиять на формирование требований. 

Рисунок 15. Добавление новых характеристик в Start REQ

На платформе через кнопку в правом верхнем углу можно добавлять и свои характеристики автоматизированных систем.

Этап 2. Пользователь добавляет требования и объединяет их с характеристиками. Обычно у компаний с высоким уровнем зрелости уже есть накопленные базы с требованиями — их можно загрузить в дополнение к предустановленным требованиям в Start REQ. Далее все требования связываются с характеристиками в разделе «Настройки» → «Шаблоны требований».

Рисунок 16. Список характеристик приложения в Start REQ

Пользователи Start REQ могут использовать десятки преднастроенных базовых характеристик приложения и добавлять свои, такие как:

• тип приложения;
• категория пользователей;
• тип технологического процесса;
• категория информации.

Этап 3. Пользователь заполняет анкету. Когда все характеристики и требования собраны, команда разработки в разделе «Системы» → «Добавить систему» заполняет анкету для своего приложения. В Start REQ также можно загрузить информацию о системах из уже существующих баз в организации.

Этап 4. Платформа формирует список требований. В подразделе «Требования анкеты АС» Start REQ сразу собирает актуальные требования для команды.

Рисунок 17. Связь характеристик приложения и источников требований в Start REQ

Пока пользователь заполняет анкету, требования из базы в настоящем времени синхронизируются со значениями в анкете и формируют готовый к работе список. Например, если пользователь указал, что он разрабатывает приложение на iOS, платформа выгружает из шаблонов все требования, связанные с этой операционной системой.

Когда список требований готов, каждый участник команды — технические писатели, разработчики, администраторы — видит конкретные задачи по своим ролям. Руководители видят ход работы над проектом в аналитических отчётах, а эксперты по ИБ ведут с разработкой общие задачи и проводят верификацию реализованных требований.

Анкета рисков

Администратор заполняет анкету рисков для всего проекта, а не для каждого отдельного приложения (такая анкета распространяется на все системы), и отвечает на вопросы о коммерческой тайне, персональных данных, доступе через интернет и других характеристиках. Каждому ответу в анкете присвоен вес, по нему рассчитывается уровень угрозы каждого риска для продукта: критический, высокий, средний, низкий. 

Рисунок 18. Шаблон анкеты рисков в Start REQ

Затем требования ранжируются по уровням рисков, где высокий уровень риска равен высокому приоритету выполнения требования: чем выше уровень угрозы, тем быстрее задачу нужно взять в работу. 

Рисунок 19. Маркировка уязвимостей по уровню критической значимости в Start REQ

Отчёты по критически значимым рискам можно скачать в виде JSON-файлов.

Выводы 

Start REQ помогает разработчикам и специалистам по безопасности действовать в одном пространстве и вместе следить за выполнением требований. Абстрактные требования по безопасной разработке превращаются в понятные для продуктовых команд задачи, которые можно синхронизировать с Jira и распределять по конкретным исполнителям. Безопасная разработка со Start REQ начинается ещё на этапе построения архитектуры — такой подход ускоряет выпуск продукта и снижает риск уязвимостей. 

Для специалистов по безопасности Start REQ обеспечивает контроль за соблюдением требований и улучшает взаимодействие с разработчиками за счёт единого рабочего пространства.

Достоинства:

• Снижается стоимость разработки за счёт уменьшения количества дефектов безопасности, выявляемых на этапах тестирования и эксплуатации.
• Приложения выпускаются без уязвимостей в коде, снижается риск простоев.
• Снижаются репутационные риски, связанные с возможным публичным взломом приложений и компрометацией клиентских данных.
• Сокращается площадь возможной цифровой атаки на предприятие.
• Срок прохождения ПСИ кратно уменьшается и не тормозит релиз. 
• Выполняются требования по безопасности цифровых продуктов и защите клиентских данных, в том числе по пп. 5.1 и 5.2 ГОСТ Р 56939-2016.
• Сертификация по стандартам безопасности проходит быстрее.
• Реализовываются лучшие практики и модули модели зрелости OWASP SAMM.
• Требования выгружаются мгновенно.
• Можно автоматизировать работу с помощью шаблонов.

Недостатки:

• Нет визуального отображения связей между характеристиками и требованиями, а также уязвимостей системы в виде диаграмм.
• Некоторые требования было бы полезно формировать в виде конфигурационных файлов, а не текста, чтобы сразу применять их во время развёртывания системы.
• Нет возможности задать экспертам вопрос по требованиям непосредственно из интерфейса системы.