Une société de gestion qui gère plusieurs centaines de millions d’euros d’encours reçoit, un vendredi soir, une alerte sur une connexion sortante anormale depuis un serveur de valorisation. Le RSSI de permanence n’est pas joignable, le prestataire IT généraliste ne couvre pas le week-end. Lundi matin, l’équipe découvre que l’alerte était un faux positif, mais personne n’a pu le qualifier pendant 60 heures.
Ce type de scénario pousse de plus en plus de sociétés de gestion à structurer un SOC externalisé, non pas comme un luxe technologique, mais comme une brique opérationnelle dictée par la réglementation et la réalité des menaces.
A lire en complément : L'importance d'utiliser des mots de passe sécurisés
Audit de surface d’attaque : ce que DORA change pour le périmètre d’un SOC en finance
Depuis le 17 janvier 2025, le règlement DORA impose aux entités financières un cadre de résilience numérique structuré. Pour une société de gestion, cela ne se limite pas à cocher des cases de conformité. DORA exige la traçabilité complète des incidents TIC et la maîtrise des risques liés aux prestataires tiers. Un audit de surface d’attaque mené avant la mise en place d’un SOC doit donc intégrer ces obligations dès le cadrage.
Concrètement, on cartographie les actifs critiques : outils de gestion de portefeuille, systèmes de passage d’ordres, accès aux dépositaires, flux de reporting réglementaire vers l’AMF. Chaque actif génère des journaux qu’il faudra collecter, normaliser et corréler. L’erreur fréquente consiste à reproduire un périmètre SOC généraliste alors que les cas d’usage prioritaires diffèrent. Un accès frauduleux au système de valorisation des parts n’a pas le même impact qu’un phishing sur la messagerie d’un assistant commercial.
Lire également : Gpeers expliqué aux débutants : fonctionnement, risques et limites
Les sociétés de gestion qui externalisent ce volet s’appuient généralement sur un partenaire capable de combiner infogérance et cybersécurité pour les sociétés de gestion dans un cadre réglementaire maîtrisé, plutôt que sur un MSSP généraliste qui découvrirait les contraintes AMF après la signature du contrat.
Règles de détection spécifiques aux sociétés de gestion d’actifs
Un SOC générique arrive avec un catalogue de règles de détection standards : brute force sur Active Directory, exfiltration de données volumineuse, mouvement latéral classique. Ces règles couvrent la base, mais elles ne ciblent pas les scénarios propres à la gestion d’actifs.
Cas d’usage à couvrir en priorité
- Connexion inhabituelle aux systèmes de gestion de portefeuille en dehors des horaires de marché, particulièrement le week-end ou pendant les périodes de valorisation
- Modification non autorisée des paramètres de calcul de la valeur liquidative, qui pourrait masquer une erreur opérationnelle ou une manipulation
- Accès simultané depuis deux géolocalisations distinctes à un compte disposant de droits d’exécution d’ordres
- Tentative d’extraction massive de données investisseurs (KYC, positions clients), soumises à des obligations de confidentialité renforcées
Chaque règle de détection doit être associée à un scénario d’escalade documenté. DORA impose la notification des incidents TIC majeurs aux autorités compétentes dans des délais stricts. Le SOC externalisé doit savoir qui prévenir, dans quel ordre, et avec quel niveau de qualification avant de déclencher la notification.
Les retours varient sur ce point, mais on constate que les sociétés de gestion de taille intermédiaire sous-estiment souvent le volume d’alertes générées par leurs flux de données de marché. Un SOC qui n’a pas calibré ses seuils sur ce type de trafic risque de noyer les analystes sous les faux positifs.
Gouvernance du run 24/7 : contractualiser la réponse, pas seulement la surveillance
Surveiller un périmètre en continu ne suffit pas. La valeur d’un SOC externalisé se mesure à sa capacité de réponse qualifiée, pas au nombre d’écrans affichés dans un centre de supervision. Pour une société de gestion, le contrat doit définir précisément les niveaux de réponse autorisés : le prestataire peut-il isoler un poste compromis sans validation préalable du RSSI ? Peut-il couper un flux vers un dépositaire en cas de suspicion d’exfiltration ?
Ces questions ne sont pas théoriques. Une coupure réseau non coordonnée pendant une fenêtre de passage d’ordres peut générer des pertes financières directes et des manquements réglementaires. Le contrat de service doit prévoir des procédures distinctes selon les plages horaires de marché et les périodes hors marché.
Points à verrouiller dans le contrat SOC
La gestion des preuves constitue un sujet à part entière. DORA prévoit que les entités financières maintiennent un registre des incidents TIC. Le SOC doit alimenter ce registre avec des données exploitables, horodatées et conservées sur une durée compatible avec les exigences de l’AMF. On négocie ce point avant la signature, pas après le premier incident.
Le volet prestataire tiers mérite aussi une attention particulière. Le SOC externalisé est lui-même un prestataire critique au sens de DORA. Il faut donc évaluer sa propre résilience : où sont hébergées les données de supervision, quels sont ses plans de continuité, dispose-t-il d’une certification ou d’une qualification reconnue ?
Transition audit vers run : les étapes terrain qui conditionnent la réussite
La phase de transition entre l’audit initial et le fonctionnement opérationnel dure en général plusieurs semaines. On commence par une période de tuning pendant laquelle le SOC ingère les journaux, génère des alertes et les confronte aux retours de l’équipe interne. Cette phase de calibrage réduit le bruit et affine les seuils de détection sur les vrais cas d’usage métier.
Pendant cette période, on identifie aussi les angles morts. Un outil de gestion de portefeuille hébergé chez un éditeur SaaS ne produit pas forcément des logs exploitables par le SIEM du SOC. Il faut parfois développer des connecteurs spécifiques ou accepter une couverture partielle sur certains périmètres.
La réussite du passage en run dépend aussi de la relation entre le SOC et les équipes internes. Un analyste SOC qui ne comprend pas le métier de la gestion d’actifs qualifiera mal une alerte sur un flux Bloomberg ou un accès SWIFT. Les sessions de transfert de connaissance métier en début de contrat ne sont pas optionnelles.
Le SOC externalisé adapté à une société de gestion n’est pas un produit sur étagère. C’est un dispositif qui se construit à partir des contraintes réglementaires DORA, des spécificités métier de la gestion d’actifs et d’un contrat de service qui encadre la réponse autant que la détection. Les structures qui traitent ce sujet comme un simple achat de prestation découvrent les lacunes lors du premier incident significatif.
