Обзор МТС RED ASOC 1.0, платформы управления безопасной разработкой

1. Введение
2. Функциональные возможности МТС RED ASOC
3. Архитектура МТС RED ASOC
4. Системные требования МТС RED ASOC
5. Подготовка работы с системой в зависимости от роли пользователя
   1. 5.1. Роль «Администратор системы»
   2. 5.2. Роль «Владелец продукта» (процессы управления продуктами и командами)
   3. 5.3. Роль «Юрист» (процессы управления лицензиями)
   4. 5.4. Роль «Специалист AppSec» (процессы управления уязвимостями)
6. Общие возможности системы для любых ролей
7. Выводы

Введение

В настоящее время внедрение процесса безопасной разработки (SSDLC) является необходимым для многих организаций. Причин для этого несколько. Во-первых, автоматизация производственных и бизнес-процессов влечёт за собой увеличение количества разрабатываемых систем, взлом которых может вылиться в финансовые, имиджевые и иные потери. Во-вторых, многие заказчики предъявляют повышенные требования к качеству разрабатываемого ПО, неотъемлемой составляющей которого является безопасность кода. В-третьих, публикации разработанных приложений в интернете приводят к тому, что доступ к ним получают в том числе и злоумышленники, что необходимо учитывать при анализе возможностей нарушителя.

Наша редакция регулярно проводит эфиры на тему разработки безопасного ПО и лучших практик SSDLC. Во время последнего из них проводился опрос аудитории, показавший, что в 2023 г. лишь 29 % респондентов внедрили все лучшие практики безопасности процесса CI / CD или используют более трёх инструментов для повышения защищённости разрабатываемого ПО.

Рисунок 1. Результаты опроса о принимаемых мерах по безопасной разработке

Главной проблемой при внедрении SSDLC в компании является проблема дефицита кадров и соответствующих компетенций — об этом заявили 50 % опрошенных.

Рисунок 2. Опрос о проблемах при внедрении SSDLC

Первый вопрос, который встаёт при внедрении SSDLC, — какие инструменты применять для анализа кода в рамках процесса безопасной разработки? Подобных инструментов на рынке десятки, и их выбор весьма затруднителен для тех, кто впервые внедряет этот процесс.

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

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

Справиться с вышеописанными трудностями и решить задачи по автоматизации управления разработкой безопасного ПО поможет платформа МТС RED ASOC 1.0, выпущенная в ноябре 2023 года.

Функциональные возможности МТС RED ASOC

MТС RED ASOC представляет собой комплексное техническое решение, сочетающее в себе несколько классов продуктов.

ASOC (Application Security Orchestration & Correlation) — это оркестрация и корреляция мер по безопасности приложений. Решение обеспечивает централизованное управление процессами безопасной разработки: фильтрацией уязвимостей в ПО с помощью различных инструментов анализа, корреляцией результатов, их приоритизацией по степени критической значимости и представлением сводной информации в едином интерфейсе. Это позволяет быстрее и эффективнее выстроить процессы исправления дефектов в коде приложений.

Оркестрация

Эта функциональность решений класса ASOC подразумевает автоматизированный запуск инструментов по анализу защищённости ПО и управление ими. Платформа МТС RED ASOC управляет несколькими встроенными статическими анализаторами кода (SAST), композиционным анализатором (OSA / SCA), а также модулем визуализации и отчётности. В перспективе к набору инструментов добавится динамический анализатор защищённости ПО (DAST). Кроме того, отличительной особенностью системы является возможность интегрировать в неё сторонние инструменты анализа. Это позволяет обеспечить наиболее эффективное применение практик разработки безопасного ПО.

Корреляция

МТС RED ASOC обладает возможностью сопоставлять полученные из различных инструментов анализа данные об уязвимостях и приоритизировать их для дальнейшей обработки. Для того чтобы привести отчёты всех анализаторов в единый вид, выполняется нормализация результатов. Затем проводится корреляция для выявления связей между различными типами уязвимостей, для их группировки и формирования итогового списка дефектов, с которыми начинает работать специалист по AppSec. Это экономит время аналитиков и уменьшает нагрузку на команду при решении задачи устранения уязвимостей в ПО.

