Faux positifs des détections Okta : VPN, mobile, réglage

TL;DR. Les détections d'identité sont des heuristiques. Les faux positifs les plus fréquents viennent des VPN d'entreprise et passerelles de sécurité qui sortent par des réseaux cloud (constats hébergeur et session multi-réseaux), des téléphones qui passent du Wi-Fi aux données mobiles (une session, deux ASN) et des vraies réinitialisations par le helpdesk. Les faux négatifs les plus fréquents viennent des exports incomplets, des attaques distribuées sur de nombreuses IP et des techniques que les règles ne couvrent pas encore. Vérifiez chaque constat auprès des personnes concernées, et lisez un verdict propre comme « rien ne s'est déclenché », jamais comme « il ne s'est rien passé ».

Je préfère que vous fassiez un peu moins confiance à l'analyseur et que vous l'utilisiez bien. Cette page liste ce qu'il ne voit pas et là où il s'emballe, règle par règle.

Limites des données

Rétention de 90 jours. L'API System Log ne renvoie pas les événements de plus de 90 jours (Okta Developer). Un IdP créé il y a quatre mois, ou les premières étapes d'une intrusion lente, ne sont tout simplement pas dans l'export.
Exports filtrés. Un export limité à un utilisateur manque l'agent du helpdesk qui l'a réinitialisé et l'admin qui l'a promu. Exportez toute l'organisation.
Événements tardifs. Okta indique que certains événements d'une période récente peuvent arriver en retard. Réexportez les dernières heures plus tard pendant un incident en cours.
Fidélité des CSV. Les CSV aplatis perdent ou renomment des champs. L'analyseur lit les en-têtes en chemins LogEvent et les colonnes _raw ; les colonnes aplaties Okta_CL de Sentinel ne sont pas encore mappées. Préférez le JSON de l'API.
debugData n'est pas un contrat. Des champs comme privilegeGranted, behaviors, risk, threatSuspected et tunnels varient selon les organisations et les versions. Les règles qui les lisent peuvent se taire si un champ change de nom.
Historique court, références faibles. « Nouveau réseau pour cet utilisateur » est calculé à partir de l'export lui-même. Avec deux jours d'historique, tous les réseaux sont nouveaux.

Limites des détections

Les 25 règles sont listées avec leur sévérité sur la page d'accueil. Ce qu'elles ne font pas (encore) :

Non couvert	Contournement
Spraying distribué sur de nombreuses IP (regroupement par IP)	regrouper les échecs par ASN et user agent à la main, voir password spraying
Voyage impossible / nouveau pays par utilisateur	trier par date les connexions d'un utilisateur dans le tableau des événements
`risk = HIGH` ou `behaviors` comme détection	visibles dans le détail de l'événement ; filtrer par utilisateur
Consentement d'applications OAuth et abus de client credentials	chercher les événements `app.oauth2.*`
Modifications de règles de groupe et de routage	examiner en entier la session d'administration de l'attaquant
Nouvel utilisateur créé puis immédiatement promu admin	vérifier `user.lifecycle.create` à côté des constats d'octroi d'admin
Chaque connexion via un IdP entrant	lister `user.authentication.auth_via_IDP` pour tout nouvel IdP
Ce qui s'est passé dans les applications en aval	utiliser les journaux propres à l'application

Faux positifs, règle par règle

Connexions depuis un hébergeur ou un anonymiseur

