Тестування безпеки

🌐 Цей документ доступний українською та англійською мовами. Використовуйте перемикач у правому верхньому куті, щоб змінити версію.

1. Вступ

Мета підходу з тестування безпеки — окреслити стратегію, цілі та обсяг тестування безпеки Платформи реєстрів. Такий підхід детально описує, як ідентифікувати та усувати вразливості безпеки щоб забезпечити захист конфіденційних даних і зберегти цілісність програми.

1.1. Обсяг тестування безпеки

Тестування безпеки зосереджено на виявленні вразливостей у веб-додатку Платформи реєстрів та відповідній інфраструктурі. Воно охоплює такі області, як автентифікація, авторизація, перевірка введених даних, керування сеансами, шифрування даних і безпечне налаштування.

1.2. Цілі

Головні цілі тестування безпеки:

  • Визначити вразливі місця та слабкі сторони безпеки застосунку.

  • Оцінити ефективність існуючих засобів контролю безпеки.

  • Усунути виявлені вразливості та покращити загальну безпеку.

1.3. Посилання

Платформа реєстрів розробляється у відповідності до наступних стандартів безпеки:

  • Управління безпекою програмного забезпечення відповідно до Моделі зрілості програмного забезпечення OWASP (OWASP Software Assurance Maturity Model, SAMM).

  • Проект стандарту перевірки безпеки програми OWASP (OWASP Application Security Verification Standard [ASVS] Project) як основа для тестування засобів контролю технічної безпеки веб-додатків і джерело вимог для безпечної розробки.

  • Посібник з безпеки ланцюга поставок програмного забезпечення Центру безпеки в Інтернеті (Center for Internet Security Software Supply Chain Security Guide, CIS SSCS) як основа безпеки ланцюга поставок.

  • Комплексна система захисту інформації (Comprehensive information protection system, CIS) — законодавча сертифікація засобів контролю інформаційної безпеки та комплекс технічних заходів, що забезпечують захист інформації в системі інформаційно-комунікаційних технологій (Information and Communication Technology, ICT).

2. Підхід з тестування безпеки

2.1. Методології тестування безпеки

Тестування безпеки поєднує підходи з ручного та автоматичного тестування. Воно включає сканування вразливостей, тестування на проникнення, перевірку коду, безпеку GitOps, керування безпекою в хмарі та аналіз найкращих практик безпеки.

Методології тестування безпеки — це систематичні підходи, які використовуються для виявлення та оцінки вразливостей і слабких місць безпеки в програмах, мережах або системах. Вони допомагають забезпечити ефективне та всебічне тестування безпеки. Ось список використаних методологій тестування безпеки:

  • Тестування на проникнення (пентест): Тестування на проникнення, яке інколи називають "етичним хакерством" або "пентестом" (від англ. pentest), — це метод оцінки безпеки комп’ютерної системи, мережі, програми чи організації шляхом імітації реальних кібератак. Основною метою тестування на проникнення є виявлення вразливостей і слабких місць, якими можуть скористатися зловмисники для компрометації системи або викрадення конфіденційної інформації.

  • Моделювання загроз: Моделювання загроз включає виявлення потенційних загроз і ризиків для системи або програми. Це допомагає зрозуміти можливі вектори атак і приймати обґрунтовані рішення щодо заходів безпеки. Ми прагнемо застосувати безперервне моделювання загроз, що є ітеративним і безперервним процесом виявлення й аналізу потенційних загроз і безпекових ризиків протягом усього життєвого циклу розробки програмного забезпечення.

  • Безпечний життєвий цикл розробки програмного забезпечення (Secure Software Development Lifecycle [SSDLC]): Це структурований і системний підхід до розробки програмного забезпечення, який інтегрує методи безпеки на кожному етапі процесу розробки.

  • Оцінка безпечності архітектури: Цей підхід гарантує, що архітектура програми та інфраструктури адекватно задовольняє всі належні вимоги безпеки та відповідності, а також достатньою мірою зменшує виявлені загрози.

2.2. Використані інструменти та технології

Під час тестування безпеки використовуються такі види, інструменти та технології:

Вид тестування безпеки Набір інструментів

Статичне тестування безпеки програми (Static Application Security Testing, SAST)

Semgrep

Аналіз складу програмного забезпечення (Software Composition Analysis, SCA)

  • CycloneDx SBOM

  • OWASP Dependency Track

Сканування секретів

Detect Secrets

Безпека інфраструктури як коду (IaaC)

KICS

Безпека оркестрування контейнера

Kube bench

Безпека контейнера

Trivy

Динамічне тестування безпеки додатків (Dynamic Application Security Testing, DAST)

OWASP ZAP

Керування безпекою в хмарі

Qualys CloudView

2.3. Опис тестового середовища

