Edito – L’échec de la protection : misons sur la détection et la réponse à incident

Suivez Cyber-Securite

Discover Ajouter comme
source préférée

Aujourd’hui, il est de coutume de dire que les entreprises ne doivent plus se demander quand elles ont été victimes d’une attaque informatique mais plutôt s’interroger depuis quand, comment et pourquoi leur système d’information a été compromis. Ce n’est malheureusement pas une caricature et les organisations (entreprise privée ou administration) se rendent à l’évidence : aucune défense n’est parfaite et il faut se préparer à réagir le plus efficacement à une cyber attaque.

C’est pourquoi après avoir misé sur la prévention et la protection, nous devons investir dans la détection et la réaction. Détecter pour identifier le plus en amont possible une tentative d’attaque, un comportement anormal sur ses réseaux ou une exfiltration de données. Répondre en étant préparé à réagir en cas d’incident de sécurité (attaque virale, DDoS, phishing…) à travers un véritable processus de gestion et de réponse à incidents :

1.     Préparation 

C’est une phase indispensable pour anticiper la gestion d’un incident de sécurité :

–  Organisation de la gestion des incidents : désigner un point de contact unique, lister les contacts utiles (internes et externes), les outils (base d’incident), les procédures (fiches de réaction rapide, procédure d’escalade, support de communication, analyses forensics…) l’infrastructure nécessaire, les astreintes, la formation des équipes, la collecte des incident, etc.

–  Communication autour du dispositif : les utilisateurs et les responsables informatiques doivent savoir qui contacter lors de la remontée d’un incident de sécurité

–  Coordination avec les processus de gestion de crise (si incident qualifié de majeur) ou de continuité d’activité.

 2.     Détection, identification et analyse

Pour réagir à un incident, l’équipe de réponse à incident (ou la cellule incident / CSIRT / CERT, IRT…) doit être au courant de la survenance d’un incident (le plus rapidement possible) :

–  Remontée de l’incident de sécurité – fiche d’incident

–  Analyse de l’incident : est-vraiment un incident de sécurité (recoupement des sources, vérification…) ? quelle est son étendue ? ses impacts immédiats ? ses impacts potentiels dans les heures qui suivent ?

–  Qualification et catégorisation de l’incident de sécurité

Plusieurs sources d’informations existent pour détecter des incidents : utilisateurs, help desk, clients, fournisseurs, sous-traitants, analyses des logs, SIEM, indicateurs opérationnels,CERT, comportements anormaux sur le SI, presse, Internet…

3.     Confinement

L’objectif de cette phase est de réduire les conséquences de l’incident de sécurité. La difficulté est de le faire tout en analysant ce qui a pu être compromis ou perdu.

 4.     Investigation et éradication

Il s’agit maintenant de résoudre le problème et éviter qu’il se reproduise. Dans le cas d’une attaque virale, il s’agira par exemple d’utiliser des outils pour désinfecter les postes de travail touchés ou de mettre en place les correctifs de sécurité nécessaires.

C’est dans cette phase que des actions de forensics pourront être mises en œuvre afin de déterminer la cause de la compromission ainsi que le mode opératoire de l’attaquant dans certains cas.

Dans le cas d’analyses forensics, il ne faudra pas négliger l’étape de préservation des preuves si l’organisation envisage un dépôt de plainte et donc de coopérer  à l’enquête judiciaire.

5.     Remise en état

L’avant dernière phase consiste à remettre en service les systèmes impactés en service après l’identification et l’éradication du problème.

Cette phase de remise en état devra être menée prudemment avec pourquoi pas la mise en place d’une surveillance spécifique pour détecter une potentielle « rechute ».

 6.     Retour d’expérience

La dernière et pas la moins importante étape vise à capitaliser sur les incidents de sécurité qui sont survenus et qui ont été traités. Il s’agit donc de réaliser « à froid » un retour d’expérience sur la gestion du dernier incident pour identifier ce qui s’est bien ou moins bien passé.

Le but est, comme toujours, de se placer dans une démarche d’amélioration continue afin d’éviter de commettre les mêmes erreurs et optimiser l’efficacité de la réponse à incident.

Si vous vous lancez dans ce type de démarche, je ne peux que vous conseiller de vous inspirer des fiches de réponse à incident du CERT Société Générale. Je vous incite aussi fortement à consulter cette présentation de HSC sur le sujet ainsi que ce guide du NIST et pour les plus courageux celui de l’ENISA pour monter votre propre équipe de réponse à incidents de type  CSIRT / CERT.

N’oubliez pas non plus que la norme ISO 27035 traite exclusivement de la gestion des incidents de sécurité. Je vous conseille d’y jeter un coup d’œil en parcourant cette présentation d’Alexandre Fernandez Toro.

MAJ : suite au commentaire d’Eric Freyssinet sur Twitter, j’ai rajouté des éléments sur la conservation des preuves, le dépôt de plainte et la coopération à l’enquête judiciaire. Il faut en effet encourager les entreprises à porter plainte ou tout du moins à notifier les incidents les plus sérieux (surtout pour certains secteurs d’activité).

PS : une première version de cet édito a été publiée hier (lundi 19 mars 2013) dans la newsletter cybersécurité hebdomadaire de BSSI Conseil & Audit. N’hésitez pas à vous y abonner !