Интеграция

Платформа МТС RED ASOC интегрируется в среду разработки компании, после чего с помощью платформ CI / CD можно реализовать автоматизированный запуск сканирований, получение отчётов и создание объектов сканирования. Доступна интеграция с системами следующих классов:

• CI / CD: Jenkins, GitLab;
• Defect Tracking: Jira;
• Source Code: GitHub, GitLab, TFS, Bitbucket;
• Software Artifacts: Nexus Repository;
• SAST: коммерческие и опенсорсные анализаторы (список доступен по запросу).

Также в платформе есть интеграция с системами единого входа (SSO) для управления доступами и почтой с целью аутентификации и отправки уведомлений.

Поддержка языков программирования

Встроенный в платформу механизм SAST поддерживает сканирование исходного кода на следующих языках программирования: Python, Java, JavaScript, TypeScript, C / C++, C#, Ruby, Golang, Kotlin, PHP, Dart, Swift, Shell, Elixir, Terraform.

Инструмент композиционного анализа (OSA / SCA) поддерживает следующие языки программирования: Golang, Java, C#, TypeScript, JavaScript.

Управление доступом

Модель доступа в системе достаточно гибка, чтобы удовлетворить потребности разных заказчиков. Можно управлять доступом каждого пользователя ко всем разделам платформы вручную или автоматически при первом входе в систему, а также администрировать целые группы пользователей (команды), предоставляя либо отзывая доступ к конкретным продуктам или репозиториям.

Панели мониторинга (дашборды) и метрики

Платформа содержит набор дашбордов и метрик для оценки процессов безопасной разработки: статистика по выявленным уязвимостям, динамика управления уязвимостями, оценка уровня безопасности продукта, информация по используемым в продукте лицензиям и другие. В настоящее время пользователям доступен готовый набор дашбордов, в перспективе в решении появится мастер настройки мониторинговых панелей.

Архитектура МТС RED ASOC

МТС RED ASOC представляет собой комплексное решение, состоящее из пяти основных модулей:

• модуль корреляции и приоритизации;
• модуль оркестрации;
• статические анализаторы кода (набор SAST-решений);
• композиционный анализатор (OSA / SCA);
• модуль визуализации и отчётности.

Принцип взаимодействия пользователей с платформой отражён на рисунке 3 ниже. Команда разработки готовит код для анализа, размещая его в репозиториях, которые подключаются к МТС RED ASOC. Платформа, используя инструменты оркестрации, передаёт код и информацию о применяемых программных компонентах в статический и композиционный анализаторы. Итоги проверки соотносятся между собой, приоритизируются в соответствии с критической значимостью выявленных дефектов и поставляются в единообразном виде в интерфейс системы. Отчёт анализируется основными подразделениями, задействованными в создании программного обеспечения. Как правило, это владельцы продуктов, команда отвечающая за безопасную разработку, программисты и юристы. После анализа дефектов формируются задачи на их исправление, затем процедура повторяется.

Рисунок 3. Архитектура МТС RED ASOC

Системные требования МТС RED ASOC

Для корректной работы системы предъявляются следующие требования к автоматизированным рабочим местам (АРМ) и серверам.

Таблица 1. Минимальные системные требования к АРМ пользователя

На АРМ требуется установить антивирусное ПО с актуальными базами данных и регулярным обновлением, а также убедиться, что брандмауэр (если он есть) настроен для безопасной работы с платформой МТС RED ASOC.

Для развёртывания платформы, поддерживающей работу с 10 активными продуктами (в среднем по 20 репозиториев в каждом), и обеспечения 40 сканирований кода в сутки с применением SAST и SCA требуются следующие ресурсы.

Таблица 2. Минимальные системные требования к серверам

Подготовка работы с системой в зависимости от роли пользователя

