Tribunes

Panne IT de McDonald's, un cours magistral de tout ce qu'il ne faut pas faire

En décryptant les déclarations de McDonald's, la panne subie par l’enseigne semble résulter d’une tentative de bloquer rapidement une attaque potentielle. (Crédit : Wikipédia)

Lorsque McDonald's a subi en mars une panne mondiale bloquant tout paiement en magasins, l'enseigne a publié une longue déclaration sur l'incident qui était à la fois vague et trompeuse. Mais qui permettait de comprendre de nombreux détails techniques de la mésaventure vécue par la chaîne de fast-food.

PublicitéLa panne mondiale qui, le mois dernier, a empêché McDonald's d'accepter les paiements a incité l'entreprise à publier une longue déclaration. Une communication qui devrait servir de cours magistral sur la manière de ne pas communiquer sur un problème IT. Le communiqué était vague, trompeur et pourtant la société a utilisé un langage qui permettait encore de comprendre de nombreux détails techniques relatifs à l'incident. Des errements qui ont d'ailleurs value à 'McDo' un post LinkedIn moqueur de son concurrent Burger King.

La déclaration de McDonald's est restée vague sur ce qui s'est passé, mais elle a choisi de mettre en cause le fournisseur de terminaux points de vente (POS) de la chaîne, sans préciser son nom. La classe. Ce communiqué, publié peu de temps après le début de la panne, mais avant qu'elle ne prenne fin, indique que « ce problème n'a pas été causé par un événement de cybersécurité, mais par un fournisseur tiers lors d'un changement de configuration ». Quelques heures plus tard, la déclaration a discrètement été modifiée en ajoutant le mot 'directement' : « ce problème n'a pas été directement causé par un événement de cybersécurité ».

Cet ajout a soulevé toutes sortes de questions. Techniquement, cela signifie qu'il y a bien eu un « événement de cybersécurité » quelque part - qui n'a probablement pas affecté McDonald's ou son fournisseur de terminaux points de vente - qui a d'une manière ou d'une autre joué un rôle dans la panne. Le scénario le plus probable est que McDonald's ou son fournisseur a appris qu'une attaque avait eu lieu ailleurs (peut-être même plusieurs) et qu'elle avait exploité une faille du POS présente également dans l'environnement de McDonald's. L'un des deux a alors décidé de déployer un patch sécurité sur les terminaux de l'enseigne. Et en raison de tests insuffisants ou inexistants concernant l'impact du correctif, les systèmes de l'entreprise sont tombés en panne. Cela expliquerait comment la panne a pu être indirectement causée par un événement de cybersécurité.

Après la correction, les lenteurs du DNS

Revenons à la déclaration de McDonald's, où nous trouvons d'autres indices sur ce qui s'est probablement passé. Brian Rice, directeur des systèmes d'information de McDonald's, y déclare : « vendredi, vers minuit heure du centre (soit le fuseau horaire médian de l'Amérique du Nord, NDLR), McDonald's a connu une panne du système d'information mondial, qui a été rapidement identifiée et corrigée. De nombreux marchés sont de nouveau en ligne et les autres sont en train d'être remis en service. Nous travaillons en étroite collaboration avec les marchés qui rencontrent encore des problèmes ».

À première vue, ces phrases semblent présenter une contradiction. Le DSI affirme que la panne a été « rapidement identifiée et corrigée », mais la phrase suivante indique que de nombreux pays où opère l'enseigne sont toujours hors ligne. Si la panne avait été rapidement corrigée, pourquoi tant de systèmes étaient-ils encore hors ligne au moment de la publication de ce communiqué ?

PublicitéLa réponse à cette contradiction semble résider dans le DNS. Cela expliquerait comment le problème a pu être corrigé, mais que ladite correction n'ait pas encore atteint tout le monde. Le DNS a besoin de temps pour se propager et, compte tenu de l'étendue des zones géographiques touchées (États-Unis, Allemagne, Australie, Canada, Chine, Taïwan, Corée du Sud et Japon), le délai d'un à deux jours qui a touché certaines régions correspond à ce que l'on peut attendre d'un problème de DNS.

D'une erreur de configuration à une panne mondiale

Mike Wilkes, directeur des opérations au sein du cabinet spécialisé en cybersécurité The Security Agency, est l'un des nombreux spécialistes de la sécurité contactés qui considèrent que le DNS est le coupable le plus probable : « il semble qu'il s'agisse d'une défaillance du DNS qui a transformé une erreur de configuration en une panne mondiale. A la source, il s'agissait probablement d'un correctif insuffisamment testé ou trop grossier ». Et de noter que la panne n'a pas eu d'impact sur l'application mobile de McDonald's, ce qui - si c'est exact - est un autre indice de ce qui s'est passé.

