Journaux de sécurité : introduction, lecture et limites

Niveau : débutant.

Prérequis : connaître les notions de compte, adresse IP, serveur, application et requête HTTP. Savoir créer un fichier texte suffit. Aucun SIEM n’est nécessaire.

L’exercice utilise uniquement des événements fictifs locaux, sans collecte tierce.

Un événement décrit un fait enregistré à un instant donné : connexion réussie, requête HTTP, arrêt de service ou accès refusé. Il peut être banal, utile au diagnostic ou pertinent pour la sécurité. Le terme ne signifie pas qu’une attaque a eu lieu.

Un journal rassemble des événements dans un fichier, le journal Windows, journald, une base ou un flux syslog. Plusieurs journaux peuvent montrer des facettes différentes d’une même action. Une alerte résulte ensuite d’une règle ou d’une analyse qui sélectionne certains événements. Cinq échecs suivis d’une réussite méritent une enquête, mais ne prouvent pas un vol de compte.

Le NIST SP 800-92 présente la gestion des journaux comme un cycle de génération, transmission, stockage, analyse et élimination. Pour rester rigoureux, sépare toujours le fait observé, la condition qui l’a sélectionné et l’hypothèse à vérifier.

Cherche d’abord quand, où, qui, quoi, sur quelle cible et avec quel résultat. Un événement exploitable contient souvent un horodatage, une source, un compte ou processus, une action, une ressource, un statut et parfois une adresse IP ou un identifiant de requête. Lis aussi le message brut : un parseur peut mal classer un compte technique, et un code HTTP 200 ne garantit pas le succès métier.

Note le fuseau, le suffixe Z pour UTC, la précision et l’état de l’horloge. Distingue l’heure de création de l’heure de réception. Un agent arrêté ou une file réseau crée du retard ; deux hôtes désynchronisés peuvent inverser l’ordre apparent.

La RFC 5424 sépare notamment horodatage, hôte, application, processus et message. Tous les journaux ne suivent pas ce standard, mais cette structure forme une bonne grille de lecture. Conserve la valeur originale et documente toute conversion temporelle.

La collecte transporte les événements par agent, syslog, API ou collecteur. Surveille les dernières réceptions, les retards, les erreurs et les variations de volume : voir des données aujourd’hui ne prouve pas que chaque source attendue fonctionne.

La normalisation rapproche des champs comme src_ip, client.address et remote_addr. Elle facilite les recherches, mais un parseur peut perdre une nuance après une mise à jour. Garde le message brut et la version du parseur.

La corrélation relie plusieurs événements par compte, adresse, machine, session ou identifiant de requête dans une fenêtre définie. Une IP partagée derrière un proxy ne représente pas forcément une personne ; choisis donc plusieurs pivots.

Les bonnes pratiques de la CISA sur la journalisation et la détection recommandent une stratégie cohérente et des événements utiles à la détection. Pars d’une question d’analyse, puis choisis les sources capables d’y répondre. Tout collecter sans finalité augmente bruit, coût et exposition de données sensibles.

Sous Windows, les journaux Application, System et Security associent fournisseur, identifiant, niveau, ordinateur et date. Security dépend de la stratégie d’audit. Un événement absent peut refléter une action inexistante, un audit désactivé, un journal écrasé ou une collecte rompue. Les événements Windows à surveiller selon Microsoft donnent des repères, mais interprète toujours l’identifiant avec son fournisseur et ses champs.

Sous Linux, tu trouveras des fichiers dans /var/log, systemd-journald, syslog et les journaux applicatifs. Une ligne SSH peut montrer un échec, un compte et une IP sans identifier une personne. Les métadonnées de journalctl, comme l’unité et le processus, aident à borner la recherche.

Sur le Web, une trace contient souvent adresse cliente, méthode, chemin, statut et agent utilisateur. Derrière un reverse proxy, l’adresse vue peut être celle du proxy. Les paramètres d’URL peuvent aussi exposer des jetons ou données personnelles. Dans chaque environnement, vérifie ce qui est activé et ce que la source peut réellement observer.

Définis la durée de conservation selon les scénarios d’enquête, le délai de découverte, le coût, les obligations applicables et la sensibilité des champs. Une durée trop courte efface la chronologie ; une durée indéfinie accumule risques et coûts.

