Direction de la sécurité Orange Business Services Novembre 2013 Les progrès réalisés par l’entreprise à travers la mise en œuvre d’un Centre de Supervision de la Sécurité Stéphane SCIACCO Direction de la sécurité Orange Business Services Novembre 2013

AGENDA Introduction Description d’un service de supervision de sécurité Apports Evolutoin de la maturité Coûts Externalisation Conclusion

Introduction

Problème, besoins et enjeux Le problème n’est pas : « De savoir si nous allons nous faire attaquer MAIS de détecter quand cela va se produire » besoins identifiés par la direction de la sécurité du groupe : Renforcer la sécurité Des réseaux d’entreprise Des plates-formes de service les enjeux pour Orange : Protéger l’image de marque Orange Protéger les biens sensibles Autres « besoins » OIV

SOC ?

Une vision d’un S(ecurity)O(perating)C(enter) Définition Une vision d’un S(ecurity)O(perating)C(enter) Ce n’est pas une équipe dont l’activité consiste à : Configurer des équipements de sécurité, Assurer le « monitoring » système ou réseau, Réaliser des reportings. C’est un service qui (pour nous) : Fournit des moyens de détection d’attaque, « reçoit » et qualifie des événements de sécurité, Délivre des plans de réaction. Un SOC pour cette présentation = Centre de détection/qualification des événements de sécurité

Modélisation d’une attaque

«Représentation d’une attaque » Etapes d’une attaque Prise d’empreinte DETECTION Renseignement Déploiement Exploitation Fuite information Dépôt code malicieux

Périmètre de supervision sécurité

Types de services en supervision de sécurité Scope de supervision Types de services en supervision de sécurité Services data Réseau Backbone Supervision sécurité « applicative » Supervision sécurité « infrastructure» Zone d’hébergement Zone d’administration

Trame de création du service

Création d’un service de supervision de la sécurité Processus et choix critiques Processus Processus de spécification et réponse à l’expression du besoin de supervision Processus de traitement des alertes Gouvernance Processus de de sélection des services à superviser (priorisation) Outillage Choix de capteurs de sécurité Choix de l’outil de corrélation/visualisation des alertes Humain Recrutement idéalement profil ingénieur sécurité Plan de formation sécurité (test d’intrusion, capteurs, SIEM,…..)

« Processus » de mise en supervision d’un service

Processus de mise en supervision d’un service Etapes de mise en place Réponse technique, réalisation et tunning Initialisation Traitement « expert » service SOC Alerte/report Rédaction des spécifications des besoins Implémentation Les clients Le SOC Supervision Analyse du besoin 5 à 10 jours Etude de « faisabilité » 15 à 40 j Test 1/3 mois

Détection

Détection : introduction Type de capteurs utilisés IDS, Analyse de LOGS, modélisation de trafic Réseau de confiance ou service IDS « interne » « Réseau externe » SOC IDS « externe » Lutte DDoS Concentrateur de logs

Exploitation des vulnérabilités par un attaquant Détection : IDS Principe d’un IDS Ecoute flux Vulnérabilités Exploitation des vulnérabilités par un attaquant Base de signature By-pass des IDS

Détection : qualification d’un événement de sécurité Chaîne de qualification « enrichissement Analyse des flux réseaux Règles de détection Qualification de l’host Identification des vulnérabilités Alerte (Sévérité) Impact (Criticité) Qualification

Détection : logs Objectif Architecture Supervision des logs fournis par les grandes familles de fonction de sécurité Architecture Utilisation de concentrateur de log D’une interface de scripting Redirection des alertes Fonction Description Type de logs Contrôle d’accès Commande critique Logs système Durcissement Désactivation d’un service Logs TACACS Changement configuration

Détection : DDoS Principe d’attaque Principe de détection Saturation de la bande passante d’un lien réseau Principe de détection « Modélisation » des comportements normaux « Comparaison » avec le modèle et mise en place de seuil alerte

Apports : les quatre éléments

