1. Méthode détection
1.1. Signature
1.1.1. -
1.1.1.1. Base de données de signature
1.1.1.1.1. Mise à jour fréquente
1.1.1.2. Détection uniquement d'attaques connues
1.1.2. +
1.1.2.1. Diagnostic clair, possibililité de réagir
1.1.2.2. Peu de faux positifs
1.1.2.3. Simplicité
1.1.3. Exemples
1.1.3.1. Exemple de génération d'une signature : PDF "IDS et IPS"
1.1.3.2. Trouver le « motif /winnt/system32/cmd.exe » dans une requête http
1.1.3.3. Trouver le motif « failed su for root » dans un log système
1.1.4. Intégrité
1.1.4.1. Utilisé par les HIDS
1.1.4.2. Hash des fichiers systèmes et alerte si altération
1.2. Comportement
1.2.1. Détection d'anomalie par rapport au traffic normal
1.2.2. Phase d'apprentissage du traffic normal
1.2.3. Analyse statistique
1.2.4. +
1.2.4.1. Permet détection nouveaux modes d'attaque
1.2.4.2. Difficile à tromper
1.2.5. -
1.2.5.1. problème si attaque pendant apprentissage
1.2.5.2. Pas d"interprétation de l'attaque, on ne sait pas comment réagir
1.2.5.3. Faux positifs nombreux
1.2.6. Exemple informations comparéees
1.2.6.1. Taux d’utilisation CPU
1.2.6.2. Utilisation de certains fichiers
1.2.6.3. Activité sur le disque
1.2.6.4. Les horaires de connexion
2. Type
2.1. HIDS
2.1.1. Surveiller processus et fichiers d'une machine
2.1.2. Cas d'utilisation
2.1.2.1. Machines à données sensibles (serveurs web/applicatifs)
2.1.3. +
2.1.3.1. Précision sur les attaques
2.1.3.2. Réactivité
2.1.3.3. Détection attaques sur traffic crypté
2.1.4. -
2.1.4.1. Sensible attaques DoS
2.1.4.2. Utilisation CPU importante
2.1.5. Entrée (analyse)
2.1.5.1. Journaux systèmes
2.1.5.2. Appels systèmes
2.1.5.3. Vérifie l'intégrité des systèmes de fichiers
2.1.5.4. Base de registre
2.1.5.5. Flux cryptés
2.1.6. Sortie
2.1.6.1. Log
2.1.6.1.1. Plus léger
2.1.6.1.2. Certaines attaques non visible
2.1.6.2. Trace d'audit
2.1.6.2.1. Précis et détaillé
2.1.7. Solutions
2.1.7.1. Tripwire
2.1.7.2. AIDE
2.2. NIDS
2.2.1. Analyser l'ensemble des paquets du réseau
2.2.2. Capteurs
2.2.2.1. A différents points du réseau
2.2.2.2. Envoi à une console sécurisée des alertes pour analyse et traitement
2.2.2.3. Placement (politique de sécurité)
2.2.2.3.1. Zone sensible (DMZ) pour contrer
2.2.2.3.2. Avant/après pare-feu pour détecter et vérifier configuration pare-feu
2.2.3. +
2.2.3.1. Invisibilité sur le réseau (Mode furtif, sans adresse IP, carte réseau en "promiscuous mode")
2.2.3.1.1. Difficile à attaquer
2.2.4. -
2.2.4.1. Ne peut pas analyser traffic crypté
2.2.4.2. Ne voit pas les impacts d'une attaque
2.2.5. Solutions
2.2.5.1. Snort
2.2.5.2. Check Point
2.2.5.3. Tipping point
3. Réponse
3.1. Passive
3.1.1. N'empêche pas une attaque de se produire
3.1.2. Journalisation de l’attaque
3.1.3. Notification
3.1.4. Sauvegarde des paquets suspicieux
3.2. Active
3.2.1. Stopper une attaque
3.2.1.1. Etre sûr qu'il s'agit d'un traffic malveillant
3.2.2. 2 techniques
3.2.2.1. Reconfiguration pare-feu (bloquer port, adresse IP)
3.2.2.2. Arrêt de la connexion avec l'attaquant
3.2.2.2.1. Envoi d'un paquet TCP reset aux deux extrémités pour déconnexion
4. Utilité
4.1. +
4.1.1. Surveillance continue et détaillée
4.1.1.1. Historisation et analyse
4.1.1.2. Informations détaillées (type supposé d'attaque, la source, la destination...)
4.1.1.3. Centralisation des alertes
4.1.2. Modularité de l'architecture
4.1.3. HIDS/NIDS se complètent
4.1.3.1. Suivi du parcours d'une attaque sur le réseau, étude efficacité des protections
4.1.3.2. Impact sur la machine final
4.2. -
4.2.1. Connaissances pointues pour analyser les alertes
4.2.2. Intervention humaine nécessaire
4.2.3. DDoS très efficace contre NDIS car sniffent tout le traffic
4.2.4. Nombreuses alertes
4.2.4.1. Comment distinguer un faux-positif
5. Alertes
5.1. 3 cas
5.1.1. Identification pertinente d'une attaque
5.1.2. Identification non pertinente d'une attaque (l'attaque a échouée)
5.1.3. Faux positif
5.2. Gestion des alertes
5.2.1. Classification des alertes
5.2.1.1. Adaptive Learner for Alert Classification
5.2.1.2. Real-time Classification of IDS Alerts with Data Mining Techniques
5.2.1.3. Processing intrusion detection alert aggregates with time series modeling
5.2.1.3.1. Différence dans le flux d'alertes quand il ya ou non attaque
5.2.2. Alert Correlation (groupement d'alertes similaires)
5.2.2.1. Clustering intrusion detection alerts
5.2.2.1.1. Décomposition des attributs des alertes avec hiérarchisation
5.2.3. Knowledge Base Alert Filtering (ajout de connaissances supplémentaires à propos du réseau, des données...)
5.2.3.1. M-Correlator project
5.2.3.1.1. Alertes filtrées en fonction des connaissances sur le réseau et des vulnérabilits connues
5.2.4. Combinaison des 3
6. Types d'attaques détectées
6.1. Dos/DDoS
6.2. Altération de fichiers
6.2.1. Comparaison des hashs des fichiers pour vérifier l'intégrité par les HIDS
6.3. Virus/trojan
7. Gestion des incidents de sécurité
7.1. Définition d'incident
7.1.1. ISO 27000
7.1.1.1. Un ou plusieurs évènements intéressant la sécurité de l'information indésirable(s) ou inattendu(s) présentant une probabilité forte de compromettre les opérations liées à l'activité de l'organisme et de menacer la sécurité de l'information
7.1.2. ITIL
7.1.2.1. Tout évènement qui ne fait pas partie du fonctionnement standard d'un service et qui cause, ou peut causer, une interruption ou une diminution de la qualité de ce service
7.2. Etapes de HSC
7.2.1. Préparation
7.2.1.1. PSSI
7.2.1.2. Approbation de la direction
7.2.1.3. Constitution d'une équipe
7.2.1.3.1. Former
7.2.1.3.2. Définir les responsabilités
7.2.1.3.3. Prévoir les astreintes, rappels d'urgence
7.2.1.4. Information des utilisateurs
7.2.1.5. Organisation de la collecte d'incidents
7.2.1.6. Identification des sources d'information
7.2.2. Identification et analyse
7.2.2.1. Désigner un responsable de l'analyse
7.2.2.2. Vérifier et croiser les sources
7.2.3. Confinement et endiguement
7.2.3.1. Sécuriser la zone
7.2.3.2. Faire une sauvegarde
7.2.3.3. Déconnecter le serveur
7.2.3.4. Réduire les conséquences
7.2.3.5. Déterminer ce qui a été perdu, divulgué, compromis et sa nature
7.2.4. Eradication
7.2.4.1. Résoudre le problème avant de retourner en ligne
7.2.4.2. Déterminer les causes de l'incident
7.2.4.3. Faire une revue des vulnérabilités
7.2.4.4. Améliorer les moyens de protection
7.2.4.5. Communiquer en interne
7.2.4.6. Conservation des preuves légales
7.2.5. Recouvrement
7.2.5.1. Etre certain de ne pas restaurer des données infectées
7.2.5.2. Surveiller le sysème remis en marche
7.2.6. Retour d'expérience
7.2.6.1. Ecrire et distribuer un rapport
7.2.6.2. Faire une analyse de la gestion de l'incident
7.2.6.2.1. Affiner son processus de gestion des risques
7.2.6.3. Informer les parties prenantes externes
7.2.6.4. Envoyer des recommandations à la direction
7.3. Etapes ENISA
7.3.1. Incident report
7.3.1.1. Réception des rapports par email, sur un terminal central...
7.3.2. Registration
7.3.2.1. Dans un système de gestion d'incident
7.3.2.2. Mécanisme de pré filtrage
7.3.3. Triage
7.3.3.1. Vérification si il s'agit d'un réel incident et pas d'un faux positif ou non pertinent
7.3.3.2. Classification
7.3.3.3. Priorisation
7.3.3.4. Assignation d'une personne à l'incident
7.3.4. Incident resolution
7.3.4.1. Data analysis
7.3.4.1.1. Collecte de données notamment venant d'autres sources
7.3.4.1.2. Informer ceux qui pourraient être le plus impactés pour notamment diminuer la menace
7.3.4.1.3. Rechercher dans la base de données des incidents si il a déjà eu lieu
7.3.4.2. Resolution research
7.3.4.3. Action proposed
7.3.4.4. Action performed
7.3.4.4.1. Surveiller la mise en place
7.3.4.5. Eradication and recovery
7.3.4.5.1. Retrouver le service normal d'avant l'incident
7.3.5. Incident closure
7.3.5.1. Final information
7.3.5.1.1. Informer les parties impliquées sur l'incident, les résulats du travail effectué, des recommandations
7.3.5.2. Final classification
7.3.5.2.1. Réajuster la classification en ayant davantage d'informations
7.3.5.3. Archiving
7.3.5.3.1. Données sensibles donc protégées
7.3.5.3.2. Penser au respect des lois sur la conservation des données
7.3.6. Post-analysis
7.3.6.1. Réalisé quelque temps après, "à tête reposée"
7.3.6.2. Proposals for improvement
7.4. Etapes du CLUSIF
7.4.1. Détection et signalement
7.4.1.1. Par une personne, un outils
7.4.1.2. L'information doit remonter à une personne compétente
7.4.1.3. Vérification qu'une réponse rapide et adaptée est possible y compris hors heures d'ouverture
7.4.2. Prise en compte
7.4.2.1. Enregistrement de l'incident
7.4.2.1.1. Accusé de réception de l'alerte
7.4.2.1.2. Enregistrement dans une BDD
7.4.2.2. Catégorisation par une équipe support
7.4.2.2.1. En réponse à des fiches établies par l'équipe sécurité
7.4.2.2.2. Remonte à l'équipe sécurité si incident important
7.4.2.3. Classification par une équipe sécurité
7.4.2.3.1. Vérification qu'il s'agit bien d'un incident de sécurité
7.4.3. Réponse à l'incident SSI
7.4.3.1. Mesures de réponses immédiates
7.4.3.1.1. Limiter l'impact et préserver les traces
7.4.3.1.2. Confinement, isolation, communication ciblée et recommandations
7.4.3.2. Investigations
7.4.3.2.1. Collecte d'informations (périmètre, nature, fait générateur, impact)
7.4.3.3. Traitement
7.4.3.3.1. Mesures pour éviter l'aggravation
7.4.3.3.2. Résolution de l'incident
7.4.4. Revues post-incident
7.4.4.1. Investigation post-incident
7.4.4.1.1. Pour bien comprendre comment l'incident à pu avoir lieu
7.4.4.2. Rapport de synthèse
7.4.4.2.1. Eléments techniques
7.4.4.2.2. Bilan processus
7.4.4.2.3. Bien financier
7.4.4.3. Analyse post-incident
7.4.5. Actions post-incident
7.4.5.1. Recours pénal
7.4.5.2. Révision des contrats fournisseurs/assurances
7.4.5.3. Communication interne
7.4.6. Amélioration de la gestion des incidents SSI
7.4.6.1. Tirer des enseignements pour améliorer la gestion des incidents