Une partie du retard à la restauration des systèmes n'est pas seulement due au fait que le DNS a besoin de temps pour se propager, mais aussi au fait que McDonald's aurait dû envoyer le changement par l'intermédiaire de différents résolveurs DNS. « Il s'agissait probablement d'une modification DNSSEC (Domain Name System Security Extensions) destinée à améliorer leur sécurité », analyse Mike Wilkes. Ce dernier soupçonne également le paramètre TTL (time to live) d'avoir joué un rôle. « Personne n'a probablement eu le temps d'abaisser le TTL pour obtenir un délai de récupération de cinq minutes ». Ce qui expliquerait les longs délais de restauration.

Terry Dunlap, cofondateur et associé de la Gray Hat Academy, estime également que la panne de McDonald's résulte d'une tentative de bloquer rapidement une attaque potentielle imminente. Mais se montre critique vis-à-vis des déclarations de l'enseigne. « Il est préférable d'être proactif et aussi détaillé que possible dès le départ. "Je ne pense pas que les déclarations [de McDonalds, NDLR] aient véhiculé le niveau d'empathie et de sérénité nécessaire. Je recommanderais d'aller plus loin dans les détails. Comment avez-vous réagi ? Pourquoi cela s'est-il produit ? Les déclarations de McDonald's posent plus de questions qu'elles n'apportent de réponses ».

Un fournisseur, mais quel fournisseur ?

Pour ce qui est de se dédouaner de sa responsabilité en pointant un fournisseur, il faut se référer à la seconde version de la déclaration de la chaîne de restaurants, qui dit : « dans les jours à venir, nous analyserons le problème et demanderons à nos équipes et aux fournisseurs tiers de rendre des comptes ». Pourquoi pas. Mais la veille, le communiqué indiquait que la panne « avait été causée par un fournisseur tiers lors d'un changement de configuration ».

Il me semble, Ronald, que tu protestes un peu trop ! Qui a engagé ledit fournisseur ? Quelle équipe informatique gérait ce fournisseur ? L'équipe IT de McDonald's a-t-elle dit au fournisseur de réparer le problème immédiatement ? A-t-elle sous-entendu que si l'on prenait quelques raccourcis avec les procédures standards pour y parvenir, personne n'y trouverait à redire ?

La désignation d'un tiers pourrait être justifiée si ce tiers s'était mis à l'écart et avait apporté lui-même des modifications sans demander l'avis de McDonald's. Mais cela semble hautement improbable. Et si c'était le cas, McDonald's ne l'aurait-il pas dit directement ? Par ailleurs, il est quelque peu étrange de désigner la responsabilité d'un tiers tout en gardant son identité secrète. On ne gagne pas de points en accusant quelqu'un et en ne disant pas qui est accusé.

La gestion des risques liés aux tiers

L'épisode soulève une fois de plus le risque que représentent les tiers - en particulier ceux qui, comme cela pourrait être le cas avec McDonald's, agissent de leur propre chef et causent des problèmes à la DSI de l'entreprise. « Toutes les entreprises sont actuellement harcelées pour leur gestion des risques liés aux tiers, dit Brian Levine, directeur des activités cyber et privacy d'Ernst & Young (EY). La gestion des risques liés aux tiers est de plus en plus scrutée à la loupe par les tribunaux, les autorités de régulation et les entreprises elles-mêmes ».

Dans un premier temps, McDonald's n'a pas déposé de rapport à la SEC - le gendarme des bourses aux Etats-Unis - concernant l'incident. Étant donné que Wall Street n'a pas réagi de manière sérieuse à la panne, il est peu probable que McDonald's considère la panne comme importante. Quant au fournisseur de terminaux point de vente, on ne sait pas s'il a déposé un rapport, son identité n'ayant pas encore été confirmée.

L'une des leçons importantes à retenir pour toutes les DSI est qu'il faut bien soupeser les déclarations relatives à des pannes IT. Tout ce qui va au-delà d'un laconique « Il s'est passé quelque chose. Nous enquêtons et nous en dirons plus une fois que les faits seront connus et vérifiés » va laisser des indices. Les implications vagues ne vont pas vous aider. Si vous êtes prêt à dire quelque chose, dites-le. Si vous ne l'êtes pas, ne dites rien. Tenter la voie médiane, comme l'a fait McDonald's, ne servira probablement pas vos intérêts.

Contacté par nos confrères de Computerworld - où a été initialement publiée cette tribune -, McDonalds n'a pas souhaité apporter de commentaires supplémentaires.

Article rédigé par

Schuman Evan, Journaliste
Evan Schuman couvre les sujets informatiques depuis bien plus longtemps qu'il ne l'admettra jamais. Rédacteur en chef et fondateur du site StorefrontBacktalk consacré aux technologies dans le retail, il a été chroniqueur pour CBSNews.com, RetailWeek, Computerworld et eWeek, et sa signature a été publiée dans des titres allant de BusinessWeek, VentureBeat et Fortune au New York Times, USA Today, Reuters, The Philadelphia Inquirer, The Baltimore Sun, The Detroit News ou encore The Atlanta Journal-Constitution.