Pertinence de la réaction : la vitesse de la réaction est inutile si les actions ne sont
pas pertinentes. Une mauvaise réaction peut même conduire à aggraver l’incident au
lieu de contribuer à le résoudre.
La meilleure façon de répondre à ces deux besoins consiste à mettre en place des
procédures. Celles-ci doivent être suffisamment précises pour que chacun sache
exactement comment réagir lorsqu’un incident survient. Généralement, deux niveaux de
documentation sont nécessaires.
Procédure générale de gestion des incidents : cette procédure décrit qui sont les
responsables dans la gestion des incidents et, plus précisément, qui décide si un
incident doit être qualifié d’incident de sécurité, qui en détermine la gravité, qui dirige
les actions d’enquête, les actions d’éradication de l’incident, etc. Cette procédure est
généralement complétée par des critères de qualification et une description des
différents outils à utiliser. L’avantage de cette procédure est de cadrer les actions des
uns et des autres. Elle favorise donc une bonne prise en charge des incidents.
Cependant, son inconvénient est qu’elle n’est pas spécifique aux différents types
d’incidents pouvant survenir.
Remarque
Une procédure de gestion d’incidents est présentée en annexe de cet ouvrage, à titre d’exemple.
Fiches réflexes : la procédure générale de gestion des incidents doit être complétée
par des fiches réflexes. Ces fiches sont par nature très synthétiques et ressemblent plus
à des modes opératoires qu’à des procédures. Leur but est de dicter, aussi précisément
que possible, la conduite à tenir par chaque personne impliquée dans le traitement de
l’incident. Chaque fiche est propre à un incident en particulier. On peut donc trouver
une fiche pour la réaction aux attaques virales, une autre contre les attaques par
hameçonnage, une autre contre les intrusions sur le réseau, etc. Généralement, il n’est
possible de rédiger ces fiches que lorsque l’on a déjà rencontré un incident similaire.
C’est d’ailleurs suite au retour d’expérience qu’elles sont rédigées.
Remarque
Deux fiches réflexes sont présentées en annexe de cet ouvrage, à titre d’exemple.
En conclusion, on peut dire qu’il n’y a pas de gestion des incidents sans une
documentation opérationnelle à jour, ni des équipes entraînées.
Comprendre l’attaque
Avant d’agir, il faut comprendre. C’est pour cela que la première mesure à prendre
consiste à analyser l’incident. Certains incidents, tels que les intrusions dans le réseau
interne sont peu bruyants et ne se font pas remarquer par les utilisateurs. Dans ce cas, le
RSSI et son équipe peuvent analyser en profondeur l’incident avant d’agir. En revanche,
lorsqu’un incident de sécurité affecte directement le bon fonctionnement du SI, les
services métier font pression pour que des mesures immédiates soient prises. Or, cette
précipitation peut s’avérer inutile, voire nuisible, si la nature profonde de l’incident n’est
pas pertinentes. Une mauvaise réaction peut même conduire à aggraver l’incident au
lieu de contribuer à le résoudre.
La meilleure façon de répondre à ces deux besoins consiste à mettre en place des
procédures. Celles-ci doivent être suffisamment précises pour que chacun sache
exactement comment réagir lorsqu’un incident survient. Généralement, deux niveaux de
documentation sont nécessaires.
Procédure générale de gestion des incidents : cette procédure décrit qui sont les
responsables dans la gestion des incidents et, plus précisément, qui décide si un
incident doit être qualifié d’incident de sécurité, qui en détermine la gravité, qui dirige
les actions d’enquête, les actions d’éradication de l’incident, etc. Cette procédure est
généralement complétée par des critères de qualification et une description des
différents outils à utiliser. L’avantage de cette procédure est de cadrer les actions des
uns et des autres. Elle favorise donc une bonne prise en charge des incidents.
Cependant, son inconvénient est qu’elle n’est pas spécifique aux différents types
d’incidents pouvant survenir.
Remarque
Une procédure de gestion d’incidents est présentée en annexe de cet ouvrage, à titre d’exemple.
Fiches réflexes : la procédure générale de gestion des incidents doit être complétée
par des fiches réflexes. Ces fiches sont par nature très synthétiques et ressemblent plus
à des modes opératoires qu’à des procédures. Leur but est de dicter, aussi précisément
que possible, la conduite à tenir par chaque personne impliquée dans le traitement de
l’incident. Chaque fiche est propre à un incident en particulier. On peut donc trouver
une fiche pour la réaction aux attaques virales, une autre contre les attaques par
hameçonnage, une autre contre les intrusions sur le réseau, etc. Généralement, il n’est
possible de rédiger ces fiches que lorsque l’on a déjà rencontré un incident similaire.
C’est d’ailleurs suite au retour d’expérience qu’elles sont rédigées.
Remarque
Deux fiches réflexes sont présentées en annexe de cet ouvrage, à titre d’exemple.
En conclusion, on peut dire qu’il n’y a pas de gestion des incidents sans une
documentation opérationnelle à jour, ni des équipes entraînées.
Comprendre l’attaque
Avant d’agir, il faut comprendre. C’est pour cela que la première mesure à prendre
consiste à analyser l’incident. Certains incidents, tels que les intrusions dans le réseau
interne sont peu bruyants et ne se font pas remarquer par les utilisateurs. Dans ce cas, le
RSSI et son équipe peuvent analyser en profondeur l’incident avant d’agir. En revanche,
lorsqu’un incident de sécurité affecte directement le bon fonctionnement du SI, les
services métier font pression pour que des mesures immédiates soient prises. Or, cette
précipitation peut s’avérer inutile, voire nuisible, si la nature profonde de l’incident n’est