Modernisation du SOC : comment planifier, organiser et financer ce projet

La modernisation d’un SOC est un processus continu et par étapes visant à améliorer la couverture, la détection, les flux de travail et les effectifs d’un centre d’opérations de sécurité. L’objectif est de détecter les menaces et d’y répondre sur une surface d’attaque en constante expansion. Il s’agit d’une discipline de gestion de projet — une feuille de route comprenant les facteurs moteurs, l’évaluation, l’enchaînement des étapes, le financement et les indicateurs de performance — et non d’un simple achat ponctuel d’outils. Si vous dirigez ou supervisez un SOC, les vraies questions sont d’ordre pratique : pourquoi moderniser maintenant, dans quel ordre, à quel coût et comment prouver que cela a fonctionné ? Ce guide suit ce fil conducteur, et le parcours le plus rapide consiste à passer de la définition ci-dessous à l’évaluation de l’état actuel, puis aux coûts, avant d’aborder les raisons pour lesquelles les programmes échouent.

Ce qu'est (et ce que n'est pas) la modernisation du SOC

La modernisation d'un SOC n'est pas synonyme d'acquisition d'une nouvelle plateforme. Il s'agit d'une démarche consistant à mener un programme : évaluer l'état actuel du SOC, planifier les mises à niveau, financer les travaux et mesurer les résultats. L'état final est un sujet à part, car la définition d'un SOC moderne relève des opérations du SOC. Cette page traite du parcours à suivre pour y parvenir.

Les données montrent que le chemin à parcourir est long. L’enquête SANS 2025 sur les SOC clôt neuf années de suivi longitudinal par un constat qui donne à réfléchir : les capacités et les défis des SOC sont « restés globalement inchangés » sur cette période. Les vagues successives d’outils ont promis la transformation des SOC tout en laissant les contraintes structurelles en place. C’est le cas lorsque l’on considère la modernisation des opérations de sécurité comme un travail progressif et cumulatif plutôt que comme un simple remplacement. L’unité de mesure du progrès n’est pas le déploiement d’un produit. Il s’agit d’une amélioration mesurable de la couverture de détection des menaces, de la qualité des signaux et des flux de travail qui agissent sur ces deux aspects.

Pourquoi les SOC se modernisent : les véritables facteurs déclencheurs

Les projets de modernisation commencent rarement par des présentations stratégiques : ils démarrent lorsque le modèle opérationnel actuel ne parvient plus à suivre le rythme de l’environnement qu’il doit protéger. Aucun des véritables déclencheurs n’est une mode technologique. Chacun correspond à un échec opérationnel assorti d’une date et d’un coût précis. L’enquête SANS SOC 2026 a révélé que 24 % des responsables de la cybersécurité citent le manque de visibilité à l’échelle de l’entreprise comme le principal obstacle à l’efficacité du SOC — c’est la réponse la plus fréquemment mentionnée. Dans cette même enquête, 75 % des responsables de la cybersécurité ont déclaré que la technologie ne fonctionne que lorsqu’elle est gérée par des personnes qualifiées. Ce sont la couverture et les ressources humaines, et non l’âge des outils, qui constituent les défis auxquels la transformation d’un SOC apporte réellement une réponse.

Huit déclencheurs sont à l'origine de la plupart des programmes :

1. Des lacunes en matière de visibilité apparaissent à mesure que la surface d'attaque dépasse la portée de la surveillance.
2. Une prolifération d'outils qui augmente les coûts sans améliorer la clarté.
3. Une surcharge d'alertes qui accable l'équipe en l'obligeant à effectuer un triage sans grande utilité.
4. Les difficultés en matière de ressources humaines : recrutement, fidélisation et épuisement professionnel des analystes.
5. Une migration SIEM en cours ou le renouvellement d'un contrat de plateforme.
6. La croissance Cloud des identités dépasse le champ d'action de la surveillance sur site.
7. Pression réglementaire visant à démontrer la capacité de détection et d'intervention.
8. Le fait de devoir compter sur des tiers pour détecter vos propres failles de sécurité.

‍

