Qui a besoin d’un centre d’opérations de sécurité (SOC)?
Quelle que soit la taille ou l’objectif d’une entreprise, il est précieux d’avoir une équipe dédiée au niveau de l’organisation dont le travail consiste à surveiller constamment les opérations et les incidents de sécurité et à répondre à tous les problèmes qui peuvent survenir. Les diverses responsabilités au sein d’une équipe de cybersécurité peuvent être extrêmement complexes, et un SOC peut non seulement servir de console tactique pour donner aux membres de l’équipe les moyens d’accomplir leurs tâches quotidiennes, mais aussi de centre stratégique pour tenir l’équipe au courant des tendances de sécurité plus importantes et à plus long terme.
Un centre d’opérations de sécurité typique suit un nombre quelconque d’alertes de sécurité qu’une organisation peut rencontrer, y compris les notifications de menaces potentielles via les technologies et les outils, ainsi que les employés, les partenaires et les sources externes. À partir de là, le SOC enquête ensuite et valide la menace signalée pour s’assurer qu’il ne s’agit pas d’un faux positif (c’est-à-dire une menace signalée qui est en fait inoffensive). Si l’incident de sécurité est jugé valide et nécessite une réponse, le SOC le transmet aux personnes ou aux équipes appropriées pour la réponse et la récupération.
Il faut une combinaison sophistiquée d’expertise, de processus et d’organisation pour gérer efficacement un centre d’opérations de sécurité dans le cadre d’un programme global de détection et de réponse aux incidents. C’est pourquoi chaque organisation peut ne pas être en mesure de prendre en charge ou d’affecter des ressources à un SOC en interne. Au lieu de cela, beaucoup choisissent de faire gérer leur SOC par une agence externe ou même de l’externaliser complètement.
Préparer les bases
Il y a un certain nombre de composants de soutien qui doivent être en place avant qu’un SOC soit une option viable pour une organisation. Le premier est d’avoir un bon programme de gestion de la surface d’attaque. Cela comprend une technologie de prévention des menaces pour toutes les voies d’entrée et de sortie des menaces, une analyse régulière des vulnérabilités (et les correctifs associés), des pen tests, l’authentification et l’autorisation des utilisateurs, la gestion des actifs, les tests des applications externes (avec les correctifs associés) et la gestion des accès à distance.
Suivant, il faut avoir un plan de réponse aux incidents. Généralement, l’un des principaux objectifs de l’introduction d’un SOC dans un programme IDR est d’augmenter l’efficacité de la détection des menaces dans l’environnement de l’organisation. Si les processus de réponse aux incidents qui suivent la découverte d’une brèche ne sont pas en place et testés régulièrement, vous n’abordez que certaines composantes d’un programme IDR efficace.
Enfin, il est important de disposer d’un plan de reprise après sinistre. Une brèche n’est qu’un exemple spécifique d’un désastre dont les organisations doivent se remettre. Une fois que la brèche détectée a été entièrement délimitée et que les actifs, les applications et les utilisateurs affectés ont été contenus, il faut mettre en place un plan pour rétablir les processus normaux de fonctionnement de l’entreprise. C’est la reprise après sinistre.
Démarrer
Compte tenu de la complexité inhérente à un centre d’opérations de sécurité, il y a beaucoup de choses à prendre en compte lors de sa mise en place. Qu’il soit créé en interne ou externalisé, la préparation des trois éléments suivants est essentielle à la réussite du SOC :
- Personnes : La compréhension des rôles et des responsabilités des analystes du SOC est un précurseur important du choix de la technologie qui fera fonctionner votre SOC. Les équipes que vous créez et les tâches que vous leur confiez dépendront de la structure existante de votre organisation. Par exemple, si vous créez un SOC pour renforcer les capacités existantes de détection et de réponse aux menaces, vous devrez déterminer les tâches spécifiques dont les membres de l’équipe SOC sont responsables et celles qui incombent aux équipes IDR non-SOC. Vous voudrez également répartir les responsabilités entre les analystes du SOC, afin de savoir clairement qui traite les alertes de haute fidélité, qui valide les alertes de basse fidélité, qui transmet les alertes, qui recherche les menaces inconnues, etc. De nombreux centres d’opérations de sécurité fonctionnent avec un cadre à plusieurs niveaux pour le personnel afin d’aider à établir des responsabilités et une hiérarchie claires.
- Technologie : Décider quelle technologie le SOC utilise est l’endroit où le temps passé à établir les rôles et les responsabilités mentionnés ci-dessus sera payant. Quelle technologie utiliseront-ils ? Probablement, ils devront combiner des outils pour l’agrégation des journaux, l’analyse du comportement des utilisateurs, l’interrogation des points d’extrémité, la recherche en temps réel, et plus encore. Il sera important d’examiner comment les analystes du SOC utilisent votre technologie et de déterminer si la technologie existante aide ou entrave les processus du SOC, et si une nouvelle technologie devra la remplacer. En outre, il sera important de mettre en place des outils de communication qui permettent aux analystes de collaborer.
- Processus : L’établissement des processus que les personnes et la technologie décrites ci-dessus suivront est le dernier élément que vous devrez prendre en compte lorsque vous démarrez avec un SOC. Que se passe-t-il si un incident de sécurité doit être validé, faire l’objet d’un rapport, être remonté ou transmis à une autre équipe ? Comment allez-vous collecter et analyser les mesures ? Ces processus doivent être suffisamment précis pour garantir que les pistes d’investigation sont traitées par ordre de criticité, mais suffisamment souples pour ne pas dicter les processus d’analyse. Les processus peuvent faire ou défaire l’efficacité d’un SOC et valent la peine de faire l’effort de bien faire les choses.