Qui n’a pas son homologation RGS ? Dans son dernier « retour d’expérience », le CERT-FR n’en dit mot. Il rappelle néanmoins que la démarche est obligatoire pour toutes les entités publiques…

En fait de retex, il s’agit plutôt d’une liste de préconisations agrémentée de quelques constats de terrain. Sujet : les violations de données dans le contexte d’applications web. Les bonnes combinaisons pour chiffrer les disques Le CERT-FR évoque le cas du fournisseur d’une solution de télétransmission de données médicales.

Celui-ci a, en conséquence d’une erreur lors d’une intervention de maintenance sur un serveur, exposé des données de patients sur les sites qu’il concevait. Lire aussi : DGFiP : les six failles que l’ANSSI invite à corriger après le scraping Cet exemple introduit une série de recommandations en matière de politique de gestion des données. Le CERT-FR conseille entre autres de protéger les supports de stockage contre l’extraction, y compris après usage.

Moyen suggéré : le chiffrement systématique par une clé gérée dans des composants cryptographiques matériels ou par un serveur de clé. Sur Linux, on associera typiquement Clevis à LUKS pour lier le disque au TPM, avec un serveur Tang pour le déverrouillage à distance. Sous Windows, on combinera BitLocker au service Network Unlock.

Penser aux restrictions basées sur les en-têtes Dans plusieurs incidents, le CERT-FR a relevé l’usage d’adresses IP publiques à l’intérieur d’infrastructures applicatives. Il n’y a pas de risque tant que les routages sont strictement segmentés. Mais cela complique l’interprétation des flux observés, en plus d’aggraver toute erreur de configuration des protocoles de routage et de provoquer des erreurs dans certains produits de sécurité informatique qui font des inférences sur la base des sous-réseaux IP utilisés.

Aussi, on respectera les plans d’adressage de la RFC 1918, qui définit les plages IPv4 réservées pour les réseaux privés. Pour limiter l’exposition des applications, le CERT-FR invite aussi à préférer distinguer les services par nom d’hôte que par chemin. Par exemple, privilégier hxxps://admin.example.com à hxxps://www.example.com/admin.

Motif : cela permet d’exercer plus facilement des politiques de filtrage différentes, tout en minimisant à la fois les risques d’exposition croisée sur les services portant le routage d’URL et les partages de données implicites dans le navigateur. Autre recommandation : configurer les applications qui manipulent les flux HTTP pour qu'elles incluent, dans les en-têtes, de quoi garder l'origine de la connexion. On utilisera par exemple le champ X-Forwarded-For.

En parallèle, on intégrera l'adresse IP dans les journaux des pare-feu, VPN et équipements périmétriques, par exemple avec le champ remoteip. Au niveau des applications, on peut compléter le filtrage par adresse IP avec des restrictions basées sur les en-têtes. De nombreux attaquants y laissent des valeurs marquantes, explique le CERT-FR.

Et de donner l'exemple d'un compte utilisateur effectuant une connexion valide avec un user-agent caractéristique d'une bibliothèque Python. C'est un indicateur que ses identifiants sont potentiellement compromis. Surveiller le standard DBSC pour la protection des cookies de session Pas de retour terrain à proprement parler pour ce qui est de l'authentification.

Mais un rappel : le W3C travaille sur le standard DBSC (Device Bound Session Credentials), destiné à luttter contre le vol de cookies et le piratage de sessions. Dans les grandes lignes, le navigateur génère une paire de clés stockée dans le TPM et prouve régulièrement la possession de la clé privée pour renouveler les cookies en arrière-plan. Les cookies, éphémères, ne peuvent être rafraîchis sur une autre machine, sauf si on parvient à extraire ladite clé privée.

Lire aussi : La DGFiP... et bien d'autres : un été riche en vols de données dans le secteur public Pour le moment, parmi les principaux navigateurs, seul Chrome gère DBSC. L'adoption du standard exige une légère évolution de la négociation dans les applications (gestion de la cinématique Secure Station Registration). Dans les architectures web modernes, cela se fait souvent au niveau de l'IDP.

Ne pas oublier l'option zero trust Appelant à dépasser le couple login / mot de passe, le CERT-FR propose, entre autres, des mesures de transition pour les utilisateurs internes des applications. Il part du principe que tous les facteurs d'authentification qu'on doit saisir à la main sont vulnérables au phishing. Solution proposée : déployer bi-clés et certificats TLS dans les navigateurs des postes clients à protéger.

Une méthode cryptographiquement forte, mais qui ne résiste pas aux infostealers capables d'extraire les certificats et leurs clés privées non protégées par du matériel de sécurité. Les mesures traditionnelles de protection des cookies de session (marquage en http_only et secure, chiffrement strict des communications par TLS) ne protègent pas non plus des infostealers, ajoute le CERT-FR. D'où la référence à DBSC.

Même si, en attendant que ce standard se diffuse, on peut jouer sur le délai d'expiration des sessions, en y associant des mesures qui facilitent la reconnexion rapide, comme les passkeys. Ou choisir l'option zero trust : « lier la session à ses conditions d'utilisation », pour reprendre les mots du CERT-FR. En n'oubliant pas, dans ce cas, les usagers mobiles, dont l'adresse IP peut changer fréquemment.

Adopter une journalisation UNIX à la milliseconde Le CERT-FR dit rencontrer souvent des configurations de serveurs de journaux UNIX qui stockent les horodatages sans date et ont une précision limitée à la seconde. Il recommande d'adopter un format de flux conforme au protocole Syslog (RFC 5424) et une précision à la milliseconde. Ainsi que d'avoir une source de temps commune sur tous les équipements qui émettent des journaux et des événements.

Et d'harmoniser le fuseau horaire des enregistrements (GMT conseillé). Autres configurations souvent rencontrées : des logs applicatifs qui perdent l'information d'adresse IP source. Les connexions semblent alors toujours provenir de l'équipement frontal.

Sur ces derniers, on utilisera donc, comme au niveau des applications, les en-têtes HTTP (champs X-Forwarded-For, Forwarded, X-Real-IP...). Des interfaces réseau aux services d'administration, désactiver ce qui n'est pas utilisé Le CERT-FR explique avoir souvent observé des services destinés à un usage local mais configurés pour écouter sur toutes les interfaces réseau du système. Il recommande d'éviter cette pratique.

Et conseille, en complément, de désactiver les services d'administration et de supervision non utilisés dans les applications et dans le socle système. Par exemple SNMP, actif sur beaucoup d'équipements. Sur l'interdiction des flux d'Internet vers les consoles d'administration, le CERT-FR s'arrête sur les services qui ne sont distingués de la production que par un chemin (par exemple, « /admin »).

Il suggère de les bloquer au niveau du WAF ou du proxy inverse. Refléter la logique applicative dans la structure des requêtes Pour définir les seuils de détection d'anomalies, on discutera idéalement avec les métiers. Et face à des attaquants qui travaillent sur des durées longues, on prévoira des seuils cumulatifs.

Le CERT-FR attire l'attention sur le paramétrage de blocages et de bridages dans le WAF. Il est des seuils faciles à définir, comme ceux basés sur la quantité de données par session ou la source de connexion. Mais pour des règles plus fines (par exemple, qui corrèlent les groupes d'utilisateurs avec les accès aux objets), la logique applicative doit être reflétée dans la structure des requêtes.

Dans la négative, l'analyse est plus complexe. Les frontaux peuvent même devenir des causes de déni de service. Illustration © Frenchiebuddha - Adobe Stock