access.hosting_provider cherche des mots-clés dans securityContext.asOrg et isp (hosting, VPS, data centre, et les noms de grands fournisseurs cloud et d'hébergement). Il se déclenche quand :

votre VPN d'entreprise ou passerelle web sécurisée sort par un fournisseur cloud ;
des salariés utilisent un VPN personnel ou un relais de confidentialité ;
un système de CI ou un script se connecte de façon interactive depuis le cloud (en soi un constat à corriger).

access.anonymizer lit securityContext.isProxy et les données tunnels de debugData. Du point de vue d'Okta, les VPN commerciaux sont des anonymiseurs.

Réglage : listez les IP et ASN de sortie de votre VPN et de vos passerelles avant l'incident, et confrontez d'abord chaque constat hébergeur à cette liste. En prévention, les zones dynamiques enrichies d'Okta peuvent bloquer les catégories d'anonymiseurs tout en autorisant vos réseaux connus.

Une session, plusieurs réseaux ou navigateurs

session.multi_asn (élevée) et session.multi_user_agent (moyenne) regroupent les événements par externalSessionId sur 12 heures. Causes légitimes :

des appareils mobiles qui passent du Wi-Fi au réseau de l'opérateur (deux ASN, même user agent) ;
la connexion au VPN en cours de session ;
des mises à jour automatiques du navigateur pendant une longue session (deux chaînes de user agent qui ne diffèrent que par la version) ;
une connectivité double pile IPv4/IPv6 où les deux chemins sont annoncés par des ASN différents.

Réglage : vérifiez si le second ASN est un opérateur mobile ou votre VPN, et si les user agents ne diffèrent que par la version. Un système ou une famille de navigateur différents sur un réseau d'hébergeur, c'est le cas sérieux, comme expliqué dans détournement de session. Rappelez-vous aussi que externalSessionId peut être régénéré après des événements du cycle de vie des facteurs (Okta Security) : une session rejouée peut apparaître sous un autre identifiant que la connexion d'origine ; pivotez sur authenticationContext.rootSessionId dans le JSON brut ou dans votre SIEM.

Fatigue MFA

mfa.push_fatigue compte les envois comme les refus : cinq push en 15 minutes. Un utilisateur avec plusieurs appareils, ou qui se connecte à de nombreuses applications exigeant chacune la MFA, peut l'atteindre. Regardez les résultats (tous approuvés ?) et le réseau d'origine des connexions déclenchantes. Détails dans détection de la fatigue MFA.

Réinitialisation par le helpdesk puis enrôlement

mfa.helpdesk_reset_then_enroll se déclenche aussi sur chaque vrai ticket « j'ai perdu mon téléphone » ; c'est pourquoi sa sévérité de base est élevée, pas critique. Il devient critique quand l'enrôlement vient d'un réseau que l'utilisateur n'avait pas utilisé avant la réinitialisation, d'un proxy ou d'un hébergeur. Un utilisateur qui enrôle son nouveau téléphone depuis chez lui (où il s'est déjà connecté) reste en élevée. Un utilisateur en vacances à l'étranger passe en critique : confirmez avec lui. Voir ingénierie sociale du helpdesk.

Password spraying et devinette

access.password_spray exige au moins 8 utilisateurs distincts en échec depuis une IP en une heure, avec en moyenne 3 échecs ou moins par utilisateur. Un NAT de bureau partagé après une vague d'expiration de mots de passe peut s'en approcher ; le taux de réussite les départage. access.brute_force (10 échecs sur un utilisateur en 15 minutes) se déclenche sur des scripts aux identifiants périmés, comme un vieux client de messagerie qui réessaie.

Modifications d'admin, de politiques et d'IdP

Octrois de rôles, jetons d'API, modifications de politiques, IdP et réglages de sécurité sont signalés quel qu'en soit l'auteur, car le journal ne distingue pas un changement planifié d'un changement malveillant. Les sévérités faible et moyenne le reflètent. Réglage : rapprochez chacun de vos tickets de changement. Un octroi Super Administrator ou un nouvel IdP sans ticket est un incident tant qu'il n'est pas expliqué.

Une routine de vérification pour chaque constat

Qui est l'acteur, et est-ce vraiment lui ? Appelez sur un numéro connu.
D'où ? ASN, pays, user agent comparés à l'historique de l'utilisateur.
Et ensuite ? Les événements qui suivent le constat : actions d'administration, enrôlements, SSO.
Y a-t-il une trace ? Ticket, demande de changement, déplacement.
Décidez et documentez dans le rapport, avec les uuid des événements.

Quand le verdict est propre

Confrontez la période, le nombre d'événements et les utilisateurs de la ligne de statistiques à ce que vous attendiez. Si quelque chose paraît court, corrigez l'export et relancez. S'il est complet et propre, c'est une information utile, pas une garantie. Conservez l'export, et passez en revue les recommandations HealthInsight d'Okta pour votre organisation.

FAQ

Pourquoi mon VPN d'entreprise apparaît-il comme un hébergeur ?

Beaucoup de services VPN et de passerelles web sécurisées sortent par des réseaux cloud ou de centres de données. Le nom de l'organisation de leur ASN correspond aux mêmes mots-clés qu'un fournisseur de VPS. Identifiez vos ASN de sortie et vérifiez-les en premier.

L'analyseur peut-il manquer une attaque ?

Oui. Il ne voit que les événements exportés, utilise des seuils fixes et ne couvre pas encore toutes les techniques. Un verdict propre signifie qu'aucune de ses règles ne s'est déclenchée, pas qu'il ne s'est rien passé.