Zero Trust : trois composantes stratégiques clés de l’approche « Assume Breach »

Ken Arora

Le zero trust est aujourd’hui un sujet très populaire dans les milieux de la cybersécurité, mais je suscite encore des regards étonnés chaque fois que j’évoque le concept de présomption de compromission comme un élément clé de l’approche zero trust. Je suppose que cette réaction découle de l’une de ces deux préoccupations. Tout d’abord, certains professionnels de la sécurité peuvent y voir une vision terriblement pessimiste du monde ; pour eux, « présumer une compromission » revient à dire : « Donc, vous dites que nous sommes tous condamnés. Dans ce cas, autant baisser les bras et ne même plus essayer. » D’autres, peut-être les plus orgueilleux, peuvent se dire : « Bon, vos systèmes peuvent être compromis, mais ma sécurité est à toute épreuve, et les acteurs malveillants ne parviendront jamais à franchir mes défenses ».

Mon propos ne se situe dans aucun de ces deux extrêmes ; il s’agit plutôt de prendre pleinement conscience de la réalité inhérente au monde numérique, à savoir que des compromissions se produiront et qu’elles peuvent — et doivent — donc être prises en compte dans la conception de tout système de sécurité. Ce concept n’a rien de nouveau, et nous devrions nous inspirer de la sagesse acquise par des générations d’artisans et de professionnels qui l’ont adopté.

Les plombiers, les électriciens et les autres professionnels qui interviennent dans le monde physique ont depuis longtemps intégré la véritable essence du principe « partir du principe qu’une compromission est inévitable ». Chargés de concevoir des solutions qui doivent être robustes dans des environnements concrets, ils acceptent et intègrent implicitement le simple fait que des défaillances surviennent dans le cadre de leur travail. Ils comprennent également que ces défaillances ne remettent pas en cause leurs compétences et ne constituent pas une raison de renoncer à leurs services. Au contraire, les professionnels les plus compétents savent que leurs créations finiront par connaître des défaillances, tirent les enseignements des incidents passés et sont capables d’anticiper les défaillances susceptibles de se produire à l’avenir.

J’ai récemment été confronté à une défaillance de ce type : une canalisation d’évacuation des eaux usées de ma maison s’est bouchée au milieu du réseau d’évacuation. La maison a plus de 30 ans, une défaillance — une brèche — ne devrait donc pas être une surprise. Après tout, sur une période prolongée, la probabilité qu’un système subisse une brèche approche les 100 %.

C’est bien là le problème. Il est tout aussi pertinent d’anticiper une défaillance à terme pour une solution de sécurité applicative que pour mon système de plomberie. En outre, partir du principe que « mon système de plomberie ne tombera jamais en panne » n’est pas plus judicieux comme stratégie d’entretien domestique que de penser que « mes défenses informatiques ne seront jamais compromises ».

Par conséquent, le plombier comme le spécialiste de la cybersécurité doivent réfléchir à la manière de gérer la défaillance — autrement dit, la brèche — qui finira inévitablement par se produire.

Les trois composantes stratégiques clés de l’approche « Assume Breach »

Une stratégie efficace pour faire face à la défaillance des systèmes, qu’ils soient physiques ou informatiques, comporte généralement trois volets.

