Suivre Construire ou acheter est la décision concernant les détections de menaces qu’une équipe de sécurité rédige en interne et celles qu’elle source comme du contenu de détection prêt à l’emploi. La réponse n’est presque jamais tout construire ou tout acheter. Achetez la couche de commodités, construisez ce qui est unique à votre environnement, et mesurez les deux côtés par le temps de couverture : le temps écoulé entre la publication d’une technique et une détection validée, en fonctionnement dans votre propre infrastructure.
Mon équipe de sécurité doit-elle écrire nos propres règles de détection ou acheter du contenu de détection ?
Les deux. La répartition dépend de quatre facteurs, non d’un ratio prédéfini.
| Facteur | Indicateur de construction | Indicateur d’achat |
|---|---|---|
| Unicité de la télémétrie | Applications personnalisées, protocoles propriétaires, logique spécifique à l’environnement | TTP standard contre des plateformes communes, mappables sur MITRE ATT&CK techniques |
| Effectifs | Ingénieurs en détection en personnel avec capacité de rédaction et de maintenance | Aucun FTE en ingénierie de détection, ou FTE occupé par d’autres tâches |
| Capacité de validation | L’équipe peut prouver que les règles fonctionnent et produisent des preuves d’audit | Pas de pipeline de validation |
| Objectif de temps de couverture | Fenêtre tolérable mesurée en semaines | Fenêtre mesurée en heures ou en jours |
Le temps de couverture est le facteur sur lequel repose toute la décision. Il mesure la fenêtre entre la publication d’une technique et une détection validée et fonctionnelle dans votre environnement. Chaque jour à l’intérieur de cette fenêtre représente une exposition que l’équipe a choisi de supporter.
Quel est le coût d’un ingénieur en détection, tout compris, et quel est le coût du backlog ?
La réponse réside dans vos propres chiffres. La structure de coût de chaque organisation est différente, et aucun indice externe ne remplace votre coût total, votre calendrier de montée en puissance ou votre taux de rotation. Ce qui importe, c’est de le calculer complètement.
Un ingénieur en détection tout compris coûte plus qu’un salaire. Le total inclut le salaire, les avantages, les outils, la formation et les frais de gestion qu’un embauche spécialisée engendre.
Ajoutez la période de montée en puissance. Un nouvel ingénieur ne produit pas des détections validées pour votre télémetrie spécifique et configuration SIEM dès le premier jour, et le backlog augmente pendant sa montée en puissance.
Ajoutez la rotation. Les ingénieurs en détection sont rares et mobiles. Chaque départ réinitialise l’horloge de montée en puissance et emporte avec lui le savoir spécifique à l’environnement.
| Facteur | Votre chiffre | Notes |
|---|---|---|
| Coût annuel chargé (salaire + avantages + outils + gestion) | ||
| Temps de montée en puissance pour être productif sur votre infrastructure | Mois avant que l’embauche n’écrive des règles de production | |
| Taux de rotation annuel | Chaque départ réinitialise l’horloge de montée en puissance | |
| Coût de maintien du backlog | Risque encouru tandis que les règles restent non écrites | |
| Règles rédigées par ingénieur par mois | Règles validées et déployées uniquement | |
| Nombre de plateformes (cibles SIEM, EDR, XDR) | Chaque cible multiplie le coût de maintenance |
Le backlog lui-même a un coût. Chaque règle qui n’est pas écrite ou non validée est une lacune de détection que l’environnement gère jusqu’à ce que quelqu’un l’écrive, la teste et la déploie. Quantifier ce coût de maintien est difficile, ce qui explique pourquoi la plupart des équipes l’ignorent et pourquoi la lacune persiste. La feuille de calcul à la fin de cette page fournit la structure pour le calculer.
Comment les petites équipes de sécurité peuvent-elles garder leurs règles de détection à jour face aux nouvelles menaces ?
La contrainte est le temps, non la compétence. Garder des centaines ou des milliers de règles à jour tandis que de nouvelles techniques arrivent continuellement est une charge de travail différente de celle de les rédiger. Une petite équipe ne peut le faire à la vitesse d’émergence des techniques tout en ajustant les règles, en gérant les incidents et en maintenant le SIEM.
Trois réalités accentuent le problème :
- Le volume des techniques dépasse la capacité de rédaction. Les flux de renseignement sur les menaces publient continuellement de nouvelles techniques. Une équipe de un ou deux ingénieurs en détection ne peut pas suivre la cadence tout en gérant tout le reste que le SOC exige
- Le nombre de plateformes multiplie le coût de construction. Deux plateformes SIEM ou EDR signifient que chaque règle nécessite deux implémentations. Trois plateformes, trois. Le coût de construction augmente linéairement avec les cibles.
- La validation est le goulot d’étranglement. Une règle qui parse n’est pas une règle qui fonctionne. Prouver qu’elle fonctionne sur des événements réels ou émulés, et qu’elle produit des preuves auditables est là où le temps va. Sans capacité de validation, le contenu acheté ou construit est également non prouvé.
Le contenu de détection portable aborde directement la couche de commodités. Les règles rédigées dans un format indépendant du fournisseur comme Sigma et traduites pour chaque plateforme cible offrent aux petites équipes une couverture continuellement mise à jour sans rédiger et maintenir chaque règle depuis le départ.
Les ingénieurs de l’équipe se concentrent alors sur les détections qui nécessitent la connaissance de l’environnement : applications personnalisées, sources de télémétrie internes, et logique métier qu’aucune bibliothèque externe ne peut anticiper. Le contenu indépendant du fournisseur réduit l’intervalle entre la publication d’une technique et une détection déployée pour la couche de commodités, libérant la capacité d’ingénierie contrainte pour le travail que seule cette équipe peut faire.
La bibliothèque de détection avancée de SOC Prime fournit des règles de comportement sécurisées pour les menaces émergentes, gérées centralement, déployables à grande échelle, et stockées comme détection en tant que code.
Quels facteurs devrais-je considérer lors du calcul du coût de l’embauche d’ingénieurs en détection par rapport à l’achat de solutions ?
Sept facteurs, chacun une case dans le modèle de coût. Remplissez chacun avec vos propres données. Les estimations comportent des risques : sous-estimer un seul facteur rend l’ensemble du modèle peu fiable.
| Facteur | Que mesurer | Pourquoi cela importe |
|---|---|---|
| Coût chargé par ingénieur | Salaire, avantages, outils, formation, frais de gestion | Économie de base de construction interne |
| Temps de montée en puissance | Mois à partir de la date d’embauche jusqu’à la première règle de production validée | Ingénierie de la détection est spécifique à l’infrastructure |
| Coût de rotation et de réembauche | Taux de rotation multiplié par le coût de montée en puissance par remplacement | Chaque départ réinitialise le chronomètre et rouvre le backlog |
| Coût de maintien du backlog | Règles non écrites multipliées par le risque évalué par écart | Le coût payé tandis que la file d’attente ne bouge pas |
| Nombre de plateformes | Cibles SIEM, EDR, XDR maintenues | Chaque plateforme multiplie chaque construction et chaque mise à jour |
| Fardeau de preuve | Heures de production de documentation d’audit et réglementaire : inventaires des sources de journaux, enregistrements de déploiement de règles, preuves de détection, rapports de couverture datés | Coût réel, que le contenu soit construit ou acheté |
| Objectif de temps de couverture | Heures ou jours entre la publication de la technique et la détection validée déployée | Convertit tout ce qui précède en une exigence de fonctionnement |
Lorsque le coût total de la construction dépasse le coût de l’achat de la couche de commodités plus le coût de la construction de ce qui est unique, la décision est prise d’elle-même. Aucune donnée salariale universelle ou ratio ne s’applique. La réponse dépend de vos chiffres.
Comment puis-je justifier l’investissement dans du contenu de détection auprès du conseil d’administration ou du comité budgétaire ?
Présentez-le pour ce qu’il est : convertir un problème d’embauche variable et difficile à retenir en une ligne d’abonnement prévisible. Le conseil finance la couverture, la vitesse et la réduction des risques. Présentez le contenu de détection comme le mécanisme qui les délivre.
Le talent en ingénierie de la détection est rare, les cycles d’embauche sont longs, et la rotation réinitialise la montée en puissance. Un abonnement à du contenu de détection indépendant du fournisseur convertit une partie de ce coût variable en une ligne fixe que le conseil peut planifier.
Trois métriques que le conseil reconnaît :
- Temps de couverture. La fenêtre entre la publication d’une technique et une détection validée et déployée dans votre environnement. L’achat de la couche de commodités comprime cette fenêtre. Montrez au conseil la fenêtre actuelle et la cible.
- Couverture validée contre MITRE ATT&CK. La part des techniques pertinentes ATT&CK pour lesquelles vous avez une détection prouvée. Mesurable, vérifiable et comparable sur les périodes de reporting. Les conseils approuvent ce qu’ils peuvent suivre.
- Recrutements incrémentaux évités. La capacité d’ingénierie qui devrait être ajoutée pour atteindre la même couverture et le même temps de couverture uniquement par l’écriture interne. Présentez-le comme des effectifs que vous n’avez pas eu besoin d’ajouter
La demande est un abonnement fournissant des gains de couverture mesurables à une vitesse que l’équipe existante ne peut égaler, sans ajout d’effectifs. Le contenu acheté augmente la capacité sans remplacer l’expertise : les ingénieurs cessent de réécrire des règles de commodités que des centaines d’autres équipes rédigent de manière indépendante et se concentrent sur l’investigation, l’ajustement, la réponse aux incidents, et les détections qu’eux seuls peuvent construire.
Quel est le coût de l’écart entre la publication d’une technique et la détection déployée ?
L’écart est la fenêtre durant laquelle une technique est connue, publiée et potentiellement en usage, mais votre environnement n’a pas de détection pour elle. Le coût de cette fenêtre est l’exposition : un attaquant utilisant une technique connue peut opérer tandis qu’aucune détection pour ce comportement n’est en place.
L’écart a une forme :
| Étape | Que se passe-t-il | Ce qui ajoute du temps |
|---|---|---|
| Publication de la technique | Un nouveau TTP apparaît dans un rapport de menace ou ATT&CK mise à jour | Rien. Le chronomètre commence. |
| Rédaction de règles | Un ingénieur écrit une règle pour votre infrastructure | Complexité, profondeur de la file d’attente, priorités concurrentes |
| Traduction | La règle est réécrite pour chaque plateforme supplémentaire | Chaque cible SIEM, EDR ou XDR supplémentaire |
| Validation | La règle est testée pour confirmer qu’elle fonctionne et contrôle les faux positifs | Disponibilité de l’environnement d’émulation |
| Déploiement | La règle validée atteint la production | Processus de gestion du changement |
Chaque étape est séquentielle, donc l’écart est leur somme. Un backlog de règles non écrites signifie que l’écart pour la prochaine technique ne commence pas à zéro. Il commence derrière tout ce qui attend encore.
L’écart se compose de trois manières.
La réponse aux incidents devient plus difficile lorsque la détection initiale était tardive. L’attaquant a eu le temps de se déplacer latéralement et d’établir une persistance.
Les preuves d’audit et réglementaires en souffrent. Le rapport de couverture daté montre un écart pour une technique qui était déjà connue publiquement.
La confiance opérationnelle s’érode lorsque le backlog croît plus vite que l’équipe ne peut le traiter. Cela signale un problème structurel, pas une pénurie temporaire.
Acheter du contenu de détection de commodité compresse les étapes de rédaction et de traduction. Cela n’élimine pas la validation. L’équipe reste propriétaire du dernier kilomètre : confirmer que le contenu fonctionne dans leur environnement et produit les preuves que leurs auditeurs attendent.
Réduire l’écart revient à avoir plus de capacité de rédaction ou une source de contenu couvrant les techniques de commodité plus rapidement que l’équipe ne peut les rédiger et les valider en interne.
Où cela ne tient pas
Le côté achat suppose que du contenu de détection de commodité existe pour vos plateformes et que votre environnement accepte du contenu externe. Le contenu acheté remplace le contenu construit uniquement dans cette limite. Lorsque les conditions échouent, construire est la seule option.
Conditions où l’achat ne s’applique pas :
- Télémétrie propriétaire. Logique de détection liée aux journaux d’applications personnalisées, protocoles propriétaires ou sources de données internes uniquement. Aucun fournisseur externe n’a de visibilité sur ce que seul votre environnement produit.
- Environnements classifiés ou restreints. Environnements nécessitant la révision et l’approbation du contenu externe avant l’ingestion. Le processus de révision peut annuler l’avantage de vitesse.
- Lacunes de couverture de plateforme. Le contenu du fournisseur qui ne se traduit pas pour votre plateforme SIEM, EDR ou XDR est inaccessible.
- Contraintes de sourcing et de provenance. Certains cadres de conformité ou politiques internes nécessitent un contenu de détection rédigé par des individus nommés et vérifiés, ou un contrôle de provenance complet du contenu de détection depuis la rédaction jusqu’au déploiement. Le contenu acheté porte la chaîne de provenance du fournisseur, et certains cadres d’audit considèrent cette distinction comme importante. Vérifiez si vos exigences en matière de preuves acceptent du contenu sourcé à l’extérieur.
Un cas échappe entièrement à la décision. Une équipe sans SIEM fonctionnel ou sans fonction définie d’ingénierie de la détection n’est pas prête pour envisager de construire ou d’acheter. La question suppose un programme de détection fonctionnel, donc les équipes qui établissent encore une collecte de télémétrie de base devraient adresser cela en premier.
Achetez la couche de commodités là où elle fonctionne. Construisez ce qui est unique, restreint ou non pris en charge. Mesurez les deux côtés par le temps de couverture.
FAQ
Mon équipe de sécurité doit-elle écrire nos propres règles de détection ou acheter du contenu de détection ?
Les deux. Achetez la couche de commodités des détections de menaces qui couvrent les TTP largement partagées contre les plateformes communes. Construisez les détections qui nécessitent une connaissance unique à votre environnement : applications personnalisées, protocoles propriétaires, et sources de télémétrie internes. Mesurez la répartition par le temps de couverture.
Comment les petites équipes de sécurité gardent-elles leurs règles de détection actuelles contre les nouvelles menaces ?
Avec un mélange de sources, une cadence de validation, et une fenêtre mesurée de divulgation à détection. Les petites équipes ne peuvent rédiger et maintenir des détections de commodités à la vitesse d’émergence des nouvelles techniques tout en gérant les incidents, ajustant les règles, et maintenant le SIEM. Sourcer la couche de commodités comme du contenu de détection indépendant du fournisseur libère la capacité d’ingénierie contrainte pour le travail que seule cette équipe peut faire.
Comment puis-je justifier l’investissement dans du contenu de détection auprès du conseil d’administration ou du comité budgétaire ?
Présentez trois métriques que le conseil peut suivre : temps de couverture (de la publication de la technique à la détection validée déployée), couverture validée contre MITRE ATT&CK (la part des techniques pertinentes avec des détections prouvées), et recrutements incrémentaux évités (la capacité que l’équipe devrait ajouter pour atteindre une couverture équivalente uniquement par rédaction interne).
Quels facteurs devrais-je considérer lors du calcul du coût de l’embauche d’ingénieurs en détection par rapport à l’achat de solutions ?
Sept facteurs : coût annuel chargé par ingénieur, temps de montée en puissance jusqu’à la productivité sur votre infrastructure, taux de rotation annuel et coût de réembauche, coût de maintien du backlog, nombre de plateformes (chaque cible SIEM, EDR, ou XDR multiplie le coût de construction et de maintenance), fardeau de preuves (heures de documentation d’audit et réglementaire), et cible de temps de couverture. Remplissez chacun avec vos propres données.
L’achat de contenu de détection remplace-t-il l’équipe de détection ?
L’achat de contenu de détection change ce sur quoi l’équipe passe son temps. Les ingénieurs cessent de réécrire des règles de commodités et se concentrent sur l’investigation, l’ajustement, la réponse aux incidents, et les détections qui nécessitent une connaissance spécifique à l’environnement. Le contenu acheté augmente la capacité sans remplacer l’expertise.
Feuille de calcul construire-acheter
Utilisez cette feuille de calcul pour évaluer votre propre environnement. Remplissez chaque case avec vos propres données. Aucune case ne devrait contenir de supposition. Si vous manquez un chiffre pour un facteur, cet écart est lui-même un résultat valant d’être résolu avant la décision.
Étape 1 : Inventaire
| Élément | Votre réponse |
|---|---|
| Plateformes SIEM, EDR et XDR en production | |
| Ingénieurs en détection en personnel (ETP) | |
| Règles rédigées et validées par mois (taux actuel) | |
| Backlog actuel (règles non écrites ou non validées) | |
| Temps de couverture aujourd’hui (technique publiée à détection déployée) | |
| Objectif de temps de couverture | |
| Couverture MITRE ATT&CK aujourd’hui (part des techniques pertinentes) | |
| Couverture MITRE ATT&CK cible de couverture |
Étape 2 : Coût de construction (annuel)
| Élément | Votre chiffre |
|---|---|
| Coût annuel chargé par ingénieur en détection | |
| Ingénieurs en détection nécessaires | |
| Temps de montée par nouvelle embauche (mois) | |
| Taux de rotation annuel | |
| Coût de réembauche et de remontée par départ | |
| Coût de maintien du backlog (annuel estimé) |
Étape 3 : Coût d’achat (annuel)
| Élément | Votre chiffre |
|---|---|
| Abonnement au contenu de détection | |
| Traduction et intégration de plateformes | |
| Travail de réglage et validation internes |
Étape 4 : Facteurs de décision
| Facteur | Score (1 à 5) | Notes |
|---|---|---|
| Unicité de la télémétrie (5 = très unique, 1 = commodité) | ||
| Suffisance de l’effectif (5 = pleinement personnel, 1 = aucun ingénieur en détection) | ||
| Capacité de validation (5 = pipeline complet, 1 = aucun processus de validation) | ||
| Écart de temps de couverture (5 = dans les délais, 1 = semaines de retard) | ||
| Complexité de la plateforme (5 = plateforme unique, 1 = cinq ou plus) | ||
| Fardeau de preuves (5 = minimal, 1 = exigence réglementaire lourde) |
Étape 5 : Décision
Répondez à ces questions à partir des totaux et scores ci-dessus :
- Le coût annuel de construction dépasse-t-il le coût d’achat plus le coût de construction uniquement pour ce qui est unique ?
- Le temps de couverture actuel dépasse-t-il l’objectif ?
- L’équipe actuelle peut-elle maintenir la cadence requise de rédaction et de validation ?
Puis lisez les scores :
- La plupart des facteurs marquent 1 à 2 : acheter du contenu de détection de commodités répond à l’écart de capacité.
- La plupart des facteurs marquent 4 à 5 : l’équipe a la capacité et l’unicité nécessaires pour construire.
- Scores mixtes : achetez la couche de commodités, construisez ce qui est unique, et mesurez les deux par le temps de couverture.
Aucun ratio prédéfini ne s’applique. La feuille produit votre réponse.
Architecte de SOC Prime, un agent IA conçu pour construire des détections, les adapter à la langue de votre SIEM, rechercher des menaces, développer des chasses et bien d’autres outils dont les ingénieurs en détection ont besoin.
