Failles sur les équipements de sécurité : le retex du CERT-FR
Le CERT-FR revient sur les failles dans équipements de sécurité présents notamment en bordure de réseau et livre quelques conseils.
Quel point commun entre les articles 12 de la directive NIS 2, L.2321-4-1 du Code de la défense et 56 du Cybersecurity Act ? Tous créent des obligations à la charge des éditeurs en matière de gestion des vulnérabilités.
Le CERT-FR les mentionne dans le cadre d’un retour d’expérience relatif aux failles sur les équipements de sécurité (pare-feu, NAC, bastions, NIDS/NIPS…). Il en met une dizaine en avant, dévoilées entre juin 2023 et mai 2024. Parmi elles, une que l’ANSSI a listée comme « particulièrement marquante » dans son dernier panorama de la menace cyber. Elle ouvre la voie à l’exécution de code à distance sur des produits Fortinet avec fonctionnalité de VPN SSL activée.
Il arrive que l’implémentation des fonctionnalités de sécurité au sein de ces équipements se fonde sur des pratiques dépassées. Par exemple, l’absence de cloisonnement logique entre fonctions. Ou l’utilisation d’architectures et de frameworks web obsolètes.
Autre risque : les intégrations sur lesquelles reposent ces équipements. Par exemple avec AD pour la configuration dynamique et automatisée en fonction des utilisateurs du SI. Une situation qui peut se révéler dangereuse lorsqu’elle impose l’octroi de droits privilégiés sur des contrôleurs de domaine. Ou lorsqu’elle en hérite en raison d’une mauvaise procédure d’installation.
Le CERT-FR souligne aussi la tendance de ces équipements à fonctionner en boîte noire. Pas de mécanismes de contrôle d’intégrité fiable, de relevé de l’état de la mémoire et du système… et fréquemment, un export partiel – voire inexistant – des journaux.
De la NIS 2 au Cybersecurity Act, des évolutions réglementaires
Dans la mesure du possible, on utilisera des solutions certifiées CSPN ou critères communs.
On s’assurera que les équipements en question :
– Ne disposent pas de droits privilégiés au sein des annuaires AD ou OpenLDAP (ou pouvant aboutir à l’exécution de code arbitraire sur des serveurs sensibles)
– Sont toujours maintenus par le constructeur ou l’éditeur
Lire aussi : L'IA et l'IA générative devraient transformer la cybersécurité de la plupart des organisations
– Ont des interfaces réseau dédiées à leur administration et protégées par MFA
– Sont dédiés chacun à une fonctionnalité dans la mesure du possible et sans compromettre le MCO/MCS
Le CERT-FR recommande par ailleurs de mettre en œuvre un déport automatisé des journaux. Et d’intégrer leur export dans la supervision de sécurité de l’organisation.
L’article 12 de la directive NIS 2 établit un mécanisme de divulgation coordonnée des vulnérabilités. Dans chaque État membre, un CSIRT facilite les interactions entre qui signale des vulnérabilités et les fabricants ou les fournisseurs des produits/services potentiellement vulnérables. |
L’article 56 du Cybersecurity Act, en son alinéa 8, impose aux titulaires de certificats de cybersécurité européens d’informer les autorités de toute vulnérabilité ou irrégularité détectée ultérieurement. |
Selon l’article L.2321-4-1 du Code de la défense, les éditeurs de logiciels notifient à l’ANSSI les vulnérabilités significatives affectant leurs produits. Ainsi que l’analyse des causes et des conséquences. |
La proposition de règlement européen sur la cyberrésilience comporte des « obligations incombant aux fabricants » (article 10). Entre autres, veiller à une gestion efficace des vulnérabilités pendant la durée de vie prévue des produits ou pendant 5 ans à compter de leur mise sur le marché (la plus courte des deux durées). |
Illustration © Mopic – Shutterstock
Sur le même thème
Voir tous les articles Cybersécurité