1. Visibilité. Assurez une visibilité suffisante afin de détecter toute défaillance le plus rapidement possible. Une fuite de plomberie dans l’évacuation d’une salle de bains qui n’est pas réparée entraînera la pourriture et l’apparition de moisissures dans le sous-plancher, ce qui peut passer inaperçu pendant des mois, voire des années. Il arrive aussi que l’on remarque de l’eau s’écoulant du plafond de la pièce située sous une salle de bains à l’étage, après le débordement d’un bac de rétention sous le plancher et l’imbibition de la plaque de plâtre. Dans chacun de ces scénarios, le problème n’est détecté qu’un certain temps après la défaillance initiale et après que des dommages secondaires supplémentaires se sont produits. Le premier principe d’une approche fondée sur l’hypothèse d’une défaillance ou d’une compromission consiste à fournir des indicateurs clairs d’une éventuelle compromission le plus rapidement possible après la défaillance, idéalement en envoyant même une notification proactive en cas de défaillance probable. Par exemple, les sous-sols qui dépendent de pompes de relevage pour évacuer l’eau sont généralement équipés de capteurs qui déclenchent une alarme lorsque le niveau d’eau dépasse un seuil prédéfini. Dans d’autres situations, lorsqu’il n’est pas possible de mettre en place des alertes proactives pour tous les modes de défaillance probables, des contrôles de maintenance réguliers sont effectués, par exemple une inspection semestrielle des chauffe-eau. En cybersécurité, cela signifie que l’architecture de sécurité de l’application doit inclure une stratégie de télémétrie mûrement réfléchie et testée, qui tient compte des principaux modes de défaillance et offre une visibilité rapide sur toute compromission éventuelle. En pratique, les données de télémétrie doivent être transmises en continu à des outils d’analyse et de notification selon les pratiques AISecOps, tout en étant simultanément conservées dans des magasins de données en vue d’une utilisation ultérieure. Des outils d’IA et d’alerte doivent être utilisés pour améliorer l’efficacité, fournir du contexte aux équipes humaines et garantir une intervention rapide. Les données conservées doivent servir à tirer des enseignements et à renforcer davantage la robustesse à l’avenir. 
2. Robustesse. Les solutions doivent prévoir des moyens de contourner une défaillance ou d’en réduire la durée. Dans ce contexte, les modèles couramment employés pour assurer la robustesse sont (a) la dégradation progressive ou (b) la redondance, le choix dépendant de la possibilité de continuer à fonctionner avec un composant dégradé. Certains systèmes, comme les chauffe-eau, peuvent combiner les deux. Par exemple, mon chauffe-eau utilise un système de recirculation alimenté par une pompe afin que de l’eau chaude soit toujours immédiatement disponible. Mais si la pompe tombe en panne, j’aurai toujours de l’eau chaude, même s’il me faudra patienter un peu plus longtemps. En revanche, la défaillance d’un capteur de résistance chauffante — empêchant l’arrêt de l’élément chauffant — peut entraîner une défaillance catastrophique ; on utilise donc une redondance sous la forme d’une soupape de sécurité. La robustesse doit être envisagée à plusieurs niveaux du système. Par exemple, à l’échelle de la seule conduite d’évacuation, un plombier travaillant sur une solution de qualité professionnelle pourrait installer deux conduites d’évacuation redondantes, de sorte que la défaillance de l’une d’elles ne rende pas l’évacuation inutilisable. À l’inverse, un architecte raisonnant au niveau d’abstraction du système pourrait concevoir une redondance à l’échelle du système, par exemple en ajoutant à proximité un second lavabo ou des toilettes, ce qui permettrait également de couvrir davantage de modes de défaillance que le seul engorgement des conduites d’évacuation. La redondance est bien entendu une pratique courante en cybersécurité, de nombreux dispositifs de sécurité étant déployés soit en mode actif/veille (redondance complète), soit en mode actif/actif (dégradation progressive). Toutefois, le monde de la cybersécurité diffère quelque peu du monde physique. Tout d’abord, la présence d’attaquants actifs, dotés d’une intention et d’une intelligence, signifie que les défaillances résultent rarement de causes naturelles. Une seconde différence, plus importante, tient à l’échelle. Comme les logiciels sont virtuels et non physiques, ils suivent le paradigme « écrire une fois, déployer partout ». Si cette propriété est formidable pour le passage à l’échelle, elle implique également qu’une vulnérabilité du code dans un composant logiciel central affectera probablement toutes les instances de ce code au sein du système. Ainsi, la solution de cybersécurité visant à assurer la robustesse repose également sur l’élimination des points uniques de défaillance — ainsi que des catégories uniques d’éléments susceptibles de défaillir —, une stratégie parfois appelée « défense en profondeur ». L’authentification multifacteur illustre parfaitement cette idée dans la pratique. Le mode de défaillance (le moyen de compromettre le système) diffère pour chaque facteur, et la compromission d’un seul facteur ne compromettra pas l’ensemble du système. 
3. Confinement. Il est essentiel de limiter l’impact — la zone d’impact — d’une défaillance. Tout comme nous admettons que des défaillances ou des intrusions se produiront, nous devons également accepter qu’il nous sera impossible d’éviter totalement les points uniques de défaillance ou de prévoir une redondance pour chaque exigence fonctionnelle. Par conséquent, l’architecte doit aussi réfléchir à la manière de réduire au minimum l’impact d’une défaillance, en prenant en compte deux critères importants d’efficacité : l’effort nécessaire et les conséquences. Par exemple, un plombier peut ajouter des regards de nettoyage à des endroits stratégiques des canalisations d’évacuation afin de réduire le délai d’intervention. Pour les défaillances plus graves, un entrepreneur peut préférer des canalisations d’évacuation en PVC à des canalisations galvanisées afin de faciliter la réparation d’une fuite et de réduire ainsi l’effort nécessaire. En plomberie domestique, il est courant d’installer des vannes d’arrêt afin de limiter les conséquences d’une défaillance détectée et d’éviter ainsi des dommages secondaires aux meubles de salle de bains et aux sols. Dans le domaine de la cybersécurité, les concepts analogues sont l’isolation, la maintenabilité et la modularité. L’isolation consiste à réduire au minimum les dommages collatéraux ou à enrayer la propagation de l’incident ; une bonne pratique consiste à disposer d’une infrastructure capable de faire office de coupe-circuit, à l’aide de technologies telles que la microsegmentation. La maintenabilité consiste, dans la mesure du possible, à permettre un retour rapide et peu coûteux d’un état compromis à un état non compromis ; par exemple, le redémarrage d’une charge de travail compromise par des attaques par dépassement de mémoire peut constituer une mesure d’atténuation efficace, quoique incomplète. La modularité consiste à concevoir des systèmes permettant de remplacer facilement des composants fonctionnels comparables, afin de réduire au minimum l’effort nécessaire à la remédiation lorsque la maintenance est impossible ou insuffisante.

Voici quelques-unes des bonnes pratiques que j’ai apprises en matière de gestion des failles de sécurité, même si je ne prétends évidemment pas qu’il n’en existe pas d’autres. Le plus important est que les développeurs et les professionnels de la sécurité chargés de protéger les applications comprennent que certaines vulnérabilités passeront entre les mailles du filet et que des failles de sécurité finiront inévitablement par se produire. Dans cette optique, la manière dont nous anticipons et gérons ces défaillances est tout aussi importante et mérite une réflexion aussi approfondie que les mesures que nous prenons pour en réduire la fréquence.

En définitive, nous serons jugés non seulement sur la fréquence des failles de sécurité, mais aussi sur notre capacité à y réagir lorsqu’elles se produiront inévitablement.

À propos de l’auteur

Ken Arora

Autres articles de Ken Arora