QIWI Security Development Lifecycle

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


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


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


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


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

image

Процессы


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


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


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


image

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


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


image

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


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

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


image

Для небольшого количества релизов этих шагов было бы достаточно. Но в нашем случае нужно было доработать процессы постановки задач и автоматизировать 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, информация о которой с одного из агентов отправляется в сервис контрольного центра. Он же делает ряд манипуляций с исходниками, отправляет их в сканер и начинает мониторинг.


image

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


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


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


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


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


QIWI Security Development Lifecycle


image

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


  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х человек;

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

QIWI
Ведущий платёжный сервис нового поколения в России

Comments 7

    0
    Молодцы! Действительно похоже на дизруптивный подход.
    Скажите пожалуйста а что имеется ввиду под ежегодными тренингами для разработчиков? Тренинги по разработке безопасного кода?
      0
      Да. Целевые тренинги по веб-безопасности и безопасной разработке, выполненные дополнительно еще в контексте используемых нами технологий. Плюс внутренние CTF, «неделя безопасности QIWI» и тому подобное.
      0
      Спасибо за статью. А что для SAST использовали? Я в статье не нашел упоминания. Если, конечно, можете раскрывать детали.
        0
        Можем. Checkmarx на данный момент.
          0
          Благодарю.
      • UFO just landed and posted this here
          0
          Если имеется ввиду время сканированяи, то время распрееляется примерно так
          — DAST, как я и говорил, трудно настроить на итеративное сканирование, т.к. придется определить наличие новых входных точек и измененных праметров. Поэтому DAST используем на момент предрелизного регрессионного тестирования. Такой скан на больших проектах может доходить до нескольких часов.
          — SAST хорошо подходит для итеративного сканирования, здесь он может занимать буквально несколько минут, т.к. ему понадобится только достроить новые графы, проходящие через новый код.

        Only users with full accounts can post comments. Log in, please.