Le scénario de référence pour 2025 explique pourquoi ces facteurs déclencheurs ont un tel impact. Selon l’enquête SANS 2025 sur les SOC, 42 % des SOC transfèrent l’intégralité de leurs données vers un système SIEM sans avoir de stratégie d’exploitation de ces données — ils engagent des dépenses sans obtenir de résultats en matière de détection. De plus, 79 % des SOC fonctionnent 24 heures sur 24, 7 jours sur 7 (en 2025) ; chaque inefficacité s’aggrave donc sans relâche. Les calendriers de renouvellement soulignent ce problème aussi souvent que les incidents eux-mêmes : l’expiration d’un contrat SIEM est une décision de modernisation, que vous la considériez comme telle ou non. Les analystes des SOC doivent combler l’écart entre ce que les outils produisent et ce dont la mission a besoin, ce qui explique pourquoi la pénurie de personnel et la surcharge d’alertes vont généralement de pair. Pour une analyse actualisée des facteurs déterminants, le webcast « SANS 2026 SOC Survey insights » passe en revue les conclusions de l’enquête de 2026. Consignez chaque déclencheur en temps réel avec les dates et les incidents associés — la section « analyse de rentabilité » ci-dessous transforme ce journal en argumentaire de financement. Lorsque deux déclencheurs ou plus sont actifs simultanément, le report est lui aussi une décision, et généralement la plus coûteuse.

Évaluez votre situation actuelle avant de vous engager sur le budget

Les dépenses de modernisation sans référence constituent une simple conjecture. Avant d’engager des moyens budgétaires, évaluez le SOC selon cinq critères : la couverture, les déclencheurs de détection, l’utilisation des renseignements, la maturité de la chasse aux menaces et la gouvernance de l’IA/ML. Les enquêtes du SANS fournissent des repères comparatifs. En 2025, 85 % des SOC ont déclaré que endpoint constituaient leur principal déclencheur d’intervention (SANS 2025). La couverture de l’enquête 2026 par Infosecurity Magazine montre que cette tendance se maintient : 86 % des réponses étaient endpoint, contre 78 % par les systèmes SIEM en 2026. Un SOC qui réagit principalement aux endpoint a délégué sa stratégie de détection à une seule couche de télémétrie — une lacune en matière d’observabilité de la sécurité qui se fait passer pour une préférence.

Le renseignement et la chasse aux menaces suivent la même logique réactive. En 2025, 69 % des SOC utilisaient les renseignements sur les cybermenaces (CTI) principalement pour la réponse aux incidents — après coup, et non en amont. La chasse aux menaces suit la même tendance. Le mode le plus courant — la recherche partiellement automatisée à l’aide d’outils fournis par les éditeurs, à 48 % — est ce que le SANS qualifie d’« analyse rétroactive plutôt que de véritables recherches axées sur les techniques » (2025). Si votre recherche consiste à examiner les résultats fournis hier par un éditeur, considérez-la comme réactive — en toute honnêteté.

C’est dans le domaine de la gouvernance de l’IA/ML que l’auto-évaluation devient délicate. L’analyse de la gouvernance réalisée par le SANS pour 2025, illustrée à la figure 5, montre que l’utilisation devance la politique. En 2025, 42 % des entreprises utilisaient des outils d’IA/ML sans personnalisation, et environ 69,3 % déclaraient en avoir fait un usage quelconque — il s’agit d’un total dérivé, il convient donc de le noter comme tel. Les données de 2026 affinent le tableau : 79 % utilisent désormais l’IA et le ML, mais seuls 36 % les ont intégrés dans un flux de travail défini (2026). Et seuls 45 % surveillent entièrement ou partiellement les actifs liés aux technologies opérationnelles et à l’Internet des objets (OT/IoT) (2026).

Gouvernance de l'IA et du ML au sein du SOC, enquête SANS 2025 sur les SOC, figure 5 — l'utilisation devance largement les opérations définies.

Pour structurer cet exercice, un modèle de maturité SOC fournit à la base de référence un vocabulaire commun : où vous en êtes et vers quel niveau vous vous dirigez en termes de financement. Il existe des outils neutres à cet effet, notamment le SOC-CMM, un outil d’auto-évaluation spécialement conçu pour les SOC. Résistez à la tentation de trop compliquer le système de notation. L’objectif est d’établir une base de référence honnête que vous pourrez défendre lors de la réunion budgétaire, et non une base parfaite. Notez les réponses en y indiquant les dates : les sections consacrées au calendrier et aux coûts s’appuient toutes deux sur cette base de référence.

Cinq questions pour une auto-évaluation rapide :