Вход в систему возможен с помощью логина и пароля либо через SSO. Функциональность, доступная после этого пользователю, зависит от его роли. Сразу отметим, что практически во всех статусах доступны фильтры и массовые операции, позволяющие выполнить одно действие, например, сразу для нескольких уязвимостей.

Роль «Администратор системы»

Администратору доступны все возможности продукта, но в основном сфера его интересов — общие настройки системы. Он может не только добавлять репозитории, где хранится исходный код приложений, но и управлять пользователями: добавлять их, деактивировать и восстанавливать.

В системе предусмотрено управление как одиночными пользователями, так и командами (группами): администратор устанавливает их уровни доступа, роли в системе, а также может поменять описание. Для каждого пользователя администратор выбирает готовую роль с заранее заложенными функциями или создаёт новую. Пока создание роли возможно только через базу данных платформы, но в будущем эта функция появится и в интерфейсе.

Для взаимодействия с ИТ-инфраструктурой компании в пункте меню «Интеграции» администратор может подключить SSO-аутентификацию (рис. 4) и почтовый сервер для отправки уведомлений от системы, также предусмотрена интеграция с Jira (рис. 5).

Рисунок 4. Настройка интеграции с SSO в МТС RED ASOC

Рисунок 5. Интеграция с Jira в МТС RED ASOC

Для работы МТС RED ASOC нужна лицензия. Задача администратора — получить файл с информацией о ней и загрузить его в систему. Лицензия ограничена по времени действия, количеству пользователей и по числу потоков кода, которые проверяются одновременно. У администратора есть возможность скопировать сведения о лицензии (когда надо переслать информацию о ней) или загрузить новый файл (рис. 6). 

Рисунок 6. Импорт новой лицензии в МТС RED ASOC

В настроенной и работающей системе роль администратора позволяет изменить уровни риска для компонентов продукта в зависимости от их лицензии: решение принимает юрист, который отсылает запрос на изменение администратору. Сейчас эти настройки осуществляются через конфигурационный файл конкретного продукта, но в будущем появятся и в интерфейсе. 

В целом, роль администратора позволяет настроить корректную работу системы с ИТ-инфраструктурой компании.

Роль «Владелец продукта» (процессы управления продуктами и командами)

Роль владельца продукта позволяет добавлять в МТС RED ASOC новые продукты и следить за их состоянием — сколько уязвимостей в них найдено и каких именно. Однако при этом она не предусматривает операций по изменению статусов уязвимостей. Эта роль позволяет регистрировать новые продукты в системе, исправлять их описание и удалять их. Каждому владельцу доступны лишь те продукты, которыми он управляет (рис. 7).

Рисунок 7. Интерфейс МТС RED ASOC с представленными в нём продуктами

В МТС RED ASOC продукт представляет собой папку, в которую вложены составляющие его репозитории, владелец может добавлять последние к продукту. Вся статистика по репозиториям будет сгруппирована и отражена в карточке продукта с данными о результатах статического и композиционного анализа.

Владельцу продукта доступна информация о найденных уязвимостях с их ранжированием по уровню критической значимости, а также о суммарном количестве уязвимостей в продукте. В карточке продукта также отображаются тип, статус, количество репозиториев и логин владельца. В описании продукта можно изменить тип (внутренний или внешний продукт), статус (разработка, тест, промышленная эксплуатация, коммерческая эксплуатация), ссылку на Jira, название и логин владельца (рис. 8). Планируется добавить интеграцию с Jira, чтобы автоматически отправлять в неё задачи на исправление ошибок или устранение уязвимостей.

Рисунок 8. Редактирование продукта в МТС RED ASOC

В карточке продукта можно запустить сканирование репозиториев (рис. 9) и посмотреть уязвимости по всем репозиториям, которые в него входят.

Рисунок 9. Запуск сканирования продукта в МТС RED ASOC

Представленная в репозиториях статистика по уязвимостям распределена по типам данных: количеству найденных, подтверждённых и направленных на устранение уязвимостей, объёму уязвимостей на 1000 строк кода или определённое количество библиотек и т. п. — соответствующую информацию владелец продукта может просмотреть в разделах меню «SAST» и «SCA».

