Cet article de blog est le second d’une série d’articles consacrés au projet Cyrus et à la plateforme du même nom. Cet article se concentre sur l’architecture actuelle de la plateforme Cyrus et sur comment elle peut être utilisée afin de vérifier le niveau de protection d’un système ou d’un produit. Le premier article est disponible ici : https://www.cetic.be/security-for-cps.
La plateforme Cyrus est le compagnon du Hacker Éthique qui permet de rassembler et de stocker toutes les informations sur le SUT (System Under Test), le système qu’on veut tester, pendant la durée du processus de test Cyrus.
Composants de la plateforme Cyrus
Une partie importante du processus de test Cyrus est faite à l’aide d’outils communautaires externes :
NodeRED, une plateforme de développement orientée flux sur laquelle sont exécutés des flux, flows, (scripts) qui scannent les SUT et envoient les résultats à la plateforme Cyrus. Créer des flux est assez facile grâce aux flows existants et peuvent être facilement partagés. Site https://nodered.org/
Greenbone/OpenVAS, un scanner de vulnérabilités pour les systèmes physiques que les testeurs utilisent pour scanner le SUT et dont ils importent les vulnérabilités proposées par Greenbone/OpenVAS dans Cyrus. Site https://www.greenbone.net/
Kiwi TCMS (Test Control and Monitoring System), un système de gestion des cas de test, fort utilisé pour la gestion de tests de tout type (fonctionnel, performance, …), dans lequel les testeurs créent et exécutent les tests de pénétration sur le SUT pour confirmer ou infirmer la présence des vulnérabilités. Ils importent ensuite les résultats des tests dans Cyrus. Site https://kiwitcms.org/
Robot Framework, un outil d’automatisation des tests pour exécuter des tests utilisant un format de fichier spécifique décrivant des cas de test et que l’on peut lancer depuis Kiwi TCMS. Site https://robotframework.org/
Jasper Report, un outil de génération de rapports, permettant d’extraire les informations collectées pendant le processus de test et de personnaliser le rapport sans demander de la programmation. Site https://www.jaspersoft.com/
Enfin, un autre outil externe libre est utilisé pour sécuriser le serveur Cyrus API :
Keycloack (serveur d’authentification open source). Site https://www.keycloak.org/
Les composants suivants ont été développés pour la plateforme Cyrus :
Un set, prêt à l’emploi, de flux NodeRED et de fichiers cas de test Robot Framework est fourni par la plateforme Cyrus.
Déploiement de la plateforme Cyrus
La plateforme est déployée de la manière suivante :
La plateforme Cyrus est fouine sous forme d’images Docker et déployée avec Docker Compose de manière à utiliser le même conteneur du serveur PostgreSQL :
Le diagramme ci-dessous présente l’ensemble des logiciels de la plateforme Cyrus et leurs interconnexions.
Ce chapitre décrit les différentes interfaces que la plateforme offre à l’utilisateur (testeur) et comment elles sont utilisées pour effectuer des activités du processus de test générique défini par le projet Cyrus. Comme mentionné dans le premier article, le processus de test générique de Cyrus est divisé en plusieurs parties :
Données d’entrées / Coup d’envoi du projet
Dans cette phase initiale, le propriétaire du système à tester vient avec toutes les informations nécessaires pour démarrer le processus de test cyrus. Certaines sont obligatoires :
Pour la plateforme Cyrus, cette phase implique plusieurs actions :
La définition du SUT et de l’analyse des risques est représentée à la figure 1.
 |
 |
Les autres informations telles que la documentation ou le code source ne sont pas directement entrées dans la plateforme mais sont utilisées dans la phase suivante : collecte d’informations.
Collecte d’informations
La collecte d’informations regroupe plusieurs actions pour l’utilisateur telles que :
Toutes ces actions fourniront des informations sur les constituants du SUT et la façon dont ils communiquent. Ces renseignements doivent également être entrés dans la l’interface utilisateur de Cyrus.
Les constituants du SUT sont appelés “assets” dans la plateforme Cyrus et ils peuvent être de 2 types :
Pour chaque constituants, différents types d’informations peuvent être collectées et stockées dans la plateforme Cyrus. Pour simplifier cette partie, elles sont stockées dans un tableau de « paramètres » qui peuvent être toute information jugée utile : adresse IP, fournisseur du composant, bande de fréquence utilisée, version TLS, etc...
Les constituants et leurs paramètres dans la plateforme Cyrus sont représentés à la figure 2.
 |
