TL;DR. Ouvrez l'analyseur Okta Forensics, déposez votre export du System Log (JSON, JSON Lines, CSV, gzip, ZIP ou un dossier entier) et lisez le verdict : Aucun signe de compromission, Activité suspecte ou Compromission probable, avec les constats qui l'expliquent. Parcourez ensuite cinq onglets : Constats (ce qui s'est déclenché et sur quels événements), Chronologie de l'incident, Entités (utilisateurs, IP, sessions, facteurs, applications, admins), Tous les événements (filtrables, exportables) et Remédiation (une checklist classée par urgence). Rien n'est téléversé : l'analyseur est écrit en Rust compilé en WebAssembly et tourne dans votre navigateur.

Voici l'article « sur quel bouton appuyer ». Pour la méthode (quoi chercher et pourquoi), lisez d'abord le guide d'investigation d'une compromission Okta.

Avant de commencer

Il vous faut un export du System Log Okta. Le guide d'export présente les options ; en résumé : toute l'organisation, la période la plus longue possible, du JSON brut issu de l'API quand c'est possible.

Pas d'export sous la main ? Cliquez sur Essayer un exemple sur la page d'accueil. Cela charge un export synthétique d'un incident fictif (160 événements, organisation inventée, adresses IP des plages de documentation) pour apprendre l'interface sur un cas qui déclenche forcément des détections. La démonstration sur un incident fictif explique chacun des constats produits.

Étape 1 : charger les fichiers

Déposez les fichiers sur la zone prévue, ou utilisez Choisir des fichiers / Choisir un dossier. Formats acceptés :

Entrée	Remarques
Tableau JSON de `/api/v1/logs`	plusieurs pages dans un fichier, sans problème
JSON Lines, lignes préfixées syslog	un événement par ligne
Exports EventBridge, Elastic, Splunk	enveloppes `detail`, `_source`, `result` / `_raw` dépliées
CSV	en-têtes en chemins LogEvent (`actor.alternateId`, `target[0].displayName`…) ou colonne `_raw` ; séparateur virgule, point-virgule ou tabulation
`.gz`, `.zip`, dossiers	décompressés et parcourus dans le navigateur, ZIP imbriqués compris

Les fichiers sont lus par blocs de 4 Mo et transmis en flux à l'analyseur : les exports de plusieurs gigaoctets passent, la vraie limite étant la mémoire nécessaire aux événements eux-mêmes. Pour les très gros exports (au-delà de 200 000 événements), les détections tournent toujours sur tous les événements, mais le tableau affiche toutes les preuves plus les événements les plus récents.

Étape 2 : vérifier ce qui a réellement été lu

Avant de faire confiance à un verdict, ouvrez Fichiers analysés. Chaque fichier affiche son nombre d'événements, son format et sa taille, ainsi que des remarques : doublons supprimés, enregistrements qui ne sont pas des événements du System Log, JSON invalide, événements sans horodatage lisible, ou fichier qui s'arrête au milieu d'un événement (export tronqué). Fichiers non analysés explique chaque rejet : fichier vide, pas un journal Okta, un tableur au lieu d'un CSV, un gzip ou un ZIP endommagé.

Regardez ensuite la ligne de statistiques : événements, utilisateurs, adresses IP, sessions, et la Période (UTC). Si la période ne correspond pas à ce que vous avez exporté, arrêtez-vous et corrigez l'export.

Étape 3 : lire le verdict

La logique du verdict est volontairement simple et visible :

Verdict	Règle
Compromission probable	au moins un constat critique, ou des constats élevés issus de deux règles différentes
Activité suspecte	tout autre constat élevé ou moyen
Aucun signe de compromission	rien au-dessus de faible (les constats faibles sont informatifs)

Sous Pourquoi, les constats à l'origine du verdict sont listés. Un verdict propre signifie qu'aucune des 25 règles de détection ne s'est déclenchée sur ces événements. Ce n'est pas un certificat ; l'article sur les limites explique ce qui peut échapper.

Étape 4 : examiner les constats

Chaque carte de constat affiche une sévérité (critique, élevée, moyenne, faible), un badge aggravé quand une condition de suivi l'a relevée (par exemple une rafale de push suivie d'un push accepté), une phrase construite à partir des preuves, les horodatages de début et de fin, les utilisateurs et IP concernés, les techniques MITRE ATT&CK, et Voir les événements pour ouvrir les preuves dans le tableau des événements.

Chaque famille est expliquée dans son propre article :

Demandes MFA et réinitialisations : fatigue MFA, ingénierie sociale du helpdesk
Sessions : détournement de session
Administration et persistance : rôles et jetons d'API, fournisseurs d'identité
Attaques sur la connexion : password spraying

Quand une application sensible (AWS, Microsoft 365, Google Workspace, GitHub, plateformes Kubernetes…) a été ouverte après une activité suspecte, le constat renvoie vers l'outil frère qui lit les journaux de cette plateforme, par exemple AWS Forensics pour CloudTrail.

Étape 5 : parcourir la chronologie de l'incident

L'onglet Chronologie de l'incident ordonne dans le temps les preuves de chaque constat moyen, élevé et critique, ainsi que les actions d'administration des comptes concernés. C'est le brouillon de la chronologie de votre rapport. Basculez entre UTC et Local avec le sélecteur ; gardez l'UTC pour tout ce que vous partagez.

Étape 6 : pivoter sur les entités

L'onglet Entités liste utilisateurs, adresses IP (avec ASN et pays), sessions, facteurs, applications et admins, chacun avec ses nombres d'événements et d'échecs, première et dernière apparition, et les constats où il figure. Cliquez sur Événements sur une ligne et le tableau des événements est filtré sur cette entité. C'est ainsi que l'on répond à « qu'a fait d'autre cette IP ? » ou « que s'est-il passé dans cette session ? » sans écrire de requête.

Étape 7 : filtrer et exporter les événements

Tous les événements combine un filtre texte libre (utilisateur, IP, eventType, application, session, date), un filtre par catégorie (authentification, MFA, sessions, admin et IdP, politiques, accès aux applications…), un filtre par résultat et Dans un constat seulement. Cliquez sur une ligne pour voir chaque champ utile : message, résultat, acteur, cibles, client, réseau, session, facteur, privilège accordé, risque, comportements, tunnel d'anonymisation, indicateur ThreatInsight, URI de requête, transaction et uuid.

CSV et JSON exportent ce qui est filtré à l'écran. Le CSV est protégé contre l'injection de formules : vous pouvez l'ouvrir sans risque dans un tableur.

Étape 8 : remédier

L'onglet Remédiation transforme les constats en checklist classée par urgence : préserver les journaux, supprimer les sessions, réinitialiser facteurs et mots de passe, revoir et révoquer les rôles d'admin, révoquer les jetons d'API, supprimer les fournisseurs d'identité inconnus, restaurer les politiques, enquêter sur les applications en aval. Cochez au fur et à mesure (l'état ne reste que dans la page). Le bloc Que faire ensuite renvoie vers la documentation de sécurité d'Okta.

La confidentialité, en bref

Les journaux contiennent des données personnelles. C'est pourquoi l'analyseur n'a aucun point de téléversement : les fichiers sont lus localement dans un Web Worker, analysés par WebAssembly, et les résultats restent dans la page. Fermer l'onglet les efface.

Analyse du System Log Okta pas à pas (outil gratuit)