5 bonnes façons de rater un projet de SOC

mySOC & Security-as-a-Service
5 bonnes façons de rater un projet de SOC

Le déploiement d’un SOC est un chemin pavé d’embûches. De nombreuses organisations se sont lancées dans une telle aventure, avec un résultat qui n’a pas été satisfaisant… ou malheureusement pas assez de résultat pour convaincre ! Pour être sûr de (ne pas) y arriver, voici notre top 5 des bonnes façons de rater un projet SOC. Prenez des notes, ça peut être utile !

 

  • #1 : Vouloir un cyberSOC 2.0 prédictif qui voit tout…

« Je veux un SOC qui détecte tout, qui analyse tous les logs, de tous les équipements, sur l’intégralité du groupe et dans toutes les filiales… et qui s’appuie sur l’intelligence artificielle et la cyber-threat intelligence pour détecter ce à quoi je n’ai pas encore pensé »

A trop en faire, on oublie les bases. Concentrons-nous sur quelques règles d’hygiène, sur un périmètre maitrisé, puis étendons progressivement les capacités d’analyse et les périmètres surveillés.

 

  • #2 : Faire du SOC une problématique technique pour et par la technique

« Le SOC,  c’est un SIEM managé qui va alerter la prod en cas d’incident au niveaux des firewalls…»

Le SOC doit être plus ambitieux que ça, même s’il faut commencer simple et efficace. C’est un dispositif complet de protection et de surveillance. Et n’oublions pas nos fondamentaux : le plan de surveillance du SOC se construit en réponse à des risques, directement issus de la compréhension des enjeux Sécurité des métiers de votre organisation.

 

  • #3 : Ne pas piloter le sujet et penser que ça va se déployer tout seul 

« C’est facile : je transmets la liste des adresses IP à l’équipe SOC et après c’est bon. »

Tout le monde sait que chaque organisation dispose d’une cartographie à jour et exhaustive de son SI. A l’heure des clouds et de l’IoT, c’est encore plus simple qu’avant. Et quand bien même la cartographie sera prête, qu’en est-il du reste ? A-t-on une idée des actifs vraiment critiques ? Comment traduire les risques métiers en un plan de surveillance pertinent ?

 

  • #4 : Ne pas inscrire le projet dans une stratégie plus globale

« Je veux un  SOC, tous mes copains et copines du club de RSSI en ont un et pas moi ! »

Déployer un SOC par principe sera un sacré challenge si l’organisation n’est pas mature. Le SOC ne tourne pas tout seul. Sa mise en œuvre va s’accompagner d’une charge de travail, impactant différentes équipes (pas le RSSI uniquement, ni la « prod » au sens strict). Et ce dispositif s’inscrit dans une démarche de sécurité, qui se doit d’être complète et équilibrée. La prévention et la réaction vont toujours de pair !

 

  • #5 : Ne pas en faire un projet… et s’appuyer sur les équipes de run pour faire le build

« C’est bon : le prestataire va installer le SOC rapidement et ensuite c’est les équipes de RUN qui vont le déployer et s’en occuper ! »

La mise en place d’un SOC doit se traiter en mode « projet », avec un début et une fin, avec différentes équipes et des jalons qui vont marquer l’avancement des étapes clés (test technique, test fonctionnel, conduite du changement, etc.). Ces activités ne sont pas toujours les plus faciles pour les équipes de « run », parfois trop peu habituées au mode projet ou parfois tout simplement indisponibles pour traiter le sujet.

 

En conclusion dans « projet de mise en place d’un SOC », il y a « projet » : il est essentiel d’aborder ce projet comme tous les autres, avec une méthode et un accompagnement adaptés à votre contexte. Pour en savoir plus sur le sujet, nous vous partagerons prochainement quelques retours d’expérience et bonnes pratiques pour faire de votre projet de SOC une réussite - et une étape structurante de votre démarche de sécurité !

 

Benjamin Leroux, Innovation & Marketing, Advens