Pour l’intégrité, limite les droits d’écriture et de suppression, sépare si possible source et destination, protège le transport et surveille les ruptures. Une empreinte ou une signature aide seulement si les clés et la chaîne de traitement sont maîtrisées. Un logiciel compromis peut produire une trace trompeuse avant son transfert : l’intégrité du stockage ne garantit pas la vérité du contenu.

La minimisation évite de collecter mots de passe, jetons, secrets d’API, formulaires ou données personnelles inutiles. Masque les champs non nécessaires, restreins les consultations, journalise les accès et organise la suppression. Ces objectifs peuvent entrer en tension. Documente l’arbitrage par source et teste la restauration : une archive illisible ou inaccessible à l’équipe autorisée n’apporte aucune capacité réelle.

Suis une méthode reproductible :

1. Formule une question, par exemple si un compte a subi plusieurs échecs avant une réussite.
2. Borne le périmètre en notant systèmes, comptes, fuseaux et fenêtre horaire.
3. Vérifie les sources : producteur, collecte, champs absents, retard et conservation.
4. Préserve le brut et travaille sur une copie en documentant les transformations.
5. Filtre avec plusieurs pivots comme compte, session, hôte, IP et requête.
6. Construis la chronologie tout en conservant l’heure de réception et les incertitudes.
7. Sépare faits et hypothèses : trois échecs enregistrés sont un fait ; un mot de passe deviné est une hypothèse.
8. Cherche une explication concurrente, telle qu’une erreur de saisie ou un test autorisé.
9. Recoupe avec une autre source capable de confirmer ou contredire.
10. Qualifie la conclusion comme confirmée, probable, possible ou non déterminée.

Mentionne les filtres, sources et limites. Une interruption de collecte est une contrainte, jamais une preuve d’absence d’activité.

Crée auth-demo.log et colle ces lignes fictives :

2026-08-26T08:14:02Z host=lab-web user=lea action=login result=failure src=192.0.2.18 request=r-101
2026-08-26T08:14:31Z host=lab-web user=lea action=login result=failure src=192.0.2.18 request=r-102
2026-08-26T08:15:07Z host=lab-web user=sam action=login result=success src=192.0.2.44 request=r-103
2026-08-26T08:15:19Z host=lab-web user=lea action=login result=failure src=192.0.2.18 request=r-104
2026-08-26T08:16:03Z host=lab-web user=lea action=login result=success src=192.0.2.18 request=r-105
2026-08-26T08:17:40Z host=lab-web user=lea action=profile_read result=success src=192.0.2.18 request=r-106

Le bloc 192.0.2.0/24 est réservé à la documentation. Dans un éditeur local, relève les champs, confirme UTC grâce à Z, filtre lea et trie ses événements. Écris deux blocs : Faits observés et Hypothèses à vérifier. Ajoute les données manquantes, comme MFA, session et activité habituelle.

Critère observable

Tu dois isoler cinq événements pour lea : trois échecs, une réussite 2 minutes et 1 seconde après le premier échec, puis une lecture de profil. Exclus l’événement de sam, conserve r-101 à r-106 dans la copie complète et indique que ces traces seules ne prouvent aucune compromission.

• Prendre une alerte pour un verdict. Elle ouvre une enquête.
• Lire une ligne isolée. Élargis la fenêtre et compare les sources.
• Ignorer fuseaux et dérive d’horloge. La chronologie peut être fausse.
• Faire confiance au seul champ normalisé. Contrôle le brut et le parseur.
• Attribuer une IP à une personne. NAT, VPN, proxy et machine partagée fragilisent ce lien.
• Prendre une absence pour une preuve. Audit désactivé, rotation ou panne de collecte créent des angles morts.
• Conserver des secrets. Filtre jetons, mots de passe et paramètres sensibles.
• Modifier l’original. Travaille sur une copie et note chaque transformation.
• Collecter sans superviser. Mesure retards, volumes et erreurs de parsing.

Un journal décrit seulement ce que son producteur a enregistré. Il peut être partiel, erroné ou altéré. Une conclusion solide précise donc son périmètre, son degré de confiance, les données absentes et la prochaine vérification défensive.