Apports directs Apport 1 Apport 2 Evaluation des « barrières » de défense Si attaque sans impact alors barrière de défense efficace Pas de reconfiguration Si attaque avec impact alors barrière de défense inefficace Reconfiguration de/des barrière(s) de défense Apport 2 Evaluation des politiques de sécurité Si attaque sans impact alors « politique» efficace Pas d’action de mise à jour des « politiques » Si attaque avec impact alors « politique» inefficace Mise à jour des « politiques », sensibilisation,…

Apports indirects Apport 3 Apport 4 Piste pour mise en place d’un « ROI » Analyse de la répartition des attaques sur le service Si ∑ attaques avec impact > ∑ attaques sans impact alors allocation des moyens de défense insuffisante ou mal employée Apport 4 « Résilience » des services Comparaison de la durée d’indisponibilité d’un service Sans détection temps d’indisponibilité d’un service = tps1 Avec détection temps d’indisponibilité d’un service = tps2 « Augmentation» résilience avec de la supervision tps1 > tps2

Apports directs 1 et 2 : exemples Evaluation des « barrières » de défense Tentative d’authentification sur des équipements réseau Attaque sans impact protection via la chaîne d’authentification MAIS Visibilité des équipements anormale Modification des règles de filtrage Contrôle des règles de filtrage sur l’ensemble des équipements Apport 2 Evaluation des politiques de sécurité Tentative d’authentification sur des équipements réseau Attaque sans impact protection via la chaine d’authentification MAIS Traitement de l’alerte anormalement long Modification de la politique de traitement des alertes Modification de la politique de gestion de crise

Apports indirects : exemple 3 et 4 Indicateurs délivrés efficacité Barrières de défense Efficacité des politiques Efficacité Résilience

Evolution de la maturité

Evolution dans le temps de la maturité de la supervision de sécurité Corrélation transformation 1 ou X alerte en attaque Analyse des anomalies d’authentification Utilisation des logs Comptage « Brute force » Authentification Analyse des anomalies dans les flux Utilisation d’un IDS Agréation src/dst/signature Flux réseau « Périodique » N log période glissante Analyse des anomalies réseau Enrichissement Type/version Vulnérabilité Trafic réseau Modélisation réseau DDoS Attaque applicative Analyse des anomalies applicative Analyse de logs applicatifs Scénarii « modélisation » attaque

Coût

Répartition des activités et des coûts Coût et activités Répartition des activités et des coûts Les activités de supervision Les outils Capteurs, SIEM,….. Qualification des événements Les experts sécurité Les activités d’ingénierie La définition des processus Répartition des activités Coûts de supervision

Externalisation

Externalisation de la supervision de sécurité Constat Coût d’un Centre de Supervision Sécurité important Solution Mise en place d’une externalisation de la supervision Condition Sécurisation de la chaîne de remontée des alertes Hébergement et cloisonnement des données sécurisées « SLA » temps de traitement des alertes (induit expertise) Difficultés Faux positif lors de la qualification des alertes par méconnaissance du contexte service Chaine de communication et de traitement des attaques

Conclusion

Conclusion : condition de réussite Pour chaque projet mis en supervision de sécurité Communication des enjeux à la « MOA » Spécification les « objets » à superviser précis Structurer les rôles et responsabilités Détection, traitement des alertes, traitement des corrections Hors projet L’ingénierie des capteurs est réalisé par le SOC Mise en place d’une cellule de veille hors équipe SOC Plate forme de simulation des attaques Amélioration continue une solution de supervision de sécurité pertinente est une solution qui évolue !

Conclusion : une nouvelle « barrière » de défense La supervision de sécurité Une brique supplémentaire dans le système de défense Formation Analyse de risque Antivirus Veille Certification Audit IAM DLP Code audit PKI Firewall Sensibilisation WAF ? SOC, IDS/IPS, SIEM

Questions

Merci pour votre écoute

Récupération de la payload du paquet Flux réseau Capture du paquet Récupération de la payload du paquet

Impact Synthèse d’une règle de détection Summary Signature Protocole TCP Fourniture de la chaine recherché Summary Vulnérabilité Firefox Impact Déni de service

Découverte des systèmes «Enrichissement » Découverte des systèmes Système Red Hat Port TCP ouvert Protocole réseau

Fourniture des vulnérabilités «Enrichissement » Fourniture des vulnérabilités Liste des vulnérabilités associé au système découvert DHCP Buffer Overflow