При просмотре статистики в разделе «SAST» владелец продукта увидит краткую или подробную информацию по уязвимостям (рис. 10), вплоть до места в коде, где они обнаружены (рис. 11). Но при этом ему недоступны операции по изменению уязвимости: подтверждать или изменять статус критической значимости, направлять уязвимость на исправление и т. п. может только пользователь с ролью «Специалист AppSec», о которой речь пойдёт ниже.

Рисунок 10. Детальная информация об уязвимости в МТС RED ASOC

Рисунок 11. Исходный код файла с подсветкой уязвимости

Структура раздела «SCA» выглядит немного по-другому. В начале отображаются обнаруженные сканером компоненты (библиотеки / зависимости), для каждого из которых можно посмотреть список известных уязвимостей (рис. 12). Владелец продукта и в этом случае не вправе менять статусы их критической значимости, но может получить описание уязвимости и даже посмотреть ссылки на ознакомительные материалы о ней, а также добавить комментарии.

Рисунок 12. Компоненты, обнаруженные SCA, в МТС RED ASOC

Раздел «Репозитории» позволяет посмотреть информацию обо всех репозиториях, добавленных в продукт (рис. 13): статистику по уязвимостям для каждого репозитория в разрезе метода анализа и уровня критической значимости, ссылку на репозиторий в гит-хостинге (в нашем случае — GitLab); узнать владельца репозитория и время последнего сканирования. Также можно запустить сканирование для конкретного репозитория. Такая вложенная иерархическая структура сохраняется для всего продукта.

Рисунок 13. Информация о репозиториях в МТС RED ASOC

Владельцу продукта доступен удобный дашборд (рис. 14), где в графическом виде представлены информация о состоянии продукта, топ уязвимых репозиториев, данные по статусам сканирований, по плотности дефектов, по языкам в продукте и пр. Также в дашборде отображаются динамика устранения уязвимостей и топ лицензий, используемых в компонентах системы (рис. 15), данные об уязвимых репозиториях, последние комментарии в продукте, последние сканирования продукта.

Рисунок 14. Дашборд владельца продукта с основной статистикой в МТС RED ASOC

Рисунок 15. Дашборд владельца продукта с динамикой уязвимостей и используемыми лицензиями

Владелец может управлять доступом конкретных пользователей к принадлежащим ему продуктам. При этом он не вправе поменять роль пользователя — это прерогатива администратора.

Роль «Юрист» (процессы управления лицензиями)

По сравнению с владельцем продукта, юрист не может создавать продукт и добавлять в него репозитории. Его работа заключается в оценке рисков, поэтому он может просматривать некоторые результаты сканирования — например, видеть обнаруженные лицензии на используемые в проверяемом коде продукты (рис. 16), а также информацию о том, в каких репозиториях и библиотеках эти лицензии применяются.

Рисунок 16. Список обнаруженных лицензий компонентов продукта в МТС RED ASOC

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

Для роли «Юрист» разработан свой дашборд (рис. 17). В нём представлены приоритизация лицензий по уровню риска и статистика по компонентам, в которых лицензии используются. Графически на дашборде юриста отображаются самые востребованные лицензии и динамика их применения. Также можно открыть список, в котором отражено то, к каким компонентам относятся найденные лицензии. При этом отдельно отмечается, если лицензия компонента неизвестна.

Рисунок 17. Дашборд юриста в МТС RED ASOC

Роль «Специалист AppSec» (процессы управления уязвимостями)

Роль специалиста по AppSec (или DevSecOps) позволяет непосредственно работать с уязвимостями: изменить критическую значимость (рис. 18) и описать причину изменения, отправить уязвимость на исправление, принять риск или признать срабатывание ложноположительным. При этом статус уязвимости может быть как постоянным, так и временным: например, система позволяет на определённый срок принять риск, а позже поставить задачу на исправление.

