R&S® Trusted Application Factory: Workflow as Code

R&S®Trusted Application Factory: Workflow as Code

In this article, we will look at how workflows work in the R&S®Trusted Application Factory.
 

The " Workflow "  according to Rohde & Schwarz Cybersecurity

 

The concept of workflow in Rohde & Schwarz Cybersecurity products refers to the possibility of defining actions to be performed on a request depending on the context of the request, thus enabling the creation of security measures that meet different expectations.

A large number of actions are available: detecting attack patterns or bots, checking a user's cookies, creating specific redirect pages, conditions depending on the country of origin of the request, and many others.

This feature, allows moving part of the code managing the security of a web application in a dedicated application.


The files used in this article can be found at the following address:   https://doc.trustedapphub.io/guide/install_docker_compose.html

With the advent of DevOps, the concept of Infrastructure As Code has emerged, which refers to the ability to automate application deployment through configuration files.

 R&S®Trusted Application Factory is a product that seeks to evolve DevOps into DevSecOps, by adding security with the concept of " Security as Code", which allows security rules to be defined and workflows to be created directly in YAML configuration files.

 

This first one is a Docker file used to launch the instance, but we will not dwell on this in this article.


The second one contains the specific workflow to be applied on this instance and will be our common storyline.

Let us start with the first part, which contains the general configuration.


In the spec category, we find the workflow and workflow_params variables; the latter indicates the exception configuration to be used on the workflow. We find this configuration in the last part of our YAML file: 


 

In this example, only one exception rule is defined: on the path /webmail/message, HTML injections are allowed in the URL parameters.

 

Let us take a closer look at the workflow:


The name variable identifies the workflow and has the same value as the workflow variable in the general configuration.


 
 

The most interesting part is spec.


 
entrypoint indicates the function that will be called to create the workflow in the R&S®Trusted Application Factory instance. It is within the source variable that the sequence of actions to be performed is defined. 

Before studying the workflow further, let us ask the question "How is this workflow in Golang interpreted by R&S®Trusted Application Factory?"
The R&S®Trusted Application Factory engine is the same as that of the R&S®Web Application Firewall, but on the latter, workflows are created visually and converted to XML format.

This happens in two steps:


1.    Golang - AST conversion

An abstract syntax tree (AST) is an intermediary between a written program and machine code by keeping only the useful information.
To convert the workflow into AST, the parser package is used (https://pkg.go.dev/go/parser)

An AST generally looks like this:


2.    AST - XML conversion

This AST is then converted to XML, which gives us the following file (simplified).

Each <node> represents an action, the type of action is defined by the "type" attribute, the "uid" and "children" attributes as for them allow to obtain the execution order.


By inserting this file into the R&S®Web Application Firewall, we obtain the following visual workflow:



By comparing our visual and go workflows, we can see the correspondences; let us take advantage of this to understand how this workflow works:

To start, the entry point with the main()  takes two parameters:

The first function used is ActionICXSecurityEngine(), which will analyze the current request with the configuration passed as a parameter to the main() function to detect potential attacks. 

Then comes the ActionSecurityExceptionManagement() function using the second variable of main() representing the defined exception rules, these exceptions will be accepted in the request.


The ActionLogAlert() function will then send the alerts to the database. 


To understand this first part of the program, a diagram is necessary.
   

http.request.security.event s is an attribute used to store attacks detected by the security engine.
It is first filled by the latter, then the allowed attacks are removed based on the exception rules.
The remaining security alerts are then sent to be displayed in the container logs.

To continue the workflow we find a condition checking that at least one security alert is listed in http.request.security.events via the Boolean attribute provided by the SecurityExceptionManagement node: security.exception.blocked 


If the latter is true, then a response generated with ActionGenerateResponse() will return an error page with the status 403, this status and the content of the error page are customizable. 

Otherwise, the ActionProxyRequest() function will forward the HTTP request to the backend of the application protected by R&S®Trusted Application Factory.

Let us end with a summary diagram:

 

Other news