Détection et analyse

2ème étape
Ian Quincy Egnonnam GBAGUIDI
Table des matières

01 04
Vecteurs d'attaque Analyse des incidents

02 05
Signes d'un incident Documentation des incidents

03 06
Priorisation des incidents
Sources des précurseurs et indicateurs

07
Notification d'incident
 Vecteurs d'attaque
01
Les incidents peuvent se produire d'innombrables façons, il est donc impossible
de développer des instructions étape par étape pour gérer chaque incident.

Les organisations doivent généralement être prêtes à gérer tout incident, mais
doivent se concentrer sur la préparation à gérer les incidents qui utilisent des
vecteurs d'attaque communs.

Différents types d'incidents méritent différentes stratégies d'intervention.

Les différents types de vecteur

Les vecteurs d'attaque répertoriés ci-dessous ne sont pas destinés à fournir une
classification définitive des incidents ; au lieu de cela, ils énumèrent
simplement les méthodes d'attaque courantes, qui peuvent être utilisées
comme base pour définir des procédures de traitement plus spécifiques:

● Support externe/amovible;
● Attrition;
● Web;
● E-mail;
● Impersonation;
● Utilisation inappropriée;
● Perte ou vol d’équipement;
● Autre.
Support externe/amovible
Une attaque exécutée à partir d'un support amovible ou d'un périphérique, par
exemple, un code malveillant se propageant sur un système à partir d'une clé USB
infectée.
 Attrition
Une attaque qui utilise des méthodes de force brute pour compromettre, dégrader ou
détruire des systèmes, des réseaux ou des services (par exemple, un DDoS destiné à altérer
ou à refuser l'accès à un service ou à une application ; une attaque par force brute contre un
mécanisme d'authentification, tel que comme mots de passe, CAPTCHAS ou signatures
numériques).
 Web
Une attaque exécutée à partir d'un site Web ou d'une application Web, par exemple, une attaque de
script intersite utilisée pour voler des informations d'identification ou une redirection vers un site
qui exploite une vulnérabilité du navigateur et installe un logiciel malveillant.
 E-mail 
Une attaque exécutée via un e-mail ou une pièce jointe, par exemple, un code d'exploitation
déguisé en pièce jointe ou un lien vers un site Web malveillant dans le corps d'un e-mail.
 Impersonation
Une attaque impliquant le remplacement de quelque chose de bénin par quelque chose de
malveillant, par exemple, l'usurpation d'identité, les attaques de l'homme du milieu, les
points d'accès sans fil malveillants et les attaques par injection SQL impliquent toutes
l'usurpation d’identité.
Utilisation inappropriée

Tout incident résultant de la violation des politiques d'utilisation acceptables d'une

organisation par un utilisateur autorisé, à l'exclusion des catégories ci-dessus ; par
exemple, un utilisateur installe un logiciel de partage de fichiers, entraînant la perte
de données sensibles ; ou un utilisateur effectue des activités illégales sur un
système.
 Perte ou vol d'équipement
La perte ou le vol d'un appareil informatique ou d'un support utilisé par
l'organisation, comme un ordinateur portable, un smartphone ou un jeton
d'authentification.
 Autre
Une attaque qui n'entre dans aucune des autres catégories.
 02
Signes d'un incident
 Pour de nombreuses organisations, la partie la plus difficile du
processus de réponse aux incidents consiste à détecter et à
évaluer avec précision les incidents possibles, à déterminer si un
incident s'est produit et, le cas échéant, le type, l'étendue et
l'ampleur du problème.

Ce qui rend cela si difficile est une combinaison de trois

facteurs :
 Les incidents peuvent être détectés par de nombreux moyens différents, avec différents niveaux de
détail et de fidélité. Les capacités de détection automatisées incluent des IDPS basés sur le réseau
et sur l'hôte, des logiciels antivirus et des analyseurs de journaux. Les incidents peuvent également
être détectés par des moyens manuels, tels que les problèmes signalés par les utilisateurs. Certains
incidents ont des signes évidents qui peuvent être facilement détectés, tandis que d'autres sont
presque impossibles à détecter.

Le volume de signes potentiels d'incidents est généralement élevé. Par exemple, il n'est pas rare
qu'une organisation reçoive des milliers, voire des millions, d'alertes de capteur de détection
d'intrusion par jour.

Des connaissances techniques approfondies et spécialisées et une vaste expérience sont

nécessaires pour une analyse appropriée et efficace des données relatives aux incidents.
Les signes d'un incident appartiennent à l'une des deux
catégories suivantes : précurseurs et indicateurs.

Un précurseur est un signe qu'un incident peut se produire dans

