Enrichissement d’URL dans le SOC : vérifier la destination réellement contactée
Une URL dans une alerte ne doit pas ouvrir le réseau interne à un outil d’enrichissement. Contrôlez destination, redirections, accès et preuves de refus.
Périmètre des intégrations : Seculogik utilise une architecture indépendante des sources pour ingérer les alertes et événements de sécurité via son propre modèle de données. Wazuh et OpenSearch sont les premières intégrations. Les autres sources citées correspondent à des connecteurs prévus ; leur disponibilité doit être confirmée pour chaque évaluation.
Une alerte contient un lien. Pour aider l’analyste, un outil propose d’en consulter le titre, les en-têtes ou une capture. L’intention est raisonnable, mais une nouvelle question apparaît : depuis quelle machine cette consultation part-elle, avec quels accès et vers quelle destination réelle ?
Le serveur qui enrichit une alerte peut disposer d’une connectivité différente de celle de l’analyste. Lui transmettre une URL non fiable ne doit pas lui donner mandat de contacter n’importe quel service. Ce guide propose des critères de réception pour cette fonction, qu’elle soit appelée par une automatisation, un analyste ou un assistant IA.
1. Définir le besoin avant d’autoriser une requête réseau
La faiblesse CWE-918 décrit une requête côté serveur dont la destination peut être influencée par une entrée externe sans contrôle suffisant. Elle est généralement appelée SSRF. Le risque concerne ici l’outil qui effectue la consultation, même si l’alerte contenant le lien n’a aucun droit d’administration. Source : MITRE CWE-918
Notre recommandation : préciser ce que l’enrichissement doit apporter. Rechercher la réputation d’un domaine auprès d’un fournisseur approuvé est différent de visiter directement une page inconnue. Dans le premier cas, la destination réseau peut rester un service connu ; dans le second, la fonction doit traiter une destination choisie par des données non fiables.
Commencez par le besoin le plus restreint. Si une information de réputation suffit, ne téléchargez pas la page par habitude. Faites aussi valider les données envoyées au fournisseur : une URL complète peut contenir un identifiant ou une valeur sensible. Le droit de lire une alerte ne vaut pas automatiquement autorisation de transmettre son contenu à un tiers.
2. Distinguer l’URL reçue de la connexion réellement effectuée
La fiche OWASP sur les SSRF recommande notamment de désactiver le suivi automatique des redirections et examine les risques liés à la résolution DNS. Un contrôle du texte initial ne suffit donc pas à décrire toutes les destinations qu’un client peut ensuite contacter. Source : OWASP
Nous recommandons de faire documenter le comportement du client utilisé : protocoles admis, ports, résolution des noms, redirections, proxy éventuel et conservation des informations d’authentification. Lorsque le besoin impose une redirection, chaque nouvelle destination doit faire l’objet de la politique prévue ; suivre le premier lien approuvé ne doit pas autoriser toute la chaîne.
Demandez également comment la décision de validation reste liée à la connexion. Si un composant vérifie une adresse puis qu’un autre résout de nouveau le nom sans appliquer les mêmes contraintes, le contrôle initial peut ne plus décrire la destination jointe. La preuve utile vient du chemin effectif, avec les résolutions et décisions observables, pas seulement d’une case « URL validée ».
3. Définir les destinations permises avec l’équipe réseau
Une règle limitée à quelques adresses privées courantes ne couvre pas toutes les situations. Les registres IANA distinguent plusieurs usages particuliers en IPv4 et en IPv6 ; leurs propriétés ne constituent pas à elles seules une politique d’autorisation applicative. Registre IPv4, registre IPv6.
Notre recommandation : expliciter les destinations autorisées pour ce composant et interdire les autres chemins selon le besoin. Incluez les adresses locales, les services de gestion, les réseaux internes et les destinations particulières pertinentes dans la revue. Vérifiez les deux familles IP, les différents formats acceptés et les flux passant par un proxy. Une résolution vers plusieurs adresses doit aussi avoir un comportement défini.
Le contrôle doit être vérifié depuis l’environnement réel d’exécution de l’outil. Un test effectué depuis le poste d’un développeur ne décrit pas les accès du service déployé. L’objectif est de limiter sa connectivité à ce que nécessite l’enrichissement, sans modifier les droits des analystes ni exposer davantage le réseau.
4. Séparer l’enrichissement des identités sensibles
Nous recommandons un composant de consultation qui ne transporte ni session d’administration, ni cookies métier, ni identifiants destinés à un autre service. Vérifiez aussi les en-têtes ajoutés par la configuration, les bibliothèques ou le proxy. Une destination nouvellement choisie ne doit pas hériter d’une authentification prévue pour une destination différente.
Dans un environnement cloud, examinez séparément l’accès au service de métadonnées. AWS documente IMDSv2 comme une méthode utilisant des sessions et permet d’imposer son usage à la place d’IMDSv1. Ce contrôle propre à EC2 ne constitue pas une garantie générale contre les SSRF ni un remplacement de la politique réseau de l’outil. Source : Amazon EC2
Bornez également le temps, le volume et le nombre de consultations autorisées par demande. Une réponse trop volumineuse ou une boucle ne doit pas immobiliser la file d’investigation. Définissez ce que le SOC verra en cas de refus, de délai ou de résultat tronqué : ces états doivent rester distincts d’un enrichissement achevé.
5. Tester les limites avec des destinations contrôlées
Notre recommandation : utiliser un environnement d’essai et des services dont les responsables ont autorisé les tests. N’envoyez pas des requêtes de démonstration vers les véritables services d’administration ou de métadonnées de production. Des destinations simulées suffisent pour vérifier le chemin de décision sans consulter leurs données.
Préparez au moins ces situations, avec un résultat attendu écrit avant chaque essai :
- Une destination approuvée répond normalement.
- Une destination interdite est refusée avant toute connexion.
- Une destination approuvée redirige vers une destination interdite.
- Un nom contrôlé change de résolution entre les étapes du traitement.
- La résolution fournit plusieurs adresses, dont une hors du périmètre permis.
- Le protocole ou le port n’est pas autorisé.
- Une réponse dépasse les limites prévues ou n’aboutit pas à temps.
Exemple entièrement fictif : un service d’essai autorisé renvoie une redirection vers un second service simulant une destination interdite. Le résultat attendu est un refus explicite, sans requête reçue par ce second service. Vérifiez les traces des deux côtés : un message « bloqué » dans l’interface ne prouve pas, seul, qu’aucune connexion n’a eu lieu.
Ajoutez un contrôle positif pour éviter un faux succès : si toutes les consultations échouent parce que l’outil est en panne, le refus apparent ne valide pas la protection. Vérifiez aussi que le refus ne déclenche pas automatiquement un autre outil disposant d’un accès plus large.
6. Conserver une preuve exploitable et revoir les changements
Pour chaque essai, conservez la version du composant, la politique appliquée, la destination de test, l’heure, la décision et les observations réseau nécessaires. Les traces de diagnostic ne devraient pas recopier sans limite les URL complètes, leurs paramètres ou les contenus reçus. Préservez la possibilité de retrouver les éléments autorisés sans multiplier les copies sensibles.
Après une modification du client HTTP, du proxy, du résolveur, du réseau ou des outils accessibles à l’assistant, rejouez les scénarios concernés. Le critère de réception est concret : expliquer quelle destination a été permise ou refusée, sur quelle base, et confirmer le chemin réellement emprunté. Une URL issue d’une alerte reste une donnée à examiner ; elle ne devient pas une autorisation réseau.