Sûreté Fonctionnelle d’un Produit : Méthodes Simples

Sureté, Sécurité, Fiabilité, Résilience… Ces 4 mots ne désignent en fait pas les mêmes notions. Et la différence est importante lors de la conception de votre produit car les objectifs et méthodes sont différents. Je traite dans cet article de la notion de Sûreté Système, et j'aborde cela avec les méthodes simples de l'état de l'art.

Attention aux faux-amis : en Anglais la notion de Sûreté se traduit… Security ! Et celle de Sécurité se traduit Safety.

‍Définition et objectif

La Sûreté est la lutte contre les dysfonctionnements ou mauvaises utilisations volontaires d’un Système.

Le but est d’analyser les menaces externes (mais aussi internes) de votre Système, ses faiblesses, et de mitiger le Risque de défaillances induites. Et ce pendant toutes les phases de vie de votre Produit (conception, opérations, maintenance, démantèlement…)

NOTA : Certains ouvrages invitent également à considérer les menaces « involontaires » dans le périmètre des études de Sûreté. C’est-à-dire celles qui proviennent d’une mauvaise utilisation ou d’un détournement involontaire du Système. Pour ma part, je préfère parler de Sécurité Fonctionnelle dans ce cas, et j’ai traité de la Sécurité dans cet article puis celui-ci.  

Les dysfonctionnements/contournements volontaires peuvent être relatifs :

• au fonctionnement du système lui même
• mais aussi aux informations qu’ils contient
• aux moyens autours de votre système (moyens de prod, de support...)
• aux propriétés intellectuelles
• au respect des lois/normes/standards
  

Exemple avec un robot de chirurgie :

• ‍‍Un pirate arrive à modifier le logiciel dirigeant la procédure de découpe d’un organe
• Un petit malin met hors de fonctions la machine en branchant son alimentation « à l’envers » (le + sur le –, et le – sur le +…)
• Un exploitant soucieux de faire des économies utilise une machine destinée aux opérations du genou pour mener des opérations sur l’épaule
• Un utilisateur malveillant arrive à s’octroyer les droits nécessaires pour pénétrer au sein de la mémoire du robot et s’emparer des logs des récentes opérations, contenant les détails de ces dernières procédures avec le nom des personnes opérées.
• La machine destinée à installer en usine le logiciel sur le robot est un ordinateur lambda non protégé sur lequel n’importe qui peut venir modifier ledit logiciel
• Les machines en charge de la calibration en usine des mouvements du bras outillé du robot sont volontairement déréglées afin de détériorer la précision des mouvements du bras
• La mécanique astucieuse dont le constructeur est particulièrement fier et qui permet au bras robot de se mouvoir est visible depuis l’extérieur du robot et permet à tous de voir comment cela fonctionne et de faire de la rétro-ingénierie
  

Comment assurer la Sûreté de son produit ?

Il s’agit d’utiliser un mélange d’outils technologiques, de principes de management, et de principes de conception.

Par exemple :

• Mise en place d’un VPN pour les connexions du produit à Internet
• Mise en place d’une démarche Projet avec revues régulières et d'une démarche d’Ingénierie Systèmes lors du projet de conception
• Construction d’une architecture électronique rendant indépendantes au maximum les différentes fonctions
  

Concrètement comment faire, depuis la conception jusqu’au retrait de service pour assurer cette Sûreté ?

Listons ici les principales méthodes. Dans cet article, nous nous intéressons aux méthodes simples. C’est-à-dire le minimum syndical.

Adopter une démarche d’Ingénierie Systèmes

Je n'insisterai jamais assez là-dessus. Cela permet d’y voir clair sur son produit lorsqu’il est en train d’être conçu (avec différentes représentations de ce dernier), et ainsi d’anticiper et empêcher dès la conception les éventuelles utilisations ou dégradations malicieuses de son Produit.

On parle alors de « Security by design ».

Toutes les phases de vie du Système doivent être considérées, notamment la phase de Production Série ou de fin de vie !

Exemple :