Тестування безпеки постійно проводиться в окремому середовищі, схожому на виробниче, яким володіє та керує команда безпеки.

3. Сценарії тестування безпеки

У таблиці наведено набір конкретних тестів або ситуацій, призначених для оцінки різних аспектів безпеки Платформи реєстрів:

Витік інформації

Переповнення буфера

Атака на хмарні метадані

Ін’єкція коду

Ін’єкція команди

Пасивний міжсайтовий скриптинг (reflected)

Активний міжсайтовий скриптинг (persistent)

Ін’єкція CRLF

Перегляд каталогів

Зовнішнє перенаправлення

Помилка формату рядка (Format String Error)

GET замість POST

Уразливість Heartbleed OpenSSL

Пошук прихованих файлів

Log4Shell (CVE-2021-44228 та CVE-2021-45046)

Заповнення Oracle (Padding Oracle)

Підробка параметрів

Обхід шляху

Віддалене виконання коду (RCE) — CVE-2012-1823

Віддалене включення файлів (RFI)

Включення на боці сервера (SSI)

Ін’єкція шаблону на боці сервера (SSTI)

Розкриття вихідного коду

Spring4Shell (CVE-2022-22965)

SQL-ін’єкція

Тестування вразливості через користувацький агент (User Agent Fuzzing)

Ін’єкція XPath

Ін’єкція XSLT

Ін’єкція XXE

Перевірка міжмережевого протоколу керуючих повідомлень (ICMP)

Перевірка портів

Перевірка SSL/TLS

Політика безпеки вмісту (Content Security Policy, CSP)

HSTS

Перереєстрація

Перезапис існуючого користувача

Унікальність імені користувача

Політика слабких паролів

Підтвердження електронної пошти

Одноразові адреси електронної пошти

Перевірка директорій

Довгий пароль (200+)

Тестування автентифікації

JSON-атака

Стійкість до вгадування пароля

XSS для імені або пошти

Нездатність підтвердити пароль під час зміни електронної пошти, пароля або 2FA

Механізм блокування облікових записів користувачів

Ліміт тарифу

Перевірка перенаправлення на сторінці реєстрації після входу

Порушення контролю доступу

Перевірка токенів на передбачуваність

Розкриття токенів

Безпечне завершення сеансу

Фіксація сесії

Підробка міжсайтового запиту (Cross-Site Request Forgery, CSRF)

Обсяг файлів cookie

Декодування файлів cookie (Base64, hex, URL тощо)

Завершення терміну дії файлів cookie

Повторне використання файлів cookie після закриття сесії

Вихід та використання функції "повернутися" в браузері (Alt + стрілка вліво)

Відкриття двох екземплярів, зміна або скидання 1-го екземпляру, оновлення 2-го екземпляру

Незахищене пряме посилання на профіль користувача (Insecure Direct Object Reference, IDOR)

Підробка міжсайтового запиту (CSRF) на профіль користувача

Підтвердження електронної адреси

Незахищене пряме посилання (IDOR) на параметри

Перевірка політик для різних ролей

Перевірка усіх параметрів запиту

Непостійний XSS (reflected)

Введення заголовка HTTP в GET та POST (X Forwarded Host)

Віддалене виконання коду через заголовок посилання (Referer)

SQL-ін’єкція через заголовок User-Agent

Довільне перенаправлення

Збережені атаки

Ін’єкція скрипта

Завантаження файлу

Зовнішня сутність XML (XXE) у будь-якому запиті, зміна типу вмісту на text/xl

Стійкий XSS (stored)

Контрабанда HTTP-запитів

Відкрите перенаправлення

Підробка запитів на боці сервера (SSRF) у раніше відкритих портах

4. Тестові дані

В процесі тестування безпосередньо використовуються дані, які за своєю суттю є відкритими. Такі дані доступні на ресурсі https://data.gov.ua/dataset. Справжні та чисті дані під час тестування не використовуються.

5. Етапи тестування

5.1. Огляд архітектури

Під час перегляду архітектури нової функції ми перевіряємо правильне забезпечення загальних механізмів безпеки, як-от автентифікація, авторизація, керування користувачами та правами, безпечний зв’язок, захист даних, керування ключами та керування журналами.

Також проводиться перевірка того, чи архітектура рішення відповідає всім визначеним вимогам безпеки та відповідності. Усі інтерфейси додатків аналізуються на відповідність списку вимог безпеки та відповідності. Крім того, аналізується потік даних, щоб переконатися, що вимоги належним чином адресовано різними компонентами.

Згадані типи аналізу виконуються як на внутрішніх інтерфейсах — наприклад, міжрівневих, — так і на зовнішніх — тих, що складають поверхню атаки.

5.2. Моделювання загроз