• Quelle part des interventions de réponse provient d'endpoint , par rapport cloud provenant du réseau, de l'identité et cloud ?
• La CTI permet-elle de définir des priorités de manière proactive, ou sert-elle uniquement à la gestion des incidents ?
• La chasse repose-t-elle sur des techniques, ou s'agit-il d'une analyse a posteriori des résultats fournis par les prestataires ?
• L'utilisation de l'IA et du ML est-elle définie dans les opérations, tolérée ou inconnue ?
• Quels sont les actifs — y compris ceux liés aux technologies opérationnelles (OT) et à l'Internet des objets (IoT) — qui ne sont actuellement pas couverts par la surveillance ?

Organiser et mettre en scène l'œuvre

C'est au niveau de l'enchaînement des étapes que les programmes de transformation des opérations de sécurité (SOC) prennent leur essor ou s'enlisent. Le point de départ le plus solide est la couverture. Les 10 leçons concrètes Cloud Google Cloud pour moderniser les opérations de sécurité accordent la priorité aux profils de menaces — une « étoile polaire de la couverture ». Définissez les menaces qui comptent pour votre organisation, et laissez ce profil déterminer les priorités de couverture avant toute décision relative aux outils. Ces mêmes leçons insistent sur la nécessité de trouver un équilibre entre les sauts transformationnels et les améliorations progressives, afin que le programme continue à générer de la valeur pendant que les changements majeurs se mettent en place. « Priorité aux profils de menaces » : cela semble évident, mais est souvent négligé. La plupart des conseils de séquencement sur ce sujet sont des affirmations sans source ; ancrez donc les vôtres dans les pratiques observées.

À partir de là, l'ordre des opérations est le suivant : couverture, puis signal, puis flux de travail, puis automatisation :

1. Commencez par établir un profil de menaces afin de définir les priorités en matière de couverture.
2. Combler les lacunes en matière de visibilité au sein de la « triade de visibilité » du SOC.
3. Décidez de l'avenir du SIEM — commencez par comparer le XDR et le SIEM.
4. Améliorer la qualité du signal grâce à l'ingénierie de détection.
5. Il convient de mettre au point les processus de triage et d'enquête avant de les automatiser.
6. Automatisez les processus éprouvés — découvrez l'automatisation du SOC.
7. Regrouper les outils qui se chevauchent au sein d'une plateforme SOC.
8. Choisissez le mode d'exploitation : en interne, hybride ou SOC en tant que service.

‍

Chaque étape constitue une discipline à part entière — les liens ci-dessus en détaillent les aspects approfondis, de sorte que cette feuille de route reste une feuille de route. Ce qu’elle doit apporter, c’est un calibrage du rythme, et c’est précisément ce que fournit l’enquête SANS 2025 sur les SOC. Il s’avère que l’évolution de l’architecture est lente. En 2025, les services SOC cloud représentaient 24,2 % des déploiements, et 29,0 % des entreprises prévoyaient de les adopter dans les 12 mois. Les SOC centralisés uniques n’ont pratiquement pas évolué : 37,8 % aujourd’hui contre 36,2 % prévus. Interprétez ces chiffres comme des indications du rythme observé, et non comme des objectifs à atteindre. Ils plaident en faveur d’une mise en œuvre progressive du travail, par étapes que l’organisation peut assimiler, et non d’un sprint de refonte de la plateforme en un an. Planifiez les étapes par trimestre, et laissez les résultats de chaque étape définir la portée de la suivante.

Répartition entre l'architecture SOC actuelle et celle prévue, enquête SANS 2025 sur les SOC — description de la lenteur réelle de l'évolution de l'architecture, et non un ensemble d'objectifs.

L'ordre est plus important que la rapidité. L'automatisation d'un workflow défaillant ne fait qu'amplifier la défaillance — c'est pourquoi la réparation du workflow doit précéder l'automatisation, et pourquoi la qualité du signal prime sur les deux. La valeur de la détection provient de la couverture qui alimente en signaux de haute qualité des flux de travail qu’une équipe est réellement en mesure d’exécuter. Passer directement à l’automatisation sous prétexte qu’elle fait bonne impression lors d’une démonstration est l’erreur de séquencement la plus courante, et la section consacrée aux modes de défaillance y revient. Une séquence par étapes réduit également les risques liés au financement : chaque étape produit des preuves, qu’il s’agisse de couverture atteinte ou de minutes gagnées, sur lesquelles la prochaine demande de budget pourra s’appuyer.

Quel est le coût de la modernisation du SOC et comment élaborer une analyse de rentabilité ?

