Traçabilité dans un audit ISO 21434 : valoriser le fuzzing

L’ISO/SAE 21434 ne vous demande pas seulement d’être sécurisé. Elle vous demande de le montrer, à un évaluateur, avec des preuves. C’est sur cette différence qu’un bon travail de sécurité trébuche souvent lors d’un audit, et les tests de sécurité en sont l’exemple le plus net.

La norme demande les tests. Elle demande aussi la trace écrite

Les exigences en matière de tests sont assez claires. La Clause 10.4.2 (intégration et vérification) exige de vérifier que l’implémentation satisfait la spécification de cybersécurité ([RQ-10-09]), et [RC-10-12] recommande des tests de composants, avec du fuzz testing et de l’analyse de vulnérabilités, afin de réduire les faiblesses non identifiées. La Clause 11 (validation de la cybersécurité) cite les tests d’intrusion ([RQ-11-01]). À partir du niveau CAL 2, le fuzzing des interfaces de communication est de fait attendu.

Mais une évaluation 21434 n’est pas notée sur le fait d’avoir exécuté un fuzzer. Elle est notée sur vos produits de travail : le rapport de vérification, le rapport de validation, et au bout du compte le dossier de cybersécurité qui argumente que votre élément est suffisamment sécurisé, jugé dans l’évaluation de cybersécurité (Clause 6.4.9). L’évaluateur lit l’argumentaire et les preuves qui le sous-tendent. Une campagne de fuzzing qui n’est pas intégrée à cet argumentaire aurait aussi bien pu ne jamais avoir lieu.

La traçabilité bidirectionnelle, en une phrase

Ce que les évaluateurs ne cessent de réclamer, c’est la traçabilité bidirectionnelle : un lien documenté de chaque exigence de cybersécurité vers le test qui la vérifie, et de chaque test vers une exigence.

Pour les tests de sécurité, cela signifie qu’un évaluateur peut partir d’un objectif de cybersécurité (« l’ECU ne doit pas accepter d’écritures diagnostiques sans authentification »), le suivre jusqu’à une exigence de cybersécurité, suivre celle-ci jusqu’au test qui la contrôle, et voir le résultat, sa date, et ce qu’il est advenu de chaque constat. Et il peut faire le chemin inverse : prendre un constat et le remonter jusqu’à l’exigence qu’il menace.

La plupart des équipes savent produire les tests. Bien moins nombreuses sont celles qui savent produire cette chaîne le jour de l’évaluation.

Là où le fuzzing devient spécifiquement difficile

Le fuzzing est particulièrement délicat à rendre traçable, pour trois raisons :

• Il est non déterministe par nature. Si un crash ne peut pas être reproduit, c’est une anecdote, pas une preuve. Un évaluateur ne peut pas accepter « ça a planté une fois en mars ».
• Il produit du volume, pas de la structure. Des millions d’itérations et une pile de journaux ne se rattachent pas proprement à une courte liste d’exigences de cybersécurité.
• Il est exécuté tard et rarement. Une campagne ponctuelle avant un audit vous renseigne sur le logiciel que vous aviez cette semaine-là, pas sur celui que vous livrez, et elle ne porte aucun historique.

Ainsi, la vraie question que pose un évaluateur à propos de votre fuzzing n’est pas « avez-vous fait du fuzzing ? » C’est : pouvez-vous reproduire ce constat, quand l’avez-vous vu pour la première fois, à quelle exigence se rattache-t-il, et qu’avez-vous fait à son sujet ?

À quoi ressemble une preuve de test de sécurité prête pour l’audit

Quel que soit l’outil utilisé, la preuve doit porter cinq choses :

1. La reproductibilité. Une graine ou une configuration stockée pour que tout constat puisse être rejoué à la demande, par vous et par l’évaluateur.
2. Un historique daté. Pas un instantané, mais un relevé de ce qui a été testé et quand, sur toute la vie de l’ECU, afin de montrer la tendance et pas seulement l’état final.
3. Un rattachement aux exigences. Chaque constat lié à l’exigence de cybersécurité ou au ticket qu’il affecte, pour que la trace bidirectionnelle tienne.
4. Une acceptation du risque documentée. Quand un risque résiduel est accepté, la décision et sa justification sont consignées et subsistent jusqu’au cycle de test suivant.
5. Un export lisible. La preuve doit sortir de l’outil sous une forme que l’évaluateur et votre propre suivi peuvent exploiter, du PDF pour le dossier et du SARIF pour l’outillage.

Réussissez ces cinq points et une campagne de fuzzing cesse d’être un fichier journal pour devenir un produit de travail.

Comment AutoST est conçu pour cela

C’est la partie d’un programme 21434 qu’AutoST est conçu pour porter.

Chaque exécution est reproductible : la graine de fuzzing est stockée et affichée, de sorte qu’un crash peut être rejoué à l’identique. Chaque analyse est datée et conservée, pour que l’historique sur la vie d’un ECU soit disponible, et non reconstitué. Chaque constat porte une sévérité et un correctif concret, et le Fix Plan attribue à chaque tâche un statut et un champ de référence ALM/PLM, là où vit le lien de retour vers votre exigence ou votre ticket. L’acceptation du risque et les commentaires se reportent d’un re-test à l’autre, de sorte qu’un risque résiduel accepté reste documenté et qu’un problème corrigé apparaît comme résolu. Et la sortie est en PDF pour le dossier d’audit et en SARIF pour votre outillage.

Parce qu’AutoST s’exécute depuis l’API et en CI, les tests deviennent une activité continue au sens où l’entend la Clause 8.5, plutôt qu’une course effrénée avant l’évaluation. L’évaluateur voit une tendance et une trace, pas une unique campagne héroïque.

La limite honnête

AutoST produit la preuve de test et la maintient traçable. Il n’écrit pas votre TARA, ne pilote pas votre système de management de la cybersécurité et ne rédige pas votre dossier de cybersécurité. Ce sont des travaux de processus et de jugement d’ingénierie. Zyberum assure aussi ce volet, en conseil, avec une équipe qui détient la certification SAE et TÜV SÜD Automotive Cybersecurity pour l’ISO/SAE 21434 et qui a mené des programmes Tier 1, Tier 2 et OEM exactement à travers cela. Les références sont disponibles sur demande.

Si vous voulez voir à quoi ressemble une preuve de test prête pour l’audit sur votre propre ECU, réservez une démo et nous l’exécuterons contre une cible réelle.