Рисунок 18. Изменение критической значимости уязвимости в МТС RED ASOC

Именно в роли специалиста по AppSec удобно использовать вышеупомянутые возможности фильтрации и выполнения массовых операций (рис. 19) — например, выбрать уязвимости по статусу критической значимости и оставить комментарий сразу для всех.

Рисунок 19. Массовое изменение статуса и выставление комментариев для уязвимостей в МТС RED ASOC

Естественно, специалисту доступна сводка по отфильтрованным уязвимостям, по выбранному репозиторию или по ветке. Можно активировать или деактивировать ветку, что определяет, будет ли она просканирована. Кроме ручного запуска можно запустить сканирование по времени: в этом случае периодичность проверки продуктов определяется интервалом, который установлен администратором в конфигурационном файле.

Общие возможности системы для любых ролей

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

Также предусмотрена функция по формированию портфеля продуктов. Если репозитории — это составные элементы продуктов, то портфель, наоборот, — более высокий иерархический уровень, в котором можно собирать продукты. Соответственно, дашборд графически будет отображать уже более общую картину, касающуюся портфеля в целом и отдельных продуктов внутри него (рис. 20).

Рисунок 20. Продукты в портфеле в МТС RED ASOC

Для всех пользователей системы доступен личный кабинет, где на данный момент есть два пункта меню: «Личные данные» и «Мои команды». В личных данных отображаются логин, Ф. И. О., роль, электронный адрес и ключ Public API. Последний позволяет взаимодействовать с системой через API, если требуется провести не предусмотренные сейчас в графическом интерфейсе операции. Обычно это актуально для технических специалистов. В меню «Мои команды» можно посмотреть, в какие команды пользователя добавили коллеги.

Репозитории в системе могут быть связаны с репозиториями на GitHub, GitLab или другом удобном хостинге (рис. 21). Также в пункте «Репозитории» предусмотрена возможность загрузить отдельный репозиторий в виде архивного файла, после чего проверить его на уязвимости. Это важно для пользователей, которые хотят разово просканировать конкретные версии продукта — например, для дальнейшей сертификации.

Рисунок 21. Подключение репозитория в МТС RED ASOC

В графическом интерфейсе доступны основные возможности системы, включая автоматизацию сканирования и предоставления отчётов. Также можно получить доступ ко всем функциям через консольную утилиту или через вызовы API — как будет удобнее пользователю.

Выводы

МТС RED ASOC — платформа, которая за счёт удобного управления инструментами анализа защищённости ПО, корреляции и приоритизации результатов анализа позволяет повысить эффективность обработки уязвимостей и, как следствие, соблюсти требуемую скорость вывода на рынок (Time-To-Market) программного обеспечения.

Использование платформы даёт возможность минимизировать штат дефицитных на рынке специалистов по AppSec, снизить количество реальных уязвимостей в приложениях, упростить оценку уровня безопасности приложений, управлять процессами SSDLC и повысить их эффективность, снизить затраты на устранение уязвимостей в ПО, в том числе за счёт их обработки на ранних стадиях (Shift Left), обеспечить юридическую чистоту кода.

Платформа активно развивается. На данный момент в планах — развитие продукта в части динамического сканирования средствами DAST, интеграция с отечественными инструментами анализа защищённости ПО. Ещё одна особенность МТС RED ASOC — использование ядра собственной разработки.

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

• Собственный механизм оркестрации и приоритизации.
• Большое количество интеграций со сторонними продуктами вне зависимости от их разработчиков (вендоронезависимость).
• Упрощение процесса безопасной разработки.
• Анализ юридической чистоты используемых компонентов.
• Наглядные дашборды.
• Интересная, продуманная ролевая модель.

Недостатки:

• Отсутствует динамический анализ кода (появится в 2024 году).
• Отсутствует облачная реализация платформы (запланировано на 2025 год).
• Отсутствует в реестре отечественного ПО (в настоящее время проходит процедуру включения в реестр).
• Ряд функций ещё не реализован в графическом интерфейсе.