Nous mesurons, en lecture seule depuis votre console XDR, ce que votre dispositif de supervision voit réellement : sources de journaux qui remontent, techniques d’attaque couvertes, qualité des alertes, réactivité du prestataire. Puis nous suivons les améliorations jusqu’à leur vérification.
Un SOC ne détecte que ce qu’il reçoit, avec les règles qu’il applique. Une source de journaux tombée en silence, une règle désactivée ou un seuil mal réglé suffisent à rendre une attaque invisible, sans que les rapports le signalent.
Nous partons donc des faits de votre console, pas des rapports du prestataire : quelles sources se sont tues, quelles règles se déclenchent, quelles techniques d’attaque n’ont produit aucune alerte, en combien de temps chaque alerte est prise en compte et résolue. Puis nous les rapportons aux menaces qui pèsent sur vos activités.
Nous travaillons avec votre prestataire, pas à sa place, et sans rien modifier dans votre SI : la mesure porte sur le dispositif, pas sur les personnes.
Vous obtenezDes menaces prioritaires et les techniques qui les composent
Vous obtenezUne matrice de couverture par technique, et les délais mesurés
Vous obtenezDes résultats de tests datés
Vous obtenezUn plan d’amélioration et son suivi
Les textes ne demandent pas seulement de surveiller : ils demandent des mécanismes testés, des seuils définis et des moyens suffisants.
Les entités financières doivent disposer de mécanismes de détection rapide des activités anormales, testés régulièrement.1
Ces mécanismes prévoient plusieurs niveaux de contrôle, des seuils et des critères d’alerte qui déclenchent la réponse aux incidents, et des ressources suffisantes pour surveiller l’activité.23
La directive range la gestion des incidents parmi les mesures que les États membres doivent exiger des entités ; le ReCyF (version de travail) leur fixe l’objectif de disposer d’une organisation, de processus et d’outils pour se préparer et réagir aux événements de sécurité.45
La CNIL recommande de journaliser les activités des utilisateurs, les interventions techniques et les événements de sécurité, et de vérifier régulièrement la présence de journaux exploitables.67
Les textes ne s’appliquent pas à toutes les organisations : leur applicabilité dépend de votre statut, de votre secteur, de votre taille et de vos contrats. Elle est à faire confirmer par votre juriste ou un avocat spécialisé.
Vous choisissez le niveau ; le périmètre et les livrables sont fixés par contrat.
Nous mesurons en continu la couverture et la réactivité de la supervision, et documentons les écarts.
LivrablesNous analysons les écarts, les décisions et les rapports du prestataire, et vous aidons à décider des priorités.
LivrablesNous animons le suivi des améliorations avec vos équipes et votre prestataire, sans effectuer les changements dans votre SI.
LivrablesBranchée sur votre console XDR avec une clé en lecture seule : santé des sources, couverture ATT&CK, délais du prestataire par sévérité et par mois, recalculés en continu. Cortex XDR aujourd’hui ; Sophos et Trend Vision One en cours de validation.
Les alertes closes relues décision par décision, les règles qui ne produisent que du bruit, les faux positifs récurrents jamais corrigés.
Un rapport hebdomadaire commenté, des constats reliés à leurs preuves, et pour chacun un responsable, une échéance et un historique.
Non. Nous ne sommes pas un SOC. Nous mesurons ce que votre dispositif détecte et vous aidons à l’améliorer avec votre prestataire, qui reste en charge de la supervision et de la réponse.
Cortex XDR, directement par son API. Les connecteurs Sophos et Trend Vision One sont développés et en cours de validation sur un premier client. Pour les autres outils, nous travaillons à partir d’exports.
Pour une entité financière soumise à DORA, oui : le règlement demande que les mécanismes de détection soient testés régulièrement. Pour les autres organisations, c’est le seul moyen de savoir ce que la supervision voit vraiment.1
Proposés en option, ils sont conçus pour être inoffensifs : ils imitent la trace d’une attaque sans en produire l’effet. Leur périmètre, leurs horaires et les personnes prévenues sont convenus par écrit avant tout test.
Une clé d’API en lecture seule sur votre console XDR, qui donne les sources de journaux, les alertes et les incidents. Nous n’avons pas besoin de droits d’administration. Certains outils ne laissent pas lire la configuration des règles avec ce type de clé : nous la demandons alors en export à votre prestataire.
À partir de votre console XDR ou d’exports disponibles, identifiez les sources silencieuses, la couverture documentée, les alertes réellement observées et les délais de traitement. Vous obtenez les écarts prioritaires à discuter avec votre prestataire et un plan d’amélioration. Nous pouvons démarrer par une mesure ciblée, puis la comparer à 30 jours si les données le permettent. Accès en lecture seule, périmètre et prix sur devis ; les tests de détection nécessitent un accord écrit et restent optionnels.
Texte exact, dans sa langue d’origine, tiré des référentiels extraits du texte officiel.
32022R2554-a10-p1Financial entities shall have in place mechanisms to promptly detect anomalous activities, in accordance with Article 17, including ICT network performance issues and ICT-related incidents, and to identify potential material single points of failure. All detection mechanisms referred to in the first subparagraph shall be regularly tested in accordance with Article 25.32022R2554-a10-p2The detection mechanisms referred to in paragraph 1 shall enable multiple layers of control, define alert thresholds and criteria to trigger and initiate ICT-related incident response processes, including automatic alert mechanisms for relevant staff in charge of ICT-related incident response.32022R2554-a10-p3Financial entities shall devote sufficient resources and capabilities to monitor user activity, the occurrence of ICT anomalies and ICT-related incidents, in particular cyber-attacks.32022L2555-a21-p2-2incident handling;recyf:obj-12Les entités [importantes ou essentielles] mettent en œuvre une organisation, des processus et des outils adaptés pour se préparer et réagir à des événements de sécurité susceptibles d’affecter la réalisation de leurs activités ou la fourniture de leurs services.F16-PE-01Prévoir un système de journalisation (c’est-à-dire un enregistrement dans des fichiers journaux ou « logs ») des activités métier des utilisateurs (traces applicatives), des interventions techniques (y compris par les administrateurs), des anomalies et des évènements liés à la sécurité (traces techniques ou « système »).F16-PE-06S’assurer du bon fonctionnement du système de journalisation en intégrant les équipements dans un outil de supervision et vérifier régulièrement la présence de journaux exploitables.