Как быстро внедрить DevSecOps
и не менять привычную разработку?
Кейс «Атомик Софт» и Apsafe

«Альфа платформа» — это инструментальная среда для создания автоматизированных систем управления технологическим процессами (АСУ ТП): HMI, SCADA, многоуровневых систем диспетчеризации и других решений. У платформы модульная архитектура — есть «базовое ядро», которое отвечает за управление, мониторинг и хранение данных, а также дополнительные модули для его кастомизации под задачи конкретного предприятия.

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

Скорость и «бесшовность» интеграции были основными аргументами в пользу Apsafe — экосистемы инструментов безопасной разработки, которая обеспечивает легкий старт
и ручную верификацию результатов проверок.

С Apsafe внедрение DevSecOps занимает не более 10 дней. Помимо широкого набора инструментов, Заказчик получает экспертную поддержку специалистов УЦСБ, поэтому
в итогах анализа кода не будет ложных срабатываний. Решение позволяет не перестраивать привычный процесс разработки, а органично добавить в него безопасность, что особенно важно при интеграции с инфраструктурой Заказчика.

Кроме того, эксперты УЦСБ обеспечивают документальное сопровождение проекта
и обновляют руководство по безопасной разработке для Заказчика.

Для проведения анализа защищенности «Альфа платформы» ее исходный код должен передаваться в Apsafe из Jenkins — это автоматизированная система сборки и обновления ПО, в которой работают «Атомик Софт». Чтобы этот механизм функционировал без сбоев, специалисты УЦСБ разработали скрипт, встроенный Заказчиком в Jenkins.

Теперь Jenkins отправляет в Apsafe исходный код, где он проверяется на уязвимости и затем верифицируется AppSec-инженером. Результаты проверок систематизируются на интерактивных дашбордах в личном кабинете Apsafe, а задачи на устранение уязвимостей передаются в таск-трекер Заказчика.

В итоге благодаря Apsafe практики DevSecOps стали органичным элементом системы разработки Заказчика: сборка, тестирование и анализ защищенности работают в ней
как единый автоматизированный процесс.

Для работы с «Альфа платформой» использовались различные виды анализа из стека инструментов Apsafe, которые помогли выявить и исправить несколько уязвимостей.

1. SAST (Static Application Security Testing) — статический анализ кода, который позволяет находить дефекты в исходном коде продукта в момент его разработки.

Инструменты статистического анализа обнаружили ошибки, из-за которых система могла запускать внешние файлы без проверки. Это создавало риски их подмены злоумышленниками и активации вредоносного кода. Специалисты УЦСБ передали информацию об уязвимостях разработчикам «Альфа платформы», и команда «Атомик Софт» исправила ошибки в следующем релизе продукта.

2. SCA (Software Composition Analysis) — композиционный анализ состава ПО для обнаружения угроз в подключаемых компонентах и соблюдения политик использования открытого кода.

В больших проектах, таких как «Альфа платформа», часто используются сторонние библиотеки с открытым исходным кодом. Они ускоряют разработку, но иногда содержат известные уязвимости, которые могут быть описаны в Банке данных угроз безопасности информации ФСТЭК России или других источниках.

Разработчики не всегда успевают быстро закрыть эти уязвимости. SCA помогает выявить такие компоненты, вовремя их обновить или заменить на безопасные версии.

3. DAST (Dynamic Application Security Testing) — динамический анализ безопасности приложения. Он выявляет уязвимости методом «черного ящика» в работающем ПО,
когда тестирование проводится без доступа к исходному коду. Похожим образом действуют злоумышленники.

С его помощью эксперты УЦСБ обнаружили что, если сотрудник уже авторизован в системе, хакер мог отправить через браузер опасную команду от имени оператора. Для усиления безопасности была добавлена защита запросов — проверка источника запроса
и подтверждение подлинности действия пользователя.

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

Также для «Альфа платформы» проводилось фаззинг-тестирование, при котором ПО подвергается воздействию большого объема неверных входных данных. Этот метод эффективен для обнаружения ошибок и уязвимостей, часто остающихся незамеченными
при других способах тестирования.

Фаззинг обязателен для продукта Заказчика — это требование Приказа №239 ФСТЭК России. Он помог выявить несколько ошибок, которые были устранены специалистами «Атомик Софт».

Проведенные проверки и совместная работа команд «Атомик Софт» и Центра кибербезопасности УЦСБ позволили наладить процессы DеvSecOps и подготовить документацию, которые усилили безопасность продукта и повысили его конкурентоспособность.

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

Организована ежемесячная отчетность по результатам анализа — результаты проверок систематизируются на интерактивных дашбордах, доступных в личном кабинете Apsafe. Задачи и информация по уязвимостям передаются в таск-трекер Заказчика.

Также специалисты УЦСБ каждый месяц готовят подписанные бумажные отчеты. Их можно использовать как еще один аргумент для клиентов «Атомик Софт», подтверждающий, что «Альфа платформа» разрабатывается с использованием принципов DevSecOps.

Разобраны причины возникновения уязвимостей и способы их исправления — каждый тип найденной уязвимости эксперты УЦСБ разбирали вместе с разработчиками «Альфа платформы» и превращали в обучающий кейс. В нем объясняется, почему возникает уязвимость, как этого избежать и сформировать правила, по которым будет писаться безопасный код в похожих случаях.

Получившиеся правила встроили в процесс код-ревью, что позволило повысить безопасность продукта.

Выполнение регуляторных требований, в частности пункта 29.3 Приказа №239 ФСТЭК России. Согласно ему, у разработчика должно быть руководство по безопасной разработке программного обеспечения и ряд других обязательных документов. При этом ПО должно проверяться статистическим анализом кода и фаззинг-тестированием.

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