Personne ne publie de grille tarifaire pour la modernisation des SOC, et les recommandations existantes ne fournissent pas de chiffres concrets. L’article de TechTarget intitulé « Ce que les RSSI doivent savoir sur la modernisation des SOC » énumère utilement les éléments d’analyse de rentabilité qu’un RSSI devrait présenter — mais ne fournit aucun chiffre à y insérer. Cette lacune explique pourquoi tant de programmes sont financés sur la base de la confiance et défendus à l’aide d’anecdotes. C’est également la raison pour laquelle cette section fait la différence : la question du coût est en effet celle sur laquelle repose en réalité toute discussion relative au financement. Il existe un meilleur point d’ancrage : la valeur démontrable de la rapidité de détection et de la responsabilité de la détection.

L’étude « Le coût d’une fuite de données » de l’Institut Ponemon, édition 2025, quantifie ces deux aspects. La durée moyenne du cycle de vie d’une fuite s’est élevée à 241 jours — soit 181 jours de délai moyen d’identification (MTTI) plus 60 jours de délai moyen de maîtrise (MTTC) —, ce qui représente son niveau le plus bas depuis neuf ans. La rapidité de détection influe sur la répartition des coûts : les violations dont le cycle de vie est inférieur à 200 jours ont coûté en moyenne 3,87 millions de dollars, contre 5,01 millions de dollars pour celles dépassant les 200 jours. La source de la violation influe également sur cette répartition. Les violations détectées par les organisations elles-mêmes ont coûté en moyenne 4,18 millions de dollars, contre 5,08 millions de dollars lorsque c’est l’attaquant qui a révélé la violation — et les violations identifiées en interne ont été détectées en 172 jours. L’autodétection est également en hausse — 33 % en 2023, 42 % en 2024 et 50 % en 2025 — de sorte que l’entreprise médiane détecte désormais elle-même ses propres violations.

L'importance de la rapidité — Étude du Ponemon Institute sur le coût d'une fuite de données, 2025. Les chiffres reflètent une corrélation et non un lien de causalité.

Il faut considérer ces chiffres avec objectivité : ils reflètent une corrélation, et non un lien de causalité. Un SOC modernisé ne réalise pas automatiquement la différence entre ces tranches, et toute analyse de rentabilité prétendant le contraire sera démolie. Le cadre d’analyse valable est celui de l’exposition. Votre posture actuelle vous place dans les tranches les plus lentes et les plus coûteuses. Chaque étape de la feuille de route a pour but de vous faire évoluer vers les tranches plus rapides et moins onéreuses. Ajoutez à cela les coûts propres à chaque étape — télémétrie, temps d’ingénierie, formation et éventuels changements d’approvisionnement — et l’analyse de rentabilité se transforme en un débat sur la tranche que vous pouvez vous permettre d’occuper.

Deux conclusions de l’étude SANS 2025 viennent compléter le tableau. Premièrement, 42 % du personnel des SOC ne connaît pas le budget de son SOC — un décalage que le SANS interprète comme un fossé entre le travail technique et l’entreprise qui le finance. Si l’équipe n’a pas accès au budget, le dossier de rentabilité n’a aucun responsable en dessous du RSSI. Deuxièmement, la taille la plus courante d’un SOC doté d’un effectif complet se situe entre 2 et 10 personnes (SANS 2025) — il s’agit d’une fourchette de planification réaliste, et non d’un effectif précis. Évaluez le coût de la feuille de route en fonction de cette réalité — une petite équipe, assurant dans la plupart des cas un fonctionnement 24 h/24 et 7 j/7 — plutôt qu’en vous basant sur un organigramme qui n’existe pas.

Évaluer si la modernisation porte ses fruits

La mesure fait partie intégrante de l’instrumentation du programme ; ce n’est pas un tableau de bord ajouté a posteriori. Le test est simple : pouvez-vous générer l’indicateur sans intervention humaine ? À l’aune de ce critère, la plupart des SOC ne sont pas instrumentés : l’enquête SANS 2025 sur les SOC a révélé que 69 % d’entre eux continuent de générer leurs indicateurs manuellement ou presque manuellement. Un reporting manuel signifie que la boucle de rétroaction du programme fonctionne à la vitesse de la création d’un tableur, et que cette lenteur freine discrètement tout le reste. Cette page s’abstient délibérément de proposer un catalogue d’indicateurs clés de performance (KPI) : le choix des indicateurs à suivre et leur définition relèvent des indicateurs de sécurité. Ce qui importe ici, c’est le niveau d’instrumentation. Avant de passer à l’étape suivante de la feuille de route, vérifiez que les rapports suivants sont bien générés automatiquement :

