Джефф Уильямс, основатель OWASP и основатель и технический директор Contrast Security – Интервью

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

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

Contrast Security – компания по безопасности приложений, ориентированная на защиту программного обеспечения изнутри самого приложения, а не полагаясь исключительно на внешние инструменты сканирования. Платформа компании использует технологию инструментирования runtime для предоставления реального времени видимости уязвимостей, атак, API, открытых зависимостей и поведения приложения в средах разработки и производства. Ее предложения охватывают такие области, как Interactive Application Security Testing (IAST), Application Detection and Response (ADR), Runtime Application Self-Protection (RASP) и анализ состава программного обеспечения. Contrast Security позиционирует себя вокруг интеграции безопасности直接 в современные рабочие процессы DevSecOps, позволяя разработчикам, командам AppSec и командам безопасности операций выявлять и устранять уязвимости быстрее, сохраняя при этом быстрые циклы доставки программного обеспечения.

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

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

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

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

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

Почему целые категории уязвимостей не генерируют оповещения в современных средах Security Operations Center (SOC), и что это раскрывает о том, как команды безопасности в настоящее время измеряют риск?

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

Современные архитектуры приложений, такие как микросервисы, API и серверные системы, эволюционировали быстро. Где эти архитектуры обгоняют текущие подходы к безопасности, основанные на обнаружении?

Эти архитектуры разрушили старую модель периметра. Запросы теперь пересекают десятки сервисов, эфемерные функции, API, очереди и зависимости третьих сторон, прежде чем завершить транзакцию. Большинство систем обнаружения все еще видят фрагменты вместо полного пути выполнения. Они могут инспектировать пакеты или журналы, но они не могут понять намерение, поток данных или то, выполнялся ли опасный код на самом деле. Безопасность заключается в контексте, поэтому нам нужно построить модель, цифровой двойник, нашей инфраструктуры приложения, которая позволит нам (или агентам ИИ) рассуждать о том, что мы видим.

OWASP Top Ten продолжает подчеркивать проблемы, такие как небезопасный дизайн и уязвимые компоненты. Почему эти риски сохраняются, несмотря на широкое осознание и инструменты?

Осознание не исправляет стимулы или сложность. Большинство организаций все еще измеряют успех количеством сканирования, закрытием тикетов или контрольными списками соответствия, а не фактическим снижением уязвимостей.

В то же время цепочки поставок программного обеспечения взорвались в размере. Разработчики собирают приложения из тысяч компонентов, которые они не написали и, конечно, не оценили на предмет безопасности. Команды безопасности перегружены, пытаясь триажировать теоретические риски и не могут сосредоточиться на 1-2%, которые действительно имеют значение. Без доказательств runtime приоритизация разрушается. И с появлением мощных моделей ИИ и средств, объем увеличивается экспоненциально.

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

Журналы – это доказательство того, что приложения выбирают сообщить, а не обязательно доказательство того, что на самом деле произошло. Это опасное различие. Организации должны перейти от косвенного наблюдения к прямому наблюдению. Вместо того, чтобы надеяться, что эксплуатация создает обнаруживаемый артефакт, системы безопасности должны выявлять уязвимое поведение и поведение эксплуатации в runtime. Если опасный код выполняется, система должна знать об этом сразу – независимо от того, существует ли запись в журнале.

Вы выступали за runtime-видимость в качестве решения. Что представляет собой真正ая runtime-видимость на практике, и как она меняет работу команд безопасности в повседневной деятельности?

Истинная runtime-видимость означает понимание того, что приложение фактически делает в производстве: какие маршруты открыты, какие библиотеки активны, где течет чувствительная информация, какой код выполняется и достигает ли атака уязвимой функциональности. Операционно, это меняет безопасность с реактивной охоты в точную дисциплину. Команды перестают преследовать огромные очереди уязвимостей и начинают сосредотачиваться на небольшом проценте экспозиций, которые доступны, критичны и активно нацелены. Это значительно улучшает соотношение сигнал-шум и скорость реакции. В среднем только 38% библиотек с открытым исходным кодом, упакованных в приложение, фактически загружаются в память и выполняются. И не весь код в этом подмножестве используется. Итак, одна простая вещь, которую обеспечивает runtime-безопасность, – это фокус на коде, который фактически выполняется, а не на всех неиспользуемых библиотеках и функциях, которые сопровождают приложение.

Как инструментированная безопасность сравнивается с традиционными подходами, такими как SAST, DAST или мониторинг периметра, в плане эффективности и масштабируемости?

Традиционные инструменты предполагают риск извне. Инструментирование наблюдает реальность, наблюдая за фактическим кодом во время его выполнения. Инструментирование может видеть фактические пути выполнения, поведение фреймворка, контекст аутентификации, поток данных и успех эксплуатации в реальном времени. Это устраняет огромные категории ложных положительных результатов и раскрывает уязвимости, которые инструменты периметра полностью пропускают.
В масштабе эта точность становится критической. Организации не могут вручную триажировать миллионы теоретических результатов. Доказательства runtime становятся единственным устойчивым фильтром. Runtime работает в реальном времени, поэтому он лучше подходит для процессов разработки и CI/CD, чем сканирование и триажирование. И runtime непрерывен, поэтому вы не ограничены моментальной точкой зрения безопасности.

Когда системы ИИ и автономные приложения становятся более распространенными, становятся ли эти невидимые уязвимости более опасными, и как команды должны подготовиться?

ИИ делает невидимые уязвимости намного более опасными, поскольку он ускоряет обе стороны проблемы. Разработчики генерируют программное обеспечение быстрее, и атакующие находят и эксплуатируют слабости быстрее. Но большинство программ безопасности все еще полагаются на процессы, управляемые человеком, которые не могут работать на скорости ИИ. Команды должны подготовиться двумя способами. Во-первых, построить более сильные защиты runtime, которые могут обнаруживать, блокировать и содержать атаки в производстве, пока уязвимости не будут исправлены. Это дает организациям прикрытие. Во-вторых, использовать ИИ и автоматизацию для написания более безопасного кода сначала – с лучшим дизайном, тестированием, проверкой и верификацией. В противном случае мы просто создаем риск быстрее, чем можем его управлять.

Если бы вы советовали современному лидеру Security Operations Center (SOC) сегодня, какие первые конкретные шаги они должны предпринять, чтобы закрыть эту пробел видимости, прежде чем он приведет к серьезному нарушению?

Во-первых, признайте, что периметральная телеметрия одна является недостаточной для современной безопасности приложений. На самом деле, невозможно увидеть или остановить многие атаки на приложения и API на периметре. SOC cần видимость внутри работающих приложений, а не только инфраструктуры, которая их размещает. Во-вторых, приоритизируйте доказательства runtime над теоретическими результатами. Сосредоточьтесь на уязвимостях, которые находятся в активном коде, выявите активные пути атак и открытые сервисы, которые фактически выполняются в производстве. Наконец, объедините безопасность приложений и инженерную безопасность. Будущий SOC не может больше рассматривать приложения как непрозрачные черные коробки. Приложения теперь являются основной поверхностью атаки, и они нуждаются в первоклассной видимости в runtime.

Спасибо за отличное интервью, читатели, которые хотят узнать больше, должны посетить OWASP или Contrast Security.