Actualite 6 min de lecture

Faille UEFI: votre sécurité web commence sous le CMS

Faille UEFI sur les serveurs: les questions à poser à votre hébergeur et à votre agence pour savoir comment les correctifs sont suivis et appliqués.

Harry Porcu
Harry Porcu
Faille UEFI: votre sécurité web commence sous le CMS

Service associé Audit de site web gratuit SEO, vitesse et sécurité, rapport sous 48 h

Sommaire


Une faille critique dans le firmware UEFI vient de rappeler une évidence que l’on oublie vite: un site web, un CRM ou une boutique en ligne reposent sur des machines, et ces machines ont leur propre couche logicielle, bien en dessous de ce que votre équipe marketing ou votre agence manipule au quotidien. Selon Ars Technica, cette vulnérabilité permettrait à un attaquant d’exécuter du code très tôt dans le processus de démarrage, et elle concernerait la majorité des serveurs de la planète.

Pour un dirigeant, l’enjeu n’est pas de comprendre le détail technique. Il est de savoir si quelqu’un, chez son hébergeur et chez son prestataire, a la responsabilité claire de suivre ce type d’alerte, et si cette responsabilité est écrite quelque part. Nous vous proposons ici une lecture sobre de l’information, puis une liste de questions à poser.

Ce que dit l’actualité, en termes simples

Commençons par ce que nous savons, et seulement cela. La source décrit une faille jugée critique, située dans EDK2, un composant lié au firmware UEFI. Le firmware est le logiciel de base d’un serveur: celui qui s’exécute au démarrage de la machine, avant le système d’exploitation, avant le serveur web, avant le CMS, avant tout code applicatif.

La faille permettrait l’exécution de code à ce stade précoce du démarrage. Autrement dit, un attaquant qui parviendrait à l’exploiter se placerait dans une zone qui précède les protections que l’on installe habituellement plus haut dans la chaîne. Le titre de l’article va jusqu’à écrire que la grande majorité des serveurs dans le monde seraient touchés.

Nous nous en tenons là. Le résumé dont nous disposons ne nous donne pas d’information fiable sur l’état des correctifs, sur les fabricants ou hébergeurs concernés, ni sur l’existence d’attaques en cours. Nous ne les inventerons pas, et nous vous invitons à vous méfier de tout commentaire qui affirmerait le contraire sans citer de source. La lecture de l’article d’origine reste le meilleur point de départ pour votre équipe technique.

Pourquoi cela concerne une entreprise établie

La plupart des organisations que nous accompagnons ont, au fil des années, empilé des sites, des applications métier, des outils de relation client, des espaces partenaires, des pages de campagne. Cet ensemble tourne quelque part: chez un hébergeur mutualisé, sur un serveur dédié, dans une offre cloud, parfois dans une salle technique interne. Quel que soit le choix, il existe un serveur physique ou virtualisé, et donc un firmware, derrière.

Le premier réflexe d’un décideur, face à une question de cybersécurité, est souvent de regarder la couche visible: le CMS est-il à jour, les extensions sont-elles maintenues, les accès sont-ils protégés par une double authentification. Ce sont des questions légitimes, et nous les posons systématiquement. Mais cette actualité illustre leur limite: on peut avoir un site parfaitement entretenu et reposer sur une infrastructure dont la couche basse n’est pas suivie avec la même rigueur.

Trois conséquences concrètes en découlent.

La responsabilité est souvent diffuse. Dans un projet web, plusieurs acteurs interviennent: l’agence qui conçoit et maintient le site, l’hébergeur qui fournit l’infrastructure, parfois un prestataire d’infogérance, parfois votre DSI. Chacun peut raisonnablement penser que le firmware est l’affaire d’un autre. Tant que personne n’a posé la question, la réponse peut être « personne ne le suit explicitement ».

Le niveau de contrôle dépend du type d’hébergement. Sur une offre mutualisée ou managée, le firmware relève en principe de votre hébergeur. Sur un serveur dédié que vous administrez ou faites administrer, la répartition des rôles peut être différente. Sur une infrastructure interne, vous en êtes directement responsable. Il est utile de savoir dans quel cas vous vous trouvez pour chaque service important, ce qui n’est pas toujours documenté.

