Un SOC détecte. Un CERT répond. Cette distinction paraît technique, mais elle est néanmoins entièrement opérationnelle.
La confusion est fréquente, et elle arrange bien des prestataires. Beaucoup d'organisations pensent avoir une couverture complète parce qu'elles disposent d'un SOC managé. Elles découvrent pourtant le contraire au moment où elles en ont le plus besoin.
Qu'est-ce qu'un SOC et qu'est-ce qu'un CERT ?
Un SOC (Security Operations Center) est un centre opérationnel de sécurité chargé de surveiller en continu le système d'information, de collecter les événements de sécurité et de détecter les comportements anormaux. Il permet de qualifier une alerte et d'identifier une menace avant qu'elle ne se propage.
Un CERT (Computer Emergency Response Team), parfois désigné CSIRT (Computer Security Incident Response Team), est une équipe spécialisée dans la réponse aux incidents de cybersécurité. Il intervient une fois la menace confirmée : containment, éradication, remédiation, reprise d'activité et analyse post-incident. Il permet de limiter les dégâts, de reprendre le contrôle et de comprendre ce qui s'est passé.
Ces deux fonctions sont complémentaires par nature. Cependant, elles sont souvent vendues séparément, parfois sans que le client en soit clairement informé.
Ce qui se passe concrètement quand le SOC détecte mais que le CERT n'est pas là
Il est 23h. Le SOC émet une alerte critique : un mouvement latéral est détecté sur plusieurs postes de travail. L'alerte est qualifiée et le niveau de criticité est élevé. Le prestataire envoie dès lors une notification.
Et ensuite ? Sans CERT intégré, la réponse s'arrête là. L'organisation reçoit l'information mais se retrouve seule pour décider quoi faire, dans quel ordre, avec quelles ressources et en combien de temps. Pour une organisation sans équipe sécurité dédiée, ce scénario est catastrophique. Chaque minute sans confinement est une minute pendant laquelle l'attaquant progresse.
A retenir : Un SOC sans CERT, c'est une alarme anti-intrusion sans intervention. Elle détecte l'intrusion. L'arrêter, en revanche, est une autre affaire."
Que fait réellement un CERT lors d'un incident ?
Un CERT n'est pas une hotline. En effet, c'est une équipe formée à l'analyse des incidents, à l'évaluation des risques et aux enquêtes forensiques, c'est-à-dire à la reconstitution technique et juridique de la chaîne d'attaque.
Lors d'une suspicion d'intrusion, le CERT est activé et commence par évaluer la situation : outils disponibles, indices de compromission, indicateurs d'attaque, périmètre exposé et impacts potentiels. Il interagit directement avec la DSI et le SOC pour exploiter au mieux les ressources disponibles et prendre les décisions de confinement adaptées.
Pendant la crise, le CERT peut recommander ou déployer des outils spécifiques, isoler des segments réseau, bloquer des comptes compromis, préserver les preuves numériques. Cette préservation forensique est décisive : sans elle, il est impossible de reconstituer précisément la chaîne d'attaque, d'identifier la vulnérabilité initiale et de produire le rapport réglementaire requis par NIS2, DORA ou le RGPD.
Après la crise, le travail du CERT ne s'arrête pas au retour à la normale. Il comprend également une analyse post-incident approfondie, des recommandations d'architecture pour corriger les failles identifiées, et un renforcement de la posture globale de sécurité. C'est cette dimension durable qui distingue un vrai CERT d'une simple équipe d'intervention d'urgence.
Exemple concret : un ransomware détecté à 2h du matin. Le SOC alerte. Le CERT intervient immédiatement : isolation des machines chiffrées, identification du vecteur initial, blocage des comptes utilisés par l'attaquant, préservation des journaux pour les forensiques. À 8h, la direction a un premier rapport d'incident prêt pour la notification réglementaire. Sans CERT intégré, aucun de ces éléments n'est disponible dans ce délai.
SOC et CERT : ce que NIS2, DORA et le RGPD imposent désormais
Les cadres réglementaires européens ne séparent plus la détection de la réponse. Ils les imposent conjointement, avec des délais qui rendent l'improvisation impossible.
NIS2 (Directive UE 2022/2555, Texte intégral EUR-Lex) impose aux entités essentielles et importantes une capacité de détection ET une capacité de réponse documentée. L'article 23 est explicite : les entités doivent notifier "dans les meilleurs délais et au plus tard dans les 24 heures après avoir eu connaissance de l'incident significatif" une alerte précoce au CSIRT compétent, suivie d'une notification complète sous 72 heures et d'un rapport final sous un mois. Sans CERT opérationnel capable de qualifier l'incident et de produire les éléments requis, tenir ces délais est impossible pour une organisation non préparée.
DORA (Règlement (UE) 2022/2554, Texte intégral EUR-Lex, applicable depuis janvier 2025) va plus loin pour les entités financières. Les articles 9, 10 et 11 imposent respectivement des obligations de prévention, de détection et de réponse aux incidents ICT. Le règlement délégué 2025/301 précise les délais : la notification initiale doit être soumise "le plus tôt possible, mais en tout état de cause, dans un délai de quatre heures à compter de la classification de l'incident comme majeur". Un garde-fou supplémentaire s'applique : ce délai ne peut en aucun cas dépasser 24 heures après la détection, pour éviter qu'une entité retarde artificiellement la classification. Un SOC seul, sans CERT intégré capable d'intervenir immédiatement et de produire la documentation requise, ne permet pas de tenir ces engagements.
RGPD : l'obligation des 72 heures qui s'applique à tous
RGPD (Règlement (UE) 2016/679, Obligations de notification à la CNIL) impose à tout responsable de traitement de notifier toute violation de données à caractère personnel à l'autorité de contrôle compétente. L'article 33 est précis : "dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance, à moins que la violation en question ne soit pas susceptible d'engendrer un risque pour les droits et libertés des personnes physiques." Sans CERT pour qualifier la violation, évaluer son périmètre exact et documenter la réponse apportée, cette obligation est pratiquement impossible à honorer dans les délais avec les éléments requis.
Réglementation
Délai de notification
Texte de référence
Pourquoi l'intégration SOC/CERT change tout lors d'un incident
Lorsque le SOC et le CERT sont opérés par la même équipe, sur la même infrastructure et avec les mêmes outils, la chaîne de traitement est continue. L'analyste qui détecte l'incident peut ainsi immédiatement déclencher le confinement sans délai de transfert, sans réunion de coordination, sans perte d'information dans le passage de relais.
Cette continuité a des conséquences directes et mesurables. En premier lieu, le temps entre la détection et le confinement est réduit. Par ailleurs, les preuves numériques sont préservées correctement dès les premières minutes, ce qui conditionne à la fois la qualité des forensiques et la solidité du rapport réglementaire. La communication de crise est dès lors pilotée par des experts qui ont le contexte complet de l'incident. En conséquence, les obligations de notification peuvent être honorées dans les délais, avec la documentation requise.
En revanche, lorsque le SOC et le CERT sont deux entités distinctes, le transfert de dossier introduit des délais, des frictions et des risques de perte d'information. Dans un incident de ransomware, ces minutes comptent plus que tout.
Pour une organisation soumise à NIS2 ou DORA, travailler avec un prestataire dont le SOC et le CERT sont réellement intégrés n'est donc pas un confort supplémentaire. C'est une exigence opérationnelle que les réglementations rendent incontournable.
La souveraineté des données constitue en outre un critère décisif. Un SOC et un CERT opérés 100% en Europe, sans sous-traitance extraterritoriale, garantissent que les données les plus sensibles du système d'information, notamment les journaux d'événements et les preuves numériques collectées lors d'un incident, ne transitent jamais vers des juridictions soumises à des législations extraterritoriales comme le Cloud Act américain. Pour les organisations soumises au RGPD, cet argument est effectivement loin d'être accessoire.
Les 5 questions à poser à votre prestataire SOC
Avant de signer, cependant, ces cinq questions méritent une réponse écrite et contractuelle.
- Votre offre inclut-elle un CERT opérationnel, ou seulement la détection et l'alerte ?
- Quels sont vos engagements contractuels de délai de réponse par niveau de criticité ?
- Vos équipes SOC et CERT sont-elles intégrées ou deux entités distinctes ?
- Disposez-vous d'une capacité forensique pour reconstituer la chaîne d'attaque et produire les rapports réglementaires requis ?
- Où sont physiquement localisés vos analystes et vos infrastructures ?
Un prestataire qui ne peut pas répondre précisément à ces cinq questions ne sera pas en mesure de vous accompagner efficacement le soir d'un incident réel.
Votre organisation dispose d'un SOC. Mais dispose-t-elle d'un CERT prêt à intervenir en dehors des heures ouvrées, avec une capacité forensique et un accompagnement réglementaire ? Le SOC managé par Stroople intègre un CERT opérationnel 24/7 et des engagements contractuels de réponse. Prenez contact avec un expert pour évaluer votre couverture actuelle.
Pour aller plus loin sur ce qu'un SOC managé doit couvrir et comment choisir le bon prestataire, lisez notre guide complet : SOC managé : Qu'est-ce que c'est, ce qu'il doit couvrir et comment le choisir
Offre Stroople SOC managé 24/7
Service SOC managé qui protège, détecte et répond. 24/24.