Panne Crowdstrike / Microsoft : sommes-nous totalement impuissants ?

Sans y voir la catastrophe mondiale que certains commentateurs ont imaginé, ce sont autant d’ordinateurs à redémarrer de façon unitaire, et surtout, au-delà des machines, des perturbations sur de nombreux services, particulièrement visibles là où nous nous sommes le plus accoutumés à l’immédiateté, notamment dans les médias ou les transports.

De façon très basique, que révèle cet incident ?

• Que nous sommes de plus en plus dépendants du numérique.
• Que le retour total au “papier crayon” est douloureux – voire impossible – compte tenu de la complexité de certains processus.
• Que certaines solutions informatiques possèdent un caractère systémique : environ 70% des postes de travail fonctionnent aujourd’hui sur Windows.
• Que la “supply chain” logicielle est de plus en plus complexe, ce qui a pour conséquence de diluer à l’excès les responsabilités entre de multiples acteurs, et d’augmenter le niveau de risques, qu’il soit d’origine accidentel ou malveillant. 
• Que l’architecture de notre espace numérique est beaucoup plus centralisée qu’on ne le pense.
• Qu’il existera toujours un risque résiduel, même après application des meilleures pratiques en matière d’anticipation, de prévention, de protection ou d’assurance. 

Rien que nous ne savons tous depuis longtemps, me direz-vous… Exact ! Mais que nous avons un peu tendance à oublier, volontairement ou non, et qui nous rappelle que les technologies sont faillibles, à l’instar de toutes les constructions humaines. Il serait ainsi absurde de blâmer le type de technologie en cause : un système EDR (Endpoint Detection & Response), qui nous sauve quotidiennement de très nombreuses attaques en apportant des capacités de détection et de réaction automatisées jamais égalées face aux menaces informatiques.

Faut-il pour autant se contenter de blâmer la fatalité en considérant que cet incident est la faute “à pas de chance” ? Non ! A la différence du fameux “cygne noir”, ce type d’événement imprévisible, à faible probabilité et à très fort impact théorisé par Nassim Nicholas Taleb, les leviers ne manquent pas pour réduire la probabilité et limiter l’impact de ce type de risque.

• Cette panne a pour origine une erreur de code dans la mise à jour non du logiciel EDR Crowdstrike Falcon lui-même, mais dans la base de signatures. Ce n’est pas la première panne de ce type. Rien qu’en matière de cybersécurité, on peut citer les difficultés rencontrées après des mise à jour McAfee Virus en 2010, Symantec en 2012,  Webroot SecureAnywhere et Avast en 2017, Sophos en 2019 – et ce ne sera pas la dernière. Et c’est justement parce que l’erreur est humaine que ce type de mise à jour doit non seulement faire l’objet de tests préalables, mais aussi d’un déploiement progressif afin d’en vérifier l’innocuité – ce qui ne semble pas avoir été le cas ici. Faut-il y voir les limites de la “speed security”, évoquée dans un post Linkedin par Franck Rouxel, qui revient souvent à confondre vitesse et précipitation, et de son corollaire, le “speed dev”, imposé par le tempo de la transformation numérique ? De là à imaginer l’avènement d’une “slow security” et d’un “slow dev” à base de revues de code approfondies, de “pair programming” etc…

• L’impact de l’incident – le fameux “écran bleu de la mort” (ou blue screen of death) – est lié aux privilèges dont dispose la solution EDR sur Windows, qui lui permettent d’accéder au noyau central du système (le “kernel”). Cela a conduit un porte-parole de Microsoft à tenter de reporter la faute sur la Commission européenne, qui a contraint, en 2009, l’entreprise à ouvrir son système d’exploitation pour faciliter l’interopérabilité avec d’autres solutions. Sauf que cet accord, qui a pour objectif d’éviter les abus anticoncurrentiels, n’a jamais imposé à Microsoft de donner un accès au fameux kernel. Et qu’il est tout à fait concevable que des logiciels de sécurité puissent disposer des accès nécessaires sur le système d’exploitation pour surveiller et réagir efficacement aux menaces sans pour autant toucher au “noyau”. 

• Souvent trop complexe, la “supply chain IT” doit être simplifiée en s’appuyant sur des solutions et des services fortement intégrés, automatisés, interopérables. En renforçant la collaboration avec les fournisseurs ainsi que l’examen de leurs contrats, on s’asure que le nombre d’acteurs impliqués ne débouche pas une irresponsabilité collective… Il en va de la souveraineté même des organisations sur leurs processus, leurs données, leurs salariés, et donc sur leur business. 

• Même largement globalisée, toute chaîne d’approvisionnement IT possède des Single Points of Failure (SPoF) : ceux dont l’arrêt ou le dysfonctionnement peut entraîner l’échec complet ou partiel du système ou du service considéré. D’où l’importance de mettre en place des architectures redondantes et décentralisées ainsi que des plans de continuité et de reprise d’activité (PCA et PRA) testés régulièrement et de façon opérationnelle. Je me souviens de ce RSSI de collectivité territoriale qui me disait imposer à toutes les équipes de son organisation un retour au “papier-crayon” complet une fois par an. Difficile, cependant, à imaginer dans tous les secteurs. À moins que l’on accepte, là aussi, de ralentir le rythme, attitude qui relèverait d’une décroissance assumée… 

• La panne ne semble, heureusement, avoir généré aucun décès, blessure ou dommage aux biens. Si des services dits essentiels comme les transports, les médias ou même la santé ont été affectés, c’est au travers d’activités comme l’enregistrement des passagers pour les compagnies aériennes. Le contrôle aérien, les systèmes de navigation, les automatismes industriels, et les environnements dits “opérationnels” ne semblent pas avoir été touchés. Cela correspond d’ailleurs aux limitations de garantie de Crowdstrike qui indiquent que ses produits et services “ne sont pas tolérants aux pannes et ne sont ni conçus ni destinés à être utilisés dans un environnement dangereux nécessitant une performance ou un fonctionnement sécurisé en cas de défaillance.” Ouf… Il n’empêche qu’il aurait été de bon ton d’évaluer la criticité de certains services touchés à l’aune des chaînes dans lesquels ils s’insèrent et de privilégier pour ceux-ci une politique de sécurité différenciée, en particulier pour les mises à jour, à défaut de pouvoir opter pour un environnement spécifique et un cloisonnement complet. 

• La faible “diversité génétique” des systèmes d’exploitation et solutions de cybersécurité a été largement montrée du doigt depuis le début de cette crise. À raison. À n’en pas douter, celle-ci renforce l’impact du moindre problème, quelle qu’en soit l’origine. En termes de sécurité, un compromis doit ainsi être trouvé entre les bénéfices apportés par un environnement ou une solution largement déployée, qui permettra dans le cas d’un EDR de bénéficier d’une intelligence collective supérieure face aux menaces (“crowd security”), et celui de solutions alternatives qui limiteront le risque d’effondrement systémique. Attention, cependant, à ne pas mélanger ce débat avec celui, tout aussi stratégique, sur la souveraineté numérique et de l’indépendance technologique ! L’idéal est bien sûr de disposer de solutions à la fois sécurisées et souveraines, mais le souverain non sécurisé existe aussi, et vice versa.

In fine, cette panne pourrait bien avoir un impact négatif sur le marché de l’assurance des risques IT et celui, plus naissant, des cyber risques. Tout élément renforçant le caractère systémique du risque, quel que soit le fait générateur, rend celui-ci nettement moins attrayant pour l’assureur. De quoi fragiliser un marché dont l’équilibre est encore précaire, indique le dernier rapport LUCY de l’AMRAE.