Je vais prendre un domaine que je connais mieux que la sécurité alimentaire: la sécurité de la prescription médicamenteuse. Dans ce domaine, on a aussi quelques principes généraux :
Entre deux médicaments équivalents, privilégier le plus ancien
Il n'est pas rare d'avoir le choix entre deux médicaments de la même classe thérapeutique. Quand ça arrive, il faut se dire que le médicament le plus ancien a été plus prescrit, plus étudié, et que son profil de sécurité est mieux connu. Il est donc plus sûr de donner le médicament le plus ancien.
Dans le monde logiciel, il n'est pas courant d'avoir deux logiciels exactement identiques. Cependant, les différentes versions d'un logiciel diffèrent généralement par 3 types de patchs : les correctifs de sécurité, les correctifs de bug non-sécurité, les ajouts de fonctionnalité. Tous ces patchs pouvant amener des failles de sécurité, il peut être intéressant de se limiter aux patchs strictement nécessaires, dans la mesure du possible.
Un autre enseignement est l'effet de masse : plus un logiciel sera utilisé, plus il sera audité et plus il sera sûr. Le pire étant sans doute, dans ce domaine, le logiciel édité à la rache par une SSII pour un client unique.
Au-delà de 3 médicaments, on ne sait plus très bien qui fait quoi
Il est courant de prendre en charge plusieurs pathologies, surtout chez la personne âgée. Cependant, les médicaments n'ont pas une infinité de voies métaboliques d'activation/transport jusqu'à la cible/dégradation et il n'est pas rare qu'ils entrent en compétition, ce qui peut aboutir à désactiver ou suractiver un médicament, dans des proportions généralement non mesurables. Une grosse partie du travail du prescripteur consiste à choisir les maladies qu'il souhaite traiter et celles qu'il est moins risqué de laisser évoluer.
Dans le domaine logiciel, une analogie serait que la faille d'un logiciel expose potentiellement d'autres logiciels de la même machine. Une protection repose donc sur le cloisonnement des services : de nos jours, il est tellement facile de virtualiser qu'il serait dommage de se priver de la sécurité supplémentaire apportée par la possibilité de séparer, logiciellement voire physiquement, les différents services critiques.
Il n'existe pas de thérapeutique efficace et dépourvue d'effets secondaires
(corollaire 1 : si ça ne donne jamais aucun effet secondaire à qui que ce soit, c'est probablement inefficace (cf. homéopathie). Corollaire 2 : ne prenez des médicaments en automédication que si vous savez vraiment ce que vous faites)
Les systèmes vivants sont des systèmes complexes. Il n'existe pas de médicament qui n'ait qu'une seule cible biologique et qu'un seul effet possible sur cette cible. Et même s'il n'avait qu'un seul effet, il y aurait toujours le risque de dépasser l'effet recherché (un antihypertenseur qui fait trop baisser la pression artérielle et provoque des étourdissements et des chutes, un anxiolytique qui finit par endormir, etc.)
Ce principe découle directement du fait qu'en biologie, et encore plus en médecine, on ne choisit pas son objet d'action. On ne peut pas dire à un patient "Désolé, votre corps n'est pas le bon, on ne va pas le soigner" ou "Votre foie n'est pas à la dernière version, on va d'abord faire une màj". En informatique, ce postulat est partiellement faux, mais seulement partiellement. Il est théoriquement possible d'avoir la maîtrise complète de sa machine. Théoriquement car ça suppose d'avoir accès au code source de tous les logiciels qui tournent, le temps de le lire, et les capacités de le comprendre. C'est déjà quasi-impossible rien qu'avec des logiciels libres, et ça devient impossible tout court avec des logiciels propriétaires (pas d'accès au code source).
Une solution est de simplifier au maximum le système : "Keep it simple, stupid". Pour chaque service, chaque démon, chaque logiciel préinstallé, se demander s'il est pertinent pour le service visé, et sinon, l'éliminer impitoyablement.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
# Analogie avec un autre modèle : la sécurité du médicament
Posté par Liorel . En réponse au journal Assurer la sécurité informatique sur le modèle de la sécurité alimentaire. Évalué à 10.
Je vais prendre un domaine que je connais mieux que la sécurité alimentaire: la sécurité de la prescription médicamenteuse. Dans ce domaine, on a aussi quelques principes généraux :
Entre deux médicaments équivalents, privilégier le plus ancien
Il n'est pas rare d'avoir le choix entre deux médicaments de la même classe thérapeutique. Quand ça arrive, il faut se dire que le médicament le plus ancien a été plus prescrit, plus étudié, et que son profil de sécurité est mieux connu. Il est donc plus sûr de donner le médicament le plus ancien.
Dans le monde logiciel, il n'est pas courant d'avoir deux logiciels exactement identiques. Cependant, les différentes versions d'un logiciel diffèrent généralement par 3 types de patchs : les correctifs de sécurité, les correctifs de bug non-sécurité, les ajouts de fonctionnalité. Tous ces patchs pouvant amener des failles de sécurité, il peut être intéressant de se limiter aux patchs strictement nécessaires, dans la mesure du possible.
Un autre enseignement est l'effet de masse : plus un logiciel sera utilisé, plus il sera audité et plus il sera sûr. Le pire étant sans doute, dans ce domaine, le logiciel édité à la rache par une SSII pour un client unique.
Au-delà de 3 médicaments, on ne sait plus très bien qui fait quoi
Il est courant de prendre en charge plusieurs pathologies, surtout chez la personne âgée. Cependant, les médicaments n'ont pas une infinité de voies métaboliques d'activation/transport jusqu'à la cible/dégradation et il n'est pas rare qu'ils entrent en compétition, ce qui peut aboutir à désactiver ou suractiver un médicament, dans des proportions généralement non mesurables. Une grosse partie du travail du prescripteur consiste à choisir les maladies qu'il souhaite traiter et celles qu'il est moins risqué de laisser évoluer.
Dans le domaine logiciel, une analogie serait que la faille d'un logiciel expose potentiellement d'autres logiciels de la même machine. Une protection repose donc sur le cloisonnement des services : de nos jours, il est tellement facile de virtualiser qu'il serait dommage de se priver de la sécurité supplémentaire apportée par la possibilité de séparer, logiciellement voire physiquement, les différents services critiques.
Il n'existe pas de thérapeutique efficace et dépourvue d'effets secondaires
(corollaire 1 : si ça ne donne jamais aucun effet secondaire à qui que ce soit, c'est probablement inefficace (cf. homéopathie). Corollaire 2 : ne prenez des médicaments en automédication que si vous savez vraiment ce que vous faites)
Les systèmes vivants sont des systèmes complexes. Il n'existe pas de médicament qui n'ait qu'une seule cible biologique et qu'un seul effet possible sur cette cible. Et même s'il n'avait qu'un seul effet, il y aurait toujours le risque de dépasser l'effet recherché (un antihypertenseur qui fait trop baisser la pression artérielle et provoque des étourdissements et des chutes, un anxiolytique qui finit par endormir, etc.)
Ce principe découle directement du fait qu'en biologie, et encore plus en médecine, on ne choisit pas son objet d'action. On ne peut pas dire à un patient "Désolé, votre corps n'est pas le bon, on ne va pas le soigner" ou "Votre foie n'est pas à la dernière version, on va d'abord faire une màj". En informatique, ce postulat est partiellement faux, mais seulement partiellement. Il est théoriquement possible d'avoir la maîtrise complète de sa machine. Théoriquement car ça suppose d'avoir accès au code source de tous les logiciels qui tournent, le temps de le lire, et les capacités de le comprendre. C'est déjà quasi-impossible rien qu'avec des logiciels libres, et ça devient impossible tout court avec des logiciels propriétaires (pas d'accès au code source).
Une solution est de simplifier au maximum le système : "Keep it simple, stupid". Pour chaque service, chaque démon, chaque logiciel préinstallé, se demander s'il est pertinent pour le service visé, et sinon, l'éliminer impitoyablement.
Ça, ce sont les sources. Le mouton que tu veux est dedans.