Что FAST использует при тестировании на уязвимости

В своей работе FAST использует следующие компоненты:

• Набор запросов,
• Политика тестирования FAST,
• Тест безопасности (или кратко «тест», если не указано иное),
• Токен.

Некоторые важные взаимосвязи между этими компонентами:

• Одна политика и один набор запросов могут использоваться несколькими тестами и FAST-нодами.
• Один токен — одна FAST-нода в облаке Валарм, один запущенный Docker-контейнер с FAST-нодой, один тест.
• Вы можете передать в Docker-контейнер с FAST-нодой уже существующий токен при условии, что он не используется другими контейнерами с FAST-нодами.
• Если для FAST-ноды создается новый тест безопасности в то время как на ней уже запущен другой, то выполнение последнего будет остановлено и произойдет запуск нового.

Компоненты, участвующие в работе FAST

В процессе тестирования на уязвимости FAST-нода проксирует все запросы, поступающие к целевому приложению от источника запросов. Такие запросы в терминологии Валарм называются базовыми запросами (англ. baseline requests).

Когда FAST-нода проксирует базовые запросы через себя, она сохраняет эти запросы для последующего создания набора тестов безопасности на их основе. Этот процесс иначе называется записью базовых запросов. Запросы записываются в специальный объект, далее — набор запросов (англ. test record).

На основе записанных базовых запросов FAST-нода создает несколько тестовых запросов согласно политике тестирования (англ. test policy). Этот набор затем выполняется для проверки целевого приложения на наличие уязвимостей.

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

Набор запросов

Набор запросов хранит в себе все записанные базовые запросы, на основе которых FAST-нода создает набор тестов безопасности.

Для первичного наполнения набора запросов необходимо создать и запустить тест безопасности, связанный с набором запросов и FAST-нодой, в рамках которого будет происходить запись базовых запросов. Это можно сделать, используя API Валарм; такой подход может использоваться для интеграции FAST-ноды в CI/CD. Подробнее об этом вы можете узнать здесь.

Кроме того, наполнение набора запросов возможно и без запуска тестов, для этого существует механизм запуска FAST-ноды в режиме записи, который можно использовать в процессах CI/CD. Подробнее об этом написано здесь.

После создания набора запросов его можно использовать в различных тестах безопасности.

При этом один существующий набор запросов может использоваться несколькими FAST-нодами и тестами безопасности одновременно. Например, это может быть полезно, если проводится:

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

Политика тестирования FAST

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

Вы можете создать новую политику или использовать уже существующую.

Тест безопасности

Однократный цикл тестирования на уязвимости описывается с помощью теста безопасности (англ. test run).

Тест безопасности содержит в себе:

• идентификатор политики тестирования;
• идентификатор набора запросов.

Эти данные используются FAST-нодой при выполнении тестирования целевого приложения на уязвимости.

Тест тесно связан с конкретной FAST-нодой. Если вы запустите новый тест безопасности B для FAST-ноды, в то время как на ней уже проходит тест A, то выполнение теста A будет остановлено и начнется выполнение теста B.

Вы можете использовать тесты безопасности для одного из следующих сценариев:

• Для тестирования целевого приложения на уязвимости c записью базовых запросов от источника запросов к целевому приложению (новый набор запросов).

  Далее для краткости изложения под созданием теста безопасности будет подразумеваться запуск теста безопасности с новым набором запросов, если не указано иное.

• Для тестирования целевого приложения на уязвимости с использованием записанных ранее базовых запросов (если используется существующий набор запросов, то повторного развертывания источника запросов не требуется).

  Операция создания такого теста называется копированием теста безопасности. Это определение будет использоваться далее в тексте этого руководства.

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

Порядок выполнения теста безопасности при осуществлении записи базовых запросов

После создания и запуска теста безопасности начинается его выполнение, включающее в себя следующие шаги:

1. FAST-нода ожидает запуска теста.

   После обнаружения соответствующего теста безопасности, нода получает содержащиеся в нем идентификатор политики тестирования и идентификатор набора запросов.

2. После получения идентификаторов начинается процесс записи базовых запросов: теперь FAST-нода готова проксировать запросы от источника запросов к целевому приложению.

