Nécessité d’un processus de gestion des incidents
La première chose que l’on peut dire sur les incidents de sécurité est qu’ils sont
nécessaires (au sens probabiliste du terme), c’est-à-dire que tôt ou tard, il est certain que
le SI sera confronté à de tels événements.
Jamais le terme « responsable de la sécurité du SI » n’a autant de sens que lorsqu’un
incident survient. En effet, le RSSI doit répondre de la sécurité du SI dont il a la
responsabilité. Il centralise tous les regards car tout le monde veut connaître les
conséquences de l’incident et comment les résoudre. Le RSSI doit apprendre à gérer
cette situation très délicate.
Par ailleurs, les incidents de sécurité sont d’autant plus inconfortables à gérer que, par
nature, ce sont des phénomènes que l’on subit (si on ne les subissait pas, nous ne
parlerions pas d’incident). Le RSSI est donc nécessairement en mode réactif. Il a toujours
un temps de retard par rapport à l’événement, du moins au début. Trois cas de figure sont
possibles.
Absence totale de processus de gestion d’incidents : c’est le règne de
l’improvisation. Aussi, lorsqu’un incident survient, personne ne sait ce qu’il doit faire.
Comme aucune action n’est coordonnée, l’impact de l’incident ne cesse de s’accroître.
Ce n’est qu’après un temps que les rôles et responsabilités sont répartis et que les
mesures de lutte sont prises. Cette première façon de gérer les incidents est
naturellement la plus mauvaise car toute l’équipe informatique subit les événements
de bout en bout, avec des conséquences pouvant atteindre parfois des proportions
désastreuses.
Présence d’un processus, nouvel incident : dans ce cas, on dispose en interne d’une
procédure de gestion des incidents, où chacun connaît son rôle et réagit
immédiatement, de façon cohérente. Certes, le caractère nouveau de l’incident fait
qu’un travail relativement important d’enquête doit être réalisé pour comprendre sa
nature et pour évaluer son impact, mais comme les rôles sont bien répartis, la réaction
est globalement pertinente, limitant ainsi les conséquences.
Présence d’un processus, incident connu : c’est la meilleure situation possible.
Lorsqu’un incident survient et qu’il s’est déjà produit par le passé, il suffit de se
référer à la fiche réflexe rédigée spécifiquement pour ce type d’incident. Ainsi, la
réaction est très rapide et efficace. L’impact négatif est minimal.
Ces trois exemples illustrent clairement la relation directe entre le temps de réaction à
l’incident et ses conséquences. Le but de la gestion des incidents de sécurité est
précisément de rattraper le plus vite possible ce temps de retard. Ce rattrapage rapide ne
peut s’effectuer qu’en mettant en place un processus approprié.
La première chose que l’on peut dire sur les incidents de sécurité est qu’ils sont
nécessaires (au sens probabiliste du terme), c’est-à-dire que tôt ou tard, il est certain que
le SI sera confronté à de tels événements.
Jamais le terme « responsable de la sécurité du SI » n’a autant de sens que lorsqu’un
incident survient. En effet, le RSSI doit répondre de la sécurité du SI dont il a la
responsabilité. Il centralise tous les regards car tout le monde veut connaître les
conséquences de l’incident et comment les résoudre. Le RSSI doit apprendre à gérer
cette situation très délicate.
Par ailleurs, les incidents de sécurité sont d’autant plus inconfortables à gérer que, par
nature, ce sont des phénomènes que l’on subit (si on ne les subissait pas, nous ne
parlerions pas d’incident). Le RSSI est donc nécessairement en mode réactif. Il a toujours
un temps de retard par rapport à l’événement, du moins au début. Trois cas de figure sont
possibles.
Absence totale de processus de gestion d’incidents : c’est le règne de
l’improvisation. Aussi, lorsqu’un incident survient, personne ne sait ce qu’il doit faire.
Comme aucune action n’est coordonnée, l’impact de l’incident ne cesse de s’accroître.
Ce n’est qu’après un temps que les rôles et responsabilités sont répartis et que les
mesures de lutte sont prises. Cette première façon de gérer les incidents est
naturellement la plus mauvaise car toute l’équipe informatique subit les événements
de bout en bout, avec des conséquences pouvant atteindre parfois des proportions
désastreuses.
Présence d’un processus, nouvel incident : dans ce cas, on dispose en interne d’une
procédure de gestion des incidents, où chacun connaît son rôle et réagit
immédiatement, de façon cohérente. Certes, le caractère nouveau de l’incident fait
qu’un travail relativement important d’enquête doit être réalisé pour comprendre sa
nature et pour évaluer son impact, mais comme les rôles sont bien répartis, la réaction
est globalement pertinente, limitant ainsi les conséquences.
Présence d’un processus, incident connu : c’est la meilleure situation possible.
Lorsqu’un incident survient et qu’il s’est déjà produit par le passé, il suffit de se
référer à la fiche réflexe rédigée spécifiquement pour ce type d’incident. Ainsi, la
réaction est très rapide et efficace. L’impact négatif est minimal.
Ces trois exemples illustrent clairement la relation directe entre le temps de réaction à
l’incident et ses conséquences. Le but de la gestion des incidents de sécurité est
précisément de rattraper le plus vite possible ce temps de retard. Ce rattrapage rapide ne
peut s’effectuer qu’en mettant en place un processus approprié.