Définis les besoins de télémétrie à partir des actifs, risques et contrôles

01Pars des décisions déjà prises

SORIA Distribution a déjà travaillé ses actifs, risques, baselines, accès privilégiés et contrôles. Tu ne recommences pas l’analyse de risques et tu ne réinstalles pas Loki.

Tu transformes un besoin de défense en exigence observable:

Actif critique      contrôleur de domaine
Risque              abus d'un compte privilégié
Contrôle préventif  séparation des comptes d'administration
Question sécurité   qui s'authentifie avec le compte privilégié, quand et où ?
Télémétrie attendue événements d'authentification Windows avec identité et horodatage fiables

La télémétrie n’est pas une fin. Elle sert une question.

02Crée le corpus de travail

lab=/tmp/soria-ir-lot1-$USER
bash module1-telemetry-timeline-qualification.sh setup "$lab"
bash module1-telemetry-timeline-qualification.sh status "$lab"

Tu obtiens exactement douze fichiers synthétiques. Observe les exigences:

column -s, -t "$lab/source/sources/coverage-requirements.csv"
column -s, -t "$lab/source/sources/source-catalog.csv"

Les exigences déclarent ce qu’il faut voir. Le catalogue déclare ce qui est représenté comme disponible.

03Mesure la couverture sans inventer une source

Exécute le traitement:

bash module1-telemetry-timeline-qualification.sh run "$lab"
column -s, -t "$lab/output/source-coverage.csv"

Quatre exigences sont couvertes. TEL-005 demande une source endpoint-edr, absente du catalogue.

Le résultat correct est:

TEL-005 ... GAP

Le résultat incorrect serait d’ajouter fictivement un agent EDR afin de rendre le tableau vert. L’absence de visibilité est une information de sécurité.

04Distingue observabilité et télémétrie de sécurité

L’observabilité publiée dans SORIA Académie t’a déjà appris à examiner métriques, logs et alertes pour comprendre un système.

Ici, une source devient exploitable pour la réponse à incident seulement si tu peux répondre à des questions comme:

• quel actif a émis l’événement ?
• quelle identité est concernée ?
• à quelle heure, avec quelle qualité d’horloge ?
• quel identifiant permet de retrouver l’original ?
• la source répond-elle à une exigence de sécurité précise ?
• quelle période est réellement couverte ?
• qu’est-ce qui reste invisible ?

Un dashboard utile à l’exploitation peut rester insuffisant pour une investigation.

05Conserve le lien avec le contrôle

Pour chaque exigence, complète mentalement cette chaîne:

mission → actif → risque/contrôle → question → source → champs → conservation → limite

Exemple:

order-processing
→ AST-IR-004
→ abus d'un rôle administrateur
→ qui a modifié le rôle ?
→ source application
→ timestamp + identity_id + event_kind + outcome
→ original préservé
→ aucune preuve d'un serveur réel dans ce lab

La chaîne permet aussi de supprimer une source inutile: si aucun besoin ne justifie un flux de données sensible et coûteux, « collecter au cas où » n’est pas automatiquement une bonne architecture.

06Ne transforme pas une déclaration en preuve

Le fichier source-catalog.csv contient SRC-WIN. Cela signifie seulement que le scénario synthétique représente cette source.

Cela ne prouve pas:

Advanced Audit Policy activée sur un vrai Windows
agent Wazuh installé
forwarder opérationnel
rétention garantie
horloge réellement synchronisée
événements complets

Pour prouver ces points, il faudrait observer les systèmes concernés et leurs chemins de collecte.

07Valide la décision du lot

bash module1-telemetry-timeline-qualification.sh validate "$lab"
cat "$lab/output/decision.txt"

La décision de référence est volontairement:

TELEMETRY_READY_WITH_ACTIONS

Le corpus est suffisamment cohérent pour poursuivre l’apprentissage, mais la lacune endpoint-edr reste visible.