Dans cette partie, nous allons détailler les
étapes du processus de gestion des incidents présentée
d'une manière générale.
III.6.1. Détection et signalement de
l'incident
La détection peut avoir pour origine :
? toute personne qui a connaissance d'un fait ou d'une menace
pour l'organisme (par
exemple comportement anormal d'un équipement, d'une
application ou d'une
personne),
? un administrateur lorsqu'il est informé par un
dispositif de supervision ou lorsqu'il constate une anomalie lors des
contrôles,
? un acteur de la sécurité lorsqu'il est
informé par un outil de surveillance (détection d'intrusion ou
d'action frauduleuse) ou lorsqu'il constate une anomalie lors des
contrôles.
L'anomalie doit pouvoir être signalée à
une personne compétente dans les plus brefs délais. Le contact
habituel pour l'utilisateur est le help desk.
Cependant, il doit également être possible de
contacter directement un responsable de la sécurité en toute
discrétion si la situation l'exige. Les utilisateurs doivent être
sensibilisés et informés sur les différents niveaux
d'alerte.
Dans tous les cas, on doit s'assurer que les moyens d'alerte
sont suffisamment rapides, y compris en dehors des heures ouvrées, pour
permettre une réponse adaptée (empêcher que l'incident se
poursuive, préserver les preuves, etc.).
Des mesures immédiates peuvent être
associées à la détection, soit sous forme de consignes
pour la personne qui détecte, soit par l'activation automatique de
mécanismes de protection.
54
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
III.6.2. Enregistrement de l'incident
Comme indiqué précédemment, un incident
supposé de sécurité peut être signalé
à différentes personnes, en général le help desk,
selon des procédures devant être connues de tous. Dans tous les
cas, la personne qui réceptionne l'appel ou l'alerte doit en accuser
réception.
L'événement doit immédiatement
être enregistré dans une base de données des incidents. A
ce stade de la procédure, l'événement n'est pas encore
qualifié d'incident de sécurité mais il est
catégorisé. L'enregistrement de l'événement doit
comporter à minima la date et l'heure de l'alerte, son origine (personne
ou dispositif technique), les coordonnées du déclarant, une
description aussi précise que possible de l'événement et
sa catégorisation. Comme pour tout incident, un numéro de dossier
est généré et communiqué si nécessaire au
déclarant. La personne qui enregistre l'événement doit
également mentionner l'action immédiate traitement des incidents
de sécurité pour qualification).
L'enregistrement de l'événement est essentiel
à plusieurs titres. Il permet de garder une trace de chaque
événement et d'en effectuer un suivi dans toutes les phases
ultérieures, d'analyse ou de traitement, jusqu'à la fermeture du
dossier. La base des événements constitue également un
outil d'analyse a posteriori dans le cadre d'analyses de risques, pour
évaluer l'efficacité des dispositifs en place ou pour identifier
des incidents récurrents pouvant être qualifiés de «
problème ».
III.6.3. Catégorisation de
l'incident
Une fois l'incident identifié comme « incident de
sécurité potentiel», l'équipe support peut être
habilitée pour prendre des mesures ou transmettre l'incident à
l'équipe de gestion des incidents de sécurité.
L'équipe de réponse aux incidents de
sécurité établit des consignes d'alerte
sécurité (fiches par type d'incident) pour les équipes
support.
Pour les incidents identifiés, ces consignes indiquent
le mode opératoire du traitement de ces incidents pour les
équipes de support. Dans les autres cas, c'est l'équipe de
réponse aux incidents de sécurité qui doit être
immédiatement sollicitée.
Par exemple : l'équipe de réponse aux incidents
de sécurité peut également être sollicitée
à chaque fois qu'une équipe support ou qu'un membre du personnel
pense être face à un événement susceptible d'avoir
un impact fort sur l'organisation.
55
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
Les consignes peuvent éventuellement spécifier
que tout incident susceptible d'être d'origine malveillante ou concernant
certains équipements ou logiciels ou encore signalé par certains
dispositifs techniques, doit être transmis à l'équipe de
réponse aux incidents de sécurité.
III.6.4. Qualification de l'incident
Une première analyse, conduite par l'équipe de
réponse aux incidents de sécurité, confirme ou infirme la
catégorisation « incident de sécurité ». Les
incidents non confirmés « incident de sécurité »
sont transmis aux équipes support pour traitement. L'équipe de
réponse aux incidents de sécurité procède si
nécessaire à des investigations complémentaires pour
qualifier l'événement. Les critères d'évaluation
d'impact prenant en compte différents axes d'analyse (impacts
financiers, impacts sur l'image, impacts sur les clients ou partenaires,
risques de poursuite judiciaire, etc.) doivent être
préétablis et mis à la disposition de l'équipe.
Typiquement ces critères sont issus de l'analyse de risque. Il est
nécessaire de tenir un journal de bord horodaté et précis
des événements et actions dès sollicitation de
l'équipe.
III.7. Réponse à l'incident
SSI
III.7.1. Mesures de réponses immédiates
Suite à la qualification, des mesures d'urgence peuvent
être prises pour limiter les impacts et préserver les traces. En
effet, même sans connaître précisément la nature de
l'incident, son origine ou son impact réel qui seront l'objet de la
phase d'analyse, le simple fait d'identifier le type de danger peut
déclencher des actions palliatives, comme par exemple :
· un confinement (ex : débranchement du
réseau d'un poste infecté pour le mettre dans un VLAN de
quarantaine),
· une isolation (ex : couper tous les flux de messagerie
Internet),
· une communication ciblée de recommandations.
Certaines de ces mesures peuvent être prévues
à l'avance dans des procédures du support et de l'équipe
sécurité.
Si ces mesures s'avèrent insuffisantes ou/et si la
situation n'est pas maitrisée ou/et si le niveau d'impact de l'incident
le justifie, au regard des critères d'évaluation, la cellule de
crise doit être activée.
56
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
III.7.2. Investigations
L'analyse de l'incident a pour objectif de préciser les
éléments suivants :
? la nature de l'incident, ? le fait
générateur,
? le périmètre concerné, ? l'impact.
Ces éléments permettront de définir les
actions à entreprendre. Dans certains cas les conclusions de
l'investigation peuvent conduire à l'activation de la cellule de
crise.
III.7.2.1. Préservation des traces
Certaines précautions doivent être prises. En
particulier, en cas de piratage (par exemple), si le but de l'analyse est de
remonter à la source de la manipulation frauduleuse et de prendre des
mesures légales à l'encontre des auteurs des faits, il est
nécessaire de préserver les informations d'origines (logs, etc.)
afin de conserver le contexte de preuve.
En effet, l'analyse peut, dans certains cas modifier (le
travail d'analyse génère lui-même des traces qui se
confondent ensuite avec les traces laissées par l'agresseur), voire
effacer, les traces du passage d'un `attaquant'. De fait, il est
nécessaire de sauvegarder (par exemple via une copie intégrale,
de type bit à bit) les informations avant d'entreprendre toute action
susceptible de nuire à l'intégrité des données sur
le support d'origine.
Si une copie complète des disques n'est pas
réalisable ou l'est difficilement, il faut au moins conserver une copie
des logs (journaux de connexions au système). Toutefois, cette
sauvegarde n'est pas toujours simple à mettre en oeuvre et peut
nécessiter des outils et/ou des compétences
particulières.
Enfin, les données ainsi sauvegardées doivent
être protégées physiquement et un cadre opératoire
doit être mis en oeuvre qui précisera notamment par qui ces
sauvegardes ont été effectuées, à quel moment,
comment elles ont été protégées et qui y a eu
accès. En fonction des enjeux, il peut être recommandé de
faire appel à un huissier de justice.
Le travail d'investigation pourra alors commencer, si
possible sur les copies de sauvegarde, les disques durs d'origine étant
rangés en lieu sûr (une procédure pouvant durer des mois,
voire des années). Ces derniers ainsi que la sauvegarde des logs,
pourront servir de preuves en cas de poursuites judiciaires.
57
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
III.7.2.2. Environnements potentiellement
concernés
Durant l'investigation il est important de déterminer le
périmètre concerné :
· OS,
· réseau et téléphonie,
· serveurs,
· applications,
· locaux,
· groupe de personnes,
· données,
· services,
· clients, fournisseurs, partenaires, ...
III.7.2.3. Aide à l'analyse
Dans chaque environnement technique il existe des outils qui
peuvent aider à déterminer l'étendue de l'attaque
menée.
Des procédures peuvent également être mises
en oeuvre, intégrant des check-lists qui permettent de réaliser
l'analyse dans les meilleures conditions. Par exemple, on peut positionner les
actions suivantes :
· vérifier les performances des systèmes,
· rechercher des processus ou des applications non
autorisées en cours d'exécution,
· si des logs existent, y rechercher d'éventuelles
connexions inhabituelles, tentatives d'ouverture de session infructueuses,
tentatives d'ouverture de session avec des comptes par défaut, etc.,
· déterminer si du matériel non
autorisé a été connecté au réseau,
· examiner les groupes clés (administrateurs, etc.)
afin de vérifier qu'ils ne contiennent pas de membres non
autorisés,
· etc
III.7.2.4. Identification du fait
générateur et analyse de l'impact
L'objet principal de l'analyse de l'incident proprement dit
permet de répondre à plusieurs questions qui se posent, comme par
exemple :
58
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
· quelle est la vulnérabilité ou la faiblesse
qui a rendu possible l'incident ? C'est la question la plus importante ! En
effet, si aucune réponse claire n'est trouvée à cette
question, le système restera vulnérable une fois remis en service
; il pourrait être attaqué à nouveau,
· quel est l'inventaire des dégâts ou quel est
l'impact de l'incident (déni de service, baisse de la qualité du
service, perte de donnée, divulgation d'information confidentielle,
etc.).
III.7.3. Traitement
III.7.3.1. Mesures pour éviter l'aggravation
des conséquences
En complément des mesures de réponses
immédiates déjà prises dès la qualification de
l'incident, des mesures peuvent être prises pour éviter
l'aggravation des conséquences. Disposant à ce stade des
informations obtenues lors des investigations, ces mesures seront plus
ciblées que les réponses conservatoires d'urgence :
· activation de la Cellule de Crise : elle n'a pas
été activée lors de la phase de réponse
immédiate, la gestion de crise du PCA peut être
déclenchée à ce stade, si la situation s'est
dégradée entre temps et l'impose,
· restrictions temporaires d'accès aux
réseaux ou/et aux applications : ces restrictions peuvent être,
suivant les cas, des blocages ou des simples filtrages. (Exemple : interdiction
d'accès à certains sites Web),
· communications ciblées : pour adapter la
communication, il faut évaluer très rapidement la durée de
la perturbation (exemple : évaluer la durée de restauration par
rapport au volume de données à restaurer en cas de pertes de
données). On identifie trois types de communication :
o communication vers les utilisateurs: le communiqué
contient en règle générale à minima:
· les faits qui doivent être édulcorés
dans certains cas,
· les activités impactées du fait des
restrictions temporaires en place,
· des consignes de comportements (exemple : ne pas ouvrir
les pièces jointes),
· l'heure prévisionnelle de retour à la
normale,
o communication technique entre homologues (d'autres sites ou
filiales) :
· les faits précis,
· les recommandations d'actions,
· une proposition d'actions coordonnées,
59
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
o communication vers les externes (clients, assureurs,
fournisseurs, etc.). On peut utiliser si besoin la communication de crise
prévue dans le cadre du PCA.
III.7.3.2. Résolution de
l'incident
Sans être exhaustifs, les quelques points ci-dessous
nécessitent une attention particulière.
Appels aux supports externes
L'entreprise ou l'organisme peut avoir besoin d'urgence de
compétences externes qui interviendront à distance ou sur site et
qu'il faut réserver en priorité en raison des délais
d'intervention.
Éradication
L'éradication du problème dépend du type
d'incident rencontré.
On peut noter deux grandes tendances entre lesquelles il faudra
choisir :
· le mode « réparation », souvent manuel
mais qui peut être automatisé par un script,
· le mode « restauration ou réinstallation
» en repartant d'une sauvegarde ou d'une image système.
Les critères de choix entre ces deux méthodes sont
:
· le temps total (estimation) pour éradiquer
l'incident,
· le niveau de certitude d'avoir bien identifié tous
les impacts précis liés à l'incident,
· le niveau de perte de données acceptable.
Dans les cas complexes, il peut être important
d'écrire le plan d'action correctif pour bien ordonnancer les
étapes.
Détermination du point zéro de
l'incident
Les éléments permettant de déterminer le
point zéro sont (entre autres):
· le recueil des preuves et journaux,
· le témoignage des utilisateurs,
· tous les outils de supervision et reporting.
60
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
Cette compréhension de l'origine de l'incident permet
de vérifier la pertinence des mesures correctives et de réduire
le risque de reproduction.
Délai de Réapprovisionnement de
matériel
Même si l'entreprise/organisme utilise le
matériel de secours, il n'est pas recommandé de « rouler
trop longtemps sans roue de secours ». C'est pourquoi le
réapprovisionnement du matériel est également une
priorité.
Retour à la normale
Le retour à la normale doit être associé
à une communication spécifique.
III.7.4. Revues post-incident
III.7.4.1. Investigation
post-incident
Une fois l'incident maîtrisé, il est possible
qu'il soit nécessaire de lancer des investigations
complémentaires pour bien comprendre comment cet incident a pu avoir
lieu. Si tel est le cas, il ne faut pas hésiter à consacrer le
temps nécessaire à cette étape qui viendra enrichir le
dossier de synthèse.
Si des éléments de preuve sont encore
présents et que l'incident a vocation à être
présenté devant un tribunal, la collecte des indices devra
être particulièrement précise et se conformer aux bonnes
pratiques techniques en adéquation avec les obligations
légales.
III.7.4.2. Rapport de synthèse
Chaque incident de sécurité doit être
accompagné d'un dossier de suivi et si possible d'un rapport de
synthèse. Ce rapport doit être rédigé par
l'équipe en charge de la résolution de l'incident. Il peut servir
de cadre directeur lors d'une revue post-incident, dans la mesure où il
apporte les réponses par rapport aux causes techniques, à la
défaillance du SMSI et à la perte financière.
Le rapport de synthèse doit être
rédigé au plus près de la date de résolution de
l'incident afin d'éviter que le temps n'efface dans la mémoire
des acteurs des éléments ou des détails importants pour la
compréhension et l'analyse de l'incident. Le rapport doit
prioritairement présenter des conclusions claires compréhensibles
par les responsables. Ce rapport doit être conservé dans un espace
dédié servant de base de connaissance aux incidents de
sécurité. Cette base d'information pourra par la suite être
mise à profit pour une meilleure anticipation des
61
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
incidents, pour définir les contremesures les plus
appropriées ou encore pour vérifier si les décisions
actées ont été suivies d'effets.
III.7.4.3. Analyse post-incident
L'analyse post-incident s'inscrit dans une démarche
d'amélioration continue et de qualité. PDCA permettant de prendre
connaissance des éléments qui doivent évoluer dans le
Système d'Information. Cette analyse post-incident doit impliquer les
responsables pour que les engagements soient pris rapidement en matière
d'évolution du Système d'Information. Celle-ci peut prendre la
forme d'un comité de pilotage ou tout autre type de réunion
impliquant les décideurs adéquats. Un compte-rendu de l'analyse
post-incident doit être rédigé pour acter des
évolutions du Système d'Information
III.7.5. Actions post-incident
III.7.5.1. Bilan de l'incident
Les informations et les mesures déterminées
lors du traitement de l'incident doivent être conservées et
permettre d'enrichir la base de connaissances. Dans le traitement d'un incident
majeur, il est important d'analyser avec recul, ce qui a bien fonctionné
et ce qui a moins bien fonctionné.
Cela doit se traduire par la rédaction d'un bilan
adressé aux directions concernées. La mise en place des mesures
du bilan, de préférence sous forme de plan d'actions
précis, devra être suivie par le responsable
sécurité.
III.7.5.2. Révision des contrats
Il peut être nécessaire de réviser les
contrats d'assurance ou d'engagement avec des fournisseurs.
III.7.5.3. Communication interne spécifique
(sensibilisation, etc.)
Les incidents rencontrés par l'équipe de
réponse aux incidents lui procurent une bonne visibilité des
choses à faire et à éviter. Cette connaissance peut
être mise à contribution pour des actions ponctuelles ou
récurrentes de sensibilisation auprès de publics variés
(salariés, managers, développeurs, etc.).
62
Mémoire de M2TDSI | Gestion des incidents de
sécurité avec Request Tracker | Mor Thiam
