Transparence et réactivité : nos bonnes pratiques pour la sécurité de vos systèmes

Nous sommes de plus en plus fréquemment interrogés sur des alertes CVE qui inquiètent nos clients.

Avec un contexte international tendu, la sécurité des systèmes informatiques est encore plus soumise aux tentatives d'intrusion, de DDoS, ou de vol de données qui contribuent à accentuer la pression (cf dans la même semaine le Piratage de France Travail et la tentative de DDoS sur le réseau interministériel de l'État).

C'est positif que nos clients soient sensibles à ces questions pour leurs applications, et ce n'est pas pour rien qu'ils sollicitent notre expertise sur cet aspect stratégique de leur infrastructure.

C'est aussi l'occasion pour nous de présenter nos pratiques de gestion de sécurité, qui sont au coeur de nos préoccupations pour votre tranquillité.

La transparence, garantie de sécurité

Il n'y a rien de pire pour un système informatique qui est exposé publiquement sur Internet que de ne pas être mis à jour en continu.

Tous les services qui contribuent au bon fonctionnement de l'environnement d'exploitation des machines mises à disposition par Bearstech sont scrutés en permanence par nos outils afin d'identifier les mises à jours disponibles. Dès qu'elles le sont, elles sont appliquées, selon la criticité des projets.

A la différence d'offres de service de grands clouds que nous ne citerons pas, selon les besoins de nos clients nous pouvons nous engager formellement dans des délais précis et contractuels à implémenter non seulement les mises à jour majeures et mineures et surtout les CVE.

On se trompe peut-être, mais nous n'avons trouvé nulle part dans les grands clouds, d'engagement de résultat sur des délais exacts en nombre de jours.

Chez Bearstech il nous est possible de procéder à l’installation des mises à jour de sécurité quotidiennement, voire plusieurs fois par jour (y compris les week-end et jours fériés), sur des services dont nous avons la responsabilité.

Ces mises à jour sont effectuées selon leur degré d'importance:

• Hautement critique - Vulnérabilité dont la mise en œuvre est triviale ou pourrait avoir un fort impact de compromission. Bearstech peut s’engager à déployer les correctifs dès que ces derniers sont disponibles, jusqu'à un délai d'un jour ouvré.
• Critique - Vulnérabilité dont la mise en œuvre pourrait compromettre le système en termes de confidentialité, intégrité ou disponibilité. Bearstech peut s’engager à déployer les correctifs dès que ces derniers sont disponibles, jusqu'à un délai d'un jour ouvré.
• Standard - Vulnérabilité dont la mise en œuvre est largement atténuée par des facteurs tels la configuration par défaut ou la non exploitabilité à distance. Bearstech peut s’engager à déployer les correctifs dès que ces derniers sont disponibles, jusqu'à un délai d'un jour ouvré.

Ainsi, il n'est pas nécessaire de nous demander de mettre à jour tel ou tel service : ils sont à jour selon les engagements pris, tant que la distribution de Debian qui est déployée sur votre serveur est couverte par le "Long Time Support".

Mises à jour en continu : OS, release et versions

Attention aux faux positifs de vos tests de sécurité !

Chez Bearstech, un nombre de fois très important chaque année, nous recevons des demandes de mise à jour de sécurité, des alertes de clients inquiets pour la sécurité de leurs services parce que nous aurions des versions vulnérables de paquets.

Nous allons essayer ici d'expliquer le plus clairement possible ce marronier de notre métier :

• La politique de mise à jour consiste à déployer les logiciels avec le patch de sécurité appliqué par les mises à jour de sécurité
• Les patchs de sécurité mis en oeuvre ne vont pas modifier le numéro de version
• Souci : les scanners de vulnérabilités se basant uniquement sur les versions intermédiaires (par exemple : 2.4 et non 2.4.56) vont analyser un paquet pourtant à jour comme étant vulnérable, générant ainsi des faux positifs en ignorant le niveau de patch appliqué au logiciel analysé.

Exemple de CVE récentes concernant Apache :

• la CVE-2022-28615, concerne les versions d'Apache HTTP Server 2.4.53 et précédentes, celles-ci sont donc bien vulnérables.
• suite à un rapport d'un scanner automatique, un client nous a alerté que ses services n'étaient pas à jour en postant la CVE dans un ticket
• or nous avions effectué les mises à jour requises : avec le paquet 2.4.56-1~deb11u2, on voit donc bien que l'alerte du scanner était un faux positif
• conclusion : pensez bien à consulter la version de vos paquets avant de nous alerter

Même si nous suivons quotidiennement les notifications officielles des éditeurs de logiciels, dans les faits nous pouvons garantir que les paquets sont mis à jour sur les machines que nous infogérons quelques heures après leur mise à disposition par l'éditeur.

Lorsque nous mettons à disposition des services pour un client, nous nous entendons avec lui sur la version nécessaire au bon fonctionnement de ses applications.

