Четыре плюс Один всадника безопасной разработки Приложений

С каждым годом культура разработки растёт — многие компании начинают использовать методологию DevSecOps. Основной её задача заключается в том, что должен обеспечиваться непрерывный контроль безопасности на каждой стадии создания продукта, при этом процессы DevSecOps максимально автоматизированы.

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

Безопасность приложений охватывает широкий спектр инструментов и методологий, но все они преследуют одну и ту же цель: выявить слабые места (уязвимости) и исправить их до того, как они будут использованы злоумышленником. Причём на протяжении всего жизненного цикла (SDL/SDLC, или Software Development Lifecycle), — а это последовательность этапов от анализа требований, планирования, проектирования и дизайна до непосредственной разработки ПО, тестирования и развёртывания.

Первоначально концепция SDLC рассматривала обеспечение безопасности как задачу, выполняемую в рамках этапа тестирования. Но недостаток такого подхода — это несвоевременное обнаружение уязвимостей и ошибок.

Сегодня очевидно, что интеграция требований безопасности на каждом этапе SDLC помогает обнаруживать и устранять уязвимости раньше, сводя к минимуму длительность процесса и уменьшая количество дорогостоящих исправлений на более поздних этапах разработки. Поэтому идея об оценке безопасности на всех этапах разработки ПО (тестирование на проникновение, моделирование угроз, проверка кода, анализ архитектуры и т.д.) быстро завоевала популярность и признание в индустрии и получила название Secure SDLC/SSDLC, или «безопасный SDLC».

Основные преимущества применения SSDLC-подхода:

• Безопасность приложения контролируется на всех этапах его жизненного цикла.
• Заинтересованные стороны осведомлены о функциях безопасности.
• Раннее обнаружение дефектов.
• Снижение затрат и рисков благодаря раннему выявлению и решению проблем.

Глубоко детализированный SDLC, хоть и не в своём первозданном виде, рассматривается в методологиях таких мастодонтов, как OWASP SAMM, BSIMM, OpenSAMM.

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

№1. SAST

SAST (Static Application Security Testing) позволяет разработчикам находить уязвимости безопасности в исходном коде приложения на ранних этапах жизненного цикла разработки ПО. SAST также обеспечивает соответствие руководствам и стандартам кодирования без фактического выполнения базового кода.

Одной из ключевых сильных сторон SAST является широкий охват языков программирования и платформ разработки. Для практически любого основного языка найдётся несколько вендоров, предлагающих инструменты по статическому анализу кода. Ещё одним плюсом является то, что SAST легко внедряется — весьма просто добавить статический сканер в конвейер разработки или в IDE. Наконец, разработчики извлекают выгоду из того, что анализ выполняется с точки зрения статического исходного кода: это включает в себя обратную связь о точном местоположении потенциальной проблемы.

К SAST предъявляются следующие требования:

• Наличие качественных технологий и алгоритмов для глубокого анализа кода и выявления уязвимостей.
• Регулярно обновляемая база правил с возможностями гибкой настройки и расширения.
• SAST должен предоставлять в виде отчётов исчерпывающие обоснования наличия уязвимости и давать подробные рекомендации по устранению последней.
• SAST должен сопоставлять результаты анализа при повторном сканировании отредактированного кода (выделение исправленных, неисправленных, вновь появившихся уязвимостей).
• SAST должен поддерживать большое число языков программирования.
• SAST должен интегрироваться со средами разработки, системами контроля версий и отслеживания ошибок.
• Обеспечение связи между разработчиками и экспертами, отвечающими за безопасность.
• Минимальное количество ложных срабатываний.
• Представление результатов анализа в удобном для восприятия виде.
• Наличие средств автоматического составления отчётов.
• Возможность проводить анализ кода удалённо.

Наличие ошибок, уязвимостей и закладок в разрабатываемом приложении несёт в себе серьёзные риски для информационной безопасности. Использование SAST позволяет существенно снизить эти риски и контролировать качество разработки без привлечения внешних экспертов. SAST является практичным инструментом для разработчиков, который удобно встраивается в процессы DevSecOps. На мировом рынке представлено множество различных анализаторов — как от известных вендоров в области безопасности, так и от нишевых игроков, занимающихся только разработкой SAST.

№2. DAST

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

DAST также может пролить свет на такие проблемы как:

• проблемы аутентификации и конфигурации сервера
• недостатки, видимые только при входе известного пользователя