le futur.

Un indicateur est un signe qu'un incident peut s'être produit ou

peut se produire actuellement.
La plupart des attaques n'ont pas de précurseurs identifiables ou
détectables du point de vue de la cible.

Si des précurseurs sont détectés, l'organisation peut avoir la possibilité

de prévenir l'incident en modifiant sa posture de sécurité pour sauver
une cible d'une attaque.

Au minimum, l'organisation pourrait surveiller de plus près l'activité

impliquant la cible.
Voici des exemples de précurseurs :

Entrées de journal du Une annonce d'un nouvel

exploit ciblant une Une menace d'un groupe
serveur Web indiquant
vulnérabilité du serveur de déclarant que le groupe
l'utilisation d'un scanner
messagerie de attaquera l'organisation.
de vulnérabilité
l'organisation
 Voici des exemples d’indicateur :
Le logiciel antivirus Un administrateur
alerte lorsqu'il détecte système voit un nom de
qu'un hôte est infecté par fichier avec des
un logiciel malveillant. caractères inhabituels.
Un capteur de détection
d'intrusion réseau alerte
lorsqu'une tentative de
débordement de la mémoire
tampon se produit sur un
serveur de base de données.
Un hôte enregistre un Une application enregistre Une application enregistre
changement de plusieurs tentatives de plusieurs tentatives de connexion
configuration d'audit connexion infructueuses à infructueuses à partir d'un
dans son journal. partir d'un système distant système distant inconnu.
inconnu.
Un administrateur réseau
Un administrateur de
remarque un écart
messagerie voit un grand
inhabituel par rapport
nombre d'e-mails rejetés
aux flux de trafic réseau
avec un contenu suspect.
typiques.
03 Sources des précurseurs et indicateurs
Les précurseurs et les indicateurs sont identifiés à l'aide de
nombreuses sources différentes, les plus courantes étant les
alertes de logiciels de sécurité informatique, les journaux,
les informations accessibles au public et les personnes.
Developments
Les alertes
IDPS, SIEM, Antivirus,
Antispam, Logiciel de
vérification de l'intégrité
des fichiers,Services de
surveillance tiers
Informations
Les logs Les personnes
accessibles au public
Journaux du système
d'exploitation, des Personnes dans
services et des Informations sur les l’organisations,
applications, Journaux nouvelles vulnérabilités Personnes d'autres
des périphériques réseau, et exploits  organisations
Flux réseau 
04 Analyse des incidents
La détection et l'analyse des incidents seraient faciles si chaque
précurseur ou indicateur était garanti comme étant exact ;
Malheureusement, ce n'est pas le cas.

Pour cela l’équipe de réponse aux incidents doit travailler

rapidement pour analyser et valider chaque incident, en suivant
un processus prédéfini et en documentant chaque étape franchie.
Effectuer l'analyse et la validation initiales est un défi. Voici des
recommandations pour rendre l'analyse des incidents plus facile et plus
efficace :

● profil Réseaux et Systèmes,

● comprendre les comportements normaux,
● créez une stratégie de conservation des journaux,
● effectuer une corrélation d’événements,
● gardez toutes les horloges hôtes synchronisées,
● maintenir et utiliser une base de connaissances d’informations,
● utilisez les moteurs de recherche Internet pour la recherche,
● exécutez des renifleurs de paquets pour collecter des données
supplémentaires,
● filtrez les données,
● demander de l'aide aux autres.
 05
Documentation des incidents
 Étape fondamentale
Une équipe d'intervention en cas d'incident qui soupçonne qu'un incident s'est produit doit
commencer immédiatement à enregistrer tous les faits concernant l'incident.

Pour cela:
● un journal de bord est un moyen efficace et simple ,
● les ordinateurs portables,
● les enregistreurs audio,
● les appareils photo numériques.
L'équipe d'intervention en cas d'incident doit conserver des enregistrements sur l'état des incidents,
ainsi que d'autres informations pertinentes.

L'utilisation d'une application ou d'une base de données, telle qu'un système de suivi des problèmes,
permet de s'assurer que les incidents sont traités et résolus en temps opportun.

Le système de suivi des problèmes doit contenir des informations sur les éléments suivants :

