Контрольних списків безпеки додатків більше не достатньо
Впуск OWASP top 10 2021 року викликав суперечки в середовищі фахівців з безпеки, оскільки в ньому навмисно відійшли від переліку конкретних вразливостей безпеки. Замість цього OWASP перейшов до більш стратегічного підходу, та, навіть, додав небезпечний дизайн (insecure design) як категорію вразливостей безпеки додатків. Це дало зрозуміти, що зі швидкістю та масштабами розробки додатків вже не можна розглядати безпеку вебдодатків як окремий процес, який можна звести до викреслювання SQL-ін’єкцій та інших поширених вразливостей зі списку.
Будь-яка велика організація розробляє принаймні частину свого програмного забезпечення власними силами, тому використання AppSec, що розуміється як ручна перевірка найбільш поширених вразливостей додатків час від часу, є дорогим і неефективним. Це також небезпечно, оскільки вразливості можуть залишатися у виробництві місяцями, наражаючи організацію на небезпеку атак до наступного тестування та виправлення.
Найкращою практикою безпеки вебдодатків є надійне створення додатків, які не мають відомих вразливостей перед запуском у виробництво – а це означає, що безпечне кодування, тестування безпеки додатків та виправлення помилок є невіддільною частиною процесу розробки.
Основи ефективного DevSecOps
Хоча DevSecOps стало модним словом в індустрії, воно ідеально відображає ідею інтеграції безпеки в процес розробки та експлуатації, а не розглядає її як окрему фазу. Подібно до того, як DevOps зруйнував традиційні бар’єри між розробкою й експлуатацією, так і DevSecOps повинен (в ідеалі) зробити безпеку додатків невіддільною частиною DevOps. Складність полягає в тому, щоб зробити це для реальних середовищ, команд розробників і графіків випусків.
Базуючись на викликах з якими стикались клієнти Invicti можна визначити чотири стратегічні стовпи для побудови найкращої стратегії безпеки вебдодатків для реального світу.
Знайти всі ризики
В ідеальному світі розробники завжди надавали б безпечний код, а всі вебактиви в організації були б ретельно каталогізовані та керовані. Насправді ж, ніщо не є 100% захищеним, і вся інформація, що отримується про вебсередовище, завжди несе в собі певну невизначеність. Навіть одна вразливість може бути достатньою для заподіювання значної шкоди, тому єдиний спосіб бути впевненим, що робиться все можливе – це постійно контролювати вебсередовища, тестувати все і нікому не довіряти.
Хоча, безумовно, найкращою практикою є ведення централізованого реєстру всіх вебсайтів, додатків та API для полегшення введення в експлуатацію, обслуговування та виведення з експлуатації, більшість організацій все ще мають лише поверхневе уявлення про справжній стан їх поверхні веб атак. Велика організація може мати сотні або навіть тисячі вебактивів, в тому числі вебсайти, вебдодатки, вебсервіси та вебінтерфейси. Сучасні додатки, орієнтовані на сервіс, часто підключаються до десятків сервісів і надають власну функціональність через інтерфейси, збільшуючи поверхню атаки. Це робить автоматизоване і безперервне виявлення вебактивів важливою частиною будь-якої програми веббезпеки.
Що стосується самого тестування, можна вибрати з безлічі підходів та інструментів. Кінцева мета полягає в тому, щоб переконатися, що немає відомих проблем з безпекою у виробництві, і підхід буде різним для кожної організації. Щоб отримати комплексне сканування вразливостей у різних додатках, технологіях, архітектурах та етапах розробки, знадобиться принаймні якісне динамічне тестування безпеки додатків (DAST) з автоматизацією робочих процесів, щоб не відставати від конвеєра розробки.
Швидко виправити
Сучасні команди розробників перебувають під тиском необхідності впроваджувати інновації та виконувати роботу вчасно, зазвичай працюючи в коротких, гнучких спринтах, не маючи часу чекати на безпеку. Щоб бути ефективними, тестування безпеки додатків і виправлення помилок повинні бути вбудовані в життєвий цикл розробки програмного забезпечення (SDLC) і працювати ефективно, не порушуючи темп розробки. А оскільки весь конвеєр розробки значною мірою автоматизований, процес тестування та усунення вразливостей безпеки має бути інтегрований в нього з таким же рівнем автоматизації.
Ефективне та довготривале виправлення помилок є справжнім ключем до створення більш безпечних вебдодатків та покращення якості коду в довгостроковій перспективі. Візьмемо конкретний приклад: XSS є найпоширенішою вразливістю вебдодатків, і якщо про них повідомляється розробникам без рекомендацій щодо виправлення, вони будуть з’являтися і розмножуватися нескінченно через часткові виправлення, що працюють лише в певному контексті. Ще один спосіб зменшити кількість XSS в довгостроковій перспективі це допомогти розробникам зрозуміти та усунути першопричину, яка полягає у відсутності або неповній перевірці даних, введених користувачем.
Автоматизація процесу тестування та усунення вразливостей вимагає інструментів, які безпосередньо взаємодіють з чинними інструментами розробки та тестування. Розробники покладаються на трекери для планування та виконання завдань, тому внесення актуальних проблем безпеки в трекер є критичним для того, щоб їх побачили та вирішили. Найголовніше, які б інструменти безпеки не використовувались, вони повинні повідомляти про реальні ризики безпеки, не завалюючи розробників хибнопозитивними результатами.
Працювати з перевіреними та дієвими даними
Досягнення правильного балансу між знаходженням всіх важливих вразливостей і мінімізацією шуму у звітах про вразливості є стрижнем будь-якого процесу сканування безпеки. Це виходить далеко за рамки звичайних дискусій про помилкові спрацьовування. Хоча хибні спрацьовування абсолютно точно створюють додаткову роботу, яка може звести нанівець багато або всі переваги автоматизації, фундаментальним питанням є впевненість у тому, що дані, які ви передаєте в робочі процеси, є коректними та придатними для використання.
Щоб отримати точні результати, які відображають реальний стан безпеки в поточному середовищі загроз, необхідно ретельно підійти до вибору інструментарію. Подібно до того, як захист вебсайтів і додатків зараз – це набагато більше, ніж тестування на наявність конкретних вразливостей, так і рішення щодо інструментів тестування безпеки більше не є простим питанням проставлення галочок у технічних полях. Краще спитати, які покращення безпеки інструмент зробить в унікальному середовищі та робочих процесах. Просто нагромадження ще одного джерела звітів про безпеку не завжди призводить до покращення безпеки додатків – і може навіть погіршити її, якщо команди безпеки та розробники будуть перевантажені нерелевантною інформацією.
Зворотною стороною роботи лише з перевіреними даними є неявна недовіра до всього, що не було перевірено. На практиці це означає не тільки тестування кожної частини наявного середовища вебдодатків, але й тестування всіх нових збірок і кожного виправлення вразливостей. Неповні або поверхневі виправлення є лише тимчасовим вирішенням безпеки додатків, оскільки основні проблеми рано чи пізно з’являться знову і спричинять більше роботи, ніж було заощаджено завдяки швидкому і виправленню. Таким чином, найкраща практика AppSec повинна включати інструменти та робочі процеси, які автоматично і невпинно тестують і повторно тестують все, що рухається до виробництва.
Завжди працювати над покращенням: не існує ідеального рівня захисту програм
Кібератаки – це цілодобова загроза безпеці, яка може призвести до все дорожчих витоків даних, втрати конфіденційних даних, розгортання шкідливого програмного забезпечення та руйнівних простоїв. Мануальне тестування на проникнення, хоча і є життєво важливим періодичним завданням, не є достатнім для постійного підтримання узгодженої позиції безпеки всіх вебактивів. Тому, окрім тестування безпеки в SDLC, потрібно регулярно тестувати сайти та додатки, які вже запущені у виробництво. Це особливо важливо для сторонніх ресурсів і всього, що не перебуває в активній розробці, а отже, не охоплено будь-яким тестуванням безпеки, яке проводиться в конвеєрі розробки.
Навіть якщо додатки, якими компанія користується, не змінювалися останнім часом, щодня виявляються десятки нових вразливостей і векторів атак. Те, що вважалось безпечним минулого тижня або навіть вчора, може бути вразливим сьогодні. Безпечне, але точне сканування вразливостей для виробничих додатків – це окрема тема. Разом з тим, частою рекомендацією є клонувати поточне виробниче середовище і сканувати клон, а не реальне розгортання. Таким чином, можна охопити повний набір потенційних проблем у виробничому коді та налаштуваннях, включаючи будь-які неправильні налаштування безпеки, але не впливаючи на реальне робоче середовище.
Щоб зробити такий рівень тестування можливим, а також мінімізувати час і зусилля, необхідні для виправлення, слід побудувати надійний і повністю автоматизований процес тестування безпеки, який починається з перших рядків вихідного коду та охоплює кожну частину і фазу розробки та експлуатації, аж до виробництва. Це робить рішення DAST необхідним для тестування всього додатку на стадії розробки та виробництва. За допомогою сучасних платформ на основі DAST, таких як Invicti, можна продовжити тестування на етапі розробки, щоб доповнити чинне статичне тестування безпеки додатків (SAST) або навіть використовувати його як єдину технологію тестування додатків – особливо корисно для початку роботи з AppSec.
Основи гігієни кібербезпеки
Побудова процесу DevSecOps полягає в тому, щоб зробити безпеку справою кожного, тому радар безпеки додатків повинен виходити за рамки самого додатку та охоплювати також операційну безпеку. Це охоплює реалізацію іноді необхідних заходів безпеки як у додатках, так і на вебсервері. Наприклад, сервери мають надсилати правильні заголовки безпеки, зокрема HSTS для забезпечення шифрування SSL/TLS для всього трафіку та CSP (Content Security Policy) для обмеження потенційно шкідливих джерел контенту. Так само команди повинні знати, як встановити безпечні атрибути файлів cookie, щоб мінімізувати ризик атак перехоплення сеансу.
Якщо дивитися ще ширше, брандмауер вебдодатків (WAF) необхідний і як додаткова лінія захисту, і як спосіб тимчасового усунення вразливостей, поки не буде готовий патч або виправлення. (Нагадування: Правила WAF – це лише тимчасове рішення, а не постійне розв’язування проблем безпеки). Ефективний процес виправлення також має вирішальне значення для мінімізації векторів атак, пов’язаних з бібліотеками з відкритим вихідним кодом та іншими сторонніми компонентами у вебстеку, хоча, на відміну від мережевої безпеки, патчі – це лише один з аспектів процесу виправлення.
Повертаючись до того, що OWASP вважає категорію “незахищений дизайн” (insecure design) слабкою стороною безпеки, команди розробників програмного забезпечення повинні враховувати безпеку у всьому, що вони роблять і планують.
Ось конкретний приклад: забезпечення належного контролю доступу має вирішальне значення для мінімізації ризику неавторизованого доступу, який може призвести до отримання зловмисниками конфіденційної інформації або ескалації від незначного початкового порушення до повної компрометації системи. Але безпечний та ефективний контроль доступу – це не лише надійні паролі чи багатофакторна автентифікація (хоча і те, і інше є важливим) – він починається з безпечного дизайну ролей та привілеїв користувачів, який відповідає як необхідній бізнес-логіці, так і принципу найменших привілеїв. І це не те, що можна додати в останню хвилину.
Як Invicti впроваджує AppSec
Кожна організація унікальна, тому існує багато способів налаштувати безпеку додатків ефективно. Зазвичай пошук, розгортання та налаштування всіх інструментів і робочих процесів займає багато часу, що втрачається без користі. Invicti розробило перше рішення DAST, яке інтегрується в будь-який робочий процес розробки вебдодатків і підтримує максимальне покриття з можливістю занурення глибше за допомогою інтегрованих IAST і SCA. Це не єдиний спосіб реалізації AppSec, але це один з провідних.
