Vérification, Validation, Qualification

L’une des difficulté de la mise en œuvre d’un SOC est la volonté d’avoir un fonctionnement en partie prédictible (assurance que des événements redoutés seront bien détectés) dans un environnement complexe non maîtrisé. On pourrait donc être tenté d’appliquer des méthodes de conception visant à construire des systèmes sûrs. Essayons donc d’appliquer l’approche VVQ appliquée aux tests de recette, bien connue des ingénieurs qualité.

V comme Vérification : tests permettant de confirmer que le système est conforme aux spécifications. Dans le cas d’un SOC, cela correspondrait aux tests unitaires de règles de détection, qu’on peut imaginer intégrés dans une chaine de Detection as Code. On vérifie que techniquement, la règle est fonctionnelle face à un cas d’usage précisément spécifié. Concrètement, ceci permet de tester la couverture et la disponibilité de la collecte, l’algorithme, les seuils et l’absence de régression en cas de modification.

V comme Validation : tests permettant de confirmer que le système est fonctionnel dans un environnement prévu (théorique). Ici, on retrouve les outils de type BAS, déroulant des scénarios construits sur la connaissance générique de la menace, faiblement personnalisés à l’environnement, sans prise en compte du facteur humain. On vérifie que face à des actions déjà observées dans des environnements techniques et de risques similaires, le système est fonctionnel. Concrètement, on challenge le choix des cas d’usages, leur couverture de la menace, les corrélations entre règles et la gestion des signaux faibles.

Q comme Qualification : tests permettant de confirmer que le système répond au besoin réel. Dans le cas d’un SOC, on testerait la capacité à répondre à des acteurs de menace envisagés : c’est le Red Team (quand il est fait dans les règles) avec adaptation au contexte et utilisation de techniques d’ingénierie sociale. Concrètement, on teste la stratégie de détection, les procédures d’analyse, la rapidité et la pertinence de la qualification.

Certains pourraient vouloir positionner le Purple Team dans ce modèle. On pourrait dire qu’il s’agit d’une forme de vérification et de validation puisque les scénarios sont définis à l’avance et les règles construites en fonction. Toutefois, l’objectif du Purple Team n’est pas de tester mais de construire. En ingénierie système, il s’agirait donc plutôt de tests d’intégration.