• Si vous réalisez un gros effort pour rendre votre Robot absolument non piratable (électronique inviolable, logiciel non récupérable, parefeu réseau en béton avec whitelisting etc.) mais que lors des phases de production le logiciel est flashé sur l’électronique via un PC d’atelier qui n’est absolument pas sécurisé… Vous prenez le risque que le code du Robot soit subtilisé, modifié, pour se voir injecté ensuite (par vous-même !) dans vos robots avant livraison à vos clients…
• Si vous prenez soin de protéger physiquement votre Robot lors de son utilisation par le client (en le mettant en enceintes fermées, avec autorisations d’accès restreintes etc.) et qu’au final vous le balancez dans une décharge lambda à la fin de son utilisation, avec n’importe qui pouvant le récupérer et l’étudier finement en mode rétro-ingénierie… Vous avez du souci à vous faire pour vos prochains produits qui seront tout de suite moins sûrs car développés avec des techniques qui auront été disséquées !

Si la Sûreté est cruciale pour votre Produit, l’Architecture Système est incontournable. C’est vraiment la base. Jamais Amazon ne concevrait de serveurs sans s’assurer qu’ils soient un minimum non piratables.

Pendant la conception, vous y verrez plus clair sur comment votre Système sera en le représentant sous différentes formes. Vous pouvez vous créer des représentations d’Archi Système orientées Sûreté. C’est très utile.

Trouver et exploiter les textes pertinents

Il faut rechercher les textes qui sont pertinents pour votre Produit et qui offrent des guidelines pour assurer sa sûreté.

Exemple :

• ‍‍ISO 14971 (qu’on retrouve comme norme harmonisée pour application du MDR – Medical Device Regulation)
• D’autres exemples se trouvent dans l’article sur la Sécurité. En effet, la plupart de ces normes ne font la pas distinction entre Sécurité et Sûreté. Elles donnent la conduite à tenir pour l’identification et le traitement des Risques, peu importe que ces Risques soient d’origine involontaires ou volontaires.

Vous aurez dans ces textes des conseils, choses à ne pas faire, méthodes de validation etc. à suivre afin que votre Système soit considéré un minimum sûr lorsqu’il sera livré à vos clients.

Analyses de Risques via AMDEC (FMECA) très tôt dans la spécification du Produit

Il va s’agir ici de mener une analyse de risque (AdR) avec l’outil AMDEC. Cette analyse sera basée cette fois-ci sur un listing de menaces et de faiblesses à construire.

Pour en savoir plus sur l'outil AMDEC : voir l'article sur les méthodes simples de Sécurité.

Vous en déduirez alors les barrières à mettre en place au sein de votre Système pour l’immuniser aux dysfonctionnements et contournements volontaires et le rendre ainsi plus sûr.

Exemples de barrières usuelles :‍

• Prévention : contrôle d’accès, séparations physiques ou informatiques des bases de données...
• Détection : monitoring, logs...
• Réponse : switch vers modes dégradés de fonctionnement si besoin…

Rechercher les menaces

Pour rechercher les menaces qui vont alimenter votre Analyse de Risques, il faut considérer les points suivants.

Elles peuvent venir de partout : depuis l'environnement du Système

Exemple : Une personne rend inopérant votre machine via une attaque électromagnétique (méthode utilisée de manière très répandue pour faire tomber les drones en plein vol).

Elles peuvent être provoquées par l’homme directement...

Exemple :

• Coupure de courant
• Attaque cyber par une personne qui tente de prendre le contrôle in situ ou à distance du fonctionnement du Produit
• Introduction d’une poudre métallique dans le lubrifiant de votre machine (la CIA connaît bien).
  

...Ou même indirectement

Exemple: Attaque informatique par une multitude de bots, contrôlés par un bot de commande, lui-même contrôlé par une personne.

Depuis l'intérieur également !

Une malveillance volontaire depuis l’intérieur dites-vous ? Cela dépend en effet de votre Système. Si un hacker pénètre au sein de votre machine et passe les barrières unes à unes…

Exemple :

• Votre Système est un robot de chirurgie et un hacker y pénètre depuis internet pour accéder à une base de données X. Il tente d’accéder via X à une autre base de données Y. Pour la base de données Y, l’attaque vient bien de l’intérieur du Système.
• Votre Système est une machine-outil géante qui fait de l’impression 3D pour des moteurs de fusée. Un concurrent de votre entreprise pénètre physiquement dans la machine via une trappe de maintenance et débranche la connectique X et Y avant de s’en aller.

‍

En ayant ces éléments en tête, listez les menaces qui pèsent sur votre Système.

Faire un schéma de votre Système complet sera très utile pour vous aider.‍

Rechercher les faiblesses

Mappez, comme pour la recherche de menaces, votre système sous la forme de plusieurs schémas.

Analysez ces schémas pour voir où sont les points faibles de votre Produit.

