Джефф Вільямс, засновник OWASP та засновник і технічний директор Contrast Security – Серія інтерв’ю

Джефф Вільямс, засновник OWASP та засновник і технічний директор Contrast Security, широко вважається одним з найбільш впливових діячів у сфері сучасної безпеки застосунків. За останні кілька десятиліть він допоміг сформувати підхід організацій до розробки безпечного програмного забезпечення, управління уразливостями та захисту застосунків у режимі виконання. Вільямс відіграв центральну роль у створенні OWASP з невеликої волонтерської ініціативи у глобально визнану некомерційну організацію з безпеки, зробивши свій внесок у такі знакові проекти, як OWASP Top Ten, WebGoat, ESAPI, ASVS та XSS Prevention Cheat Sheet. До заснування Contrast Security у 2014 році він також заснував Aspect Security, одну з перших фірм, що спеціалізувалася виключно на консалтингу з безпеки застосунків, навчанні, тестуванні на проникнення та безпечних практиках розробки для підприємств.

OWASP – некомерційна організація, що зосереджена на поліпшенні безпеки програмного забезпечення через відкриті проекти, глобальну співпрацю спільноти, освіту та галузеві стандарти. Заснована у 2001 році, організація стала однією з найважливіших авторитетів у сфері безпеки застосунків, маючи сотні місцевих відділень, тисячі учасників та широко прийняті ресурси, які використовуються розробниками, фахівцями з безпеки, підприємствами та урядами усьому світі. OWASP найбільш відомий своїми проектами, такими як OWASP Top Ten, який визначає найбільш критичні ризики безпеки веб-застосунків, а також численними безпечними рамками, інструментами тестування, проектами документації та навчальними ініціативами. Організація працює на засадах нейтральності щодо виробників, роблячи свої освітні ресурси та рекомендації з безпеки вільно доступними для глобальної технологічної спільноти.

Contrast Security – компанія з безпеки застосунків, що зосереджена на захисті програмного забезпечення зсередини самого застосунка, а не лише на зовнішніх інструментах сканування. Платформа компанії використовує технологію інструментування у режимі виконання для надання реального часу видимості уразливостей, атак, API, залежностей відкритого джерела та поведінки застосунка у середовищах розробки та виробництва. Її пропозиції охоплюють такі галузі, як Інтерактивне тестування безпеки застосунків (IAST), Виявлення та реагування на застосування (ADR), Самозахист застосунка у режимі виконання (RASP) та аналіз складу програмного забезпечення. Contrast Security позиціонує себе навколо інтеграції безпеки безпосередньо у сучасні робочі процеси DevSecOps, дозволяючи розробникам, командам AppSec та командам безпеки операцій визначати та усувати уразливості швидше, одночасно підтримуючи швидкі цикли доставки програмного забезпечення.

Після того, як ви допомогли сформувати сучасну безпеку застосунків завдяки вашій роботі з Open Web Application Security Project (OWASP), яка прогалина в галузі привела вас до заснування Contrast Security, і як ця первинна теза витримала випробування часом, коли змінилися виклики безпеки?

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

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

Ви описали появу “міфічних” уразливостей. Що визначає цей новий клас ризику, і чому вони такі важкі для виявлення традиційними засобами безпеки?

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

Чому цілі категорії уразливостей не генерують сигналів тривоги у сучасних центрах операцій з безпеки (SOC), і що це говорить про те, як команди безпеки зараз вимірюють ризик?

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

Сучасні архітектури застосунків, такі як мікросервісна архітектура, API та серверні системи, розвиваються швидко. Де ці архітектури обганяють поточні підходи до безпеки, засновані на виявленні?

Ці архітектури розбили стару периметральну модель. Запити тепер перетинають десятки сервісів, ефемерних функцій, API, черг та залежностей третіх сторін перед завершенням транзакції. Більшість систем виявлення все ще бачать фрагменти замість повного шляху виконання. Вони можуть інспектувати пакети або журнали, але не можуть зрозуміти намір, потік даних чи те, чи виконувався небезпечний код насправді. Безпека полягає у контексті, тому нам потрібно побудувати модель, цифровий двійник нашої інфраструктури застосунка, яка дозволить нам (або агентам штучного інтелекту) міркувати про те, що ми бачимо.

OWASP Top Ten продовжує підкреслювати питання, такі як незахищений дизайн та уразливі компоненти. Чому ці ризики зберігаються, незважаючи на широке поширення інформації та наявність інструментів?

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

