Bonne analogie nécessaire: problèmes de sécurité dus à différents codeurs mettant en œuvre les mêmes fonctionnalités de différentes manières pour la même application
Je dois faire une présentation de l'école sur vulnérabilités trouvées dans la plate-forme Moodle . Bien sûr, ils ne s'appliquent qu'à une version héritée qui a depuis été corrigée.
Le hic, c'est que la présentation doit être destinée à un public sans connaissances techniques. Je ne suis donc pas autorisé à expliquer quoi que ce soit en utilisant le code, mais je dois donner une explication qui aide le public à comprendre le problème même s'il n'a aucune compréhension technique.
Les problèmes de Moodle provenaient de différents contributeurs mettant en œuvre la même fonctionnalité de différentes manières, ce qui a créé des failles de sécurité. L'une des vulnérabilités n'aurait pas suffi à elle seule à causer des dommages considérables au système, mais combiner des exploits de fausses hypothèses, une injection d'objet, une double injection SQL et un tableau de bord d'administrateur RCE permissif est devenu possible.
J'ai pensé à l'expliquer avec une maison qui était à l'origine construite en toute sécurité, mais qui est devenue précaire à cause de certaines choses supplémentaires construites dessus, mais je cherche quelque chose d'un peu plus spécifique ou peut-être un scénario historique du monde réel qui conviendrait.
J'ai pensé que vous pourriez peut-être avoir une meilleure idée.
Voici une idée d'analogie qui, je pense, est assez précise tout en étant généralement compréhensible:
Une banque a besoin de deux formes d'identité pour obtenir un prêt: un permis de conduire et un certificat de naissance. Les employés de la banque, Alice et Bob, sont paresseux de différentes manières: Alice tamponne toujours "permis de conduire vérifié" sans vérification, tandis que Bob tamponne toujours "certificat de naissance vérifié" sans vérification.
Individuellement, c'est mauvais mais pas trop mal - toute personne présentant une demande avec des documents falsifiés serait prise par le seul contrôle que l'employé effectue toujours. Mais un jour, Alice est en retard, tamponne le "permis de conduire vérifié" sur un formulaire et laisse Bob terminer. Bob voit le formulaire, suppose qu'Alice a effectivement vérifié la licence et tamponne "certificat de naissance vérifié" sans vérifier comme il le fait toujours. Le prêt est approuvé, sans qu'aucune des pièces d'identité n'ait été vérifiée.
La situation est la suivante: des personnes travaillant de manière indépendante sans coordination, pour concevoir des fonctionnalités censées être utiles localement, mais combinées, ont créé un désastre.
Les premières références historiques qui me viennent à l'esprit:
- le chaos du système ferroviaire britannique où chaque propriétaire de ligne de train exploitait ses propres voies, tailles de voies, trains et horaires (et parfois, leurs propres horloges )
- les premières sociétés de lutte contre l'incendie de New York où ils se sont battus pour les clients (parfois littéralement, avec le feu et les coups de poing)
Les deux font des histoires amusantes et des visuels passionnants.
La solution aux deux était la surveillance centrale et la planification centrale, qui est la même solution aux fiascos Open Source, comme celle que Moodle a connue.
Voici un exemple parfait: la perte de l’orbiteur climatique de Mars. https://www.wired.com/2010/11/1110mars-climate-observer-report/
Citer:
Un comité d'examen de la NASA a découvert que le problème venait du logiciel contrôlant les propulseurs de l'orbiteur. Le logiciel a calculé la force que les propulseurs devaient exercer en livres de force. Un logiciel distinct a pris les données en supposant qu'elles se trouvaient dans l'unité métrique: newtons.
Cela a entraîné un désaccord d'environ 4,5 fois le bon montant. Le satellite est entré dans l'atmosphère beaucoup trop profondément et a brûlé.
Cela fait penser à l'effondrement de la passerelle Hyatt Regency en 1981. TL; DR l'architecte a stipulé une conception, un fabricant sous contrat a substitué leur propre conception, une défaillance mécanique (et la mort) s'ensuit. Il s'agit d'une étude de cas courante pour les étudiants en génie.
Source: https://en.wikipedia.org/wiki/Hyatt_Regency_walkway_collapse#Investigation
MODIFIER pour apporter plus de clarté:
L'ingénieur attitré a attribué le défaut de conception fatal à une panne de communication. Il ... a confié la responsabilité à l'associé en charge de chaque projet.
L'ingénieur attitré a en outre soutenu qu'il était de pratique courante dans l'industrie que l'ingénieur en structures laisse la conception des assemblages acier sur acier au fabricant ...
... les fabricants ... sous-traitent [ed] le travail à un dessinateur extérieur. Ce dessinateur, à son tour, a cru à tort ... les dessins d'atelier avaient déjà été conçus et n'ont donc effectué aucun calcul sur la connexion lui-même.
... l'ingénieur attitré a apposé son sceau sur les documents ... [et] ... a déclaré qu'il n'avait pas personnellement vérifié tous les calculs et s'était appuyé sur le travail de son ingénieur de projet et de son équipe de conception.
Source: https://www.asce.org/question-of-Ethics-articles/jan-2007/
Notez que beaucoup d'informations ont été soustraites pour garder le devis de bloc bref, mais avec l'analyse complète, vous avez vraiment une idée de la tempête parfaite d'hypothèses et de mauvaises communications qui devaient s'aligner pour que la défaillance mécanique soit pleinement réalisée.
Je pense que ce qui décrit le mieux correspond à la sécurité de Swiss Cheese: https://en.wikipedia.org/wiki/Swiss_cheese_model
Le modèle suisse de causalité des accidents illustre que, bien que de nombreuses couches de défense se situent entre les dangers et les accidents, il y a des défauts dans chaque couche qui, s'ils sont alignés, peuvent permettre à l'accident de se produire.
Une chose que vous devez noter dans votre exposé est que les événements catastrophiques ont rarement une cause unique. Au lieu de cela, ils sont le plus souvent une série d'échecs qui se sont réunis pour produire une catastrophe. L'une de ces catastrophes liées aux logiciels a été la échec de Knight Capital Group . Bien que plusieurs points de défaillance aient contribué, la fin du logiciel correspond à ce que vous décrivez (c'est moi qui souligne)
La mise à jour de SMARS était destinée à remplacer l'ancien code inutilisé appelé "Power Peg" - une fonctionnalité que Knight n'avait pas utilisée depuis 8 ans (pourquoi le code mort depuis 8 ans était toujours présent dans la base de code est un mystère, mais ce n'est pas le but). Le code qui a été mis à jour a remplacé un ancien indicateur utilisé pour activer la fonctionnalité Power Peg. Le code a été minutieusement testé et éprouvé pour fonctionner correctement et de manière fiable. . Qu'est ce qui pourrait aller mal?
En raison d'un échec de déploiement (sur la Bourse de New York), l'un des serveurs avait toujours le code d'origine en cours d'exécution. Alors devinez ce qui se passe lorsque vous réutilisez le code qui était initialement destiné à faire autre chose entièrement ...
Il est important de comprendre ce que le code Power Peg "mort" était censé faire. Cette fonctionnalité était censée compter les actions achetées/vendues par rapport à une commande parent lorsque les commandes enfants étaient exécutées. Power Peg demanderait au système d'arrêter le routage des commandes enfants une fois la commande parent exécutée.
Lorsque l'indicateur Power Peg sur le huitième serveur a été activé, la fonctionnalité Power Peg a commencé à acheminer les ordres enfants pour exécution, mais ne suivait pas le nombre de partages par rapport à l'ordre parent - un peu comme une boucle sans fin.
Imaginez ce qui se passerait si vous disposiez d'un système capable d'envoyer des ordres automatisés à grande vitesse sur le marché sans aucun suivi pour voir si suffisamment d'ordres avaient été exécutés. Oui, c'était si mauvais.
Au cours des 45 premières minutes, le marché était ouvert, le code Power Peg a reçu et traité 212 commandes parentales. En conséquence, SMARS a envoyé des millions de commandes d'enfants sur le marché, ce qui a entraîné 4 millions de transactions contre 154 actions pour plus de 397 millions d'actions. Pour vous, les accros du marché boursier, cela signifie que le Knight a pris environ 3,5 milliards de dollars de positions longues nettes sur 80 actions et 3,15 milliards de dollars de positions courtes nettes sur 74 actions. En termes simples, Knight Capital Group a réalisé une perte de 460 millions de dollars en 45 minutes. Rappelez-vous, Knight n'a que 365 millions de dollars en espèces et équivalents. En 45 minutes, Knight est passé du statut de plus grand négociant en actions américaines et de teneur de marché majeur au NYSE et au NASDAQ à la faillite.
Le programmeur A a donc écrit une fonction avec un argument pour "Power Peg", et le programmeur B a supprimé ce code pour que ce même argument représente SMARS. Un seul échec de déploiement et ... un désastre.
Il semble que ce que vous décrivez soit de la "synergie". Trois agents différents qui ont seuls des effets mineurs, mais lorsqu'ils sont combinés sont plus que la somme de leurs parties.
https://en.wikipedia.org/wiki/Synergy
Si vous voulez une analogie, vous pourriez envisager de combiner deux médicaments comme un barbiturique et une benzodiazépine (ou je crois, de l'alcool). C'est probablement la synergie la plus connue que je connaisse.
L'article wikipedia lié contient plusieurs autres exemples qui peuvent s'avérer utiles.
La capture de Château Gaillard
Le château de Gaillard était considéré comme un véritable état de l'art, un château fortifié (c'est littéralement son nom, qui se traduit grosso modo par "château fort"), commandé et conçu à l'origine par le roi Richard d'Angleterre. Un certain nombre de fortifications plus larges au-delà du château ont également été utilisées pour tenter d'empêcher l'armée française de le prendre, que l'armée à son tour a contourné par divers moyens, notamment en remplissant "simplement" un fossé défensif, en faisant un pont de bateaux sur la Seine. (avec des fortifications flottantes pour aider à maintenir la voie d'attaque persistante) et à creuser un tunnel dans le mur extérieur.
Il est tombé cependant, à la fin, après que toutes les autres mesures défensives et murs ont été violés, en raison d'un choix de conception ultérieur, ce qui a entraîné deux méthodes différentes utilisées pour faire des piercings dans le deuxième mur-rideau: en plus du pont rétractable et de la principale porte fortifiée du premier au deuxième bailey, la chapelle nouvellement ajoutée du château avait des fenêtres qui perçaient le mur du bailey à seulement 3 mètres de haut.
Richard Cœur de Lion a été acclamé pour sa compréhension de pointe de l'ingénierie des châteaux. Après sa mort, cependant, son frère John Lackland a fait construire une grande chapelle dans le deuxième bailey du château et a décrété qu'elle devrait avoir des fenêtres orientées au sud. Vraisemblablement en raison de la hauteur du mur-rideau, les fenêtres ont été faites pour percer le mur lui-même pour apporter de la lumière.
Idéalement, ces fenêtres orientées plein sud n'auraient jamais été un problème: elles étaient trop petites pour fournir un moyen adéquat de prendre le château directement avec une force plus importante. Mais après l'extérieur, le premier bailey est tombé dans l'ingénierie (tunnels/exploitation minière), l'armée française a exploité les fenêtres de la chapelle afin d'entrer une petite force dans le deuxième bailey, assez pour prendre les portes de l'intérieur (certaines sources affirment avoir mis le feu à la chapelle pour semer la confusion) et ouvrez-les, laissant ensuite entrer l'armée principale depuis le premier bailey.
Alors que le château était un exploit d'ingénierie défensive avec un mur-rideau extérieur révolutionnaire avec une série d'arcs pour mieux dévier et résister aux projectiles, plusieurs fossés et une conception divisée qui a vu le premier bailey entièrement isolé du deuxième et troisième baileys, le fait que le mur-rideau extérieur du deuxième bailey a été percé les deux pour une entrée (via un pont amovible du premier bailey) et pour la lumière (les fenêtres de la chapelle) est devenu un défaut critique uniquement exploitable en raison de la présence des deux ouvertures, créées à des fins différentes et par différents concepteurs. Le troisième bailey est tombé rapidement en raison d'avoir été construit avec des murs plus minces (probablement comme un coin nécessaire à couper pour respecter le calendrier de construction très accéléré, avec l'hypothèse que les bailes externes ne tomberaient jamais tous les deux).
Plus vous créez de points d'exposition, même ceux qui semblent bénins ou d'un risque contrôlable dans des circonstances normales, plus le potentiel que quelque chose que vous avez fait permet de contourner d'autres mesures de sécurité est élevé. Plus vous créez d'ouvertures grâce à des mesures de sécurité, même des ouvertures qui sont derrière d'autres mesures de sécurité, plus il est probable que quelqu'un contourne simplement votre sécurité sur votre porte principale et trouver une façon différente de procéder. En supposant qu'il est sûr de couper les coins avec la sécurité sur quelque chose derrière d'autres mesures de sécurité, cela signifie que si ces mesures face à l'avant échouent ou sont contournées, les attaquants auront facilement du temps pour atteindre leur objectif final.
La défense en profondeur (souvent appelée stratégie du château) nécessite d'aborder le concept de sécurité du point de vue que toutes les autres mesures au-delà de celle envisagée peuvent être vaincues, plutôt que de compter sur elles pour ne pas échouer et de renforcer cette perspective.
Les châteaux peuvent et sont tombés simplement parce que quelqu'un est devenu paresseux ou a fait une erreur au sujet des mesures de sécurité qui se trouvaient derrière les murs extérieurs et ont involontairement fourni une surface d'attaque secondaire qui était moins sûre que la principale (les portes principales) pour un anneau donné (mur ) de sécurité. Plus il y a de trous dans un mur, plus il est probable que quelqu'un va se tromper sur la façon dont ces trous sont fermés, et plus il est probable qu'il soit négligé. Les gens font des fautes. Plus vous devez rechercher une erreur, plus vous risquez de manquer une erreur. Un attaquant dédié sondera toutes les voies d'attaque mises à leur disposition, même celles que vous ne connaissez pas ou celles que vous n'avez pas conçues comme des vulnérabilités.
Bien qu'il y ait une interprétation de l'histoire complète du siège sur wikipedia, il est inexact (apparemment apocryphe, car c'est une référence commune, bien que certaines sources affirment apparemment il peut avoir été la désinformation délibérée des Français pour éviter d'admettre la profanation d'une chapelle) fait référence à la brèche du deuxième bailey comme étant due à une chute de toilettes. Le actual history est disponible sur Histoire Normandie en français, auquel cette réponse fait maintenant référence.
Voici une analogie simple qui s'applique dans le monde réel et devrait être facile à comprendre pour les étudiants de tout niveau technologique. En prime, il peut également fonctionner pour les collégiens et lycéens.
Il existe deux types de verrous pour vélos:
Cordons/Chaînes
et
U-Locks
Chacun de ces verrous peut être annulé à l'aide d'un simple outil.
- Un cordon ou une chaîne peuvent être coupés avec des coupe-fils robustes.
- Un verrou en U peut être forcé à ouvrir avec un pied de biche.
Cependant, comme les tondeuses et les pinces sont des articles volumineux, les voleurs de vélos n'en transportent généralement qu'un à la fois. Donc, si vous avez un verrou de cordon, vous êtes protégé contre les voleurs avec des pinces et si vous avez un verrou en U, vous êtes protégé contre les voleurs avec une tondeuse.
Mais comment pouvez-vous vous protéger des deux? En verrouillant votre vélo à l'aide d'un cordon ET d'un cadenas en U ! De cette façon, les voleurs doivent porter les deux outils afin de voler votre vélo.
Cependant, cela ne fonctionne pour la sécurité que si le cordon et le verrou en U sont attachés séparément à votre vélo.
Dans le cas de Moodle, le cordon et le verrou en U sont attachés l'un à l'autre (avec une boucle autour du vélo et une boucle autour de l'objet auquel vous l'attachez) , ce qui signifie que le voleur doit seulement pouvoir casser l'un d'eux pour voler votre vélo ! Donc, au lieu de doubler votre sécurité en portant deux serrures différentes, vous avez réduit votre sécurité de moitié, puisque le voleur il suffit de percer l'un d'eux pour accéder à votre vélo.
Vous venez d'acheter une vieille maison. Il a été modifié au fil du temps par de nombreuses personnes différentes.
Vous avez un coffre-fort dans votre sous-sol. Il y a deux portes que vous devez franchir pour vous rendre au sous-sol. Vous vouliez que le coffre-fort soit très sûr, donc lors de l'achat de la maison, vous étiez sûr d'ajouter une autre porte entre celle-ci et le monde extérieur, alors maintenant il y a trois portes! Cela semble assez bon.
Malheureusement, la porte a été fabriquée par une entreprise à petit budget qui ne respectait pas vraiment les normes et qui n'était pas tenue de construire des portes sécurisées. Vous venez de descendre chez le fournisseur de bâtiment local et avez acheté la porte. Pire encore, les deux autres portes ont été choisies de la même manière - au hasard, pas selon un design plus large.
Malheureusement, il existe des moyens facilement disponibles de violation de l'un des trois styles de porte. Par conséquent, même s'il y a trois portes, il est trivial pour un voleur qualifié de se rendre dans votre coffre-fort et de voler vos objets de valeur. Bien sûr, un vol occasionnel occasionnel est empêché - le gamin coquin ne va pas s'en tirer avec vos richesses, mais le voleur déterminé le trouvera facile.
Comparez cela à votre voisin, qui a non seulement utilisé des portes de meilleure qualité, mais qui a embauché un entrepreneur pour construire sa maison - un entrepreneur qui comprend la sécurité à la maison. Cet entrepreneur savait comment sélectionner des portes difficiles à vaincre - ou même des portes pour lesquelles il n'existait aucune méthode de défaite connue. Il a su se coordonner entre les différents sous-traitants qui livraient et installaient les portes. Il savait comment vérifier que les portes étaient construites correctement. En raison de cette surveillance et de cette coordination, le coffre-fort de votre voisin ne sera pas aussi facilement pillé que le vôtre.
Voici une analogie inspirée du cheval de Troie.
Dans le sillage du cheval d'origine, la ville a tenté de se durcir contre ce type d'attaque. Mais à l'intérieur de la ville, les gros véhicules doivent se déplacer pour livrer des marchandises. Donc:
Étape 1: Faites entrer clandestinement les morceaux du nouveau "cheval" (peut-être que c'est une vache cette fois pour être moins méfiant) dans la ville. Une à la fois, les pièces en bois ne représentent aucune menace et ne sont donc pas remises en question. Cependant, vous ne pouvez pas introduire clandestinement des armes à ce stade.
Étape 2: Il y a un artisan dans la ville qui construit des véhicules en bois. Si les pièces arrivent dans sa cour, il les assemblera. Ensuite, une personne peut se cacher dans la vache.
Étape 3: Le jour du festival, la vache défile dans la ville avec d'autres divertissements. Avec tout le monde ivre, personne ne remarquera l'occupant de la vache grimper dessus et sauter de là sur le mur de la ville.
Étape 4: Normalement, vous devez escalader les murs de la ville via un poste de garde, et seuls les gardes seraient autorisés à passer. Ainsi, lorsque la personne se présente à la guérite et annonce au garde-porte que son quart de travail est terminé, le gardien le croit (il veut quand même rejoindre la fête). Maintenant, avec un portier compromis, vous pouvez garder la porte de la ville grande ouverte et laisser entrer une armée.
Pour aborder spécifiquement la question des "codeurs différents mettant en œuvre la même fonctionnalité de différentes manières", considérez qu'il existe deux façons de faire entrer des articles dans la ville. L'un est de petits articles avec peu d'examen, l'autre est de gros articles avec beaucoup d'examen. Le problème est que personne n'a pensé à ce que de petits articles soient apportés dans la ville puis assemblés en un plus gros article une fois sur place.
Je ne suis pas sûr que cela corresponde complètement et que cela puisse être trop sombre pour le public, mais une chose qui m'est venue à l'esprit était les défaillances du renseignement autour de l'attaque du 911 en raison du fait que différentes agences ne communiquent pas ou ne partagent pas d'informations.
Pour moi, il semble que quelqu'un ait écrit "désérialiser" dans son programme sans penser très dur aux implications. Il n'y avait rien de mal avec la première version.
Le problème de conception et de méthodologie le plus profond était peut-être que le contrat de cette partie qui avait été réimplémentée n'était pas bien documenté et testé.
Je pense qu'il est probablement plus amusant pour un public Noob (ou n'importe quel public vraiment) de jeter un œil aux choses drôles qui ont tendance à se produire lorsque quelqu'un utilise la sérialisation sans le plus grand soin. Surtout dans une langue interprétée ou très dynamique. Bien sûr, pour que cette présentation fonctionne, vous devez expliquer un peu de choses techniques, mais tel est le prix d'un public éveillé.
Pour un public non technique:
Vous avez trois portes, chacune reliée à un système d'alarme central.
Le manuel de sécurité pour la porte 1 dit:
si l'alarme se déclenche:
- Désactivez l'alarme
- Testez la porte
- Résoudre tous les problèmes détectés
- Contactez la direction du bâtiment si aucun problème n'a pu être résolu.
Le manuel de sécurité pour la porte 2 dit:
si l'alarme se déclenche:
- Attendez 30 secondes pour voir si l'alarme se réinitialise
Si l'alarme continue
- tester la porte
- Résoudre tous les problèmes détectés
- Contactez la direction du bâtiment si aucun problème n'a pu être résolu.
Le manuel de sécurité pour la porte 3 dit:
si l'alarme se déclenche:
- Attendez 30 secondes pour voir si l'alarme se réinitialise.
- Si l'alarme persiste
- tester la porte
- résoudre tous les problèmes détectés
- Contactez la direction de l'immeuble pour lui faire savoir ce qui s'est passé.
Vous êtes maintenant dans une position où un agent de sécurité peut désactiver une alarme avant que l'autre agent de sécurité ne se rende compte qu'il y a un problème qu'il doit résoudre.
La direction reçoit des notifications de problèmes et de fausses alarmes et ne se rend pas compte que d'autres alarmes sont ignorées.
Sans plonger trop profondément dans l'article lié. cela ressemble à un problème où les hypothèses sous-jacentes n'étaient pas courantes entre les personnes qui y travaillaient.
Essentiellement, le système a été initialement configuré pour avoir une liste de "choses que les utilisateurs sont autorisés à faire" que vous pouvez demander. Ceux-ci sont clairement définis et puisque vous dites simplement au système de les faire et qu'ils sont sécurisés en eux-mêmes, pas de problème, vous incluez votre mot de passe de sécurité comme authentification.
Le problème est survenu lorsqu'un développeur ultérieur a ajouté la possibilité de mettre à jour les données de votre compte, y compris vos privilèges de sécurité. Cela signifie que vous pouvez utiliser ce nouveau système pour effectivement bootstrap vos privilèges si vous savez quoi demander, parce que le système de configuration des données n'est pas très sécurisé, c'était le point d'avoir un L'approche "demander, pas ordonner" en premier lieu.
Essentiellement, normalement vous demandez au système de faire des choses pour vous et il est autorisé à vous dire "Non" si vous n'avez pas l'autorité.
Mais une mise à jour ultérieure par quelqu'un qui n'y a pas pensé pourquoi il a été configuré de cette façon a ajouté la possibilité de demander au système d'augmenter vos privilèges d'une manière qu'il ne peut pas réellement refuser.
Imaginez que vous vouliez aller à une soirée privée, mais que vous ne soyez pas sur la liste des invités. Le gars de la sécurité ne vous laissera pas entrer. Mais si vous dites à l'organisateur que vous êtes invité, il vous mettra sur la liste sans le remettre en question.
Si vous avez la même porte installée exactement de la même manière par le même menuisier à toutes les entrées d'un bâtiment, vous n'avez qu'à en tester une à fond (essayez de la rabattre, essayez de forcer la serrure, etc.) et ensuite vous pouvez simplement prendre jetez un coup d'œil aux autres pour vous assurer qu'ils sont les mêmes. Si vous avez un tas de charpentiers et que certains utilisent des portes différentes, vous devez tous les tester à fond.
Et Apollo 13? Les épurateurs de dioxyde de carbone pour le module de commande et l'atterrisseur lunaire ont été créés par différentes sociétés. L'un était carré, l'autre rond.
Voir le documentaire avec Tom Hanks pour plus de détails :-)
MTBF, ou "échecs" au sens 6σ
Bien que ce soient des choses complètement différentes, elles partagent certaines propriétés communes qui s'appliquent à votre problème.
Le Mean Time Between Failures est une mesure couramment utilisée pour évaluer la fiabilité des choses. Si, par exemple, vous achetez quelque chose comme une voiture ou un disque dur, cette chose particulière peut fonctionner sans problème jusqu'au jour de votre mort. Mais en moyenne, il finira par rencontrer un échec, après un temps moyen X. C'est le MTBF.
Six Sigma (6σ) est fondamentalement le même genre de chose, sauf que la plupart du temps vous ne traitez pas avec des choses mais avec des processus, et vous analysez (et optimisez pour) non pas le temps opérationnel, mais le nombre d '"opportunités", qui peut être ... quoi que ce soit, et des échecs, qui peuvent, encore une fois, être ... quoi que Il peut s'agir de produire quelque chose, de livrer à temps ou de simplement répondre correctement à un téléphone.
Dans un exemple plus concret, si par ex. votre usine de chaussures produit un million de baskets par mois, vous essayez de faire en sorte que pas plus de 3 d'entre elles (idéalement zéro) sortent avec la mauvaise couleur ou sans lacets, et ne peuvent pas être vendues.
Comment cela s'applique-t-il ici?
Le MTBF a une implication bien connue, il va bas proportionnellement avec le nombre d'unités utilisées allant haut. Ce qui signifie que bien qu'il il est très peu probable que votre téléphone portable explose dans votre poche pendant deux à trois ans d'utilisation typique, il est pratiquement garanti que cela arrive à quelqu'un si dix millions de personnes en possèdent un (c'est la raison par exemple de l'infâme Samsung rappelez-vous de la campagne/cauchemar des relations publiques il y a environ un an - ce n'est pas comme si vous étiez vraiment en danger si vous en possédiez un).
De même, en regardant sous l'angle 6σ, si votre usine de chaussures produit non seulement un million de baskets, mais un milliard, alors vous aurez 3000 paires de chaussures défectueuses, pas 3.
Il y a quelques années, l'utilisation du RAID-5 était découragée. Comment cela offre-t-il une sécurité supplémentaire des données, n'est-ce pas? Il se trouve que les disques durs ont très, très peu de chances de corrompre un secteur, il est donc irrécupérable. Cela n'arrive jamais ... enfin, presque.
Mais si vos disques sont assez grands (comme les disques modernes), avec de nombreux secteurs, et que vous en avez plusieurs regroupés, vous êtes fondamentalement garanti pour que cela se produise lors d'une re -une opération de synchronisation, c'est-à-dire au moment précis où vous n'avez tout simplement pas besoin que cela se produise parce que vous êtes déjà sur un disque. De plus, vous avez la possibilité qu'un deuxième disque échoue de manière catastrophique à mi-chemin de la resynchronisation. Ce qui n'arrive jamais non plus ... enfin, presque. Plus il y a de disques, plus il est probable que cela se produise.
La même chose s'applique pour réimplémenter plusieurs fois la même fonctionnalité dans un logiciel. Chaque implémentation (chaque fonction, pas seulement celles qui dupliquent des fonctionnalités) est une "opportunité", ou l'équivalent d'un disque dur. Plus de fonctions, via la fonctionnalité de duplication, signifie plus de possibilités d'échec. De plus, plus de code à revoir.
Bien que vos programmeurs fonctionnent principalement sans erreur (enfin, espérons-le), il y a toujours une petite chance pour eux de faire une fausse hypothèse, ou une erreur pure et simple. Plus les opportunités sont nombreuses, plus il est probable que cela se produise.
Une réponse alternative à mon original, après avoir lu sur le sujet et eu plus de temps pour y réfléchir.
Imaginez une entreprise avec de nombreux bureaux isolés. Chaque département fait toujours exactement ce qu'on lui dit de faire via des lettres types.
Pour vous assurer que les lettres ne sont pas envoyées par malveillance, vous devez indiquer un mot de passe dans l'en-tête. Le ministère demandera à un bureau central au sous-sol si le mot de passe qu'il a reçu est autorisé à lui dire quoi faire.
si c'est vrai, les instructions sont suivies, sinon la lettre est jetée.
Le bureau central gère également toutes les données du personnel de l'entreprise. Le bureau central n'a pas sa propre adresse postale pour des raisons de sécurité, ce qui nécessite des modifications en personne.
Un jour, la direction se lasse de devoir descendre au sous-sol pour mettre à jour les données des employés et a simplement fourni au bureau central sa propre adresse postale et ses propres formulaires. Cela leur permet d'effectuer facilement des modifications depuis leur propre bureau.
Ils ne sont pas stupides, ils ont fait en sorte que les lettres types du bureau central n'incluent rien sur le changement de mot de passe.
La particularité est que tous les formulaires sont validés dans un système commun en recherchant un papier à en-tête particulier.
Ainsi, lorsqu'une personne entreprenante crée un nouveau formulaire qui correspond aux directives de l'entreprise mais inclut un champ de changement de mot de passe, le bureau central l'accepte volontiers et apporte ses modifications.
Soudain, cette personne peut modifier ses autorisations pour lui permettre d'envoyer des lettres valides n'importe où dans l'entreprise et obtient un contrôle total sur le système.
Je dirais que c'est une analogie assez solide pour le système et ce qui lui est arrivé dans l'exemple Moodle.
Lettres de substitution pour Ajax et injection SQL pour la version modifiée de la lettre type avec le champ de mot de passe.