FAST makes use of the following entities:
There are a few important relations between the entities mentioned earlier:
- A test policy may be used by several test runs and FAST nodes.
- A token relates to the single FAST node in the Wallarm cloud, the single Docker container with the FAST node and the single test run.
- You can pass the existing token value into a Docker container with the FAST node, given 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 is stopped and replaced with the new one.
The FAST node proxies all the requests from the request source to the target application. These requests are called baseline requests in the Wallarm terminology.
After receiving the baseline requests, the FAST node creates a security test set on their basis according to a test policy. Then, the security test set is executed to evaluate the target application against vulnerabilities.
A test policy defines a set of rules, according to which the process of vulnerability detect is conducted. In particular, you can select the vulnerability types which the application should be tested for. In addition to that, 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 utilized by FAST to create test requests that are used to find out if the target application is exploitable.
The choice of the test policy depends on how the tested target application works. It is recommended to 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.
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 customly 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 to get the policy identifier in order to use the policy with FAST. To obtain the identifier, open the test policies tab on the Wallarm portal. The identifier (e.g.
158) is located under the name of the policy:
The default test policy has its own predefined identifier as well. The FAST node fetches a test policy identifier to work with from a corresponding test run.
A test run describes the single iteration of the vulnerability testing process.
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, giving the place for the test run
When you create a test run, its execution begins immediately. The execution process comprises the following steps:
The FAST node determines the start of the test run and fetches the test policy identifier from the test run.
After obtaining the identifier, the baseline requests recording process is started.
Now the FAST node is ready to proxy requests from the request source to the target application.
Given that the request recording is active, it is time to start the execution of existing tests. HTTP and HTTPS requests are proxied through the FAST node that recognizes them as baseline requests.
After the tests execution is finished, you could stop the recording process.
There is a special timeout value being 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
If you do not stop the recording process manually, the test run continues its execution until the timeout value expires, even if the FAST security tests are already finished.
You could stop the recording process on the FAST node if there are no more baseline requests to be awaited. Note that the processes of creation and execution of the security tests are not be stopped in this case. 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.
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).
The FAST node executes the test requests by sending them to the target application.
Stopping the baseline request recording process has no impact on the processes of creation and execution of the test requests.
The processes of baseline request recording, creation, and execution of the FAST security tests run in parallel:
While reading throughout 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.
A FAST node comprises:
The up and running Docker container with FAST software.
This is exactly where the processes of traffic proxying, and security tests creation and execution take place.
The FAST node in the Wallarm cloud.
A token binds the running Docker container with the FAST node in the cloud:
To deploy a FAST node, do the following:
- Create a FAST node in the Wallarm cloud using the Wallarm portal. Copy the provided token.
- Deploy a Docker container with the node and pass the token value into the container (this process is described here in detail).
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 the 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 the tokens you have obtained earlier if the tokens are not in use by other running Docker containers with FAST node (e.g. the Docker container with the node which employ the same token is stopped or removed):
The next chapter describes the necessary preparations that should be done before the integration of FAST into the CI/CD.