Par exemple, si l'OS repose la version 11 de Debian (Bullseye), alors les versions de PHP, Apache, MariaDB ... vont en dépendre directement. Concernant Apache pour Debian 11, Apache vient avec la version 2.4.56. Mais le jeu de patches de sécurité qui vont être ajoutés à cette version stable va évoluer au cours du temps, selon les bugs remontés ou les corrections de CVE détectées jusqu'à la fin du support (LTS Bullseye : 30/06/2026).

Fil de sécurité

Bearstech suit les listes de diffusion telles que Debian Security (qui diffuse typiquement les correctifs quelques heures avant les publications officielles du CERT); à la lecture des notifications, une action rapide est effectuée si nécessaire.

En amont, Bearstech utilise des méthodes de suivi de versions et de déploiement pour contrôler les versions des logiciels installés ainsi que le niveau des mises à jour de sécurité appliquées.

Nous disposons également d'outils d’alerting et d’un référent dédié à la sécurité :

• un aggrégateur de flux RSS (CVE, alertes de la distribution Debian, alertes des serveurs BDD et noSQL en production, alertes des frameworks populaires, etc.) auquel tous les administrateurs système et réseaux de Bearstech sont abonnés. Nous prenons soin à posséder au moins un flux pour chaque service infogéré.
• un scanner automatique et régulier de versions des logiciels installés par nos clients, ces versions étant croisées par l’état des logiciels tels que publié à la source (mises à jour disponibles, failles de sécurité connues). Ces données sont en particulier mises à disposition des clients pour responsabiliser leurs équipes de TMA.
• Bearstech dispose en outre d’un référent sécurité assurant une veille continue sur les outils déployés dans notre parc. En cas d’alerte concernant notre infrastructure comme celle d’un client, ce dernier peut, dans le cadre d’une levée de doutes, mener un audit interne des outils concernés afin d’apporter plus d’informations pour décider de mesures adaptées. Chaque collaborateur concerné doit répondre aux demandes du référent sécurité.

NB : Il est important de préciser que ce périmètre de sécurité s’applique au système d’exploitation et non au logiciel déployé par le client (comme un CMS). Dans ce cas Bearstech interviendra à la demande du client pour appliquer un correctif si nécessaire.

Synthèse des actions de sécurisation

Du fait de leur quantité, nous ne pouvons pas communiquer à chaque intervention de mise à jour de sécurité ou sur l'application des patchs de CVE. Il n'existe pas de semaine sans que nous ne déployions de patches de sécurité. Il y a même des semaines où chaque jour voit son patch de sécurité à appliquer.

Nos clients peuvent donc retrouver une synthèse de toutes ces actions sur un dashboard dédié que nous mettons à leur disposition. Il récapitule les mises à jour et leur nombre. L'histogramme ci-dessous montre leur fréquence sur une année.

Une frise chronologique détaille par jour les CVE concernées par les mises à jour, où l'on voit par exemple que la CVE-2023-0030 critique au niveau du Kernel Linux, a bien été mise à jour le 12/02/2024.

Nous envoyons aussi à nos clients des rapports mensuels qui leur indique une synthèse de l'application des mises à jours et correctifs :

La sécurisation des systèmes informatiques fait partie intégrante de notre métier depuis plus de 20 ans, vous pouvez donc nous faire confiance.

"ça va flooder"

Comme l'explique cet article de Jonathan Corbet, le système des CVE (Common Vulnerabilities and Exposures) qui existe depuis 1999 sous la forme d'un catalogue centralisé pour référencer les vulnérabilités est devenu au fil des années un moyen pour les développeurs d'accéler la livraison de leurs correctifs. Les numéros CVE sont devenus une cible à part entière, et de nombreux projets ont essayé de contrôler la manière dont les numéros CVE sont attribués à leur code. Afin de pouvoir endiguer cette dérive de publication de CVE pour des vulnérabilités qui n'en sont pas vraiment, le projet de noyau Linux a annoncé qu'il prenait également le contrôle de l'attribution des numéros CVE en devenant CNA (Autorité de numérotation des CVE). C'est aussi le cas pour de nombreux autres projet : cURL, PostgreSQL, GNU C Library, Apache, Docker, Kubernetes, Python ... Mais dans le cas du noyau Linux, l'équipe d'affectation CVE est très prudente et attribue des numéros CVE à tout correctif de bug qu'elle identifie. Cela explique le nombre apparemment important de CVE émis par l'équipe du noyau Linux. Ainsi, tout ce qui ressemble à une correction de bug se verra attribuer un numéro CVE, et de nombreux numéros CVE seront donc attribués au noyau dans les années à venir.

Plus que jamais, il est donc important pour les environnements de production de rester à jour sur un noyau stable.

C'est ce à quoi Bearstech travaille depuis plus de 20 ans pour que vous puissiez disposer d'un environnement qui repose sur un système et des librairies maintenues à jour en permanence, et donc sécurisées.