QIWI Security Development Lifecycle

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

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

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

С чего начать? Наш план был прост:

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

Процессы

Шаблоны процессов разработки "Software Development Lifecycle" уже давно написаны, есть даже ГОСТ и ISO. Но о шаблонах построения «безопасной» разработки в нашей стране еще пару лет назад почти не было слышно.

По началу, двигателем идеи безопасной разработки был Microsoft. В терминологии редмодовского гиганта, Security Development Lifecycle — это процесс, который помогает разработчикам строить более безопасные приложения за минимум времени, следуя определенным правилам дизайна и разработки ПО.

Как к этому прийти? В общей концепции SDLC — это замкнутый цикл процессов, например, как у Microsoft. Для себя мы выделили такие ступени процессов:

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

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

На момент старта QSDLC, у нас были:

Ежегодные тренинги для разработчиков;
Build-система и налаженная система деплоя с возможностью откатов версий;
По мере сил — тестирование приложений, выходящих в релиз;
Программа на HackerOne;

Так что следуя шаблону, мы покрывали 3 важных пункта.

Для небольшого количества релизов этих шагов было бы достаточно. Но в нашем случае нужно было доработать процессы постановки задач и автоматизировать security-тесты.

Постановка и проектирование задачи

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

Для себя мы выделили основные пункты при которых требуется ИБ-аналитика задач:

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

Затраты на этот этап небольшие, но он позволяет

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

Автоматизация

DAST

Он же Dynamic Application Security Testing. И как бы странно это не звучало, для веб-приложений мы просто взяли Burp Suite т.к. он был уже хорошо знакомым и незаменимым инструментом в работе. Помимо этого у сканера есть отличный API для доработки под наши хотелки. Возможно, кто-то скажет, что это всего -лишь настольный инструмент для пентестеров, но на деле он может покрывать и требования энтерпрайза.

В контексте SDLC это:

Сканы по расписанию и по событию (новые релизы);
Первичная оценка приложения;
Точечный скан, беспорядочный fuzzing и нагрузка приложения;
Благодаря открытому API может быть дописан под каждый определенный проект, полный контроль над инструментом;

Чего не может качественно покрыть динамическое сканирование, так это нахождение всех входных точек в приложении (впоследствии проблему решили проксированием трафика на конечных тестовых нодах и автотестах QA, но не спасет от каких-то непредусмотренных сценариев).

Чего DAST в принципе не может покрыть:

Нахождение уязвимостей второго порядка (не 100% покрытие);
Трудно разделить измененные и неизмененные входные точки. Соответственно, сканирование проходит по всему приложению, из-за чего время сканирования может сильно растянуться;
Опасность искажения продуктовых данных в случае сканирования на боевых проектах.

SAST

Лучшим вариантом автоматизации на тот момент, казалось, должен быть SAST, Static Application Security Testing — статическое сканирование исходных кодов приложений на потенциальные уязвимости.

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

По этим данным и имеющимся в сканере знаниям об антипаттернах и плохих практиках, sast-tool находит потенциальные ошибки безопасности.

Чем SAST-сканер принципиально отличается от DAST и лучше в связке SDLC:

Можно повесить запуск сканирования на commit-hook в системе контроля версий и указать, какие именно ветки репозитория сканировать;
В отличие от DAST не надо ждать выкладки в тестовую/боевую среду рабочего приложения;
Одинаково хорошо подходит для сканирования всех платформ (web, desktop, mobile);
Можно сканировать приложение итеративно — просвечивать только измененные графы вызовов. Время сканирования сильно уменьшается без потери покрытия кода.

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

SDLC подразумевает непрерывный жизненный цикл разработки

Общий пункт, относящийся к любому из типов сканеров.

Сканер всего лишь инструмент, и его нужно запускать в правильный момент, желательно повесив на какие-то события во времени. Помимо этого в SAST, чтобы скан прошел по всем данным проекта и его зависимостям, нужно собрать код всех зависимостей проекта. И не все сканеры умеют делать это сами. А еще было бы здорово мониторить появления новых срабатываний на последующие сканы, получать о них рассылки, вешать метки в билд-системах о чистых сборках и сборках содержащих баги.

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

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

Обилие проектов, первоначальное сканирование

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

Изначально придется просмотреть все срабатывания, которые появятся в отчете. В зависимости от специфики проекта/языка будет много False Positive. И пока не указаны сигнатуры точек приложения, сканер будет утверждать, что абстрактная связка методов setName — getName в классе, описывающем модель — это Reflected XSS.

Так же кастомная логика должна быть описана для всех домашних разработок. Если вы пишите свои фреймворки, придется написать и свои правила поиска. За время внедрения сканера мы собрали более сотни таких правил для разных языков и проектов.

И нужно смириться с тем, что инструмент поддерживает не все языки и фреймворки, по крайней мере, на текущий момент