• Couverture — la part des actifs et des identités faisant l'objet d'une surveillance, à la demande.
• Taux de détection — proportion d'incidents détectés en premier par le SOC.
• Rapidité — délai de détection et de maîtrise, évolution affichée automatiquement.
• Qualité du signal — conversion des alertes en incidents, sans comptage manuel.
• Mise en œuvre du programme — étapes clés liées aux indicateurs ci-dessus.

Si une ligne nécessite l'intervention d'un être humain pour être mise en place, il faut corriger le pipeline avant de financer l'étape suivante. La dette d'instrumentation s'accumule de la même manière que la dette technique — et contrairement à un tableau de bord, elle ne se manifeste jamais lors d'une réunion budgétaire. C'est également grâce aux rapports automatisés que la modernisation passe du statut d'affirmation à celui de réalité avérée : les mêmes outils d'instrumentation qui guident le programme deviennent la preuve que celui-ci a fonctionné.

Pourquoi les programmes de modernisation échouent ou piétinent

Ce schéma d’échec est suffisamment récurrent pour qu’on puisse s’y préparer : le programme consiste à acheter un outil et à le qualifier de stratégie. La conclusion de l’enquête SANS 2025 sur les SOC est sans appel : « Les outils ne résolvent pas ces problèmes à eux seuls. Ce sont les personnes qui le font. » Le contrepoids est tout aussi important. Dans cette même enquête de 2025, l’EDR/XDR est la seule technologie à obtenir une note supérieure à 3 sur 4 en matière de satisfaction, précisément parce qu’elle est « pleinement déployée… et s’appuie sur une formation et un support adéquats ». En combinant ces deux constatations, la règle d’or apparaît clairement : les outils sont efficaces lorsqu’ils sont pleinement déployés, dotés des ressources nécessaires, accompagnés d’une formation adéquate et intégrés. Les programmes échouent lorsqu’ils se contentent d’acheter l’outil et négligent les quatre autres éléments.

Ce blocage se manifeste généralement d’abord au niveau des ressources humaines. Dans l’enquête SANS SOC de 2026, 59 % des dirigeants ont déclaré que la direction accordait une attention suffisante au recrutement et à la fidélisation du personnel. Seuls 32 % des professionnels partageaient cet avis, ce qui représente un écart de perception de 27 points. L'analyse de Help Net Security concernant le déficit de visibilité des SOC aboutit à la même conclusion : le problème de visibilité tient à la dotation en personnel, et non aux capteurs. Lorsque la direction et les professionnels divergent aussi fortement sur la question des ressources humaines, tout ce qui en découle en pâtit.

DimensionMode de défaillanceSignes avant-coureursPersonnesReport de l'achat d'outils, de la formation et du recrutementLes dirigeants et les praticiens sont en profond désaccord quant à l'importance accordée au recrutementProcessusAutomatisation superposée à des flux de travail non documentésLes procédures opérationnelles restent dans la tête de chaque analysteTechnologieNouvelle plateforme, mêmes lacunes de couvertureLa carte de visibilité reste identique après le déploiementCultureModernisation menée comme un projet informatiqueAbsence de responsable au sein de la direction et budget invisible pour l'équipe

Les causes d'échec de la modernisation liées aux personnes, aux processus, à la technologie et à la culture — chaque ligne s'appuie sur les résultats des enquêtes SANS de 2025 et 2026.

La classification est bien connue — les personnes, les processus, la technologie, la culture — mais ce sont les données de l'enquête qui la rendent exploitable, car chaque ligne contient désormais un chiffre daté plutôt qu'un simple slogan. Utilisez ce tableau comme un « pré-mortem ». Il est moins coûteux de corriger chaque ligne avant la signature du contrat qu'après son renouvellement.

Mise en correspondance de la modernisation avec les référentiels et la conformité

La cartographie du cadre permet de traduire les progrès de la modernisation en un historique vérifiable. Deux repères assurent l’essentiel du travail. Le premier est le NIST CSF 2.0 (2024) et sa fonction « Détection » — plus précisément les sous-catégories DE.CM relatives à la surveillance continue : DE.CM-01, -02, -03, -06 et -09. Les sous-catégories DE.CM-01 et DE.CM-09 constituent le fondement de l’argument relatif à l’étendue de la couverture : les réseaux, le matériel informatique et les logiciels sont tous soumis à une surveillance. Le deuxième pilier est constitué par les tactiques « Enterprise »MITRE ATT&CK, qui transforment la question « Sommes-nous couverts ? » en une réponse technique par technique.

