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

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

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

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

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

Процессы

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

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

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

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

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

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

1. Ежегодные тренинги для разработчиков;
2. Build-система и налаженная система деплоя с возможностью откатов версий;
3. По мере сил — тестирование приложений, выходящих в релиз;
4. Программа на 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.

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

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

QIWI Security Development Lifecycle

Конечная схема получилась такой:

1. Постановка задачи и ее проектирование:
   
   • Привлечение ИБ на этапе начальной аналитики,
   • В случае внедрения сторонних продуктов — первоначальное тестирование (blackbox, whitebox, SAST, DAST).
2. Разработка с учетом тренингов, консультаций со стороны ИБ.;
3. Предрелизное автоматизированное тестирование. Итеративное SAST сканирование dev и тестовых веток в зависимости от build-ветки.;
4. Security-review в ISEC:
   
   • SAST релизных веток. В случае найденных уязвимостей ставится метка в build-системе о необходимости исправлений,
   • Регрессионный DAST,
   • Функциональное тестирование.
5. Релиз с последующими фидбэками от участников BugBounty-программы.

Немного сухой статистики:

• На текущий момент в постоянном сканировании находится 70 проектов, помимо тех, которые приходят извне;
• Проекты включают 7 основных языков программирования и обилие платформ;
• За первые пару месяцев внедрения, нашли порядка 25ти критичных уязвимостей на основных проектах;
• На Bug Bounty в два раза снизился поток репортов, конечно учитывая факт появления новых приложений и фич;
• Ну и наверное главное, концепция была внедрена за один год силами 2х человек;

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