Exemple :

• Vous voyez sur votre schéma que le Produit possède plusieurs portes « logicielles » vers le monde extérieur (connexion internet via 4G et/ou Wi-fi, connexion à d’autres appareils via Bluetooth…). Prenez alors grand soin de vous interroger sur comment empêcher n’importe qui d’exploiter ces entrées dans votre Système.
• Vous vous rendez compte que plusieurs de vos connectiques vers l’extérieur ne sont pas protégées contre l’inversion de polarité électrique. Rajouter les composants de protection qui vont bien ne sera certainement pas du luxe…

Décliner les exigences de sûreté comme les autres, ou presque

Comme signifié dans l'un de mes précédents articles sur la Sécurité Système, taguez vos exigences de Sûreté comme tel.

Une mention [SURETE] dans l’intitulé de l’exigence peut suffire.

Ainsi, la personne en bout de chaîne de cette spécification (électronicien, développeur, etc.) mettra soigneusement en œuvre dans son travail ces exigences car il verra qu’elles sont importantes puisque de Sûreté.

Ne pas oublier un plan de test pour ces exigences évidemment, comme le veut la démarche d’ingénierie système.

Maintenir le Système au top...

Une fois le Produit dans la nature, livré chez votre client, il faut s’assurer qu’il soit à jour de l’état de l’art de la Sûreté à mesure que les technologies évoluent et que de nouvelles menaces apparaissent.

Tenez-vous à jour des menaces. Le site CERT-FR recense et affiche les vulnérabilités découvertes de par le monde sur les logiciels courants (ou moins courants).

Ensuite, adaptez votre Système en conséquence. Par des mises à jours logicielles distantes par exemple.

Exemple : Relativement récemment, la faille de sécurité Log4j a fait grand bruit.

Enfin, pour maintenir un certain niveau de Qualité et ne pas faire régresser votre Produit en voulant améliorer sa Sûreté, gardez en tête que tout ceci doit se faire dans les règles de l’art du Change Control.

Cas des COTS

Component Off The Shelf : les composants, sous-systèmes, systèmes complets que vous achetez pour l’intégrer à votre Produit.

Exemple :

• Vous achetez un hub USB que vous insérez dans votre Système pour démultiplier un signal USB
• Vous achetez un module d’émission radio pour votre Produit, avec chiffrement intégré des données émises

Assurez-vous que ce que vous achetez répond bien au standard de Sureté que vous voulez pour votre produit.

Si les parties que vous concevez et produisez sont au top de la Sûreté mais que vous y ajoutez un COTS bancal, tout la Sûreté va potentiellement s’effondrer…

Exemple : Votre module d’émission radio assure bien un chiffrement des données… Mais ce chiffrement est trop facile à casser.

Demandez des garanties à votre fournisseur : documentations de conception (s’il est enclin à vous les communiquer), certifications indépendantes etc.

Vérification des exigences de Sûreté

Comme pour toutes exigences, les vérifications se planifient à l’avance, s’effectuent et se documentent.

En effet, elles constituent la preuve que votre Système respecte ses exigences et permettent d’identifier tout de suite les manques de conception. Pour en savoir plus, je vous invite à lire ma série d’articles sur l’Ingénierie Système hybride via cycle en V modernisé (avec Agile et Design Thinking).

Les méthodes de vérification (inspection, analyse, test, …) sont listées dans le 1er article que j’ai écrit sur la Sécurité.

Quelques mots pour terminer

De la même manière que pour la Sécurité, rendre son Produit plus Sûr n’est pas magique. Il s’agit d’appliquer des méthodes rigoureuses et systématiques, et de s’y tenir d’un bout à l’autre de la conception.

La notion de Sûreté doit faire partie intégrante d’une démarche d’Ingénierie Système pour être maîtrisée et efficace. Selon moi, on devrait ajouter le S de Sûreté à FMDS (ou RAMS) pour ne plus oublier de la traiter. On parlerait alors de FMDSS (ou RAMSS).

Souvenez-vous que corriger les vulnérabilités de son Système tard dans la conception revient très cher. C’est pourquoi il faut s’en inquiéter dès le début.

Enfin, retenez que la Sûreté n’est pas que l’affaire de Cybersécurité. Un Système absolument non connecté à Internet, sans aucun port Ethernet voire sans aucune électronique peut toujours être utilisé de manière malveillante et détourné de sa fonction à des fins malicieuses.

Aurélien NARDINI