La Sûreté d’un Produit: définition, explication et exemple, avec des méthodes Expert. Correspondant à la notion «Security» en Anglais, il s’agit de l’ensemble des dispositions assurant que votre Système reste fonctionnel, ne se dégrade pas ni ne blesse ses utilisateurs à la suite de dysfonctionnements volontaires/malicieux.
Sureté, Sécurité, Fiabilité, Résilience… Ces 4 mots ne désignent en fait pas les mêmes notions. Je traite dans cet article de la notion de Sûreté Système, et j'aborde cela avec les méthodes Expert de l'état de l'art.
Je vous conseille la lecture préalable des Méthodes Simples pour vous familiariser avec la problématique.
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…)
Pour davantage de détails sur les objectifs et des exemples, voir l’article sur les Méthodes Simples.
Il s’agit d’utiliser un mélange d’outils technologiques, de principes de management, et de principes de conception.
Par exemple :
Listons ici les méthodes complémentaires aux méthodes Simples. Dans cet article, nous nous intéressons aux méthodes Expert. C’est-à-dire les méthodes avancées qui demandent déjà une base de pratique.
Les exigences initiales de FMDS (RAMS en Anglais), dont je considère la Sûreté comme partie intégrante, sont des exigences de Besoin. Elles sont donc exprimées par le Client, seul ou accompagné par l'industriel (vous). On peut aussi parler d'Objectifs FMDS.
Ce travail de collaboration est très important car d'une part le Client sait mieux que vous ce dont il a besoin, et d'autre part il ne sait peut-être pas l'exprimer sous forme d'exigences claires et éventuellement chiffrées.
Lors de cette collaboration/négociation, il faut aussi garder en tête que les RAMS doivent être exprimés en fonction des coûts induits dans le Projet. En effet, un effort RAMS est non négligeable dans la mise au monde d'un Produit. Cela vient avec des coûts dédiés et potentiellement élevés. Il faut que tout le monde (client, fournisseur) en ait conscience et adapte le degrés d’effort en fonction du budget autorisé.
Idem que pour la Sécurité : faire une Analyse de Risques (AdR) à chaque « étage » d’exigences lors de la conception du Produit va apporter un supplément de Sûreté qui peut être primordial selon le niveau de criticité de votre produit (Dispositif Médical, Armement, Aéronautique/Spatial).
Pour savoir comment faire une AMDEC de Sûreté, voir l'article sur les méthodes simples de Sûreté.
Si vous estimez qu’une partie de votre logiciel est primordiale pour la Sûreté de votre Produit :
On parlera de partie « Rouge » du logiciel. Le reste est considéré « Vert ».
Exemple : Un logiciel de monitoring qui surveille que le fonctionnement du Produit est OK, et qui prend des mesures (passage en mode dégradé, ou buzz d’alerte) si jamais ce n'est pas le cas. Ce logiciel ne doit pas défaillir car c'est lui qui assure la mise en sécurité s'il y a un problème.
Procéder de même pour l’électronique : redondez davantage les parties Rouges, rendez la carte difficile d’accès physique ou impossible à griller via ondes EM, mettez une équipe expérimentée sur le coup, spécifiez de la manière la plus exhaustive possible etc.
Il est toujours possible de scinder votre produit entre ces éléments« verts » (ceux qui ne sont pas responsables d’une fonction Sûreté) et ces éléments « rouge » (ceux qui n’ont absolument pas droit à un problème).
Cela se fait de manière plutôt conceptuelle pour le logiciel ; mais pour l’électronique cette distinction peut par exemple se matérialiser par :
NOTA : ce concept de zones Rouge et Verte peut tout à fait s'appliquer également à la Sécurité !
Ces personnes ont l’habitude et vont vous aider à rendre votre Système sûr et inviolable en analysant de fond en comble le Produit et proposant des barrières :
Toutes les phases de vie du Produit seront étudiées, en tenant compte du Produit lui-même mais aussi de ce qui l’entoure (Personnes, Sollicitations thermiques, mécaniques, électromagnétiques, chimiques, autres systèmes, …).
Parmi les Méthodes Simples, je parle de maintenir à jour son Système face aux menaces qui elles-mêmes évoluent. Il est fort probable que malgré tous vos efforts pour rendre votre Système sûr, un pépin arrive tout de même.
Il faut donc prévoir un Plan de Continuité de l’Activité (PCA) et un Plan de Reprise de l’Activité (PRA).
Sur internet, plusieurs ressources peuvent vous aider à les construire. Un guide du Gouvernement existe également.
Exemple :
Imaginons que vous proposez à vos clients un robot chirurgien qui, pour fonctionner, a besoin d’infrastructures au sein de l’hôpital: des serveurs (que vous fournissez aussi), qui monitorent le bon fonctionnement du robot et enregistrent les évènements essentiels lors des opérations sur patients. Imaginons que le robot puisse fonctionner en autonome même si ces serveurs sont down.
Que se passe-t-il si vos serveurs dysfonctionnent un jour du fait d’une malveillance et qu’une opération est en cours avec ledit robot ? Comment assurer de terminer l’opération sans dégâts ni blessures ? Comment assurer la remise en route de ces serveurs (pendant ou après l’opération) ?
C’est à ce genre de questions que doivent répondre les PCA et PRA. Le jour où les pépins (volontaires) identifiés se produisent, vous savez comment agir et restaurer la situation à la normale.
Attention, avoir un PCA/PRA ne veut pas dire qu’on peut se passer de la Sûreté de base de notre Système ! La Sûreté réduit considérablement la probabilité d’avoir à se servir des PCA/PRA… Mieux vaut prévenir comme on dit.
Si votre Produit est destiné à être utilisé « longtemps » (c’est à dire pendant une durée supérieure à 2 ans), alors il faut bien garder en tête que les menaces vont évoluer entre la mise sur le marché et la fin d’utilisation de votre produit.
L’architecture complète du Système doit être pensée :
Une bonne pratique est de considérer que toutes les parties de votre système (tous les composants logiciels et/ou cartes électroniques etc.) doivent être des composants totalement indépendants et qu’ils doivent être sûrs à chacune de leurs frontières.
Exemple :
La Sûreté by Design permet, si un composant est attaqué/contrôlé de manière malveillante, de ne pas rendre attaquables plus facilement les autres composants par rebond. Les éléments doivent « ne pas se faire confiance » les uns les autres ; plutôt que de supposer que le danger sera « en dehors du système ».
L’évolutivité assure de rendre modifiables de manière claire et circonscrite les différents composants de son Produit, afin de les changer facilement pour faire face aux évolutions des menaces. Les changements seront plus faciles si ces composants sont bien séparés et indépendants car ils seront modifiables de manière maîtrisée.
Si votre architecture ne présente que des circuits électroniques et composants logiciels qui sont enchevêtrés les uns aux autres sans délimitations claires des fonctions et interfaces, il y a d'une part des chances pour qu’une faille se cache dans ce plat de spaghetti sans même que vous ne vous en rendiez compte, et d'autre part cette architecture sera très complexe à faire évoluer pour contrer les menaces.
Tout ceci doit rentrer dans la réflexion de Sûreté !
Une bonne pratique est d’engager un expert ou au moins une personne dont c’est le rôle à part entière dans la société : son œil extérieur et son expérience transverse sur ces sujets sera toujours d’une grande aide.
La Sécurité et la Sûreté se traitent de manière relativement proche. Lisez les articles sur la Sécurité en mode facile et mode expert pour vous en convaincre et consolider vos connaissances.
Penser long terme (évolutivité du Produit) facilitera grandement l’exploitation et la maintenance du Système... Et impactera positivement vos coûts sur la vie du Produit !
Tous ces travaux de Security By Design et d'Evolutivité ont généralement du sens car l'investissement initial consenti (travailler davantage les exigences, faire des AdR...) est inférieur aux coûts d'exploitation nécessaires ensuite sur la vie du Système si on n'a rien fait pour le rendre Sûr. Il s'agit de dépenser 1€ maintenant pour en économiser 10 plus tard !
Aurélien NARDINI
Un Système Sans Problème est une ressource de connaissances et de savoir-faire pratiques, avec exemples concrets.
Que vous soyez Chef de Programme, Chef de Projet, Architecte Système, Ingénieur, Manager dans l'Industrie, Etudiant ou Curieux de l'Ingénierie, vous êtes au bon endroit.
Au travers d'articles publiés régulièrement, découvrez ou révisez les Processus, Méthodes, Outils et Astuces utiles pour concevoir et piloter dans les domaines du Software, Firmware, de l’Électronique, et de la Mécanique.
Parce-qu'un produit fiable et industrialisable ne s'improvise pas !
