Admin CliCours
Télécharger le fichier original (Mémoire de fin d’études)
Les phases de déploiement d’un SOC
La phase de conception (design)
La plupart des SOC sont construits en réponse à un contexte réglementaire, une contrainte légale ou suite à une prise de conscience du contexte d’insécurité et de menaces ambiant (parfois même en écho à un sinistre passé qui aurait pu être prévenu par un dispositif SOC. La mise en place d’un SOC est un projet d’envergure (donc généralement visible et suivi par les instances de direction) sur lequel viennent donc s’ajouter des contraintes de planning relativement fortes. Le SOC doit être mis en place, rendu opérationnel et efficace dès que possible pour pouvoir justifier les investissements (CAPEX/OPEX) et les changements d’organisation.
Ces contraintes de planning rendent difficile l’adoption d’une méthodologie réfléchie et partagée en termes de conception, de choix des outils, de recrutement des compétences pour construire et exécuter les services de SOC.
La phase de conception/design doit, a minima, traiter les sujets suivants :
Définition du périmètre technique
o Outils déjà mis en œuvre et périmètre déjà couvert
o Procédures techniques existantes (infrastructures, applicatifs, sécurité ou non) o Processus organisationnels (gestion de crise, astreintes, escalades, …)
Définition du périmètre organisationnel
Mise en place d’un security operation center basé sur un SIEM open-source (Alienvault OSSIM)
Définition de l’organisation cible
Si l’étude de cadrage est le point de départ de tous les travaux, ces réflexions préliminaires sont néanmoins particulièrement importantes et permettent de fédérer les acteurs principaux autours du projet.
L’étude de cadrage
En fonction du périmètre considéré et des activités/organisation de l’entreprise, une première phase de cadrage/opportunité peut être organisée.
Cependant, l’organisation d’un tel projet (pour une Entreprise, par définition, novice dans le domaine) se révèle généralement complexe et chronophage. La recommandation est alors de ne pas hésiter à se faire accompagner par une assistance à maitrise d’ouvrage pour cadrer les débats et préconiser les solutions techniques et organisationnelles pour faire avancer le projet. La première étape est d’exprimer le besoin de mise en œuvre du SOC et de fixer ses objectifs :
Pourquoi un SOC pour l’Entreprise ?
Faut-il un unique SOC ou plusieurs SOC (un dans chaque branche/domaine/entité) ?
Tout le périmètre doit-il être couvert ? Faut-il se concentrer sur certains périmètres sensibles ?
Quelles sont les activités opérationnelles en plus de la supervision confiées au SOC ?
Quelles sont les technologies utilisées et pressentie pour outiller le SOC ?
Faut-il externaliser le service SOC ou l’internaliser ?
Faut-il conduire un POC ou construire le SOC ex-nihilo ?
L’étude de cadrage est également l’occasion de répondre et de contrôler les prérequis :
Existence d’une ou plusieurs PSSI accompagnée de directives de sécurité.
L’identification des principaux risques et des menaces associées
La mise en œuvre des mesures de sécurité de base (hygiène SSI).
La seconde étape de l’étude de cadrage se concentre sur les besoins SSI couverts par le SOC :
Liste des « use cases » standards portés par le SOC
Construction des scénarios de menaces métiers à couvrir
Etude Spire ou autres analyses de risques
Quel temps de rétention des différentes traces collectées ?
Une fois les besoins évalués, l’étude de cadrage se focalise sur la compatibilité technique et organisationnelle du S.I. existant avec la mise en œuvre d’un SOC. Les éléments suivants viennent donc compléter l’étude de cadrage :
Revue de l’architecture sécurisée existante
Existence et disposition des serveurs de temps
Gestion des journaux d’événements et périmètre de collecte
Volumétrie des journaux actuellement collectés / Durée de rétention.
Vérification de la politique des logs (verbosité, chiffrement, signature)
D’un point de vue organisationnel, cette dernière partie de l’étude de cadrage se concentre sur :
L’organisation du projet (RACI)
La définition du périmètre métier adressé et couvert par le SOC (cf. première étape)
Définition du socle de base des équipements supervisés :
o Passerelles internet et de messagerie
o Système de détection/prévention d’intrusions (IDS/IPS) de flux et de postes o Active Directory (et annuaires d’entreprises)
o Anti-virus de flux et de poste
Périmètre organisationnel
Mise en place d’un security operation center basé sur un SIEM open-source (Alienvault OSSIM) Les aspects organisationnels traités pendant la phase de conception concernent à la fois l’organisation de l’équipe de construction et d’exécution mais aussi les autres entités qui doivent être mobilisées pour la conduite du projet (pendant la phase de construction mais aussi pendant la phase d’exécution).
Le « noyau » de l’équipe du SOC et les principaux interlocuteurs du service doivent être identifiés fonctionnellement et nominativement. Généralement, ces acteurs sont :
Le/les DSI Le/les RSSI
Le/les responsables des risques & de l’audit Le/les architectes réseaux/système
Le/les responsable du SOC
Le/les responsables d’équipe opérationnelle Les analystes
En plus de l’identification précise des acteurs concernés par le projet, la conception doit proposer au moins une trajectoire de mise en place d’un SOC :
périmètre technique et métier couvert, volumétrie collectée et traitée,
agilité dans la supervision et la réaction, montée en efficacité.
Cette trajectoire, doit notamment permettre de convaincre et de justifier les investissements tout en fournissant une feuille de route pour les prochains mois/années d’activités du service. La phase de conception est également le moment le plus indiqué pour communiquer auprès des équipes techniques et métier.
Pour les personnels de l’IT, il faut communiquer sur l’évolution de l’organisation induite par la mise en œuvre d’un tel service. L’idée principale de cette communication est que : la mise en œuvre d’un SOC ne doit pas être vécue par les personnels de l’IT comme une perte de contrôle ou une observation à charge des opérations des équipes IT mais comme un complément et une aide.
Pour les personnels métiers, et en fonction des RACI discutés pendant les ateliers de conception, il faut communiquer sur l’arrivée de ce nouvel acteur et sur les nouveaux circuits de communication (ou sur les modifications à venir). Là encore, le SOC ne doit pas être perçu comme un observateur à charge mais bien comme une aide complémentaire dans la supervision des activités.
Un projet de SOC de par sa nature de « transformation des activités » génère des frictions et des adhérences fortes avec les activités courantes. La communication est le remède et le catalyseur qui limite ces frictions.
Périmètre technique
La conception technique du SOC doit se concentrer sur le choix des outils en fonction des équipements à surveiller. La collecte et les opérations de supervision doivent être considérées dans cette étude de conception.
Pour la collecte, la base du travail de conception est d’identifier et de localiser les outils déjà mis en œuvre sur le S.I. : IDS/IPS, pare-feu, détection de fuite de données, boitiers de chiffrement, antivirus, anti-spam, contrôles d’accès et d’identité… Chaque outil doit être associé à son/ses responsables et aux objectifs de sécurité poursuivis.
Cependant compte tenu des cas d’utilisations et des objectifs du SOC, il faut éviter à tout prix de noyer les opérations de collectes par un volume d’événements trop important et non pertinent.
Pour les opérations de supervision, l’étude de conception doit permettre de choisir l’outil majeur et les outils satellites(secondaires) permettant de recevoir, trier, qualifier/prioriser, suivre et traiter les incidents de sécurité. Ces outils doivent être adaptables et paramétrable par rapport aux contraintes de l’Entreprise. Sont notamment à prendre en compte :
Compatibilité avec le ou les SIEM mis en œuvre ;
Capacité à prioriser les incidents en rapport avec les échelles gravité/impact de l’Entreprise ;
Echange et interactions avec d’autres SOC (entités de sécurité de l’Entreprise)
Pour faciliter les opérations de supervision, la liste des actifs critiques de l’Entreprise (serveurs, bases de données, annuaires, …) peut être constituée si elle n’existe pas déjà. Cette identification peut être pilotée/validée par les métiers en fonction de leur propre gestion des risques.
La phase de construction (buld)
La phase de construction se concentre dans un premier temps sur la collecte et le traitement des événements existant. Il s’agit du socle primaire. Sa construction est séquentielle :
Collecte des journaux d’événements (déjà concentré une première fois par le SIEM) Construction des scénarios de corrélation et implémentation dans le SIEM
Alimentation du SOC en événements et résultats des corrélations.
En complément de ce socle, la construction considère :
L’identification des profils des opérateurs/acteurs du SOC Les moyens de réaction
Elaboration de scénarios de menaces et des priorités de traitement
Pilotage du niveau de sensibilité (pour améliorer la qualité de l’alerte)
Collecte
La construction du système de collecte est une activité très dépendante de la technologie (des éléments collectés et des solutions de collecte elles-mêmes). Des prérequis techniques parfois complexes à mettre en œuvre (tels que l’horodatage synchronisé de tous les événements) doivent avoir été vus et discutés en phase de conception technique.
Dans le cadre de la mise en œuvre d’un SOC, la collecte des données doit être réalisée dans l’objectif d’alimenter le service de supervision. Les événements doivent ainsi être formatés pour être exploitables – il faut donc généralement les adapter pour les rendre compatibles avec les objectifs de sécurité du SOC (notez que le SIEM est généralement déployé bien avant les études ou la mise en œuvre d’un SOC dans l’Entreprise). Dans un premier temps, la collecte concerne :
les équipements de sécurité les applications
les équipements réseaux
Déployer la collecte sur un périmètre complet est un projet ambitieux.
Compte tenu de la difficulté de la mission, la gestion de projet doit éviter à tout prix l’« effet tunnel » en privilégiant les « mini-succès ». Ce lotissement peut s’appuyer sur les besoins de détection exprimé dans le cadrage du SOC (identification des scénarios de menace, identification des sources concernées par les scénarios d’attaque, collecte des événements permettant la détection du scénario).
En complément de la collecte, le projet doit veiller à :
la normalisation des événements collectés pour permettre leur exploitation ;
le stockage des événements collectés (dans le respect des contraintes réglementaires) ; o en tenant compte de la localisation du stockage l’archivage des événements collectés.
o en tenant compte des obligations de non-répudiation et d’intégrité des données
Traitement
Le traitement a pour objectif de s’attacher à la détection des risques les plus redoutés par la structure.
Cependant ce traitement des événements de sécurités produit souvent un nombre important de faux positifs.
Le traitement des événements de sécurité, pour être efficace et réduire le nombre de faux positifs, il est nécessaire de créer des scénarios métiers qui s’appuient sur des règles de corrélation issues des applications métiers et d’infrastructure (équipements).
Le traitement des règles se doit d’être un processus industriel afin de s’assurer qu’aucune menace ne soit oubliée. Le processus de traitement est basé sur la norme ISO 27035 (gestion des incidents de sécurité d’un SOC).
La structure de traitement est décomposée en niveaux 1/2/3. L’intérêt de ces niveaux est de s’assurer que tous les incidents sont traités par les personnes les plus compétentes sur le sujet. Ainsi le niveau 1 va traiter les incidents les plus simples et déclencher le N2 sur les incidents plus compliqués. Le N3 intervient sur les incidents complexes. Le passage d’un niveau à l’autre est appelé processus de triage.
Le processus de triage est basée sur le temps de traitement d’un incident, des complexité ainsi que de sa criticité. L’objectif du triage est d’adresser les incidents aux personnes les plus compétentes pour les gérer et cela dans les meilleurs délais.
Le SOC apporte une protection inégale suivant les types de menaces. En ce qui concerne la fuite d’informations, la compromission de systèmes, la protection contre les malwares, les APT(advanced persistent threat) et les menaces ciblées, le SOC reste la meilleure des solutions pour la cyber-protection.
(Run) la phase de fonctionnement nominale d’un SOC
Un SOC, comme tout outil de sécurité, doit s’inscrire dans la roue vertueuse de Deming (ou PDCA : Plan Do Check Act). Pour ce faire il convient de prendre en compte le processus métier de gestion des incidents de sécurité.
La mission première du processus d’amélioration continue reste le maintien en conditions opérationnelles du SOC par rapport aux objectifs de sécurité qu’il remplit.
Maintenir le fonctionnement nominal d’un SOC et le pérenniser est une tâche complexe et importante qu’il faut prendre en compte dès la conception du SOC. Elle doit être portée par une volonté managériale forte sous l’exécution d’un manager fort et proche de ses équipes pour pouvoir être réalisée dans des conditions optimales.
L’évaluation de l’efficacité du SOC
La mesure de performance d’un SOC doit être faite en fonction des missions et de l’engagement du SOC. Ce dernier peut en effet avoir :
Un engagement de résultats portant sur la détection et la réaction à des scénarios prédéterminés validés et testés. En complément, le SOC doit mettre à disposition les meilleurs efforts à la détection de nouveaux scénarios d’attaque. Cet engagement est le plus fréquemment mis en œuvre car il est facilement mesurable et induit l’obtention d’un niveau minimum de sécurité ;
Un engagement de moyen portant sur la mise à disposition de ressources et de capacités d’analyse. Ce modèle est très rarement mis en œuvre bien que plus efficace dans la détection d’APTs car il repose avant tout sur la gestion et l’encadrement d’équipe.
Quelle que soit l’engagement choisi pour son modèle, un SOC doit pour démontrer son efficacité répondre à la question : « Comment garantir que l’Entreprise est mieux protégée ?
Il dispose pour ce faire de plusieurs axes de réponse :
1. Démontrer sa conformité au contrat : Test des scénarios d’attaque convenus et dont la détection et le traitement ont été implémentés au niveau du SOC. Cette recette des scénarios prédéterminés se concentre sur le comportement adopté par le SOC face à la situation, depuis la collecte/détection jusqu’à la remédiation ;
2. Démontrer sa capacité opérationnelle de gestion d’incident au travers de simulations : Tests internes/externes sur les scénarios de menaces (contractuels et de l’état de l’art). Cette démonstration est effectuée en observant les réactions du SOC face aux stimuli non annoncés (pertinence de la détection, temps de détection et de traitement de bout en bout, envergure de la réaction, …) ;
3. Mettre en avant les retours d’expérience internes : Partage des conclusions des attaques déjouées ou subies ;
4. Se comparer avec les autres établissements SOC sur les indicateurs de performances. L’évaluation par la conduite de test d’intrusion sur les scénarios de menaces couvert par le SOC est désormais une bonne pratique courante qui offre l’avantage d’alimenter le SOC en nouveaux scénarios d’attaque au plus proche de la réalité. Cette approche en plus de s’inscrire dans la méthodologie ISO d’amélioration continue fournie des retours d’expérience en conditions quasi réelles permettant ainsi au SOC de s’évaluer de manière indépendante. Il ne faut néanmoins pas oublier que ce type de tests bien qu’au plus proche de la réalité, ne remplace pas une attaque réelle qui est souvent par nature complexe et qui implique parfois des contre-feux pour occuper le SOC.
Indicateurs de performance
Il est fortement conseillé d’utiliser des indicateurs standards de place qui en plus d’avoir été conçu par une communauté d’experts, permettent de comparer l’efficacité et l’efficience de son SOC par rapport au marché. De plus dans le cas d’un SOC info-géré, la capacité du prestataire à produire et traiter facilement ces indicateurs est un bon critère d’évaluation de maturité.
Les indicateurs de performances doivent être revus à minima mensuellement par le responsable en charge du SOC (ou SOC leader) pour lui permettre d’avoir une vision factuelle et objective du service fourni. Il doit ensuite restituer les plus pertinents avec son analyse dans les différents comités de pilotage.
Le tableau de bord qu’il produit est généralement constitué d’un transparent avec les indicateurs clés suivi d’un ou plusieurs transparents où sont mis en avant des indicateurs particuliers avec leur analyse. Les indicateurs clés de performance doivent permettre d’évaluer synthétiquement les capacités du SOC et leurs évolutions potentielles.
Vulnérabilités
Un SOC ne doit pas être un moyen aval de ne pas régler un problème de sécurité amont. Pour ce faire il doit participer autant à la correction des vulnérabilités et des faiblesses du SI. Cette participation doit se faire à minima dans le pilotage de l’analyse des causes racines des incidents majeurs ou des incidents répétitifs.
Il peut donc ainsi être également évalué par rapport au nombre de vulnérabilités qui sont corrigées au sein du SI, même si cette correction ne dépend pas directement de ses attributions.
Tickets
Un ticket d’incident peut se résumer comme étant une fiche de suivi de l’incident qui permet de lui attribuer un responsable de sa résolution et d’assurer sa résolution. Il est le livrable métier du SOC, et doit donc en ce sens être évalué.
Incidents
L’une des missions principales du SOC est d’assurer le pilotage de la résolution des incidents de sécurité. À ce titre, il est indispensable de s’assurer que l’ensemble des tickets d’incident ont été clôturés avec les informations nécessaires pour comprendre les raisons de cette clôture. Ce suivi s’effectue au travers de l’indicateur du reste à faire et par échantillonnage sur les tickets fermés. Notons également que dans certaines circonstances l’entreprise à l’obligation de déclarer ses incidents de sécurité.
Parmi les législations en vigueur imposant la déclaration d’incident de sécurité, nous retiendrons les suivantes :
France : Obligation de notification des incidents de sécurité informatique pour les OIV (Opérateur d’Importance Vitale) ;
USA : Obligation de déclaration en cas de fuite de données contenant des informations personnelles ;
Singapour : Obligation de notification auprès des clients ainsi que de l’autorité de régulation locale (le MAS : Monetary Authority Of Singapore) ainsi qu’à la police en cas de piratage et d’intrusion informatique.
Table des matières
Introduction Général
Première partie : Cadre méthodologie et théorique
Chapitre I : Présentation du sujet
Chapitre II : Les phases de déploiement d’un SOC
Deuxième partie : Etude et mise en oeuvre d’OSSIM
Chapitre III : Etude de la solution OSSIM (Open Source Security Information Management)
Chapitre IV : Mise en oeuvre de la solution OSSIM
Conclusion Générale
Webographie
Bibliographie
