R&S®Trusted Application Factory: Workflow as Code

Dans cet article nous allons étudier le fonctionnement des workflows sous R&S®Trusted Application Factory.
    
Le « Worfklow » selon Rohde & Schwarz Cybersecurity


Le concept de workflow sur les produits de Rohde & Schwarz Cybersecurity désigne la possibilité de définir des actions à effectuer sur une requête selon le contexte de cette dernière, permettant ainsi de créer des mesures de sécurité conforme à des attentes différentes. 
Un grand nombre d’action est disponible : Détecter les patterns d’attaques ou les robots, vérifier les cookies d’un utilisateur, créer des pages de redirections spécifiques, conditions dépendantes du pays d’origine de la requête, et bien d’autres.
Cette fonctionnalité, permet de déplacer une partie du code gérant la sécurité d’une application web dans une application dédiée.

D’abord apparu sur le R&S®Web Application Firewall et configurable visuellement, le workflow a évolué et se présente aujourd’hui d’une nouvelle manière sur R&S®Trusted Application Factory.

Le "Worfklow As Code” de R&S®Trusted Application Factory 


Les fichiers utilisés dans cet article sont trouvables à l’adresse suivante :  https://doc.trustedapphub.io/guide/install_docker_compose.html

Lors de la naissance du DevOps, le concept d’Infrastructure As Code est apparu, désignant la possibilité d’automatiser le déploiement d’applications grâce à des fichiers de configuration.

 R&S®Trusted Application Factory est un produit qui cherche à faire évoluer le DevOps en DevSecOps, en ajoutant la sécurité avec le concept de « Security as Code » permettant de définir des règles de sécurité ainsi que de créer des workflows directement dans des fichiers de configurations YAML.

Le premier est un fichier docker utilisé pour lancer l’instance, sur lequel nous ne nous attarderons pas dans cet article.


Le deuxième contient le workflow spécifique à appliquer sur cette instance et sera notre fil rouge.
Commençons par la première partie qui contient la configuration générale


Dans la catégorie spec category, nous retrouvons les variables workflow et workflow_paramscette dernière indique la configuration d’exception à utiliser sur le workflow.
Nous retrouvons cette configuration dans la dernière partie de notre fichier 
YAML : 


 

Dans cet exemple, une seule règle d’exception est définie : sur le chemin /webmail/message, les injection HTML sont autorisées dans les paramètres de l’URL

Intéressons-nous de plus près au workflow :


La variable name permet d’identifier le workflow et possède la même valeur que la variable workflow de la configuration générale.


 
 

La partie la plus intéressante est spec.


 
entrypoint indique la fonction qui sera appelée pour créer le workflow dans l’instance de TAF.
C’est à l’intérieur de la variable source qu’est définie la suite d’actions à effectuer.

 

De R&S®Trusted Application Factory au R&S®Web Application Firewall

Avant d’étudier le workflow plus en profondeur, posons-nous la question « Comment ce workflow en Golang est -il interprété par R&S®Trusted Application Factory? »
En effet, le moteur de R&S®Trusted Application Factory est le même que celui du R&S®Web Application Firewall, or sur ce dernier, les workflows sont créés visuellement et converti au format XML.

Cela se passe en 2 étapes :


1.    Conversion Golang - AST

Un AST (Abstract Syntax Tree) est un intermédiaire entre un programme écrit et du code machine en ne gardant que les informations utiles
Pour convertir le workflow en AST, le package « parser » est utilisé (https://pkg.go.dev/go/parser)

 

Un AST ressemble généralement à cela :

2.    Conversion AST - XML

Cet AST est ensuite converti en XML ce qui nous donne le fichier suivant (simplifié).


 

Chaque <node> représente une action, le type d’action est défini par l’attribut « type », les attributs « uid » et « children » quant à eux permettent d’obtenir l’ordre d’exécution.


En insérant ce fichier dans le R&S®Web Application Firewall, nous obtenons le workflow visuel suivant : 


 

En comparant nos workflows visuels et en go nous retrouvons bien les correspondances, profitons-en pour comprendre le fonctionnement de ce workflow :

Pour commencer, le point d’entrée avec la main() elle prend 2 paramètres

La première fonction utilisée est ActionICXSecurityEngine(), qui va analyser la requête en cours avec la configuration passée en paramètre de la fonction main() afin d’y détecter de potentielles attaques

 

Vient ensuite la fonction ActionSecurityExceptionManagement() utilisant la deuxième variable de main() représentant les règles d’exceptions définies, ces exceptions vont ainsi être acceptées dans la requête
 


La fonction ActionLogAlert() va ensuite envoyer les alertes à la base de données.

  

Pour comprendre cette première partie de programme, un schéma s’impose 

http.request.security.events est un attribut utilisé pour stocker les attaques détectées par le moteur de sécurité.
Il est tout d’abord remplit par ces dernières, puis les attaques autorisées sont retirées en se basant sur les règles d’exceptions.

Les alertes de sécurité restantes sont alors envoyées pour être affichées dans les logs du conteneur.

Pour le continuer le workflow nous trouvons une condition vérifiant qu’au moins une alerte de sécurité est répertoriée dans http.request.security.events par l’intermédiaire de l’attribut booléen fournit par le noeud SecurityExceptionManagement : security.exception.blocked
 

Si cette dernière s’avère vraie, alors une réponse générée avec ActionGenerateResponse() renverra une page d’erreur avec le statut 403, ce statut et le contenu de la page d’erreur sont personnalisables depuis le paramètre de la fonction

 


Dans le cas contraire, la fonction ActionProxyRequest() va transmettre la requête HTTP au backend de l’application protégée par R&S®Trusted Application Factory
 

Terminons par un schéma récapitulatif : 

Autres communications