Veillez à ce que les informations relatives à ATT&CK restent à jour. Les notes de mise à jourMITRE ATT&CK indiquent que la version actuelle est datée du 28 avril 2026. À partir de la v19, ATT&CK définit 15 tactiques « Enterprise », la catégorie « Évasion des défenses » étant divisée en « Discrétion » (TA0005) et « Affaiblissement des défenses » (TA0112). Le contenu « Enterprise » recense également 697 stratégies de détection et 1 758 analyses. Ces ressources de détection fournissent à un programme de modernisation un backlog technique prêt à l'emploi : il suffit de recouper les détections existantes avec celles-ci pour que les lacunes de couverture apparaissent sous forme de file d'attente de tâches.

Élément du cadreCe qu’il couvreTravaux de modernisation auxquels il correspondNIST CSF 2.0 DE.CM-01, DE.CM-09 (2024)Surveillance continue des réseaux, du matériel informatique et des logicielsVisibilité à l’échelle de l’entreprise et extension de la couvertureNIST CSF 2.0 DE.CM-02, DE.CM-03, DE.CM-06 (2024) Surveillance des environnements physiques, de l’activité du personnel et des prestataires externes Extension de la couverture aux installations, aux acteurs internes et aux tiers Tactiques d’entreprise MITRE ATT&CK v19 (2026) 15 tactiques, dont « Stealth » (TA0005) et « Defense Impairment » (TA0112)Cartographie de la couverture de détection tactique par tactiqueContenu de détection MITRE ATT&CK v19 (2026)697 stratégies de détection et 1 758 analysesRetard dans l’ingénierie de détection et validation

Tableau de correspondance entre les sous-catégories DE.CM du NIST CSF 2.0 et la couverture du modèle MITRE ATT&CK , et les travaux de modernisation auxquels chacune d'entre elles se rapporte.

La conformité doit figurer dans cette section en tant que facteur déclencheur, et non en tant qu’exigence. Une date butoir pour la migration vers un système SIEM ou l’entrée en vigueur d’un nouveau cadre réglementaire constituent des motifs légitimes pour se lancer — le tableau de correspondance vous permettra ensuite de démontrer les progrès réalisés. Les obligations spécifiques varient selon la réglementation et la juridiction ; il convient donc de les recouper avec un conseiller juridique. Ce qui relève de la responsabilité du SOC, ce sont les preuves : une couverture continue de la surveillance de la sécurité, documentée au regard des référentiels mentionnés ci-dessus.

Approches modernes de la modernisation du SOC

Le discours du marché s’est cristallisé autour de visions de SOC basées sur l’IA et dotées d’autonomie décisionnelle, et chaque plateforme arbore désormais une étiquette « SOC de nouvelle génération » sous une forme ou une autre. Ces étiquettes changent plus vite que le problème sous-jacent. Au-delà des appellations, le principe fondamental reste celui que cette feuille de route met en avant tout au long de son développement. Ce qui importe, c’est une couverture étendue de la surface d’attaque moderne, ainsi que des signaux de haute qualité sur lesquels une équipe à taille humaine peut agir. Sur le plan architectural, cela implique une couverture englobant le réseau, l’identité, cloud et le SaaS — le domaine de la détection et réponse aux incidents et de la détection et de la réponse étendues. Le résultat devrait être un nombre réduit de signaux, mieux corrélés, alimentant les workflows mis en ordre par la section consacrée à la séquence des opérations.

Vectra AI en matière de modernisation du SOC

Vectra AI la modernisation comme un problème de couverture et de signal avant même d’en faire un problème d’outillage. La méthodologie part du principe que le système est déjà compromis : les attaquants finiront par s’introduire, et le rôle du SOC est donc de les détecter rapidement, où qu’ils opèrent. Cela nécessite une visibilité unifiée sur l’ensemble de la surface d’attaque moderne : réseau, identités, cloud et SaaS. Cela nécessite également une hiérarchisation des priorités, et c’est là qu’intervient l’Attack Signal Intelligence™ : elle met en évidence les comportements indiquant qu’une attaque réelle est en cours, afin que les analystes puissent agir sur les attaques plutôt que de se contenter de trier davantage d’alertes. C’est la mise en pratique de la thèse « la couverture d’abord » de cette feuille de route.

‍