Reconnaissance
La phase de reconnaissance est la première partie qui nécessite une connexion entre l’environnement de test Cyrus et le SUT. La reconnaissance peut être effectuée manuellement mais les principaux outils sont automatisés à l’aide de flux. Ces flux peuvent être lancés depuis l’interface graphique de Cyrus, ils peuvent utiliser des informations déjà recueillies précédemment et ils vont automatiquement pousser le résultat dans la plateforme Cyrus. Les flux sont représentés à la figure 3.
 |
 |
Les résultats de flux poussés dans Cyrus apparaissent dans les exécutions de flux et les logs associés peuvent être visualisés directement depuis la plateforme Cyrus (voir Figure 4).
 |
 |
Évaluation de la vulnérabilité
La phase d’évaluation de la vulnérabilité consiste à utiliser toutes les informations recueillies préalablement pour déterminer les vulnérabilités possibles sur le SUT. Il y a 2 façons d’interfacer la plateforme Cyrus pour cela :
Soit manuellement, en recherchant dans les bases de données des vulnérabilités connues sur la base des informations recueillies et en les entrant dans la plateforme Cyrus. Cette méthode est illustrée à la figure 5.
 |
 |
Ou en utilisant Greenbone/Openvas pour essayer de trouver les vulnérabilités sur le système de manière automatique. Cette méthode n’est pas exhaustive mais peut rapidement fournir des vulnérabilités utiles.
Cette méthode est illustrée à la figure 6.
 |
 |
Tests
La phase de test est gérée entre 2 outils interconnectés à l’intérieur de la plateforme Cyrus. Pour chaque vulnérabilité que nous voulons tester dans le système, nous allons créer un test dans l’interface utilisateur de Cyrus. La création de ce test créera également un test dans l’outil Kiwi.
L’outil Kiwi sera utilisé ici pour gérer nos tests de pénétration à l’aide de plans de tests et de sessions de test. Il servira également à stocker les résultats des tests et les commentaires du testeur. Voir la figure 7.
 |
 |
Rapports et recommandations
Cette partie conclut un cycle du processus de test Cyrus en effectuant les 2 dernières actions nécessaires : rédiger des recommandations par rapport aux événements qui ont eu lieu pendant le processus et générer le rapport de test.
L’utilisateur devra rédiger des recommandations pour chaque vulnérabilité confirmée et chaque test qui est en erreur dans l’interface utilisateur Cyrus. Il s’agit d’une étape très importante, car elle définit les mesures à prendre pour améliorer la sécurité du SUT ou pour améliorer les tests en vue d’un nouveau cycle de test.
 |
 |
Après les recommandations, l’utilisateur peut maintenant générer le rapport de test contenant toutes les informations sur ce qui s’est passé pendant le processus de test. Pour cela, la plateforme de test va d’abord importer toutes les informations saisies dans Kiwi puis ouvrir le serveur JasperReport. JasperReport va générer le rapport à partir d’un modèle prédéfini qui peut être totalement personnalisé et de toutes les informations que la plateforme de test Cyrus enregistre sur le processus de test : les constituants, les vulnérabilités, leur lien avec les tests, etc...
 |
 |
Dans cette seconde partie consacrée au projet Cyrus, nous avons voulu montrer l’architecture de la plateforme de test Cyrus ainsi que son utilisation. Cette plateforme permet de de dérouler le processus générique de test présenté lors du premier article. Dans le 3ème et dernier article de cette série, nous présenterons son utilisation sur un cas concret qui a permis de valider les choix d’architecture décrits ici.