Обнаружить это с помощью статистического анализа нельзя

К DAST предъявляются следующие требования:

Качество сканирования

Это — соотношение найденных и пропущенных уязвимостей. С ходу понять, насколько качественно анализирует сканер, невозможно. Для этого нужно иметь хотя бы примерное представление о том, какие уязвимости есть в приложении, чтобы потом сравнить их с результатами сканирования.

Краулинг

Если дополнительной информации о приложении нет и нужно проанализировать его «с нуля», важно понимать, как много путей и переходов получится собрать в нём, то есть насколько точным будет краулинг. Для этого нужно посмотреть настройки продукта. Необходимо выяснить, умеет ли он мониторить запросы от фронтенда к бэкенду, парсить, например, Swagger- или WSDL-приложения, находить ссылки в HTML или JS. Ещё стоит изучить процесс получения информации о приложении. Можно перед сканированием уточнить, какие именно API используются: нужно понять, что поможет инструменту совершить полноценную проверку приложения. В процессе выбора сканера полезно составить список того, что может импортировать каждый инструмент, и подумать, получится ли встроить это в процесс.

Скорость сканирования

Этот параметр также важен, особенно если проверки интегрированы в разработку: они могут тормозить процесс и в результате приводить к тратам времени и денег. Скорость сканирования во многом зависит от того, как оперативно приложение отвечает на запросы, сколько одновременных подключений оно способно обработать, и от ряда других факторов. Поэтому чтобы сравнить скорость работы различных инструментов, нужно запускать их применительно к одному и тому же ПО в примерно одинаковых условиях.

Детальная настройка

У инструментов автоматического анализа должны быть детальные настройки. Они позволят убрать лишние запросы и ограничить зону проверки, за счёт этого повысятся качество процесса и скорость анализа. Чем детальнее настройки, тем точнее получится обозначить задачи инструменту. Существуют «умные» сканеры, которые сами подстраиваются под приложения. Но у таких инструментов всё равно должна быть ручная настройка, поскольку цели у проверок бывают разные. Например, иногда нужно просканировать приложение в нескольких вариантах, начиная тотальной проверкой и заканчивая поверхностным анализом; в таком случае ручная настройка точно будет кстати. При выборе инструмента нужно обращать внимание на количество параметров, а также на то, как легко их настраивать. Чтобы сравнить работу разных инструментов, можно создать в каждом из них несколько профилей сканирования: быстрый и поверхностный для начального анализа, полный и максимальный — для полноценного.

Интеграция

Чтобы динамический анализ был максимально эффективным, стоит интегрировать эту практику в процесс разработки и периодически запускать сканер во время сборки. Нужно заранее сформировать перечень того, что используется в процессе CI / CD, составить примерный план запуска инструмента. Это поможет проанализировать сканер с точки зрения интеграции и понять, насколько легко получится внедрить его в процесс разработки и удобно ли использовать его API.

Технологии

Выбирать сканер нужно с учётом технологий, которые использует ваша компания в разработке. Для этого можно проанализировать приложения и сформировать список технологий, языков и фреймворков, которые применяются в продуктах. Перечень может получиться весьма обширным, особенно если компания велика. Поэтому уместно выбрать всего несколько параметров в качестве критериев оценки сканеров: количество технологий и фреймворков, которые охватывает инструмент, возможность поддержки ключевых технологий, которые компания использует в своих самых важных сервисах.

Запись последовательности логина

Для динамических сканеров крайне важна технология записи последовательности логина, поскольку для входа в приложение обязательно нужно пройти аутентификацию. Но в этом процессе кроется много подводных камней, например хеширование пароля перед отправкой или его шифрование общим ключом на фронтенде; это далеко не весь список. Поэтому нужно заранее проверить, справится ли инструмент со всеми нюансами. Для этого необходимо выбрать максимально разные приложения и посмотреть, сможет ли сканер пройти в них этап логина. Также нужно проверить, как поведёт себя инструмент при разлогинивании. Сканер в процессе анализа отправляет много запросов, в ответ на некоторые из них сервер может «выбросить» пользователя из системы. Инструмент должен заметить это и снова войти в приложение.

Обновления инструмента

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

