Как внедрить систему безопасной разработки ПО
Как организовать систему безопасной разработки ПО в компании и с какими самыми частыми ошибками приходится сталкиваться.
2К открытий4К показов
Привет! Меня зовут Артем Казанцев, я эксперт по информационной безопасности в Tada (Proscom). Работаю в сфере ИБ более 9 лет. С 2016 по 2019 год занимался консалтингом в части обеспечения защиты информации государственных информационных систем и информационных систем персональных данных. С 2019-го начал приводить в соответствие разработку программного обеспечения, реализующего функции защиты информации, требованиям по сертификации с последующей сертификацией.
Эта статья пригодится разработчикам, которые, как и мы когда-то, задумываются об ИБ в продуктах и не знают, с чего начать.
Поскольку нашим продуктом будут пользоваться многие компании, в том числе те, которые должны соответствовать требованиям в части обеспечения ИБ, хранить и обрабатывать конфиденциальную информацию, нам было важно минимизировать вероятность реализации угроз информационной безопасности.
Как мы проверяли безопасность разработки в компании
Логичен вопрос, зачем вообще внедрять систему разработки безопасного ПО в компании? Регуляторы требуют — это понятно. Но есть ли другие, более насущные предпосылки? Разумеется:
- это снизит риск внезапного появления критических уязвимостей;
- повысит стабильность продукта и унификацию в языках, пакетах, внешних зависимостях;
- улучшит качество кода, компетенций команды инженеров в части безопасной разработки;
- компания сможет продавать продукт, не переживая за его безопасность.
Я пришел в Tada в конце 2022 года. На тот момент о безопасной разработке ПО (БРПО) в ней «слышали, но не погружались». Поэтому для начала мне нужно было понять:
- Какие меры уже реализованы и насколько хорошо?
- Действительно ли продукт безопасно разработан, и какие уязвимости, недочеты есть в ПО и в инфраструктуре разработки?
Поскольку у меня уже был опыт прохождения сертификационных испытаний по требованиям ФСТЭК России к уровням доверия (одно из требований – наличие у разработчика-изготовителя процедур БРПО и проведение анализа уязвимостей и недекларированных возможностей), я понимал, какие процедуры, меры и инструментальные виды анализа должны быть реализованы.
Кроме того, можно и нужно воспользоваться документами, которые помогают облегчить внедрение процедур разработки безопасного ПО:
- ГОСТ 56939-2016;
- Методика выявления уязвимостей и недекларированных возможностей в ПО ФСТЭК России (чтобы сертифицировать продукт).
И иными источниками: данными с конференций, презентациями компаний, в которых они делятся опытом (ТБ Форум, Kaspersky Certification Day и др.)
Дисклеймер: мы не претендуем на звание гуру MegaNanoExpertDevSecOpsGeneral и цель статьи не пытаться научить, а поделиться нашим опытом, который, возможно, окажется полезен тем, кто находится в начале ИБ-пути.
Вернемся к проверке компании. На тот момент команда уже проводила unit-тесты и функциональное тестирование ПО, что было уже хорошо и позволяло выявить явные ошибки в ПО, которые могут привести к угрозам безопасности:
- недостаточная аутентификация и авторизация;
- уязвимости ввода данных;
- утечка конфиденциальных данных;
- недостаточная обработка ошибок и другие.
Что касается оценки безопасности продукта, мы решили провести:
- Статический анализ исходного кода.
- Ручное тестирование (что-то типа функционального), чтобы выявить реальные баги в функциях ИБ ПО.
- Анализ уязвимостей заимствованных компонентов и компонент среды функционирования ПО.
- Динамический анализ и тестирование на проникновение.
Для этого мы выбрали следующие инструменты:
Результаты анализа оказались довольно интересными и местами даже неожиданными. Мы выявили около 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% защищенности нельзя, всегда нужно быть готовым оперативно и правильно реагировать на инциденты ИБ.
Планируем полностью автоматизировать инструментальные виды анализа
Состав используемых инструментов и видов анализа достаточно объемный и нет необходимости руками делать рутинную работу, которую можно автоматизировать и внедрить в процессы жизненного цикла ПО.
Планируем сократить кодовую базу и базу зависимостей
Унификация в языках программирования, исключение «мертвого кода», контроль используемых зависимостей нам в этом помогут.
Стремимся реализовать меры, которые позволят сертифицировать наше ПО и пройти процедуру оценки соответствия безопасной разработки ПО.
Скажем сразу, эта статья вводная. И основная ее идея — показать, насколько важно внедрять процедуры разработки безопасного ПО, особенно на раннем этапе разработки, когда это менее трудозатратно.
В следующих материалах мы расскажем о вопросах выбора и внедрения инструментальных средств и организационных мер, о проблемах, с которыми сталкивались и и вариантах их решения.
2К открытий4К показов