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х чоловік;
І якщо спочатку завдання була пов'язана просто з змінами процесів для зручності роботи і впровадженням автоматизованих сканерів, то тепер можна з упевненістю сказати, що вона допомогла уникнути багатьох помилок в розробці додатків. А вони могли нам коштувати набагато більше ніж пара витрачених людино-років.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.