3. При активном процессе записи можно начать проведение существующих тестов. Эти тесты будут проксироваться через FAST-ноду и восприниматься ей как набор базовых запросов.

   Все записанные базовые запросы будут помещены в набор запросов, связанный с тестом безопасности.

4. После завершения проведения существующих тестов можно остановить процесс записи.

   Во время создания теста безопасности задается значение таймера, ограничивающее время ожидания поступления базовых запросов (параметр inactivity_timeout).

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

   Если процесс записи не остановлен, то:

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

   
   Вы можете остановить процесс записи на FAST-ноде, если поступления новых базовых запросов больше не ожидается. При этом:

   • Процессы создания и выполнения тестовых запросов будут продолжаться. Выполнение теста безопасности будет остановлено сразу же после завершения тестирования целевого приложения на уязвимости, что позволит сократить общее время выполнения задания CI/CD.
   • Набор запросов можно будет переиспользовать в других тестах.

   
   

5. Для каждого записанного базового запроса FAST-нода создает один или несколько тестовых запросов (при условии, что базовый запрос удовлетворяет политике тестирования).

6. Происходит выполнение созданных тестовых запросов путем их отправки целевому приложению.

Остановка записи базовых запросов не влияет на создание и выполнение тестовых запросов для уже записанных базовых запросов.

Процессы записи запросов, выполнения существующих тестов, а также создания и выполнения тестовых запросов проходят параллельно друг другу:

Именно этот вариант тестов безопасности был продемонстрирован в руководстве «Быстрый старт».

Выполнение теста безопасности одновременно с записью базовых запросов возможно и в рамках внедрения FAST в процессы CI/CD. Для манипуляций с таким тестом безопасности используется API Валарм. Подробнее об использовании API для внедрения FAST в CI/CD вы можете прочитать здесь.

Порядок выполнения теста безопасности при использовании уже записанных базовых запросов

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

1. FAST-нода ожидает запуска теста.

   После обнаружения соответствующего ноде теста безопасности, нода получает содержащиеся в нем идентификатор политики тестирования и идентификатор набора запросов.

2. После получения идентификаторов нода извлекает все записанные базовые запросы, хранящиеся в наборе запросов.

3. Для каждого базового запроса, содержащегося в наборе, FAST-нода создает один или несколько тестовых запросов (при условии, что базовый запрос удовлетворяет политике тестирования).

4. Происходит выполнение созданных тестовых запросов путем их отправки целевому приложению.

Процессы извлечения базовых запросов из набора запросов, а также создания и выполнения тестовых запросов проходят последовательно:

Тест безопасности с использованием заранее записанных базовых запросов применим в случае внедрения FAST в CI/CD. Для манипуляций с таким тестом безопасности может использоваться API Валарм или режим тестирования FAST-ноды (CI MODE), о чем подробнее будет написано далее.

В общем случае при использовании заранее записанных базовых запросов этапы работы FAST-ноды будут выглядеть так:

Работа с тестами безопасности

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

• остановка записи базовых запросов, если от источника запросов их больше не поступает;
• проверка состояния процесса выполнения тестов.

Для выполнения таких запросов к API и связывания FAST-ноды с тестом безопасности необходимо получить токен.

Токен

FAST-нода описывается двумя неразрывно связанными сущностями:

• Запущенным Docker-контейнером с программным обеспечением FAST.

  Именно здесь происходит проксирование трафика, создание и выполнение тестовых запросов.

• FAST-нодой в облаке Валарм.

Токен связывает эти две сущности:

Для развертывания FAST-ноды вам необходимо:

1. Создать ноду в облаке Валарм (для этого воспользуйтесь порталом Валарм) и скопировать предоставленный токен.
2. Развернуть Docker-контейнер с нодой и передать в контейнер значение токена (этот процесс описан здесь).

Также токен служит для:

• связывания запуска тестов c FAST-нодой;
• управления процессом выполнения тестов (запуска) при помощи запросов к API.

Вы можете создать необходимое количество нод в облаке и получить токены для созданных нод. Например, если у вас есть несколько заданий CI/CD, требующих использования FAST, вы можете создать по одной FAST-ноде в облаке Валарм для каждого задания.

Также возможно переиспользовать полученные ранее токены, при условии, что они не используются другими запущенными Docker-контейнерами с FAST-нодой (например, если Docker-контейнер с FAST-нодой, использующей такой же токен, остановлен или удален):