У той же час ланцюжки поставок програмного забезпечення вибухові розрослися. Розробники збирають застосунки з тисяч компонентів, які вони не написали та яких вони точно не оцінили з точки зору безпеки. Команди безпеки перебувають у стані перевантаження, намагаючись розібратися у теоретичних ризиках і не можуть зосередитися на тих 1-2%, які насправді мають значення. Без доказів у режимі виконання prioritetизація розбивається. А з появою потужних моделей штучного інтелекту та інструментів їх використання об’єм зростає експоненційно.

Як організації повинні переглянути свою залежність від журналів та сигналів тривоги, коли деякі з найбільш критичних уразливостей не залишають жодних спостережуваних сигналів?

Журнали – це доказ того, що застосунки вирішують повідомляти, а не обов’язково доказ того, що насправді відбулося. Це небезпечна відмінність. Організації повинні перейти від непрямого спостереження до прямого спостереження. Замість того, щоб сподіватися, що експлуатація створить виявний артефакт, системи безпеки повинні ідентифікувати уразливу поведінку та поведінку експлуатації у режимі виконання. Якщо небезпечний код виконується, система повинна знати про це відразу – незалежно від того, чи існує запис у журналі.

Ви відстоюєте видимість у режимі виконання як рішення. Що таке справжня видимість у режимі виконання на практиці, і як це змінює роботу команд безпеки щодня?

Справжня видимість у режимі виконання означає розуміння того, що застосунок насправді робить у виробництві: які маршрути відкриті, які бібліотеки активні, куди тече чутлива інформація, який код виконується та чи досягла атака уразливої функціональності. Операційно, це змінює безпеку з реактивної охоти на справжню дисципліну. Команди перестають гонитися за величезними чергами уразливостей та починають зосереджуватися на тому невеликому відсотку експозицій, які досяжні, критичні та активно націлені. Це суттєво покращує співвідношення сигналу до шуму та швидкість реакції. В середньому лише 38% бібліотек відкритого джерела, упакованих у застосунок, насправді завантажуються у пам’ять та виконується. І не весь код у цьому підмножині використовується. Тому одне просте, що дозволяє безпека у режимі виконання, – це зосередження на коді, який насправді виконується, а не на всіх невикористаних бібліотеках та функціях, які супроводжують застосунок.

Як інструментальна безпека порівняється з традиційними підходами, такими як SAST, DAST або моніторинг периметру, щодо ефективності та масштабованості?

Традиційні інструменти припускають ризик ззовні. Інструментування спостерігає реальність, спостерігаючи фактичний код під час виконання. Інструментування може бачити фактичні шляхи виконання, поведінку фреймворка, контекст автентифікації, потік даних та успіх експлуатації в реальному часі. Воно усуває величезні категорії хибних позитивів та розкриває уразливості, яких інструменти периметру повністю не помічають.
У масштабі ця точність стає критичною. Організації вже не можуть вручну розібратися у мільйонах теоретичних результатів. Докази у режимі виконання стають єдиною сталою фільтрацією. Робота у режимі виконання відбувається в реальному часі, тому це кращий матч для процесів розробки та CI/CD, ніж сканування та розбирання. А робота у режимі виконання є безперервною, тому ви не обмежені моментальною точкою зору безпеки.

Якщо системи штучного інтелекту та автономні застосунки стають більш поширеними, чи ці невидимі уразливості стають більш небезпечними, і як команди повинні готуватися?

Штучний інтелект робить невидимі уразливості значно небезпечнішими, оскільки він прискорює обидві сторони проблеми. Розробники генерують програмне забезпечення швидше, а атакувальники знаходять та експлуатують слабкості швидше. Але більшість програм безпеки все ще залежать від процесів з людиною у циклі, які не можуть працювати на швидкості штучного інтелекту. Команди повинні готуватися двома способами. По-перше, побудувати сильніші засоби захисту у режимі виконання, які можуть виявляти, блокувати та ізолювати атаки у виробництві, поки уразливості усуваються. Це дає організаціям повітряний захист. По-друге, використовувати штучний інтелект та автоматизацію для написання більш безпечного коду спочатку – з кращим дизайном, тестуванням, оглядом та верифікацією. В іншому випадку ми просто створюємо ризик швидше, ніж можемо його керувати.

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

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

Дякуємо за велике інтерв’ю. Читачам, які бажають дізнатися більше, рекомендуємо відвідати OWASP або Contrast Security.