SOC / SOC-04
Ingénierie de la détection et amélioration des règles
Concevoir et maintenir des règles de détection liées aux risques clients, avec des procédures de test et d'investigation. L'objectif est d'obtenir des alertes utiles et explicables plutôt qu'un catalogue incontrôlé de règles activées.
QUAND C'EST UTILE
Une réponse ciblée
à un besoin défini.
Faux positifs excessifs, angles morts connus, menaces changeantes ou nécessité de vérifier que les contrôles revendiqués génèrent effectivement des alertes exploitables.
PORTÉE ET RÉSULTATS
Ce que couvre la mission.
Portée
- Scénarios prioritaires
- disponibilité des données
- requêtes et corrélations
- enrichissement
- test
- documentation d'analyste
- exceptions
- gestion des versions
- maintenance par le changement
Livrables
- Spécifications de détection
- règles versionnées
- cas de test
- guides d'enquête
- carte de couverture
- carnet de commandes
- métriques de qualité et retours opérationnels
Preuve de réception
Chaque règle de priorité a un test, un responsable et une procédure ; les résultats attendus sont observés ; les faux positifs sont documentés ; les limites de couverture sont explicites.
LIVRAISON
Comment le travail est structuré.
Approche
Définir le périmètre du service et des rôles ; connecter et valider les données ; tester les scénarios ; démarrer les opérations ; mesurer et améliorer.
Prérequis et responsabilités
Client : actifs, journaux, contacts et autorité de réponse. Fournisseur : collecte/analyse selon le contrat. Les décisions opérationnelles et la reprise sont explicitement attribuées.
Facteurs de portée
Actifs, sources, événements, volume, rétention, intégrations, heures et niveau de réponse. Intégration, licences, consommation et service récurrent séparés.
Questions à clarifier
Quels scénarios commerciaux comptent le plus ? Les données requises existent-elles ? Comment mesure-t-on la pertinence des alertes et l'effort d'analyse ?
LIMITES IMPORTANTES
Un mappage MITRE ATT&CK ne prouve pas une détection exhaustive. La qualité de la collecte, les variations comportementales et les changements de version doivent être pris en compte.
Heures et temps de réponse uniquement après approbation contractuelle. Aucun taux de détection ni de résolution garanti ; les lacunes de collecte et les sources défaillantes restent visibles dans les rapports.
EN PRATIQUE
Situations illustratives.
Ces exemples décrivent des engagements possibles et des résultats cibles. Il ne s'agit pas de références clients ni de résultats obtenus.
Scénario 01
Un SOC reçoit des milliers d'alertes de connexion. Projet : ajouter du contexte, des privilèges et des exceptions légitimes. Résultat visé : des alertes mieux ciblées, mesurant le bruit avant et après au lieu d'inventer un chiffre de réduction.
Scénario 02
Une entreprise souhaite détecter les modifications de permissions sensibles. Projet : définir des événements et des tests avec les administrateurs. Résultat attendu : les modifications de test sont détectées ; les applications manquant de journaux adéquats sont enregistrées comme des lacunes techniques.
Contexte technologique et de référence
Références : capacités de recherche, de corrélation et de test de MITRE ATT&CK du SIEM/EDR sélectionné.
L'ensemble final des technologies est convenu lors du cadrage, sur la base de l'interopérabilité, des licences, des droits d'accès et des exigences opérationnelles.
SERVICES CONNECTÉS
Construisez l'étape suivante.
Ces services peuvent compléter la mission. Ils ne sont pas inclus automatiquement.
Commencer une conversation
Clarifiez la portée.
Nous clarifierons l'objectif, les dépendances et les responsabilités de ce service avant de proposer la livraison.