Introduction
Comment anticiper et réduire les risques de sécurité ? Afin de respecter les normes du secteur, comme ISO®/SAE® 21434 et DO-356, il est nécessaire de répondre à cette question avant de commercialiser de nouveaux produits. Cela peut s’avérer difficile si vous ne disposez pas d’un processus unifié pour la documentation, le suivi, l’implémentation et la vérification des modifications. Selon votre secteur d’activité, ce processus est connu sous le nom de TARA (threat analysis and risk assessment ou analyse des menaces et évaluation des risques), SRA (security risk assessment ou évaluation des risques de sécurité) ou sous d’autres termes. En utilisant un framework basé sur la modélisation pour votre SRA (Figure 1), vous pouvez intégrer l’aspect de sécurité à votre design grâce à une procédure détaillée. Par ailleurs, avec les nombreuses fonctionnalités de MATLAB®, vous pouvez également personnaliser, prolonger ou automatiser cette procédure selon vos besoins.
Figure 1. Framework d’analyse de sécurité basée sur la modélisation.
Contexte : robot d’entrepôt
Dans ce livre blanc, nous vous présentons un exemple de robot d’entrepôt avec un opérateur à distance, une architecture logicielle, un modèle de système physique ainsi qu’un modèle de caméra (Figure 3). Consultez la Figure 4 pour obtenir une vue détaillée de l’architecture logicielle, qui contient un scheduler de planification, des modules de planification, de contrôle et d’estimation de position.
L’analyse de la sécurité basée sur la modélisation s’articule autour des étapes suivantes (illustrées dans la Figure 2) :
- Identification des actifs et des menaces
- Calcul du risque de sécurité
- Définition, implémentation et vérification des contre-mesures
Figure 2. Étapes de l’analyse de sécurité basée sur la modélisation.
Figure 3. Modèle d’architecture de robot d’entrepôt.
Figure 4. Architecture logicielle du robot d’entrepôt.
Identifier les actifs et les menaces
Lorsque vous souhaitez identifier les actifs et les menaces, déterminez ce qui a besoin d’être protégé. Idéalement, tout ce qui apporte de la valeur à votre système devrait l’être. Toutefois, pour des raisons de complexité et de coûts, il faut parfois choisir de protéger uniquement ce qui est nécessaire (par exemple, les fonctionnalités liées à la sécurité). On désigne ces fonctionnalités par le terme « actifs ». Chaque actif contient une ou plusieurs propriétés à protéger. En voici quelques exemples :
- Disponibilité
- Intégrité
- Authenticité
- Confidentialité
- Non-répudiation
- Autorisation
Identification d’actifs : que souhaitez-vous protéger ?
Il existe plusieurs méthodes permettant d’identifier des actifs, comme l’évaluation de leur exposition auprès d’un utilisateur, l’analyse de leurs flux de données, la révision d’une nomenclature logicielle (SBOM) ou encore l’évaluation de leur rôle dans les mesures de sécurité. Par principe, tous les composants qui utilisent des entrées externes doivent être pris en compte.
Certains composants de l’architecture logicielle des robots s’appuient sur un signal (robotPosition) provenant des caméras installées au plafond de l’entrepôt (le modèle de simulation) :
- Scheduler de planification
- Estimateur de position
Dans le cadre de cet exemple, on s’intéressera à la protection de la disponibilité, de l’intégrité et de l’authenticité du signal par rapport aux actifs. Il convient de noter que d’autres propriétés des actifs doivent être protégées. L’analyse doit être appliquée à l’ensemble des actifs du système.
Les feuilles de calcul de Safety Analysis Manager dans Simulink Fault Analyzer™ permettent d’assurer la traçabilité du processus d’analyse. Nous utilisons les stéréotypes dans System Composer™ afin d’ajouter les actifs à la feuille de calcul. Lorsque vous ajoutez le stéréotype « actif » à ces sous-systèmes, ils seront automatiquement ajoutés à la feuille de calcul. La feuille de calcul permet de suivre le type d’actif, les propriétés protégées ainsi que toute autre information dont vous souhaitez garder une trace (Figure 5). Avec Requirements Toolbox™, vous pouvez également associer des actifs aux menaces identifiées. Cela vous permet de créer un fil rouge numérique pour le reste de l’analyse. Cela vous aide à :
- Respecter les exigences de traçabilité requises par les normes de l’industrie.
- Effectuer une analyse de l’impact des modifications.
Figure 5. Exemple de feuille de calcul répertoriant les actifs.
Identification des menaces : que pourrait-il arriver ?
Les actifs à protéger étant identifiées, la prochaine étape consiste à détecter les menaces qui pèsent sur eux. Pour ce faire, l’un des outils courants est le framework de modélisation STRIDE. Les propriétés souhaitées des actifs sont directement mises en correspondance avec les menaces qui les concernent, comme l’illustre le Tableau 1.
| Menace | Propriété souhaitée | Définition de la menace |
| Usurpation d’identité | Authenticité | Se faire passer pour une autre entité ou personne que soi-même |
| Falsification | Intégrité | Modifier un élément sur le disque, le réseau, la mémoire ou ailleurs |
| Répudiation | Non-répudiabilité | Affirmer ne pas avoir fait quelque chose ou ne pas être responsable (de bonne foi ou non) |
| Divulgation d’informations | Confidentialité | Obtenir des informations pour lesquelles les autorisations d’accès n’ont pas été obtenues |
| Déni de service | Disponibilité | Épuiser les ressources nécessaires pour la fourniture du service |
| Élévation des privilèges | Autorisation | Autoriser une personne à faire quelque chose qu’elle ne devrait pas être autorisée à faire |
Que vous employiez la méthode STRIDE ou une autre méthode, vous pouvez rédiger une fonction MATLAB pour suggérer automatiquement des menaces à partir des propriétés préalablement identifiées qui pèsent sur l’actif. Par exemple, le déni de service est la menace qui correspond à la disponibilité. Cette terminologie étant large, vous devrez probablement être plus précis pour déterminer le risque posé et la contre-mesure. Vous pouvez utiliser des catalogues comme CAPEC™1, ATT&CK®2 et EMB3D™3 afin d’obtenir des informations plus précises sur la manière dont la menace se présente. Dans ce cas précis, il peut s’agir de bloquer le signal entre la caméra et l’estimateur de position.
Une fois la menace précise identifiée, l’entrée CAPEC (par exemple, CAPEC-601) peut être ajoutée à la feuille de calcul des menaces. Celle-ci, comme la feuille des actifs, favorise la traçabilité et l’analyse de l’impact grâce aux liens vers le reste de l’analyse.
Calcul du risque de sécurité
Pour calculer le risque d’une menace en particulier, il faut prendre en compte deux facteurs. Le premier est la faisabilité, c’est-à-dire la facilité avec laquelle l’attaque peut être mise en œuvre. Le second est l’impact, c’est-à-dire la gravité des conséquences.
Faisabilité : dans quelle mesure la tâche est-elle difficile ?
La méthodologie de potentiel d’attaque de la norme ISO 180415 propose un framework systématique afin d’estimer la faisabilité d’une attaque. Cette estimation est basée sur l’ensemble de facteurs obligatoires suivant :
- Expertise : de quelles compétences l’acteur malveillant dispose-t-il ?
- Connaissances : quelles connaissances internes est-il nécessaire d’avoir ?
- Équipement : quels outils ou hardware sont nécessaires pour mettre en œuvre l’attaque ?
- Temps écoulé : combien de temps faut-il pour identifier une vulnérabilité et développer un exploit (programme permettant d’exploiter une vulnérabilité) ?
- Créneau : où et quand l’attaque peut-elle être menée ?
La feuille de calcul des menaces (Figure 6) dispose d’une colonne pour chacun des facteurs à prendre en compte. MATLAB propose en outre une formule personnalisable pour calculer automatiquement la faisabilité. Comme indiqué ci-dessus, on utilise la méthodologie de potentiel d’attaque. Elle fait la somme des valeurs énumérées normalisées pour chaque facteur.
Figure 6. Feuille de calcul des menaces, avec les facteurs et la faisabilité mis en évidence.
Impact : les conséquences sont-elles graves ?
Chaque menace peut avoir un impact ou une conséquence. Dans notre exemple, l’impact se traduit par des effets sur la sécurité. On utilise donc directement l’évaluation de l’impact à partir d’une analyse de la sécurité (ou évaluation des dangers) existante. Notez que la situation décrite ici est simplifiée. En situation réelle, il faut également prendre en compte les aspects opérationnels, financiers et de confidentialité.
Dans l’évaluation des dangers (Figure 7), la gravité d’un dysfonctionnement du capteur de position peut aller de S3 à S5. À des fins de simplification, on considérera la valeur la plus élevée comme l’impact d’une menace de déni de service (DoS).
Figure 7. Évaluation des dangers d’un robot.
Calcul et traitement du risque
Une fois que la faisabilité et l’impact ont été évalués, le risque peut être calculé automatiquement à l’aide d’une autre formule MATLAB. Dans cet exemple, on calcule le risque en multipliant la faisabilité par l’impact.
Selon votre tolérance au risque, vous pouvez déterminer comment appliquer des traitements du risque. Le traitement du risque est présenté dans la feuille de calcul (Figure 8) en indiquant l’une des caractéristiques suivantes :
- Éviter : le risque doit être totalement évité (par exemple, en supprimant une fonctionnalité).
- Réduire : le risque doit être réduit en implémentant des contre-mesures techniques.
- Partager : le risque est transféré à une assurance, à un utilisateur, à un tiers, etc.
- Conserver : le risque est accepté « tel quel », sans aucune autre mesure.
- Sans objet : la menace n’existe pas dans ce système.
Remarque : les traitements du risque Éviter et Réduire entraînent des exigences techniques.
Figure 8. Traitement du risque dans la feuille de calcul des menaces.
Le calcul des risques et la relation entre les menaces, les actifs et d’autres éléments peuvent être visualisés sous forme de diagramme, ce qui permet de mieux comprendre leur contribution au risque global. Ce diagramme contient des informations sur l’importance de chaque relation ; il peut donc être utilisé pour hiérarchiser les tâches. Comme le montre la Figure 9, les attaques par déni de service constituent une menace plus importante que les attaques par falsification et doivent donc être traitées en priorité. En effet, leur niveau de gravité (S5) est supérieur à celui des attaques par falsification (S4).
Figure 9. Visualisation du risque.
Définition, implémentation et vérification des contre-mesures
Le risque de brouillage du signal (DoS) entre la caméra et l’estimateur de position peut être atténué en réduisant la faisabilité ou à l’aide d’une contre-mesure. Dans ce cas, l’impact a été réduit en ajoutant un frein d’urgence. Cette mesure est traçable jusqu’à la feuille de calcul des menaces grâce à un lien dans la feuille des contre-mesures (Figure 10). Chaque contre-mesure conduit à un objectif de sécurité, qui prend la forme d’au moins une exigence dérivée. Dans ce cas, l’exigence est que le robot s’arrête dans la seconde qui suit la détection du brouillage, ce qui est également lié à la traçabilité et à l’analyse d’impact.
Figure 10. Lien entre les contre-mesures et les menaces.
Vérifications d’exhaustivité et de cohérence
À ce stade, ce livre blanc a identifié les menaces, évalué les risques associés et défini les contre-mesures à mettre en œuvre lorsque ces derniers deviennent trop élevés. L’étape suivante est le développement des contre-mesures. Avant de transmettre les objectifs de sécurité, assurez-vous que le modèle de menace et de risque est valide en vérifiant les éléments suivants :
- Au moins une menace a été identifiée pour chaque actif (notion d’exhaustivité).
- Aucune menace n’est laissée de côté.
- Des contre-mesures ont été mises en place lorsque le risque est trop élevé.
- Des exigences (par exemple, des objectifs de sécurité) ont été créées et associées aux contre-mesures.
- Il n’y a pas de liens rompus entre les menaces, les actifs, les modèles et l’analyse de sécurité.
À l’aide d’un seul appel de fonction, il est possible de valider tous ces éléments et de générer un graphique (Figure 11).
Figure 11. Validation du modèle de menace et de risque.
Implémentation des contre-mesures
Une fois que des contre-mesures ont été définies, le moment est venu de les implémenter dans le modèle. Dans le modèle Simulink® du contrôleur, MATLAB est utilisé pour ajouter un bloc fonctionnel (Figure 12), qui est associé à l’exigence de traçabilité.
Figure 12. Implémentation d’un frein d’urgence avec une exigence associée.
Vérification et validation
Une fois l’implémentation effectuée, l’étape suivante consiste à modéliser l’attaque et à vérifier le bon fonctionnement de la contre-mesure. Cela peut être réalisé à l’aide de Simulink Fault Analyzer, qui sert à modéliser et à simuler l’attaque. La Figure 13 indique les paramètres utilisés lors de la modélisation de l’attaque.
Figure 13. Boîte de dialogue de la défaillance avec le déclenchement mis en évidence.
Après avoir activé la défaillance et exécuté le modèle, il est possible d’examiner de plus près les signaux à l’aide du Simulation Data Inspector (SDI), comme illustré dans la Figure 14. Vous pouvez également visualiser les réponses à l’attaque à l’aide de Navigation Toolbox™, comme illustré dans la Figure 15. Ces outils vous permettent de vérifier visuellement que la contre-mesure fonctionne comme prévu, et ce workflow peut être mis à l’échelle à l’aide du framework Simulink Test Manager afin de d’assurer que toutes les fonctionnalités sont correctement vérifiées.
Figure 14. Simulink Data Inspector montrant où une attaque est injectée.
Figure 15. Visualisation d’une attaque avec (à gauche) et sans (à droite) contre-mesures.
Conclusion
Un framework d’analyse de sécurité basée sur la modélisation propose un workflow avec traçabilité intégrée, une personnalisation pour répondre à vos normes de conformité, ainsi que la possibilité d’automatiser, garantissant ainsi la cohérence entre le design et l’analyse. Vous pouvez accélérer la vérification et la validation en les intégrant plus tôt dans le processus de design grâce à ce workflow rationalisé, ce qui permet de réduire à la fois le temps et les coûts de développement. De la mise en évidence des menaces potentielles à la quantification et à l’évaluation des risques, en passant par la définition et la simulation de l’efficacité de vos contre-mesures, cette approche de bout en bout garantit la couverture de votre processus de sécurité.
Références
The MITRE Corporation. « CAPEC - Common Attack Pattern Enumeration and Classification (CAPEC™). » Consulté le 18 mars 2025.
The MITRE Corporation. « MITRE ATT&CK®. » Consulté le 18 mars 2025.
The MITRE Corporation. « MITRE EMB3D™. » Consulté le 18 mars 2025.
