Introduction
Cet article de blog est le premier d’une série consacrés au projet Cyrus et à la plateforme du même nom initiée dans le cadre de ce projet. Cet article se concentre sur les activités initiales du projet Cyrus : l’établissement d’un état de l’art des normes et outils donnant lieu à l’élaboration d’une méthodologie générique de test de cybersécurité.
Etat de l’art
Le projet Cyrus a débuté par un état de l’art sur 2 sujets : les principaux standards de test de pénétration et les outils de tests.
L’état de l’art sur les standards a identifié les résultats suivants :
- Le standard PTES (Penetration Testing Execution Standard) est celui qui a le plus influencé le processus générique de test, par sa découpe en phases et son approche pratique, allant jusqu’à lister des outils et des techniques à utiliser ;
- La méthodologie FDAM (Field Device Assessment Methodology) a également été une grande influence, car elle est une des rares orientées sur les tests de systèmes cyber-physiques ;
- Le standard "OWASP testing guide" (Open Web Application Security Project), plus orienté web, est toutefois intéressant pour ses scénarios de tests de pénétration ainsi que sa vision plus large qui tient compte du cycle de vie du système ;
- Le standard NIST SP 800 115 (National Institute of Standards and Technology) se veut être un guide technique pour la réalisation de tests de sécurité plutôt qu’un cadre définissant un processus en tant que tel ;
- Le framework ISSAF (Information Systems Security Assessment Framework) est lui aussi assez intéressant de par son approche "Framework", mais le manque de suivi de cette initiative en font un standard un peu daté et peu clair ;
- La méthodologie OSSTMM-3 (Open Source Security Testing Methodology Manual version 3), bien que très intéressante, est incompatible avec les autres standards de par son approche anti-risques et a peu été prise en compte.
L’état de l’art sur les outils a identifié plusieurs difficultés pour procéder à une sélection des outils nécessaires à des tests de pénétration :
- Le très grand nombre d’outils disponibles, avec des fonctionnalités parfois similaires, partiellement ou complètement, et des interfaces qui facilitent plus ou moins l’intégration ;
- La grande diversité parmi ces outils. De nombreuses catégories d’outils existent dont certaines se recouvrent entre elles ;
- La visibilité et l’accès à ces outils :
- Certains de ces outils ont été développés pour de véritables attaques et sont, par conséquent, peu visibles publiquement ;
- Des outils commerciaux très visibles peuvent être tout aussi utiles que des scripts partagés sur Github, mais ces derniers seront plus difficiles à trouver ;
- Le fait que certains de ces outils, bien qu’utiles, ne soient plus maintenus.
Les outils identifiés ont été classés en 17 catégories :
- Toolbox : cette catégorie reprend les développements qui regroupent plusieurs types d’outils ;
- Network mapping with scanner : cette catégorie reprend tous les outils permettant de faire de la découverte réseau ;
- Sniffing : cette catégorie reprend les outils permettant d’espionner des interfaces : réseau Ethernet, WIFI, CAN... ;
- MITM : cette catégorie reprend les outils permettant d’espionner des messages échangés en s’insérant dans les communications ;
- Database scan : cette catégorie reprend tous les outils permettant de scanner les vulnérabilités des bases de données ;
- Vulnerability analysis : cette catégorie reprend tous les outils permettant de scanner des éléments à la recherche de vulnérabilités ;
- SAST : cette catégorie reprend tous les outils permettant de rechercher des vulnérabilités sur base du code source d’une application ;
- SCA : cette catégorie reprend tous les outils permettant de rechercher parmi les dépendances liées à un logiciel les vulnérabilités qui y sont associées ;
- DAST & WAST : cette catégorie, proche de la catégorie "vulnerability analysis", reprend tous les outils permettant de rechercher des vulnérabilités en interagissant avec une application en cours d’exécution ;
- Firmware Analysis : cette catégorie reprend tous les outils permettant de décompiler et d’analyser des micrologiciels ;
- Fuzzing tools : cette catégorie reprend tous les outils permettant d’exécuter des tests de type fuzzing ;
- Password attacks : cette catégorie reprend tous les outils permettant de récupérer des mots de passe par différentes méthodes : brute force, rainbow, hash-based... ;
- Wireless attacks : cette catégorie reprend tous les outils permettant d’attaquer des réseaux sans fils ;
- Exploitation tools : cette catégorie reprend tous les outils permettant d’exploiter des vulnérabilités connues ;
- Compliance assessment : cette catégorie reprend tous les outils permettant de scanner une machine afin de vérifier sa conformité avec certaines règles de sécurité prédéfinies ;
- Hardware : cette catégorie reprend le matériel nécessaire à certains types d’attaques : attaques wireless, CAN, Bluetooth… ;
- Forensics : cette catégorie reprend tous les outils permettant d’analyser et d’investiguer des incidents ou des événements.
Méthodologie de test générique
Le processus générique de test (voir Figure 1), basé sur cet état de l’art, se découpe en plusieurs parties :
- Les données d’entrée comprenant l’ensemble des informations pouvant être utiles afin de faire progresser le processus de test :
- Les objectifs de test ;
- Le type de test (White, Grey, Black) ainsi que les informations associées (documentation, code source…) ;
- Le SUT (System Under Test) lui-même ;
- L’analyse de risques et les exigences de sécurité si elles existent ;
- La phase “Information gathering” définit les opérations souvent manuelles qui permettent de mieux comprendre le SUT et de le préparer pour les phases suivantes ;
- La phase de reconnaissance qui vise à capturer des informations techniques plus précises sur le SUT : ports, protocoles, canaux de communication au sens large, capteurs, actuateurs, vulnérabilités... ;
- La phase “Vulnerability Assessment” dont l’objectif est d’identifier un maximum des vulnérabilités existantes, sur base des informations collectées plus tôt ;
- Ensuite vient la phase de test à proprement parler. Cette phase est elle-même divisée en deux activités distinctes : "Deep Dive and Exploitation" pour la partie test de pénétration et "Functional Security Testing" si des exigences fonctionnelles de sécurité ont été définies ;
- Enfin la phase de reporting qui permet de générer un rapport adapté sur base de l’ensemble des informations collectées ou générées au cours du processus de test.
- Figure 1 : Processus générique de test Cyrus
Vers la plateforme de test Cyrus
En support à l’exécution de ce processus générique de test, une plateforme technique a été développée, nécessitant un ensemble d’activités :
- La définition d’un schéma de données adapté aux informations attendues dans le processus générique de test ;
- L’implémentation de ce schéma de données dans une base de donnée PostgreSQL ;
- Une interface de démonstration basée sur une application web réalisée avec le framework Python Django ;
- La réalisation de flux basés sur la plateforme Node Red pour les phases de reconnaissance et d’analyse des vulnérabilités ;
- La réalisation de scripts de test basés sur l’outil de test Python "Robot Framework", ainsi qu’un certain nombre d’outils de test de pénétration pour la partie "Deep Dive and Exploitation" ;
- la création de rapports de tests basée sur l’outil JasperReport, qui permet une personnalisation poussée des rapports et l’exploitation de l’ensemble des informations stockées dans la base de données.
Une première architecture plus avancée et reprenant ces différents éléments a également été définie :
- Figure 2 : CYRUS MVP architecture
Conclusion
Dans cette première partie consacrée au projet Cyrus, nous avons voulu montrer les étapes préliminaires qui ont donné les briques de base de la future plateforme de test Cyrus. Le processus générique de test développé permet d’identifier les étapes automatisables et les outils ou types d’outils nécessaires. L’intégration des outils initiaux dans un démonstrateur a permis de confirmer ou de préciser certains choix et certains besoins concernant la future plateforme.
