How FAST Operates

FAST makes use of the following entities:

There are a few important relationships between the entities mentioned earlier:

  • A test policy and a test record may be used by several test runs and FAST nodes.
  • A token relates to a single FAST node in the Wallarm cloud, a single Docker container with that FAST node and a single test run.
  • You can pass the existing token value into a Docker container with the FAST node, provided that the token is not in use by any other Docker container with the node.
  • If you create a new test run for the FAST node while another test run is in place, the current test run will stop and be replaced by the new one.

Relations between the components

The Entities Used by FAST

The FAST node acts as proxy for all the requests from the request source to the target application. These requests are called baseline requests in the Wallarm terminology.

When FAST node receives requests, it saves them into the special “test record” object to later create security tests based on them. This process is called “baseline requests recording” in the Wallarm terminology.

After recording the baseline requests, the FAST node creates a security test set according to a test policy. Then, the security test set is executed to evaluate the target application against vulnerabilities.

The test record allows reusing previously recorded baseline requests to test the same target application or another target application again; there is no need to repeat the sending of identical baseline requests through the FAST node. This is only possible if the baseline requests in the test record are suitable for testing the application.

Test Record

FAST creates a security test set from baseline requests that are stored in the test record.

To populate a test record with some baseline requests, a test run that is tied to this test record and a FAST node must be executed and some baseline requests must be sent through the FAST node.

Alternatively, it is possible to populate a test record without creation of a test run. To do so, you must run the FAST node in recording mode. See this document for details.

Given that the test record is populated with requests, it is possible to use it with another test run, if an application under the test can be evaluated for vulnerabilities using a subset of the baseline requests stored in the test record.

A single test record could be employed by multiple FAST nodes and test runs. This may be useful if:

  • The same target application is being tested again.
  • Multiple target applications are being tested concurrently with the same baseline requests.

Working with a test record

FAST Test Policy

A test policy defines a set of rules for conducting the process of vulnerability detection. In particular, you can select the vulnerability types that the application should be tested for. In addition, the policy determines which parameters in the baseline request are eligible to be modified while creating a security test set. These pieces of data are used by FAST to create test requests that are used to find out if the target application is exploitable.

Choosing the Appropriate Test Policy

The choice of the test policy depends on how the tested target application works. It is recommended that you create a distinct test policy for each of the applications you test.

You can create a new policy or employ an existing one. To create a test policy, go to the Wallarm portal.

How to Create a Policy

An example of the step-by-step test policy creation process is described in the “Quick Start Guide.”

You can use the default policy instead of a custom-created one. The default policy allows testing the target application against the most common vulnerability types by modifying all of the POST and GET parameters’ values in each baseline request.

If you employ your own policy, you need the policy identifier in order to use the policy with FAST. To obtain the identifier, open the test policies tab in the Wallarm portal. The identifier (e.g., 158) is located under the name of the policy:

The identifier of a test policy

The default test policy has its own predefined identifier. The FAST node fetches a test policy identifier from a corresponding test run to work with.

Test Run

A test run describes the single iteration of the vulnerability testing process.

A test run contains:

FAST node employs these values while conducting a security test of a target application.

Each test run is tightly coupled with a single FAST node. If you create a new test run B for the FAST node while there is another test run A in progress for this node, the test run A’s execution is aborted and replaced by test run B.

It is possible to create a test run for two different testing scenarios:

  • In the first scenario, a target application is being tested for vulnerabilities and a baseline requests recording is taking place simultaneously (to a new test record). The requests should flow from the request source to the target application through the FAST node for the baseline requests to be recorded.

    A creation of a test run for this scenario will be referred to as “test run creation” throughout the guide.

  • In the second scenario, a target application is being tested for vulnerabilities with the baseline requests extracted from an existing, non-empty test record. In this scenario, it is not necessary to deploy any request source.

    A creation of a test run for this scenario will be referred to as “test run copying” throughout the guide.

When you create or copy a test run, its execution begins immediately. Depending on the testing scenario in action, the execution process will follow different steps (see below).

Test Run Execution Flow (baseline requests recording takes place)

