DISCAIMER : cet article ne s'adresse pas uniquement aux organisations qui ont déjà été piratées... La CEI 62443 est une norme générique reconnue comme applicable dans des secteurs critiques tels que la fabrication, l'énergie, le transport, les soins de santé et bien d'autres.

Cet article est le premier épisode d'une série de 8, couvrant les principales pratiques à mettre en œuvre par toute organisation visant à respecter l'état de l'art en matière de cybersécurité pour les systèmes de contrôle industriels et d'automatisation. Basé sur une approche pragmatique de la partie de la norme CEI 62443-4-1 définissant les exigences liées à un cycle de développement sécurisé, cet article vous donne des conseils sur la façon de traiter ces activités dans les processus de votre organisation actuelle.

Pour développer systématiquement des produits sûrs, il faut mettre l'accent sur la sécurité tout au long du cycle de vie des logiciels, de sorte que les résultats soient sûrs dès la conception. Ainsi, chaque phase d'un cycle de vie logiciel commun doit être renforcée par des pratiques de sécurité. Cela conduit à un cycle de développement sécurisé, comme illustré ci-dessous. Dans ce premier épisode, nous nous concentrerons sur la pratique requise pour définir une cible de sécurité : L'analyse de la menace

 

La pratique de l'analyse des menaces consiste en un processus à mettre en œuvre par l'organisation pour répondre aux exigences suivantes extraites de la norme IEC 62443-4-1 :

  • Un modèle de menace comprenant les éléments architecturaux du système, les actifs, le contexte de sécurité, les vecteurs d'attaque et les limites de confiance doit être spécifié.
  • Les menaces sont identifiées, y compris l'évaluation de leur risque non atténué et résiduel.
  • Les contre-mesures qui contribuent aux exigences des composants (CRs) et à leurs améliorations (CR-REs) doivent être définies .
  • La traçabilité des produits de travail, des menaces aux exigences en matière de contre-mesures et aux cas d'essai, doit être assurée.

Certaines exigences supplémentaires peuvent être formalisées afin de garantir une approche efficace de l'analyse des menaces :

  • Le processus d'analyse des menaces doit être intégré au processus de développement existant (ex. modèle en V ou autres) et à l'approche agile.
  • L'effort d'analyse des menaces pendant le développement du produit doit être aussi faible que possible (raisonnable et gérable).
  • Le processus d'analyse des menaces doit être accepté par toutes les parties prenantes.
  • Les parties prenantes doivent être soutenues par des outils logiciels pour garantir une approche cohérente et éviter les erreurs.

Les résultats de cette analyse permettent de créer une conception sécurisée qui cible spécifiquement les menaces identifiées avec des contre-mesures appropriées au niveau architectural. Ce dernier sujet fera l'objet du prochain épisode (Ep.2). Vous trouverez ci-dessous une description de l'approche en 5 étapes :

 

Étape 1 - Spécification du contexte

Grâce à cette première étape, l'architecture du système et son contexte de sécurité sont spécifiés dans un modèle de menace. L'architecture du système est spécifiée sous la forme d'un diagramme de flux de données qui contient les composants interagissant avec l'environnement du système, leurs actifs, leur chemin d'interaction et les technologies de communication utilisées. En outre, les limites de confiance sont spécifiées pour identifier les différentes zones de confiance. Pour construire ce modèle de menace, plusieurs outils peuvent soutenir la gestion des informations de manière structurée. Par exemple, Microsoft fournit un outil de modélisation des menaces (MS-TMT) qui est disponible gratuitement. Il soutient l'analyse des menaces en fournissant des modèles de modèles de menaces qui définissent des types d'éléments de modèles utilisables.

 

Étape 2 - Identification et évaluation des menaces

Dans cette deuxième étape, les menaces pour le système spécifié à l'étape 1 doivent être identifiées et analysées sur la base d'une méthodologie prédéfinie qui peut être différente selon le contexte du système et les secteurs d'application. La méthodologie STRIDE est un exemple parmi d'autres. Elle définit une approche permettant l'identification des menaces liées aux aspects suivants : Spoofing, Tampering, Repudiation, Divulgation d'information, Denial-of-service et Elevation de privilèges. Des outils peuvent soutenir vos processus en automatisant la génération de menaces sur la base de la définition du système.

Pour l'évaluation des risques, les organisations déterminent la gravité des menaces sur la base de niveaux normalisés ou auto-définis. En outre, elles déterminent la probabilité de la menace en combinant quatre mesures supplémentaires dérivées de la définition du niveau de sécurité de la norme CEI 62443 et, par exemple, du système bien connu de notation des vulnérabilités communes (CVSS - https://www.first.org/cvss/calculator/3.0). Il s'agit des compétences requises, des ressources requises, des privilèges requis et du vecteur d'attaque. Le résultat de l'étape 2 est une liste de menaces avec leur risque non atténué, comme l'exige la norme CEI 62443.

 

Étape 3 - Définition des contre-mesures et des exigences de sécurité

Dans la troisième étape, les contre-mesures qui atténuent les menaces identifiées à l'étape 2 sont définies. Pour la traçabilité, chaque exigence de contre-mesure est liée aux menaces qu'elle atténue et aux CRs/CR-REs de la CEI 62443 auxquels elle contribue.

 

Étape 4 - Évaluation des risques résiduels

La quatrième étape consiste à déterminer le risque résiduel (après la mise en œuvre des contre-mesures) de chaque menace. Ce risque est évalué en utilisant la même approche d'évaluation que pour le risque non atténué de l'étape 2. Si le risque résiduel est considéré comme inacceptable, des contre-mesures supplémentaires doivent être définies en revenant à l'étape 3. Après l'étape 4, les résultats sont une liste de menaces avec un risque non atténué et résiduel et une liste de contre-mesures atténuant ces menaces et contribuant aux CRs/CR-REs de la norme.

 

Étape 5 - Spécification et mise en œuvre des contre-mesures

Enfin, cette cinquième étape consiste à concevoir et à mettre en œuvre des contre-mesures en accord avec le processus de développement existant.

Après l'étape 5, chaque fois que le système est modifié de telle sorte que le modèle de menace n'est plus en phase avec l'état de développement (par exemple, au début d'un nouveau sprint), le processus d'analyse des menaces doit être répété à partir de l'étape 1. Le modèle de menace est mis à jour pour refléter les modifications du système, les menaces nouvellement introduites sont analysées, les exigences en matière de contre-mesures sont révisées/ajoutées et les risques sont mis à jour.

 

Même si la conformité à la norme 62443 n'est pas un objectif, l'analyse des menaces doit être considérée comme l'une des principales bonnes pratiques à mettre en place et à appliquer par les organisations qui gèrent plusieurs types d'actifs. Elle facilite la compréhension des aspects liés à la cybersécurité par toutes les parties prenantes et minimise les cyberrisques en garantissant une approche pragmatique permettant d'identifier ces risques à un stade précoce du concept.

Si vous avez des questions sur les approches d'analyse des menaces et/ou les critères de certification, n'hésitez pas à contacter notre spécialiste de la cybersécurité : Kilian Marty