При выборе динамического анализатора стоит использовать отмеченные выше в этой статье критерии, но применять их нужно правильно. Каждая компания уникальна, имеет свои нюансы и особенности — всё это необходимо учитывать в связке со всеми критериями. Также нужно заранее определить свои потребности и понять, каких результатов вы хотите от инструмента. На рынке сейчас осталось не так много продуктов. С одной стороны, это плохо, с другой — не придётся слишком долго выбирать. Но, чтобы не ошибиться, нужно проводить полноценное тестирование различных вариантов, сравнивать их между собой и выбирать наилучшее решение с учётом потребностей компании и параметров качества.

№3. IAST

IAST – интерактивное тестирование безопасности приложений. SAST и DAST являются относительно старыми технологиями, поэтому бытует мнение, что они не лучший выбор для тестирования современных:

• Веб-приложений
• Мобильных приложений

Например, SAST плохо работает с:

• Библиотеками
• Фреймворками

А все это присутствует практически в каждом современном приложении.

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

• «lost sources»
• «lost sinks»

Аналогично и с фреймворками. Статический инструмент не обнаружит ничего неправильного в:

• API
• веб-сервисе
• конечной точке REST

Все потому, что он не может понять их структуру.

IAST разработан для устранения недостатков SAST и DAST путем объединения элементов обоих подходов. IAST выполняет весь анализ в режиме реального времени:

• в любом месте процесса разработки IDE
• непрерывной интегрированной среде
• производственной среде

Поскольку IAST работает внутри приложения, он может анализировать:

• код приложения
• потоки данных
• конфигурации
• HTTP-запросы и ответы
• библиотеки, фреймворки и другие компоненты
• информацию о внутреннем подключении

По сравнению с SAST или DAST доступ ко всей этой информации позволяет механизму IAST:

• покрывать больше кода
• выдавать более точные результаты
• проверять более широкий спектр правил безопасности

№4. RASP

RASP (Run-time Application Security Protection) — защита безопасности приложений во время выполнения. Как и IAST работает внутри приложения, но это скорее инструмент безопасности, а не тестирования. Он подключается к приложению или его среде выполнения и может контролировать выполнение приложения. Это позволяет RASP защитить приложение, даже если защита периметра сети нарушена, а приложения содержат уязвимости безопасности.

RASP позволяет приложению проводить непрерывные проверки безопасности и отвечать на атаки в реальном времени, завершая сеанс злоумышленника и предупреждая защитников об атаке.

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

Развёртывая RASP, разработчики могут выявлять уязвимости в своих приложениях. Кроме того, решение RASP может блокировать попытки использования уже известных уязвимостей.

Функции мониторинга в RASP позволяют обнаруживать широкий спектр угроз, включая атаки «нулевого дня». Когда в приложении происходит событие из области безопасности, RASP берёт программу под свой контроль и решает проблему. В режиме диагностики RASP-продукт просто подаст сигнал тревоги о том, что что-то не так. В режиме защиты он попытается остановить происходящее — например, прервать выполнение инструкций для базы данных, которые выглядят как атака с использованием SQL-инъекции.

Другие действия, которые может предпринять RASP, включают в себя завершение сеанса работы пользователя, остановку выполнения приложения, оповещение пользователя или сотрудников службы безопасности.

Разработчики могут интегрировать RASP несколькими способами: получить доступ к технологии с помощью вызовов функций, включённых в исходный код приложения, или взять готовую программу и поместить её в оболочку, которая позволяет защитить приложение одним нажатием кнопки. Первый подход более точен, поскольку разработчики могут принимать конкретные решения о том, что именно они хотят защитить в приложении — например, логины, запросы к базе данных или административные функции.

Какой бы метод ни использовался с RASP, конечный результат будет похож на объединение WAF с контекстом выполнения приложения. Тесная интеграция с приложением означает, что RASP может быть настроен более точно в соответствии с потребностями по безопасности приложения.

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

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

Как и в случае с WAF, RASP также не исправит исходный код приложения. Однако RASP интегрируется с базовыми библиотеками и защищает уязвимые области на уровне исходного кода. Когда клиент вызывает функцию содержащую параметры, которые могут нанести вред веб-приложению, RASP перехватывает вызов, регистрируя или блокируя его в зависимости от конфигурации. Этот принцип защиты веб-приложения принципиально отличается от используемого в WAF.

Любой RASP-продукт должен предлагать поддержку распространённых «корпоративных» языков программирования (например, Java, .NET), а также более новых языков и связанных с ними платформ (PHP, Python, Ruby и т. п.).

Разработчики должны тщательно выбирать решение RASP, взвешивая его по следующим параметрам:

• RASP должен быть легко развёртываемым и требовать минимального обслуживания, в противном случае он может стать неэффективным при изменении характера угроз.
• RASP должен обладать широкими возможностями для обнаружения и обработки широкого спектра уязвимостей, как традиционных, так и неизвестных.
• RASP должен оказывать минимальное влияние на показатели производительности приложения, без которых уровень безопасности теряет всякий смысл. Ни один разработчик не променяет комфорт пользователей на дополнительную функцию защиты.
• RASP должен действовать точно и с наименьшим количеством ложных срабатываний, чтобы не блокировать легитимный пользовательский трафик.
• RASP должен легко работать с другими инструментами безопасности, такими как WAF.
• RASP должен обеспечивать поддержку нескольких фреймворков и языков.
• RASP должен быть автономным, обеспечивать поддержку облачного анализа с круглосуточным мониторингом и блокировать вредоносные запросы.
• RASP должен предоставлять всеобъемлющий и полезный отчёт обо всех обработанных угрозах и обучаться на поведении приложения во время выполнения, чтобы динамически защищать его как от пассивных инцидентов, так и от активных.

Самозащита приложений во время их выполнения (RASP) — это инновация в экосистеме безопасности программ, предназначенная для борьбы с атаками на прикладном уровне за счёт обеспечения большей видимости скрытых уязвимостей. По сути это — программный комплекс, который интегрируется с приложением или средой его выполнения и постоянно перехватывает программные вызовы для проверки их безопасности. На мировом рынке представлено множество различных продуктов — как от известных вендоров в области безопасности, так и от нишевых игроков, занимающихся только разработкой RASP.

№5. SCA

Решения для анализа состава программного обеспечения (SCA) анализируют корпоративные приложения, как правило, уже в процессе разработки, чтобы идентифицировать встроенные open source компоненты и, иногда, коммерческие продукты внутри проектов заказчика. Кроме этого, инструменты SCA выявляют известные уязвимости в этих пакетах, что повышает эффективность разработки, т.е. снижает затраты на исправление дефектного кода. Они также могут определять лицензию, под которой распространяется конкретный компонент, что облегчает оценку юридических рисков.

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

В качестве вызовов, влияющих на развитие и распространение подобных решений, можно выделить следующие:

Большое количество пакетов с открытым исходным кодом, их взаимозависимостей и использованных языков программирования порождают сложную структуру. Чтобы справиться с ней, компаниям приходится комбинировать несколько решений — это усложняет реализацию анализа безопасности и затраты на этот процесс;

SCA-инструменты при выявлении вредоносного кода полагаются на публичные базы данных уязвимостей и часто обходят стороной коммерческие библиотеки ПО, которые также могут быть полезны при поиске опасных брешей;

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

SCA-системы полезно оценивать по следующим возможностям и параметрам:

• Удобство для разработчиков.
• Экосистемность и интеграционные возможности.
• Анализ зависимостей.
• Обнаружение, приоритизация, исправление уязвимостей.
• Управление и контроль.
• Составление отчётов.
• Автоматизация и расширяемость.
• Безопасность облачных приложений.

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

Заключение

Сегодня мы наблюдаем резкий рост значимости безопасности в контексте создания приложений, что приводит к увеличению популярности DevSecOps и более глубокому проникновению подходов безопасной разработки в процессы компаний. В целом технологический пул практик AppSec проявляет высокую чувствительность к современным трендам кибербезопасности и в результате трансформируется.

Источник:

1. Юрий Сергеев – основатель и генеральный партнер Swordfish Security – DevSecOps и практики разработки защищенного ПО в контексте современных вызовов
   Ссылка: https://habr.com/ru/companies/swordfish_security/articles/702732/
2. Артем Пузанков – Департамент защиты приложений VK – Кто такие Security Champions?
   Ссылка: https://habr.com/ru/companies/vk/articles/725088/
3. Екатерина Быстрова – Журналист Anti-Malware.ru – Разработка безопасных приложений.
   Ссылка: https://www.anti-malware.ru/analytics/Market_Analysis
4. Юрий Шабалин – Ведущий архитектор Swordfish Security – Выбираем динамический анализатор: на что обратить внимание?
   Ссылка: https://www.anti-malware.ru/analytics/Technology_Analysis/Dynamic-program-analysis-choosing
5. Безопасная разработка: SAST, DAST, IAST и RASP
   Ссылка: https://habr.com/ru/companies/alexhost/articles/535128/

Адаптация и редакция:
Сапиев А.