Combien de temps SRUM conserve-t-il les données ? Rétention et réglages registre

La rétention SRUM n'est pas "30 jours" ou "60 jours", c'est ce que la machine possède réellement, fonction de la politique d'élagage, du volume d'activité, et de l'éventuelle désactivation du service. La première chose à faire sur toute affaire où SRUM compte est de vérifier la fenêtre réelle, pas la supposer.

La réponse pratique

• Tables court-terme (Application Resource Use, Network Data Usage, Network Connectivity, Energy Usage, Push Notifications) : environ 30 jours de lignes par seau horaire.
• Tables long-terme (les jumelles {…}LT) : jusqu'à environ un an, agrégées par semaine.

Aucun chiffre n'est une garantie ferme. La rétention émerge de l'élagage par âge plus du volume de lignes.

Ce qui la gouverne

Il n'y a pas de case unique "garder SRUM N jours". La rétention est contrôlée par plusieurs pièces mobiles :

1. Le Diagnostic Policy Service (DPS). Planifie le vidage périodique : toutes les heures par défaut, toutes les ~10 secondes lors d'un changement d'état d'alimentation. Arrêter DPS stoppe les nouveaux échantillons.
2. Le registre d'extension SRUM. HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SRUM\Extensions liste chaque extension nommée par GUID et ses paramètres.
3. Passes d'élagage. Les vieilles lignes court-terme sont retirées à mesure que la base est maintenue ; les tables LT reçoivent des agrégations roulées avant que les originaux ne soient élagués.
4. Taille de base. ESE a ses propres seuils d'élagage quand le fichier dépasse les tailles attendues.

Ce que cela signifie pour une investigation

• Un incident plus ancien que ~30 jours ne survit probablement que dans les tables LT. Attendez-vous à des agrégats hebdomadaires, pas à du détail horaire. Vérifiez à la fois court-terme et LT pour le même préfixe de GUID.
• Un trou dans la séquence TimeStamp où vous attendriez de l'activité est en soi une preuve : le service a été arrêté, la machine était éteinte, ou quelqu'un a altéré la base. Recoupez avec les événements d'état d'alimentation d'Energy Usage et les événements de service EVTX (Microsoft-Windows-Diagnosis-DPS/Operational).
• Ne sur-revendiquez pas la précision. Une session de 30 minutes peut apparaître comme un seul seau horaire. Voir utiliser SRUM dans une investigation forensique pour les réserves sur la résolution.

Vérifier la rétention sur un échantillon

Ne croyez pas la FAQ, lisez la base. Dans n'importe quel analyseur :

1. Ouvrez Application Resource Use.
2. Triez par TimeStamp croissant. Lisez la ligne la plus ancienne.
3. Triez décroissant. Lisez la ligne la plus récente.
4. Cet intervalle est la fenêtre court-terme réelle pour cet hôte.

Répétez sur la jumelle LT pour la fenêtre long-terme.

Un poste de bureau typique affiche 28-32 jours en court-terme et 8-11 mois en LT. Un portable éteint pendant des semaines affichera moins de jours de couverture court-terme même si la base s'étale plus longtemps.

Manipulation et écarts

Un adversaire privilégié peut :

• Arrêter DPS pour stopper l'échantillonnage. EVTX Microsoft-Windows-Diagnosis-DPS enregistre souvent l'arrêt.
• Supprimer SRUDB.dat. Le fichier réapparaîtra au prochain démarrage du service mais avec un historique vide. L'entrée MFT enregistre la recréation.
• Supprimer des lignes de façon sélective. Plus difficile ; nécessite d'ouvrir la base ESE directement. Détectable par des trous dans la continuité de TimeStamp face au temps de fonctionnement attendu.

Le geste adversarial le plus courant est le paresseux : arrêter DPS, faire le travail, redémarrer DPS. L'écart apparaît comme un trou dans la chronologie Application Resource Use, à comparer à la même fenêtre dans Energy Usage (qui enregistre les événements secteur indépendamment de l'activité processus, jusqu'à ce que le service ne soit plus là).

Pour aller plus loin

• Qu'est-ce que SRUM et pourquoi cela intéresse les analystes forensiques
• Tables SRUM expliquées
• Comment réparer un SRUDB.dat corrompu