Ми прагнемо застосувати безперервне моделювання загроз і побудувати ітеративний і безперервний процес виявлення й аналізу потенційних загроз і безпекових ризиків протягом усього життєвого циклу розробки програмного забезпечення. Наразі модель загроз створюється для всієї програми і майже всі зміни моделюються поступово з метою виявлення можливих нових загроз.

5.3. Автоматичне сканування

Розробка Платформи реєстрів виконується відповідно до підходу з безпечного життєвого циклу розробки програмного забезпечення (SSDLC). Автоматизоване сканування безпеки відіграє у SSDLC вирішальну роль, допомагаючи виявляти та виправляти вразливі та слабкі місця безпеки на ранніх стадіях процесу розробки. Це важливий компонент SSDLC, який забезпечує постійне тестування безпеки та зворотний зв’язок протягом життєвого циклу розробки.

Процеси CI/CD включають в себе багато засобів контролю безпеки. Усі вони інтегровані із системою управління вразливостями, щоб створити ворота якості безпеки (security quality gates, SQG), які можуть перервати процес відповідно до встановлених критеріїв для конкретної служби чи умови. Існує також механізм винятків, щоб обійти цю поведінку, якщо ризик певної вразливості прийнято або зменшено. Такі винятки спочатку явно затверджуються, а всі випадки реєструються разом із обґрунтуванням.

Усі сервіси, розроблені власними силами, автоматично проходять через список контролю безпеки кожної нової зміни.

  • Статичне тестування безпеки програми

  • Аналіз складу програмного забезпечення

  • Виявлення розголошення конфіденційної інформації

  • Безпека Helm-шаблонів, які використовуються для розгортання сервісів

  • Загальні перевірки якості коду

  • Безпека контейнера

Після успішного проходження всіх воріт якості артефакт розгортається в окремому середовищі безпеки, де відбувається динамічне тестування. Динамічне тестування безпеки додатків (Dynamic Application Security Testing, DAST) — це тип тестування безпеки, який передбачає оцінку безпеки додатка під час його роботи або в динамічному стані. Основною метою DAST є виявлення вразливостей і слабких місць безпеки, які можуть бути неочевидними у вихідному коді програми, але можуть бути використані під час роботи програми.

Існує шість етапів динамічного тестування безпеки програми для кожної зміни:

  • Конфігурація середовища

  • Автоматизоване приймання тестових даних програмою та запис потоку даних за допомогою системи безпеки для автоматичного виявлення потоку та структури даних

  • Перевірка автентифікації

  • Сканування вразливостей веб-додатку

  • Сканування вразливостей REST API за допомогою оновлених контрактів

  • Імпорт результатів у систему управління вразливостями для подальшого аналізу інженером із безпеки

Таким чином, ми використовуємо ретельний підхід для проактивного пошуку та усунення вразливостей, щоб підвищити рівень безпеки Платформи реєстрів та захистити її від потенційних кіберзагроз.

5.4. Тестування на проникнення

Тестування на проникнення проводиться щорічно сторонніми постачальниками в спеціальному середовищі, схожому на виробниче. Звіт перевіряється, сортується та використовується системою управління вразливостями, щоб вирішити будь-які виявлені проблеми.

6. Управління вразливостями

Управління вразливостями — це проактивний підхід до збору, оцінки, визначення пріоритетів і усунення вразливостей безпеки в інформаційних системах, програмах і мережевій інфраструктурі організації. Мета управління вразливостями полягає в тому, щоб зменшити доступність організації до потенційних кіберзагроз і атак шляхом усунення слабких місць до того, як ними зможуть скористатися зловмисники. Це безперервний і циклічний процес.

Ми використовуємо OWASP DefectDojo для збору вразливостей протягом усього процесу розробки Платформи. Кожен результат сканування усіх процесів розробки використовується DefectDojo для дедуплікації, групування, хибнопозитивного аналізу та підтримки актуального статусу виявлених вразливостей.

Система управління вразливостями глибоко інтегрована з тикет-системою, що дозволяє керувати дефектом протягом усього процесу управління завданнями проекту та прозоро супроводжувати його через процес вирішення.

Крім того, вона містить важливу та найбільш повну історію будь-якої вразливості, виявленої в проекті. Використовуючи цю інформацію, ми можемо легко відстежити будь-яке прийняте рішення, як-от прийняття ризику тощо.

Згаданий підхід також дуже корисний для високорівневого аналізу вразливостей для виявлення шаблонів, швидких виграшів і покращення стану безпеки в цілому.

Зрештою, система управління вразливостями є джерелом правди для наших інженерів безпеки.

7. Звітність

Ми використовуємо можливості звітування системи управління вразливостями для створення звітів різних рівнів занурення, щоб отримати уявлення про загальну картину розвитку Платформи реєстрів та налаштувати програму безпеки.