● l'état actuel de l'incident (nouveau, en cours, transmis pour enquête, résolu, etc.),
● un résumé de l’incident,
● l’indicateurs liés à l'incident,
● autres incidents liés à cet incident,
● actions prises par tous les gestionnaires d'incidents sur cet incident,
● évaluations d'impact liées à l’incident,
● coordonnées des autres parties impliquées (par exemple, les propriétaires du système, les
administrateurs système),
● une liste des preuves recueillies au cours de l'enquête sur l'incident,
● commentaires des gestionnaires d'incidents,
● prochaines étapes à suivre (par exemple, reconstruire l'hôte, mettre à niveau une application).
L'équipe d'intervention en cas d'incident doit protéger les données d'incident et
en restreindre l'accès, car elles contiennent souvent des informations
sensibles, par exemple des données sur les vulnérabilités exploitées, les
failles de sécurité récentes et les utilisateurs susceptibles d'avoir effectué
des actions inappropriées.

Par exemple, seul le personnel autorisé doit avoir accès à la base de données des
incidents.

Les communications d'incident (par exemple, les e-mails) et les documents doivent être
cryptés ou autrement protégés afin que seul le personnel autorisé puisse les lire.
06 Hiérarchisation des incidents
Prioriser le traitement de l'incident est peut-être le point de décision le plus critique
dans le processus de traitement des incidents. Les incidents ne doivent pas être
traités selon le principe du premier arrivé, premier servi en raison des ressources
limitées.

Au lieu de cela, la manipulation doit être priorisée en fonction des facteurs

pertinents, tels que les suivants :

● impact fonctionnel de l'incident,

● informations sur l'impact de l’incident,
● récupération de l’Incident.
Categorie Définition
Aucun effet sur la capacité de l'organisation à fournir tous
None les services à tous les utilisateurs

Effet minime ; l'organisation peut toujours fournir tous

Faible les services critiques à tous les utilisateurs mais a perdu
en efficacité

L'organisation a perdu la capacité de fournir un service

Moyen essentiel à un sous-ensemble d'utilisateurs du système

L'organisation n'est plus en mesure de fournir certains

Haut services essentiels aux utilisateurs

Catégories d'impact fonctionnel

 Categorie Définition
Aucune information n'a été exfiltrée, modifiée, supprimée
None ou autrement compromise

Des informations sensibles d'identification personnelle

Privacy Breach (PII) des contribuables, des employés, des bénéficiaires,
etc. ont été consultées ou exfiltrées

Des informations exclusives non classifiées, telles que les

Proprietary Breach informations protégées sur les infrastructures critiques
(PCII), ont été consultées ou exfiltrées

Des informations sensibles ou exclusives ont été

Integrity Loss modifiées ou supprimées

Catégories d'impact des informations

Categorie Définition
Le temps de récupération est prévisible avec les
Régulier ressources existantes

Le temps de récupération est prévisible avec des

Supplémentaire ressources supplémentaires

Le temps de récupération est imprévisible; des ressources

Extend(élargi) supplémentaires et une aide extérieure sont nécessaires

La récupération après l'incident n'est pas possible (par

Non récupérable exemple, des données sensibles sont exfiltrées et publiées
publiquement) ; lancer une enquête

Catégories d'effort de récupération

 07
Notification d’incidents
 Les personnes à signaler
Les politiques de réponse aux incidents doivent inclure des dispositions concernant le signalement
des incidents au minimum, ce qui doit être signalé à qui et à quel moment (par exemple,
notification initiale, mises à jour régulières de l’état).

Les exigences exactes en matière de déclaration varient d'une organisation à l'autre, mais les
parties qui sont généralement notifiées comprennent :
● DSI,
● Responsable de la sécurité informatique,
● Responsable local de la sécurité de l’information,
● Autres équipes de réponse aux incidents au sein de l’organisation,
● Équipes externes de réponse aux incidents (le cas échéant),
● Propriétaire du système,
● Ressources humaines (pour les cas impliquant des employés, comme le harcèlement par
courriel),
● Affaires publiques (pour les incidents pouvant générer de la publicité),
● Service juridique (pour les incidents ayant des ramifications juridiques potentielles),
● US-CERT (requis pour les agences fédérales et les systèmes exploités au nom du gouvernement
fédéral ).
Les différents méthodes de communication :

● Courriel,
● Site Web (interne, externe ou portail)
● Appels téléphoniques
● En personne (par exemple, briefings quotidiens)
● Message d'accueil de la boîte vocale (par exemple, configurer
une boîte vocale distincte pour les mises à jour d'incident et
mettre à jour le message d'accueil pour refléter l'état actuel de
l'incident ; utiliser le message d'accueil de la messagerie vocale
du service d’assistance)
● Papier (p. ex., afficher des avis sur les babillards et les portes,
distribuer des avis à tous les points d'entrée).
Grande étapes
1 Identifier VA

Signe Incidents 2

3 Identifier sources

Analyse 4

5 Documentation

Hiérarchisation 6

7 Notification
Thank you!