SECEF DAY Les standards au service de l’efficacité 18 ... · › Meeting CIDF en décembre 1998...
87
SECEF DAY – 18/09/2015 / 1 www.c-s.fr SECEF DAY Les standards au service de l’efficacité 18 septembre 2015
Transcript of SECEF DAY Les standards au service de l’efficacité 18 ... · › Meeting CIDF en décembre 1998...
SECEF DAY – 18/09/2015 / 1 www.c-s.fr
SECEF DAY Les standards au service de l’efficacité
18 septembre 2015
SECEF DAY – 18/09/2015 / 2 / 2
Les intervenants
Gilles Lehmann - CS
› Architecte Sécurité
› Responsable produit : Prelude, Vigilo
Hervé Debar – Telecom Sud Paris
› Enseignant-Chercheur
› Expert en détection d’intrusion et en contre-mesures
› Co-rédacteur de la RFC 4765 – IDMEF
› Vice Chairman ETSI ISG ISI
Guillaume Hiet – Centrale Supélec
› Enseignant-Chercheur
› Expert en détection d’intrusion
SECEF DAY – 18/09/2015 / 3 / 3
Agenda
Introduction
Les formats IDMEF et IODEF
Le projet SECEF
Contexte et historique
Panorama des formats d’incidents
› Pause café
Panorama détaillé des formats de détection
Conclusion
› Buffet & démonstrations
Sensibiliser, promouvoir et impliquer
SECEF DAY – 18/09/2015 / 4 / 4
1
/ 4
INTRODUCTION GILLES LEHMANN - CS
SECEF DAY – 18/09/2015 / 5 / 5
Pourquoi des formats standards ?
Côté Attaquants
› La cybercriminalité est un marché lucratif
› Il y a beaucoup d’argent à gagner (avec peu d’investissement !)
› Les cybercriminels s’organisent et se coordonnent
› Les attaques hier unitaires deviennent nationales
Côté Cibles
› Les risques augmentent
› Il y a beaucoup d’argent à perdre (mais aussi à investir !)
› On peine à s’organiser et se coordonner
La coordination des forces de cyber-défense est un facteur potentiel
d’efficacité (donc de réduction de coût)
› La détection d’intrusion est l’un des piliers de la cyber-défense
SECEF DAY – 18/09/2015 / 6 / 6
Les contraintes réglementaires
LPM 2014-2019 (18 décembre 2013)
› Opérateurs d’Importance Vitale
Directive européenne
› NIS (Network and Information Security)
› Périmètre « en débat » :
Energie, banque, santé, transports et services financiers
Opérateurs d’Infrastructure Essentielle (et effectif > 10 et CA > 2 M€ )
Les PME « sensibles »
Obligation
› Détection et gestion des risques
› Notification des incidents
› Mesure de sécurité et audit
Protection des données personnelles, des données financières, des données de santé, etc.
SECEF DAY – 18/09/2015 / 7 / 7
Les contraintes réglementaires
Il faut transmettre les informations en cas d’incidents mais certains
éléments restent flous :
› Qui : Les acteurs concernés
› Quoi : Le contenu de cette transmission
› Comment : Le moyen de transmission
« Le Quoi et le Comment » = le sujet du projet SECEF
SECEF DAY – 18/09/2015 / 8 / 8
La détection d’intrusion
Chaque attaque suit plus ou moins le même scénario (les 5 P)
› Probe (examiner/explorer, recueil d’information)
› Penetrate
› Persist
› Propagate
› Paralyze
Durant ces étapes l’attaquant utilise des techniques qui lèvent des
alertes :
› Scan de port, reconnaissance applicative, tentative de connexion, etc.
L’objectif de la détection d’intrusion est d’alerter l’exploitant (au mieux)
avant l’attaque.
SECEF DAY – 18/09/2015 / 9 / 9
Définitions
Journal / Evénement / Message
› Une trace « brute », un log, etc.
Alerte
› Un événement considéré comme notable ou suspicieux
› Exemple : tentative d’authentification échouée sur un serveur
› Nota : Dépend fortement de la stratégie de surveillance mise en place
Incident
› Une alerte ou un ensemble d’alertes peuvent caractériser une attaque
› Exemple :
Tel serveur a subi un scan de port, suivi de plusieurs tentatives de connexions échouées ainsi qu’une modification d’un fichier « sensible ».
Pendant une semaine nous avons subi des tentatives d’intrusion multiples en provenance de tel pays. La principale technique utilisée repose sur une pièce jointe malveillante envoyée à l’ensemble des collaborateurs. Etc.
SECEF DAY – 18/09/2015 / 10 / 10
Les sondes
Sondes IDS : Tout outil qui permet de détecter une intrusion
› Les sondes NIDS (Network Intrusion Detection System)
› Les sondes HIDS (Host Intrusion Detection System)
› Les modules d’analyse des journaux (regex, pattern, etc.)
› Les anti-virus, les anti-malware, les anti-spam
› Les pare-feux
› Les pare-feux applicatifs (WAF)
› « Les scanners de vulnérabilité »
› Les outils d’investigation et d’analyse comportementale (Big Data)
› Etc.
Nota : On parle de « sondes » ou « agents » de détection.
SECEF DAY – 18/09/2015 / 11 / 11
SIEM
SIM : Security Information Management
› Indexation et archivage de l’ensemble des données brutes (Log Management)
› « Big Data »
SEM : Security Event Management
› Gestion temps réel des événements de sécurité (Alertes)
› Sélection, Normalisation (Contextualisation), Corrélation, Agrégation, Indexation
› « Big Data » Smart / Small / Specialized Data
SIEM : Security Information & Event Management
› Vision et gestion unifiées de la sécurité
SECEF DAY – 18/09/2015 / 12 / 12
Les différents niveaux de la détection
A
Alertes
Incidents Alertes
Journaux
Sondes
SIEM
LM L
A
I
I I
A
Correlation Correlation
Correlation
SOC, CERT, « SIEM de SIEM »
SECEF DAY – 18/09/2015 / 13 / 13
Pourquoi faut-il utiliser un format de « détection d’intrusion» ?
Chaque sonde produit des « alertes ».
Il faut ensuite :
› Les transporter et les centraliser
› Les stocker/archiver/indexer
› Les comparer et corréler entre elles
Au sein d’un même outil mais aussi entre outils
› Les analyser :
Analyse de tendance
Analyse comportementale
› Eventuellement les transmettre
Pour les consolider à un niveau plus central par exemple
Peut-être les re-corréler à ce niveau
› Etc
Pour tout cela il est indispensable d’utiliser un format commun.
SECEF DAY – 18/09/2015 / 14 / 14
Pourquoi faut-il un format de description d’incident ?
Chaque centre de sécurité identifie des « incidents » importants.
Il faut ensuite :
› Les centraliser
› Les stocker/archiver/indexer dans un format adéquat
› Les comparer et corréler entre eux
Au sein d’un même centre mais aussi entre centres
› Eventuellement les transmettre
Pour les consolider à un niveau plus central par exemple
Peut-être les re-corréler à ce niveau
› Les analyser :
Analyse de tendance
Analyse statistique
› Etc
Pour tout cela il est indispensable d’utiliser un format commun.
SECEF DAY – 18/09/2015 / 15 / 15
Conclusion
Des formats standards sont indispensables.
Mais lesquels ?
SECEF DAY – 18/09/2015 / 16 / 16
2
/ 16
Les formats IDMEF et IODEF GILLES LEHMANN - CS
SECEF DAY – 18/09/2015 / 17 / 17
IDMEF : RFC 4765
› Intrusion Detection Message Exchange Format
› The purpose of the Intrusion Detection Message
Exchange Format (IDMEF) is to define data formats and
exchange procedures for sharing information of interest
to intrusion detection and response systems and to the
management systems that may need to interact with
them.
IODEF : RFC 5070
› Incident Object Definition Exchange Format
› The Incident Object Description Exchange Format
(IODEF) is a format for representing computer security
information commonly exchanged between Computer
Security Incident Response Teams (CSIRTs)
ANSSI
OIV
CERT MinDef
Les formats IDMEF et IODEF
SECEF DAY – 18/09/2015 / 18 / 18
SIM + SEM = SIEM
IDMEF Syslog, etc
IODEF
SECEF DAY – 18/09/2015 / 19 / 19
Le format IDMEF
SECEF DAY – 18/09/2015 / 20 / 20
IDMEF : Les classes
Analyzer :
› Agent qui émet l'alerte. (IP, OS, Version, Classe, etc.)
Classification :
› Type de l'alerte, référence.
Source et Target :
› Adresse IP, netmask, process, utilisateur, services, fichier etc.
Assessment :
› Sévérité, impact, confiance, completion, type.
AdditionnalData :
› Le reste
SECEF DAY – 18/09/2015 / 21 / 21
IDMEF
SECEF DAY – 18/09/2015 / 22 / 22
Le format IODEF
SECEF DAY – 18/09/2015 / 23 / 23
IODEF : IHM
SECEF DAY – 18/09/2015 / 24 / 24
Alerte Alerte
IDMEF
Alerte
Données brutes => IDMEF => IODEF
SONDES
SIEM
SOC, CERT
Incident
IODEF
Trace 1 Trame Y Log B Log B
Trace 1 Log A Trame X
Trace 2
Données
Brutes Log B Trame Y
Alerte
Log B
Alerte
Trace 1 Log B
SECEF DAY – 18/09/2015 / 25 / 25
IDMEF / IODEF
Deux formats définis à l’IETF
Les deux formats utilisent des objets communs, sont
complémentaires et couvrent l’ensemble de la problématique
détection et incident
IDMEF
› SIEM : Prelude SIEM, Prelude OSS et ses forks : LogLogic, VigieSI
› Sondes : Snort, Suricata, Ossec, Samhain, etc.
IODEF
› SIEM : ArcSight, Prelude, LogLogic
› IR : RTIR, Mantis, DFLabs
SECEF DAY – 18/09/2015 / 26 / 26
3
/ 26
Le projet SECEF GILLES LEHMANN - CS
SECEF DAY – 18/09/2015 / 27 / 27
La genèse
Longue expérience CS dans les standards IETF
Convaincu de l’urgence pour la communauté Cyber et en
particulier des OIVs
L’enthousiasme du consortium et de l’administration
SECEF DAY – 18/09/2015 / 28 / 28
Le projet SECEF
Financement RAPID (Régime d'Appui PME pour l'Innovation Duale)
Objectif : Promotion et amélioration des formats IDMEF et IODEF
MOA : DGA MI
Le consortium
› CS
› Telecom Sud Paris
› Centrale Supelec
Durée : 2ans
SECEF DAY – 18/09/2015 / 29 / 29
Le découpage
Lot 1 : Analyse de l’existant
› Retour d’expérience sur les implémentations et travaux existants
Lot 2 : Communication / Communauté
› www.secef.net
Lot 3 : Promotion des formats v1
› Rédaction de tutoriaux, Mise à disposition de librairies
› SECEF DAY !
Lot 4 : IDMEF v2
› Prototypage des améliorations envisagées
Lot 5 : IODEF v2
› Suivi et implémentation des travaux MILE
Lot 6 : Publication IETF
› Mise à jour au niveau de l’IETF
Lot 7 : Conformité
› Définir des « niveaux » de conformité IDMEF et IODEF
SECEF DAY – 18/09/2015 / 30 / 30
Le planning : Sept 2014 – Sept 2016
SE
CE
F D
AY
SECEF DAY – 18/09/2015 / 31 / 31
Les travaux
Réalisés
› Analyse comparative des formats d’alertes
› Etude des formats « incidents »
› Promotion / Communication
Rédaction tutoriaux
› Nouvelles sondes IDMEF, Implémentation IODEF
En cours
› Amélioration du format IDMEF
› Rapprochement ISI/ETSI
› Mise à disposition des bibliothèques IDMEF / IODEF
› Réflexion sur les processus IODEF
SECEF DAY – 18/09/2015 / 32 / 32
4
/ 32
CONTEXTE ET HISTORIQUE HERVE DEBAR - TSP
SECEF DAY – 18/09/2015 / 33 / 33
Définition du besoin
Fondation du domaine dit « Détection d’Intrusions »: 1980
› James Anderson, 1980, Denning, 1985
Nombreux développements de prototypes (1985-1995)
› IDES et suite, Haystack, Wisdom & Sense, …
Apparition d’outils commerciaux et libres
› Réseau: ISS RealSecure, Snort, Bro
La DARPA souhaite homogénéiser l’évaluation des logiciels de
détection d’intrusion développés par les chercheurs qu’elle finance
› Workshop en décembre 1998 à Washington DC
› Demande de lancement d’un groupe à l’IETF
SECEF DAY – 18/09/2015 / 34 / 34
Déploiement et professionnalisation
Apparition des SIEMs (2000)
› ISS Proventia
› IBM Tivoli Risk Manager
Services externalisés
› MSSP: Managed Security
Services Provider
› SOC (Security Operating
Center)
› Collecte et analyse temps réel
Evolutions récentes
› Capacités d’analyse type big-
data
› Investigation numérique
Développement des
standards
› IDMEF: alertes
› IODEF: incidents (CERTs)
Intérêt de la communauté
académique et open-source
› Mais nombre
d’implémentations limité
Echange d’information
› STIX/TAXII/CyBOX
› MILE
› ETSI ISI
SECEF DAY – 18/09/2015 / 35 / 35
Développement temporel IDMEF
IDWG
Création du groupe de travail
› Meeting CIDF en décembre 1998 (Washington DC)
› Proposition d’un charter à l’IETF
› Lancement du groupe en 2000
› IBM, Mitre, Cisco, ISS, Nokia, Prelude, MIT, etc.
Objectif: 3 documents
› Normaliser la représentation des messages
› Normaliser le vocabulaire du domaine
› Normaliser le transport
Publication des RFC en 2007
IDMEF
Départ de CISL
› S-expressions (lisp)
› Représentation très flexible (sondes)
› Difficulté d’assurer un contenu
Développement d’un modèle de données
› Orienté UML
› Flexible : peu d’obligations
Deux implémentations concurrentes
› SNMP ou XML
Décision de choisir des messages XML
› Fusion des documents
SECEF DAY – 18/09/2015 / 36 / 36
Formats d’échange d’incidents
Deux familles d’efforts
représentant deux
communautés
IODEF / MILE
› CERT/FIRTS
› IETF
CyBoX, STIX & TAXII
› DOD/DHS/MITRE
Pourquoi échanger cette
information ?
Pour répondre à des questions comme
› Quel type d’activité malveillante suis-je en train d’observer en ce moment Que fait-elle ?
Quelle faille exploite-t’elle ?
Qui est derrière et pourquoi ?
Quel est le risque ?
Que puis-je faire ?
Pour permettre de
› Focaliser la détection pour améliorer FP/FN
› Mesurer le risque de non-détection
SECEF DAY – 18/09/2015 / 37 / 37
5
/ 37
PANORAMA DES FORMATS INCIDENTS HERVE DEBAR - TSP
SECEF DAY – 18/09/2015 / 38 / 38
ETSI Information Security Indicators (ISI)
Indicateurs de référence produits par une organisation pour obtenir une information sur son niveau de sécurité
› Environ 90 indicateurs (majoritairement) techniques
› Groupés en 7 grandes familles (3 d’incidents, 4 de vulnérabilités)
› Pour mesurer l’état de sécurité d’un environnement IT
Orientés SOC/SIEM : permettre d’évaluer l’efficacité de la politique opérationnelle de sécurité (sondes, détection, diagnostic)
› Suivre l’évolution des indicateurs au cours du temps
› Comparer les valeurs internes à des valeurs de référence (par secteur industriel)
Relation avec IODEF et IDMEF
› IDMEF : production automatisée d’une partie des indicateurs en fonction du type d’alerte
› IODEFv2 (MILE) : transport pour échange d’information
SECEF DAY – 18/09/2015 / 39 / 39
Un format de message pour encapsuler des informations fréquemment
échangées par les CSIRTs :
› Computer security incident reports
› Cyber security indicators
IODEFv2 est une mise à jour du « Incident Object Description Exchange
Format » (IODEF)/RFC5070
Plusieurs extensions sont en cours de normalisation autour de IODEF
› RFC 5901 (Phishing)
› RFC 7203 (Structured Cybersecurity Information)
› draft-murillo-mile-cps-00 (Cyber Physical Incidents)
› draft-schaad-mile-iodef-plasma-00 (Policy Framework)
› draft-suzuki-mile-darknet-00 (Darknet Monitoring)
IODEFv2
2015/04
/29
39
SECEF DAY – 18/09/2015 / 40 / 40
Les protocoles de transport pour IODEFv2 sont RID (RFC 6545) et
ROILE (draft-field-mile-rolie)
› Mais peut aussi être mis dans des mails, etc.
Forte implication de la communauté des CERT (Europe, Japon)
Plusieurs évaluations
› Retours d’expérience
IODEFv2
SECEF DAY – 18/09/2015 / 41 / 41
CyBox : schéma standard
› Cyber Observable eXpression
› Schéma de description de données observables
› 80 objets prédéfinis
› Ex : Linux RPM, DNS Query, Win File , Process, etc.
STIX : Langage standard
› Structured Threat Information Expression
› STIX est un framework et un langage pour la caractérisation et l’échange
d‘informations sur les cyber-attaques
TAXII : Mécanisme d’échange sécurité
› Trusted Automated Exchange of Indicator Information (TAXII)
› TAXII est un ensemble de services et de messages pour échanger de
manière sécurisée les informations liées aux cyber-attaques
Ce n’est pas un programme de partage, une base de donnée ou un outil,
…mais une spécification pour réaliser cela.
CyBox, STIX et TAXII
2015/04
/29
41
SECEF DAY – 18/09/2015 / 42 / 42
CyBoX, STIX and TAXII sont développés pour permettre
l’échange automatisé d’informations sur les cyber-attaques
entre organisations et produits
Ces spécifications sont disponibles gratuitement
› Transfert vers OASIS
› Forte implication de la communauté gouvernementale US
› Mise à disposition de code open-source.
CyBox, STIX et TAXII
SECEF DAY – 18/09/2015 / 43 / 43
Indicator Of Compromise
Effort initié par la société Mandiant pour décrire des indicateurs
de compromission
› Ex : un fichier spécifique (MD5, nom, taille, date création,
etc.), une entrée mémoire, un jeu d’entrée dans la base de
registre Windows, etc.
Une version open-source est aujourd’hui disponible : OpenIOC
OpenIOC
SECEF DAY – 18/09/2015 / 44 / 44
Synthèse : domaine d’application
Incident File Network
OpenIOC
CyBOX
TAXII
RID (SMTP)
STIX
Source : http://www.nisha-network.eu/sites/default/files/201402%20Detect-Share-Protect%20for%20NISHA.pdf
IDMEF
IODEF
SECEF DAY – 18/09/2015 / 45 / 45
Il y a une forte demande de mécanismes d’échange d’information
› Par les régulateurs notamment
› Mais aussi pour le passage à l’échelle
› Mais aussi pour l’amélioration de la détection et de la remédiation
Ces mécanismes fonctionnent aujourd’hui autour de communautés
de confiance
› CERTs
› Points focaux
L’impact sur les techniques de détection et de corrélation reste à
déterminer
› En principe c’est un besoin et une bonne idée
› En pratique c’est difficile (e.g. pots de miel)
2015/04
/29
45
En résume
SECEF DAY – 18/09/2015 / 46 / 46
Conclusion
IDMEF est considéré comme complexe
› Permet de lever des ambiguïtés
› Assure au récepteur le niveau minimal d’interaction lui permettant
d’évaluer le risque
Questions ouvertes
› Faciliter l’usage du format
Documentation, particulièrement recommandation
Interaction avec les autres formats du domaine, particulièrement IODEF.MILE
Communauté
› Mettre à jour le format
Nouveaux mécanismes d’attaque
Nouvelles méthodes et nouveaux besoins des SOC
› Lever les ambiguïtés résiduelles
SECEF DAY – 18/09/2015 / 47 / 47 / 47
PAUSE CAFE
SECEF DAY – 18/09/2015 / 48 / 48
6
/ 48
PANORAMA DÉTAILLÉ DES FORMATS ALERTES GUILLAUME HIET - SUPELEC
SECEF DAY – 18/09/2015 / 49 / 49
Architecture de supervision de sécurité
IDMEF
CERT
CSIRT
SOCs…
SECEF DAY – 18/09/2015 / 50 / 50
Corrélation d’alertes
Capteur
SondeSource
de
données
Manager
Activité
EvénementsAlertes
brutes
Système
vulnérable
Analyseur
Attaque
Réaction
alertes
corrélées
et priorisées
Normalisation
Enrichissement et
Vérification
Agrégation
Dictionnaire
de nommage
Analyse du flux de
méta-alertes
Base de Biens
Base de
vulnérabilités
Observations
Visualisation
SECEF DAY – 18/09/2015 / 51 / 51
Transport
Encodage
Format des alertes Schéma Typage
Format d’alertes ?
SECEF DAY – 18/09/2015 / 52 / 52
Transport
Encodage
Format des alertes Schéma Typage
-Version : String
Message
-messageid : String
Alert
-messageid : String-heartbeatInterval : Integer
HeartBeat
-analyzerid : String-name : String-manufacturer : String-model : String-version : String-class : String-ostype : String-osversion : String
Analyzer
1
1
1
1
-name : String-command : String
ToolAlert
-name : String
CorrelationAlert
-program : String-size : Integer-buffer : sbyte
OverflowAlert
-ident : String-text : String
Classification
1
1
-ident : String-spoofed : Integer-interface : String
Source
-ident : String-decoy : Integer-interface : String
Target
Assessment
-ntpstamp : Date
CreateTime
-ntpstamp : Date
DetectTime
-ntpstamp : Date
AnalyzerTime
-severity : Integer-completion : Integer-type : Integer
Impact
-rating : Integer
Confidence
1
0..*
1
0..1
1
0..*
1
1
1
0..1
1
0..1
1
1
1
0..1
-analyzerid : String-alertident : String
alertident
1
1..*
1
1..*
0..1
0..1
-ident : String-category : Integer-location : Integer-name : String
Node -ident : String-category : Integer-vlan-name : String-vlan-num : Integer-address : String-netmask : String
Address
1 0..*
1 0..1
1
0..1
1
0..1
-ident : String-name : String-pid : Integer-path : String-arg : String-env : String
Process
1
0..1
-ident : String-ip_version : Integer-iana_protocol_number : Integer-iana_protocol_name : String-name : String-port : Integer-portlist-protocol : String
Service
-oid : String-messageProcessingModel : Integer-securityModel : Integer-securityName : String-securityLevel : Integer-contextName : String-contextEngineID : String-command : String
SNMPService
-url : String-cgi : String-http-method : String-arg : String
WebService1
0..1
-ident : String-category : Integer
User
-ident : String-type : Integer-tty : String-name : string-number : Integer
UserId
1
1..*
1
0..1
-name : String-path : String-create-time : Date-modify-time : Date-access-time : Date-data-size : Integer-disk-size : Integer-category : Integer-fstype : Integer-file-type : String
File
1
0..*
-Permission : Integer
FileAccess
1
0..*
-path : String-name : String
Linkage
10..*
1
1
-change-time : Date-number : Integer-major-device : Integer-minor-device : Integer-c-major-device : Integer-c-minor-device : Integer
Inode
1
0..*
-algorithm : Integer-value : String-key : String
Checksum
1
0..1
1
0..*
-category : Integer
Action
1 0..*
1 1..*
1
0..1
1
0..1
1
0..1
-origin : String-meaning : String-name : String-url : String
Reference
1 0..*
alert.analyzer.name
alert.source.node.address[0]
deviceMacAddress
sourceDnsDomain vs.
Format d’alertes ?
SECEF DAY – 18/09/2015 / 53 / 53
Transport
Encodage
Format des alertes Schéma Typage
-messageid : String
Alert
-ident : String-spoofed : Integer-interface : String
Source
-ident : String-decoy : Integer-interface : String
Target
1
0..*
1
0..*
-ident : String-category : Integer-location : Integer-name : String
Node
1
0..1
1
0..1
-ident : String-name : String-pid : Integer-path : String-arg : String-env : String
Process
-ident : String-ip_version : Integer-iana_protocol_number : Integer-iana_protocol_name : String-name : String-port : Integer-portlist-protocol : String
Service
1
0..1
-ident : String-category : Integer
User
1
0..1
1
0..1
1
0..1
1
0..1
Source : source- ident : Identifiant unique de la source- spoofed : (optionnel) indique si l’analyseur pense que la source est usurpée :
- 0 -> unknown- 1 -> yes- 2 -> no
-interface : (optionnel) Interface de l’analyseur sur laquelle la source a été vue.
Target : cible- ident : Identifiant unique de la source- decoy : (optionnel) indique si l’analyseur pense que la cible est un appât :
- 0 -> unknown- 1 -> yes- 2 -> no
-interface : (optionnel) Interface de l’analyseur sur laquelle la cible a été vue.
Dictionnaires,
Énumérations,
Taxonomies, etc.
ISO 8601,
ISO 6709,
CIDR, etc.
Format d’alertes ?
SECEF DAY – 18/09/2015 / 54 / 54
Transport
Encodage
Format des alertes Schéma Typage
<?xml version="1.0" encoding="UTF-8"?>
<idmef:IDMEF-Message xmlns:idmef="http://iana.org/idmef"
version="1.0">
<idmef:Alert messageid="abc123456789">
<idmef:Analyzer analyzerid="hq-dmz-analyzer01">
<idmef:Node category="dns">
<idmef:location>Headquarters</idmef:location>
…
Textuel
(XML, JSON, etc.)
vs.
Binaire
(BER/DER/PER,
BSON,
binary XML, etc.)
{"Source" : "IDM","Observer" : {"Entity" : {"SysName" :
"chhs-sidm017"}},"Initiator" : {"Entity" : {"SvcName" :
"CN=INTG2,OU=SYSTEM,O=SOME","SvcComp" :
"\\Driver"}},…
Format d’alertes ?
SECEF DAY – 18/09/2015 / 55 / 55
Transport
Encodage
Format des alertes Schéma Typage
HTTP, Syslog, AMQP, etc.
Format d’alertes ?
SECEF DAY – 18/09/2015 / 56 / 56
Pourquoi utiliser un format standard ?
Limiter le travail de normalisation du manager
Faciliter l’interopérabilité des outils
Faciliter la spécification de règles de corrélation « génériques »
SECEF DAY – 18/09/2015 / 57 / 57
Formats étudiés
Propriétaires :
› CEF (HP ArcSight)
› LEEF (IBM QRADAR)
› SDEE (CISCO)
Standards :
› IDMEF (IETF)
› CEE (MITRE + CEE board)
› CIM (DMTF)
› XDAS/CADF (The Open Group, Novell, DMTF)
SECEF DAY – 18/09/2015 / 58 / 58
Méthodologie
Comparaison exhaustive des champs avec IDMEF
› Exercice de « traduction » IDMEF <-> format x
› Identification des champs qui peuvent être traduits
# champs traduits / # champs IDMEF = richesse relative / IDMEF
› Spécification de « passerelles » inter-formats
› Identification des champs qui ne peuvent être traduits
Pistes d’évolution d’IDMEF
Critères synthétiques de comparaison et de présentation
› Référence / documentation
› Transport et encodage
› Pouvoir d’expressivité / richesse
› Structuration
› Extensibilité
SECEF DAY – 18/09/2015 / 59 / 59
IDMEF
Décrit par RFC 4765 (requirements dans RFC 4766)
› Bien documenté (138 pages de RFC)
› Beaucoup de lecture pour créer une alerte simple
› Le style textuel de la RFC n’aide pas à « visualiser » le schéma
› Manque une définition claire de la stratégie de « peuplement » pour
différent use-case (exemples) -> création de tutoriels IDMEF
A priori, indépendant du transport et de l’encodage
› La RFC décrit des exemples s’appuyant sur XML et fournit une DTD
› Le groupe de travail devait définir un transport de référence (IDXP)
Orienté détection d’intrusion
› Format dédié aux alertes
SECEF DAY – 18/09/2015 / 60 / 60
IDMEF
Format très riche :
› Description des sondes (analyzer), sources, destinations, marqueurs
temporels, processus, utilisateurs, fichiers, services, etc.
Schéma très structuré
› 33 classes, 108 attributs
› Beaucoup d’attributs sont des classes
› Beaucoup d’attributs sont des listes (source, target, etc.)
› Combinaison multiplicité + champs « type »
› Identifiant unique des attributs, espace de nommage
› Utilisation de dictionnaires (non systématique)
Format extensible
› Champs « additional data »
SECEF DAY – 18/09/2015 / 61 / 61
CEF
Format propriétaire décrit par un document publiquement
disponible
› Documentation complète mais description succincte de certains champs
› Peuplement moins ambigu qu’IDMEF (lié à la structure du format)
Transport et encodage Syslog
› A priori portable sur d’autres formats
Orienté événements de sécurité
SECEF DAY – 18/09/2015 / 62 / 62
CEF
Format assez riche :
› Description sonde (device), sources, destinations, marqueurs temporels,
processus, utilisateurs, fichiers, services
Schéma peu structuré
› 91 attributs
› Format « à plat » (clés/valeur)
› Attributs différents pour un même type d’information (ex : champs
adresse)
› Pas de dictionnaire (notamment pour outcome, reason, cat) mais peu de
champs le nécessitent
Extensibilité limitée
› Quelques champs additionnels (nombre fixé)
SECEF DAY – 18/09/2015 / 63 / 63
LEEF
Format propriétaire décrit par un document publiquement
disponible
› Documentation complète mais description succincte de certains champs
(document similaire à CEF)
› La sémantique de certains champs est ambiguë
Transport et encodage Syslog
› A priori portable sur d’autres formats
Orienté événements de sécurité (réseau)
SECEF DAY – 18/09/2015 / 64 / 64
LEEF
Format peu riche :
› Description sources, destinations, marqueurs temporels, utilisateurs,
services
› Pas de description des fichiers, processus, sonde…
Schéma peu structuré
› 51 attributs
› Format « à plat » (clés/valeur)
› Attributs différents pour un même type d’information (ex : champs
adresse)
› Pas de dictionnaire (cat), sémantique floue (usrName) mais peu de
champs le nécessitent
Extensibilité non prévue
SECEF DAY – 18/09/2015 / 65 / 65
CIM
Format standard décrit par une spécification DMTF (DSP)
› Documentation en ligne : http://www.dmtf.org/standards/cim
› Documentation complète (méta-modèle + schéma), versionnée
› La notion d’héritage nécessite d’analyser différentes classes
Transport et encodage a priori libre
› DMTF définit WBEM comme transport (mais les spécifications sont
indépendantes)
Orienté administration de système distribué
› La description des alertes n’est qu’une sous-partie
› La description des alertes de sécurité est expérimentale
› Permet de décrire les éléments du SI
› Utilisation par d’autres formats (par exemple XDAS)
SECEF DAY – 18/09/2015 / 66 / 66
CIM
Format peu riche (pour la sécurité) :
› Le format en général est assez riche
› Description sources, destinations, marqueurs temporels, utilisateurs,
services
› Pas de description des fichiers, processus, sonde…
Schéma moyennement structuré
› 49 attributs, quelques attributs redondants (héritage)
› Utilisation de 5 classes (pour les alertes) et de l’héritage
› La classe SecurityIndication n’utilise pas d’attributs sous forme de classe
(pas d’association)
› Champs type (comme IDMEF) mais pas de multiplicité
› Utilisation de quelques dictionnaires
Extensibilité par héritage
SECEF DAY – 18/09/2015 / 67 / 67
CEE
Format standard décrit par une spécification (version beta)
› Documentation en ligne : https://cee.mitre.org/
› Documentation très légère (schéma)
› Beaucoup de champs ambigus ou redondants
Transport et encodage a priori libre
› Exemple JSON, XML et Syslog
Orienté gestion de log
SECEF DAY – 18/09/2015 / 68 / 68
CEE
Format assez riche mais sémantique ambigüe :
› Description sources, destinations, marqueurs temporels, utilisateurs,
services mais pas de description précise de la sonde
› Difficile de distinguer si les champs sont relatifs à la sonde, la source ou
la cible
Schéma moyennement structuré
› Format « à plat » (clé/valeur)
› Champs / sous-champs
› Quelques dictionnaires
Extensibilité
› Profil additionnel?
SECEF DAY – 18/09/2015 / 69 / 69
XDAS/CADF
Format standard décrit par des spécifications
› Documentation en ligne :
https://www2.opengroup.org/ogsys/catalog/P441
› http://www.dmtf.org/standards/cadf
› Version propriétaire (NetIQ/Novell) :
https://www.netiq.com/documentation/edir88/edirxdas_admin/data/bqppfz
w.html
› Documentation succincte (V1/NetIQ) ou complète des champs et de la
taxonomie (CADF)
› Pas de schéma UML
Transport et encodage a priori libre
› Exemple JSON, XML et Syslog
Orienté gestion événement/audit, cloud (CADF)
SECEF DAY – 18/09/2015 / 70 / 70
XDAS/CADF
Format assez riche mais difficile à évaluer :
› Description sources, destinations, marqueurs temporels, utilisateurs,
services mais pas de description précise des fichiers et processus
› Concepts communs mais beaucoup de différences entre les différentes
versions
Schéma assez structuré
› Notion Initiator/Observer/Target
› Structuration dépend des versions
Extensibilité
› Champs pour données additionnelles
SECEF DAY – 18/09/2015 / 71 / 71
Synthèse : transport et encodage
Transport :
Encodage :
CEF LEEF SDEE IDMEF CIM XDAS CEE
Syslog
Syslog
HTTP IDXP *
HTML *
Syslog *
Syslog *
CEF LEEF SDEE IDMEF CIM XDAS CEE
Syslog +
clé/valeur
Syslog +
clé/valeur
XML XML *
HTML *
JSON *
JSON XML
*
SECEF DAY – 18/09/2015 / 72 / 72
Synthèse : expressivité et structuration
Expressivité :
Structuration :
CEF LEEF SDEE IDMEF CIM (sec) XDAS CEE
++
- + +++ - + ? + ?
CEF LEEF SDEE IDMEF CIM (sec)
XDAS CEE
-- -- + +++ + ++ -
SECEF DAY – 18/09/2015 / 73 / 73
RICHESSE : COMPARAISON
IDMEF CEF LEEF CIM CEE XDAS CADF Nombre de champs 166 117 47 56 35 35 48 Champs normalisés 259 84 47 56 35 35 76
Champs traduisibles 65 20 29 28 18 72
Champs non traduisibles mais pertinents
15 11 11 4 3 3
Champs non traduisibles et peu pertinents
50 9 18 24 15 69
Champs pertinents 80 31 40 32 21 75 Couverture IDMEF 25% 8% 11% 11% 7% 28%
Richesse relative / IDMEF
31% 12% 15% 12% 8% 29%
SECEF DAY – 18/09/2015 / 74 / 74 / 74
CONCLUSION GILLES LEHMANN - CS
SECEF DAY – 18/09/2015 / 75 / 75
Pourquoi des standards ?
On peut comparer la détection d’intrusion avec ce qu’a été la
messagerie
A l’origine :
› Plusieurs éditeurs (Microsoft, Novell, Lotus, etc.)
› Plusieurs formats
› Pas de connexion / collaboration possible
Grâce à SMTP
› Plusieurs éditeurs
› Un format pivot standard SMTP
› Un monde connecté
SECEF DAY – 18/09/2015 / 76 / 76
L’aspect économique
L’un des objectifs premiers de IDMEF et IODEF est l’automatisation
des tâches.
Plus le format interne est puissant, plus les tâches sont automatisables
et moins l’effort humain est nécessaire.
L’efficacité des standards est inversement proportionnel aux coûts des
exploitants !
SECEF DAY – 18/09/2015 / 77 / 77
IDMEF : Les freins actuels à l’adoption
C’est trop compliqué !
› SMTP n’est pas plus simple
› SECEF : Tutoriaux, conformité, librairies
C’est pas parfait, c’est pas adopté, c’est trop vieux, c’est NIH
› C’était l’argument de (RIP) CEE
J’ai déjà un format propriétaire (ex : CEF, SDEE, etc.)
› SECEF : Travaux sur passerelles
Pas de besoin de format, on a le Big Data !
› Et Google va nous guérir de la grippe !
SECEF DAY – 18/09/2015 / 78 / 78
Historique SMTP
1971 : Mail Box Protocol – RFC 196
1980 : Mail Transfer Protocol – RFC 780
1981 : Simple Mail Transfer Protocol – RFC 788
1994 : SMTP Service Extensions – RFC 1651
1995 : SMTP Service Extensions – RFC 1869
1998 : Message Submission – RFC 2476
1999 : SMTP Service Extension for Secure SMTP over TLS – RFC 2487
1999 : SMTP Service Extension for Authentication – RFC 2554
2001 : Simple Mail Transfer Protocol – RFC 2821
2008 : Simple Mail Transfer Protocol – RFC 5321
2015 : SMTP 521 and 556 Reply Codes – RFC 7504
SECEF DAY – 18/09/2015 / 79 / 79
IODEF les freins
C’est trop compliqué
› Idem IDMEF
C’est trop vieux, STIX | CyBox | TAXII c’est US donc c’est mieux !
› Ne pas confondre le rôle de chaque format
Communiquer oui ? Mais avec qui ?
› IODEF reste un outil, il faut ensuite des processus et une volonté
Pas besoin de communiquer, je sais me défendre tout seul
› « Bonne chance … »
SECEF DAY – 18/09/2015 / 80 / 80
Pour continuer techniquement
Visitez le site Secef
› http://www.secef.net
Participez et suivez la communauté SECEF
› http://redmine.secef.net/projects/secef/boards
Expérimentez IDMEF / IODEF :
› LibPrelude, Prelude OSS
› Les bibliothèques SECEF à venir
Rendez vos outils/sondes IDMEF / IODEF « ready »
SECEF DAY – 18/09/2015 / 81 / 81
Pour continuer stratégiquement
Acteurs de la cyber-défense
› Contactez-nous !
› www.secef.net
Maîtrise d’ouvrage
› Exigez des passerelles standards à vos déploiements
Responsables sécurité, SIEM, SOC
› Quels sont les standards que vous utilisez ?
› Comment avez-vous prévu de communiquer avec l’extérieur ?
› Vos outils vous offrent-ils des interfaces standards (ex : XML, etc.) ?
Groupe d’utilisateurs / Décideurs / etc
› Nous sommes à votre disposition pour organiser des présentations
Administrations
› Quels sont les moyens utilisés dans votre administration pour déclarer les incidents ?
› Poussez IDMEF et IODEF au sein du RGI.
SECEF DAY – 18/09/2015 / 82 / 82
Merci pour votre attention
Vos questions ?
SECEF DAY – 18/09/2015 / 83 / 83
Démonstration
Démonstration n°1
› Les formats IDMEF et IODEF à l’usage
Démonstration n°2
› Comment développer un connecteur IDMEF en … 5 MINUTES !
› (Montre en main)
Démonstration n°3
› Un SIEM IDMEF en action (Prelude)
SECEF DAY – 18/09/2015 / 84 / 84
Webographie
Le site SECEF
› www.secef.net
› Introduction, présentation, tutoriaux
Le redmine SECEF
› redmine.secef.net
› Forum d’échanges, librairies
Le site Prelude OSS
› www.prelude-siem.org
Le site Prelude SIEM
› www.prelude-siem.com
Contact SECEF
[email protected] 01 41 28 43 08 06 80 06 29 99
SECEF DAY – 18/09/2015 / 85 CONCEPTEUR, OPÉRATEUR & INTÉGRATEUR DE SYSTÈMES CRITIQUES www.c-s.fr
CS 22, avenue Galilée - 92350 Le Plessis Robinson Tél. : 01 41 28 40 00 www.c-s.fr
SECEF DAY – 18/09/2015 / 86 / 86
Démonstration n°1
Objectifs
› Présenter l’utilisation d’IDMEF dans
Prelude
› Présenter une possibilité d’utilisation
d’IODEF dans Prelude (version
R&D)
Parc simulé
› Plusieurs agences : Paris, Lyon,
Bordeaux, etc.
› Centralisation des alertes au SOC
Paris
› Supervision des serveurs métiers,
des équipements réseaux
SECEF DAY – 18/09/2015 / 87 / 87
Démonstration n°2
Objectif
› Créer une sonde Prelude en 10 étapes, 5 minutes chrono
Actions de la sonde
› Connexion à Prelude
› Construction d’un objet IDMEF
› Envoi de l’objet IDMEF à Prelude
Pour notre exemple, sonde de type « Anti-Spam » qui détecte une
tentative de Phishing