Le risque est un risque d’activité, pas seulement un risque technique. Si un serveur est compromis à un niveau aussi bas, les conséquences possibles dépassent la page d’accueil: disponibilité des services, confidentialité des données de clients ou de prospects, confiance des partenaires. Nous ne prétendons pas mesurer ce risque pour votre cas, la source ne le permet pas. Nous disons simplement qu’il justifie une conversation de gouvernance, et pas seulement une ligne dans un ticket.

Ce qu’un dirigeant peut vérifier de son côté

Vous n’avez pas à devenir spécialiste du démarrage des serveurs. Vous avez en revanche à obtenir des réponses claires, idéalement écrites, à quelques questions simples.

Auprès de votre hébergeur

  • Qui, chez vous, surveille les alertes de sécurité touchant le firmware des serveurs, et selon quel processus?
  • Votre infrastructure est-elle concernée par cette faille, et si oui, que prévoyez-vous?
  • Quel est votre délai habituel entre la publication d’un correctif et son application sur les machines qui hébergent nos services?
  • Des interventions planifiées sont-elles à prévoir, et comment nous en informez-vous à l’avance?
  • Pouvez-vous nous fournir une trace de l’application des correctifs, par exemple dans un rapport périodique?

Un hébergeur sérieux a l’habitude de ces questions. La qualité et la précision de la réponse sont déjà une information en soi. Une réponse vague, ou un renvoi vers des conditions générales qui ne disent rien du sujet, doit vous alerter.

Auprès de votre agence

Votre agence n’est pas toujours responsable de l’infrastructure, mais elle doit pouvoir vous dire clairement où s’arrête son périmètre. Demandez-lui:

  • Quelle partie de la chaîne technique relève d’elle, et quelle partie relève de l’hébergeur ou d’un tiers?
  • Comment suit-elle les alertes de sécurité qui touchent l’infrastructure sur laquelle elle déploie vos projets?
  • Existe-t-il une procédure en cas d’alerte majeure, avec un interlocuteur identifié de chaque côté?
  • Le contrat de maintenance mentionne-t-il explicitement ce qui est couvert, et ce qui ne l’est pas?

Nous le disons sans détour: une agence qui promet de « tout gérer » sans préciser ses limites vous expose à un faux sentiment de sécurité. Mieux vaut un périmètre clair et assumé qu’une promesse floue.

En interne

Enfin, deux vérifications relèvent de vous. D’abord, disposer d’une cartographie simple de vos services critiques: où sont-ils hébergés, par qui, avec quel contrat. Ensuite, désigner une personne, au sein de votre direction ou de votre DSI, qui reçoit les réponses de vos prestataires et s’assure qu’elles sont suivies. Sans ce relais, les bonnes pratiques restent des intentions.

Ne pas confondre prudence et alarmisme

Une alerte de cette ampleur ne justifie ni la panique ni une refonte précipitée de votre infrastructure. Elle justifie une chose simple: vérifier que la chaîne de responsabilité fonctionne. Les failles de ce type seront corrigées, comme d’autres l’ont été. Ce qui fait la différence entre deux organisations, c’est la rapidité avec laquelle l’information circule et la clarté de qui décide quoi.

À l’inverse, il serait imprudent de conclure que « cela ne nous concerne pas parce que notre site est sur un CMS à jour ». La source rappelle précisément que le risque peut se situer avant même le démarrage du système sur lequel tourne votre site.

En résumé

La sécurité d’un site ou d’un outil en ligne ne s’arrête pas au code ni au CMS. Elle dépend aussi de couches plus basses, que l’on ne voit jamais, mais dont quelqu’un doit avoir la charge. L’actualité du jour est une bonne occasion de poser les questions que l’on remet souvent à plus tard: qui suit les correctifs, à quel rythme, avec quelle preuve, et qui vous prévient.

Si vous souhaitez faire le point sur la répartition des responsabilités entre votre hébergeur, votre agence et vos équipes, ou clarifier ce qui est couvert par vos contrats actuels, discutons de votre projet.


Image: Ann H via Pexels.

Besoin d'aide pour votre projet ?

Discutons de vos objectifs et voyons comment nous pouvons vous accompagner.

Réserver un appel gratuit
Partager :
Harry Porcu, fondateur de Hezign
Harry Porcu Fondateur de Hezign

Développeur web et consultant SEO à Lyon, Harry accompagne les entreprises dans leur croissance digitale depuis plus de 8 ans : création de sites, référencement et automatisation.

Suivre Harry sur LinkedIn

Un projet web ou SEO ?

Discutons de vos objectifs lors d'un appel découverte gratuit de 20 minutes.