Avant que LogTotal n’exécute une quelconque logique de détection sur un texte brut, un fichier CSV ou une upload JSON, il remplace les valeurs identifiantes par des espaces réservés : noms d’utilisateur, noms d’hôte, adresses IP et similaires. Il vous montre ensuite le résultat à examiner avant que l’analyse ne commence. Les fichiers téléchargés ne sont pas conservés après l’analyse. Les fichiers EVTX sont l’exception pour l’instant : ils sont analysés tels qu’ils sont téléchargés, sans l’étape de sanitation.
L’objection à l’analyse de logs en ligne est justifiée. Les logs sont pleins de noms internes, d’adresses et parfois de choses que personne ne voulait enregistrer. Cette page explique ce que LogTotal masque, ce qu’il laisse volontairement inchangé, et ce que vous devriez encore vérifier vous-même.
Ce qui reste inchangé, et pourquoi
La logique de détection analyse le comportement, pas les noms. Pour repérer un password spray ou une charge utile PowerShell encodée, les règles ont besoin d’IDs d’événements, de noms de processus et de fichiers, de la structure d’une ligne de commande, des ports, des protocoles et des horodatages. Masquer ceux-ci aveuglerait l’analyse sans réellement protéger quoi que ce soit.
Même valeur, même espace réservé
Le masquage ne fonctionne pour l’investigation que s’il est cohérent. Si jane.doe devient user_1 à chaque ligne, vous pouvez toujours voir que user_1 a échoué à 40 connexions depuis une adresse et a ensuite réussi. Si chaque nom d’utilisateur devenait une chaîne aléatoire différente, ce schéma disparaîtrait. Des espaces réservés cohérents conservent l’intégrité de l’histoire tout en écartant les noms.
Votre rôle : vérifiez avant de continuer
Le masquage automatique capture les formes courantes. Il ne peut pas connaître votre environnement. Avant de passer l’étape de sanitation, vérifiez :
- les secrets dans les messages en texte libre, tels que les mots de passe tapés dans les lignes de commande ou les clés API dans les messages d’erreur ;
- les champs personnalisés qui contiennent des noms, tels que ticket_owner ou approved_by ;
- les noms de projet ou client cachés dans les noms d’hôte ou les chemins d’accès ;
- les données personnelles dans les URLs et les chaînes de requête.
Si vous repérez quelque chose, nettoyez-le dans le fichier avant de le télécharger. Une commande sed en une ligne traite la plupart des cas :
sed -E 's/(password|token|apikey)=[^&[:space:]]+/1=REDACTED/Ig' in.log > clean.log
EVTX : pas encore assaini
Les fichiers EVTX sont analysés tels qu’ils sont téléchargés, sans l’étape de sanitation. Utilisez les uploads EVTX librement pour les machines de test. Pour les hôtes de production, obtenez l’approbation de la personne responsable de la gestion des données en premier. Si vous avez besoin de sanitation aujourd’hui, convertissez le fichier en lignes JSON avec l’outil open-source evtx_dump et téléchargez-le :
evtx_dump -o jsonl Security.evtx > Security.jsonl
FAQ
La sanitation rend-elle mes logs anonymes selon le RGPD ?
Pas nécessairement. Les espaces réservés cohérents sont une pseudonymisation, et les données pseudonymisées peuvent toujours être considérées comme des données personnelles selon le RGPD. Ce n’est pas une raison pour ne pas utiliser l’outil, mais c’est une raison de suivre les règles de protection des données de votre organisation. En cas de doute, consultez votre DPO. Ceci n’est pas un conseil juridique.