When you create a test run, its execution begins immediately and follows the following steps:

  1. A FAST node awaits a test run.

    When the FAST node determines that the test run has started, the node fetches the test policy and the test record identifiers from the test run.

  2. After obtaining the identifiers, the baseline requests recording process starts.

    Now the FAST node is ready to receive requests from the request source to the target application.

  3. Given that the request recording is active, it is time to start the execution of existing tests. HTTP and HTTPS requests are sent through the FAST node, which recognizes them as baseline requests.

    All baseline requests will be stored in the test record that corresponds to the test run.

  4. After the test execution is finished, you could stop the recording process.

    There is a special timeout value set after the creation of a test run to determine how long FAST should wait for new baseline requests before stopping the recording process due to the absence of baseline requests (the inactivity_timeout parameter).

    If you do not stop the recording process manually, then:

    • The test run continues its execution until the timeout value expires, even if the FAST security tests are already finished.
    • Other test runs are not able to reuse the test record until this test run stops.

    You could stop the recording process on the FAST node if there are no more baseline requests awaiting. Note the following:

    • The processes of creation and execution of the security tests are not to be stopped. Test run execution stops when the evaluation of the target application against the vulnerabilities finishes. This behavior helps to decrease the execution time of the CI/CD job.
    • Other test runs gain the ability to reuse the test record once recording is stopped.
  5. The FAST node creates one or more test requests based on each of the incoming baseline requests (only if the baseline request satisfies the applied test policy).

  6. The FAST node executes the test requests by sending them to the target application.

Stopping the baseline requests recording process has no impact on the processes of creation and execution of the test requests.

The processes of baseline requests recording and the creation and execution of the FAST security tests run in parallel:

Test run execution flow (baseline requests recording takes place)

Note: the chart above shows the flow described in the FAST quick start guide. A flow with baseline requests recording is suitable either for manual security testing or automated security testing using CI/CD tools.

In this scenario, Wallarm API is required to manipulate the test run. See this document for details.

Test Run Execution Flow (pre-recorded baseline requests are used)

When you copy a test run, its execution begins immediately and follows the following steps:

  1. A FAST node awaits a test run.

    When the FAST node determines that the test run has started, the node fetches the test policy and the test record identifiers from the test run.

  2. After obtaining the identifiers, the node extracts the baseline requests from the test record.

  3. The FAST node creates one or more test requests based on each of the extracted baseline requests (only if the baseline request satisfies the applied test policy).

  4. The FAST node executes the test requests by sending them to the target application.

The process of baseline requests extracting takes place prior to the creation and execution of the FAST security tests:

Test run execution flow (pre-recorded baseline requests are used)

Note, that it is the execution flow that is used in the FAST quick start guide. The flow that make use of pre-recorded baseline requests is suitable for automated security testing with use of CI/CD tools.

In this scenario, the Wallarm API or FAST node in CI mode can be used to manipulate the test run. See this document for details.

The chart below shows the most commonly encountered CI/CD workflow, which complies with the timeline shown above:

Test run execution flow (CI Mode)

Working with Test Runs

While reading this guide, you will learn how to manage the test run execution process using API calls, specifically:

  • How to stop the baseline requests recording process if there are no more requests from the request source.
  • How to check the test run execution status.

You need to obtain a token in order to make such API calls and to bind the test run to the FAST node.

Token

A FAST node comprises:

  • The up and running Docker container with FAST software.

    This is where the processes of traffic proxying and security test creation and execution take place.

  • The Wallarm cloud FAST node.

A token binds the running Docker container with the FAST node in the cloud:

FAST node

To deploy a FAST node, do the following:

  1. Create a FAST node in the Wallarm cloud using the Wallarm portal. Copy the provided token.
  2. Deploy a Docker container with the node and pass the token value into the container (this process is described in detail here).

The token serves the following purposes as well:

  • Connecting the test run with the FAST node.
  • Allowing you to manage the test run execution process by making API calls.

You could create as many FAST nodes in the Wallarm cloud as you need and obtain a token for each of the nodes. For example, if you have several CI/CD jobs where FAST is required, you may spin up a FAST node in the cloud for each job.

It is possible to reuse tokens you obtained earlier if the tokens are not in use by other active Docker containers with FAST node (e.g., any Docker container with a node that employs the same token is stopped or removed):

Reusing the token

results matching ""

    No results matching ""