Как внедрить систему безопасной разработки ПО

Привет! Меня зовут Артем Казанцев, я эксперт по информационной безопасности в Tada (Proscom). Работаю в сфере ИБ более 9 лет. С 2016 по 2019 год занимался консалтингом в части обеспечения защиты информации государственных информационных систем и информационных систем персональных данных. С 2019-го начал приводить в соответствие разработку программного обеспечения, реализующего функции защиты информации, требованиям по сертификации с последующей сертификацией.

Эта статья пригодится разработчикам, которые, как и мы когда-то, задумываются об ИБ в продуктах и не знают, с чего начать.

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

Как мы проверяли безопасность разработки в компании

Логичен вопрос, зачем вообще внедрять систему разработки безопасного ПО в компании? Регуляторы требуют — это понятно. Но есть ли другие, более насущные предпосылки? Разумеется:

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

Я пришел в Tada в конце 2022 года. На тот момент о безопасной разработке ПО (БРПО) в ней «слышали, но не погружались». Поэтому для начала мне нужно было понять:

1. Какие меры уже реализованы и насколько хорошо?
2. Действительно ли продукт безопасно разработан, и какие уязвимости, недочеты есть в ПО и в инфраструктуре разработки?

Поскольку у меня уже был опыт прохождения сертификационных испытаний по требованиям ФСТЭК России к уровням доверия (одно из требований – наличие у разработчика-изготовителя процедур БРПО и проведение анализа уязвимостей и недекларированных возможностей), я понимал, какие процедуры, меры и инструментальные виды анализа должны быть реализованы.

Кроме того, можно и нужно воспользоваться документами, которые помогают облегчить внедрение процедур разработки безопасного ПО:

• ГОСТ 56939-2016;
• Методика выявления уязвимостей и недекларированных возможностей в ПО ФСТЭК России (чтобы сертифицировать продукт).

И иными источниками: данными с конференций, презентациями компаний, в которых они делятся опытом (ТБ Форум, Kaspersky Certification Day и др.)

Дисклеймер: мы не претендуем на звание гуру MegaNanoExpertDevSecOpsGeneral и цель статьи не пытаться научить, а поделиться нашим опытом, который, возможно, окажется полезен тем, кто находится в начале ИБ-пути.

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

• недостаточная аутентификация и авторизация;
• уязвимости ввода данных;
• утечка конфиденциальных данных;
• недостаточная обработка ошибок и другие.

Что касается оценки безопасности продукта, мы решили провести:

1. Статический анализ исходного кода.
2. Ручное тестирование (что-то типа функционального), чтобы выявить реальные баги в функциях ИБ ПО.
3. Анализ уязвимостей заимствованных компонентов и компонент среды функционирования ПО.
4. Динамический анализ и тестирование на проникновение.

Для этого мы выбрали следующие инструменты:

Результаты анализа оказались довольно интересными и местами даже неожиданными. Мы выявили около 200 critical и major (статический анализ) и 90 critical и high (анализ заимствованных компонент, динамический анализ и пентест).

Уязвимостей было много, и вот несколько наиболее интересных примеров:

1. Неправильная конфигурация turn-сервера

Для обеспечения обмена трафиком (видео/голос) мы используем turn-сервер. В ходе анализа мы выявили реквизиты доступа в открытом виде в файле features.json.

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

2. Хранимая XSS

Хранимая XSS (англ. Stored XSS) – это тип атаки на веб-приложение, при котором злоумышленник вводит вредоносный код (обычно JavaScript) на страницу веб-приложения, который сохраняется на сервере и затем отображается на странице для всех пользователей, которые обращаются к этой странице.

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

Достаточно вставить следующий payload XSS в некоторые формы ввода ПО, сгенерировать ссылку – приглашение и отправить жертве: \"--><img src=x onerror=alert("XSS")>.

При переходе по ссылке-приглашению устанавливается cookieinvitation_token. Затем ПО проверяет ее на наличие этого cookie. Если оно существует, то переадресовывает пользователя в асинхронном режиме независимо от того, где в веб-приложении находится пользователь. Это позволяет внедрять вредоносный скрипт в любом чате и месте веб-приложения с целью перехвата нажатий клавиш (кейлоггер).

Эти и другие уязвимости дали нам понять, что:

• необходимо внедрять БРПО на раннем этапе разработки;
• важно регулярно анализировать и обновлять уже имеющееся ПО и контролировать заимствованные компоненты. 

Чтобы устранить эти уязвимости и обеспечить безопасность нашего ПО, необходимо было принять соответствующие меры: исправить код, обновить зависимые компоненты, изменить архитектуру ПО.

Что мы сделали по итогам проверки

Поиск и устранение недостатков и уязвимостей в ПО – это малая и далеко не самая приоритетная часть на раннем этапе внедрения разработки безопасного ПО.

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

Как это прошло у нас

Отмечу, что руководство компании изначально было заинтересовано в сертификации продукта. А это возможно только в случае корректно внедренных мер БРПО. Нам оставалось только показать и доказать эту причинно-следственную связь.

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

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

Затем мы провели цикл лекций для всей команды:

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

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

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

Что будем делать дальше

После проверок и подведения результатов мы активно занимаемся повышением квалификации команды инженеров в части безопасной разработки и проводим семинары по ИБ.

Обучаемся и внедряем процедуры проведения фаззинг-тестирования

Фаззинг-тестирование — вид тестирования, который позволяет выявить уязвимости в ПО путем подачи на вход большого количества входных данных (отслеживание утечки памяти, аварийных завершений и так далее).

Изучаем порядок и способ определения поверхности атаки, включая использование Natch

Natch — полезный инструмент для определения поверхности атаки от наших коллег ИСП РАН.

Поверхности атаки — это интерфейсы и их модули в ПО, при использовании которых могут быть реализованы угрозы безопасности.

Разрабатываем метрики и сценарии реагирования на инциденты ИБ

Гарантировать 100% защищенности нельзя, всегда нужно быть готовым оперативно и правильно реагировать на инциденты ИБ.

Планируем полностью автоматизировать инструментальные виды анализа

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

Планируем сократить кодовую базу и базу зависимостей

Унификация в языках программирования, исключение «мертвого кода», контроль используемых зависимостей нам в этом помогут.

Стремимся реализовать меры, которые позволят сертифицировать наше ПО и пройти процедуру оценки соответствия безопасной разработки ПО.

Скажем сразу, эта статья вводная. И основная ее идея — показать, насколько важно внедрять процедуры разработки безопасного ПО, особенно на раннем этапе разработки, когда это менее трудозатратно.

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