Points clés d’un processus de gestion d’incidents
Paradoxalement, le travail s’opère essentiellement hors situation d’incident. En effet, le
RSSI doit installer et animer des dispositifs de veille et de détection. De plus, des
procédures appropriées doivent assurer une réaction pertinente. Enfin, un travail
important doit être réalisé après tout incident. Nous allons passer en revue ces étapes, qui
sont les points clés dans la gestion des incidents de sécurité du SI.
La veille, ou la détection d’incidents potentiels
La veille consiste à identifier les plus importantes vulnérabilités rendues publiques, pour
s’en prémunir avant l’arrivée des attaques. On peut se demander pourquoi parler de veille
puisqu’à proprement parler il ne s’agit pas ici de gérer des incidents de sécurité ; c’est
parce que la veille conduit précisément à mener des actions préventives afin d’éviter ces
incidents. Il est donc parfaitement justifié d’intégrer la veille dans le processus de gestion
des incidents.
Les moyens de faire la veille n’ont cessé d’évoluer. Si l’abonnement à des listes de
diffusion bien ciblées, en fonction des infrastructures en place, est toujours de mise, les
médias ont continué de s’enrichir. Aujourd’hui, le RSSI a l’embarras du choix quant à la
veille. Selon sa culture technique et son parcours, il pourra être à l’écoute de canaux IRC
spécialisés, s’abonner à des flux RSS, consulter quotidiennement les alertes publiées par
les CERT, voire suivre quelques confrères reconnus sur les réseaux sociaux, très au fait
des vulnérabilités jaillissantes. Il peut naturellement s’abonner à des veilles privées, plus
ou moins configurées pour cibler uniquement les avis concernant le client. Dans ce
domaine, il ne faut avoir aucun complexe. Tout moyen d’être alerté rapidement des
vulnérabilités importantes est bon à prendre.
Tous ces médias génèrent énormément de données qu’il est littéralement impossible
d’analyser dans le détail. On peut tout juste les parcourir. La difficulté pour le RSSI
consiste à savoir extraire de ce bruit de fond les alertes qui le concernent et qui sont
importantes, car si des vulnérabilités sont rendues publiques quasiment tous les jours,
seules quelques-unes nécessitent un traitement d’urgence.
Lorsqu’une vulnérabilité est jugée suffisamment importante pour être traitée sans délai,
le RSSI peut décider de la qualifier comme « incident potentiel ». Ceci déclenche
généralement un processus d’application de patchs sur les infrastructures identifiées
comme vulnérables. Le circuit de traitement de la vulnérabilité sera très similaire à celui
d’un incident de sécurité.
En fait, la veille est l’exception qui confirme la règle, puisque dans ce cas, c’est le RSSI
qui a un temps (très court) d’avance sur l’attaque.
Détection et signalement des incidents
Les incidents peuvent être détectés par plusieurs canaux différents, selon leur nature. Ces
canaux existent généralement depuis longtemps et il suffit au RSSI d’en faire l’inventaire
Paradoxalement, le travail s’opère essentiellement hors situation d’incident. En effet, le
RSSI doit installer et animer des dispositifs de veille et de détection. De plus, des
procédures appropriées doivent assurer une réaction pertinente. Enfin, un travail
important doit être réalisé après tout incident. Nous allons passer en revue ces étapes, qui
sont les points clés dans la gestion des incidents de sécurité du SI.
La veille, ou la détection d’incidents potentiels
La veille consiste à identifier les plus importantes vulnérabilités rendues publiques, pour
s’en prémunir avant l’arrivée des attaques. On peut se demander pourquoi parler de veille
puisqu’à proprement parler il ne s’agit pas ici de gérer des incidents de sécurité ; c’est
parce que la veille conduit précisément à mener des actions préventives afin d’éviter ces
incidents. Il est donc parfaitement justifié d’intégrer la veille dans le processus de gestion
des incidents.
Les moyens de faire la veille n’ont cessé d’évoluer. Si l’abonnement à des listes de
diffusion bien ciblées, en fonction des infrastructures en place, est toujours de mise, les
médias ont continué de s’enrichir. Aujourd’hui, le RSSI a l’embarras du choix quant à la
veille. Selon sa culture technique et son parcours, il pourra être à l’écoute de canaux IRC
spécialisés, s’abonner à des flux RSS, consulter quotidiennement les alertes publiées par
les CERT, voire suivre quelques confrères reconnus sur les réseaux sociaux, très au fait
des vulnérabilités jaillissantes. Il peut naturellement s’abonner à des veilles privées, plus
ou moins configurées pour cibler uniquement les avis concernant le client. Dans ce
domaine, il ne faut avoir aucun complexe. Tout moyen d’être alerté rapidement des
vulnérabilités importantes est bon à prendre.
Tous ces médias génèrent énormément de données qu’il est littéralement impossible
d’analyser dans le détail. On peut tout juste les parcourir. La difficulté pour le RSSI
consiste à savoir extraire de ce bruit de fond les alertes qui le concernent et qui sont
importantes, car si des vulnérabilités sont rendues publiques quasiment tous les jours,
seules quelques-unes nécessitent un traitement d’urgence.
Lorsqu’une vulnérabilité est jugée suffisamment importante pour être traitée sans délai,
le RSSI peut décider de la qualifier comme « incident potentiel ». Ceci déclenche
généralement un processus d’application de patchs sur les infrastructures identifiées
comme vulnérables. Le circuit de traitement de la vulnérabilité sera très similaire à celui
d’un incident de sécurité.
En fait, la veille est l’exception qui confirme la règle, puisque dans ce cas, c’est le RSSI
qui a un temps (très court) d’avance sur l’attaque.
Détection et signalement des incidents
Les incidents peuvent être détectés par plusieurs canaux différents, selon leur nature. Ces
canaux existent généralement depuis longtemps et il suffit au RSSI d’en faire l’inventaire