Services / 01
Opérations de sécurité
Nous concevons et construisons les systèmes sur lesquels un centre opérationnel de sécurité fonctionne réellement : l'architecture de la plateforme, la télémétrie qui l'alimente, le contenu de détection qui s'exécute dessus, et l'automatisation qui maintient l'ensemble gérable à mesure qu'il grandit. L'accent porte sur une détection que l'on peut tester, versionner et raisonner, plutôt qu'accumuler.
Le problème
La plupart des problèmes d'opérations de sécurité se présentent comme des problèmes de détection et se révèlent être des problèmes d'ingénierie. Les règles s'accumulent plus vite que quiconque ne peut les retirer. La couverture est affirmée à partir d'un nombre de règles plutôt que mesurée face à un modèle de menace. Le contenu vit dans une console, donc il ne peut être ni revu, ni testé, ni annulé. Et sous tout cela, la télémétrie dont dépend la détection a été intégrée au fil de l'eau plutôt que conçue.
La conséquence est un SOC qui devient à la fois plus coûteux et moins lisible. Ajouter une source devient un projet. Modifier une règle devient un risque. Personne ne peut dire ce qui se passerait si telle technique était employée, parce que la question suppose de savoir quelles données existent, sous quelle forme et avec quelle fidélité — et cette carte n'existe pas.
Compétences
Ce que couvre ce pilier.
Regroupées par partie du système sur laquelle elles agissent.
Architecture
- Conception et architecture SOC
- Ingénierie SIEM
- Architecture Splunk
- Modernisation du SOC
- Observabilité du SOC
Détection
- Detection engineering
- Detection-as-code
- Détection des menaces
- Analytique de sécurité
- Alerting fondé sur le risque
Automatisation
- Automatisation de la sécurité
- Conception SOAR
- Ingénierie des workflows de réponse
Approche
Comment se déroule une mission.
La séquence compte davantage que l'outillage. Sauter une étape en reporte le coût, cela ne le supprime pas.
- 01
Évaluer
Établir ce qui existe : sources, pipelines, topologie de la plateforme, inventaire de détection, et où se situe réellement la douleur opérationnelle. L'évaluation est une collecte de preuves, pas un exercice de notation.
- 02
Architecturer
Concevoir l'état cible et — plus important encore — la séquence qui y mène sans gel de production. Chaque décision est écrite avec la contrainte qui l'a motivée.
- 03
Construire
Le réaliser : plateforme, pipelines, contenu de détection, tests et automatisation. Le contenu est livré sous forme de code, dans votre dépôt, sous votre contrôle.
- 04
Transférer
Transmettre avec documentation, runbooks et sessions de travail. La mesure du succès est que votre équipe puisse étendre le système sans nous.
Ce que vous recevez
Des livrables concrets, dans vos dépôts et sur vos plateformes.
- Une architecture SOC et SIEM cible, avec le chemin de migration depuis votre situation actuelle
- Un dépôt de detection-as-code : contenu sous contrôle de version, avec tests, revue et pipeline de déploiement
- Une couverture de détection cartographiée sur un modèle de menace plutôt que sur un nombre de règles
- Une conception d'alerting fondé sur le risque — comment les signaux s'agrègent en quelque chose qui mérite l'attention d'un analyste
- L'automatisation du travail répétitif qui, sans elle, plafonne la capacité d'un SOC
- L'observabilité de la plateforme : le SOC est-il lui-même en bonne santé, et comment le sauriez-vous s'il ne l'était pas
Résultats attendus
Des propriétés du système obtenu — pas des chiffres de performance, qui dépendent de votre patrimoine et non de nous.
- Un contenu de détection versionné, testé et relisible comme n'importe quel logiciel
- Une couverture exprimée face à un modèle de menace, avec les manques énoncés plutôt que masqués
- Une architecture de plateforme qui survit au prochain doublement du volume de données
- Moins d'alertes, mais meilleures — parce que l'agrégation est conçue et non subie au triage
- Une équipe capable d'étendre le système sans ceux qui l'ont construit