Cycle de vie de la réponse aux incidents — comment mettre ça en place dans une petite boîte ?

Ne vous laissez pas impressionner par les normes BSI, ce n'est que du bon sens. Dans les TPE/PME, l'erreur classique est de ne pas savoir qui a le pouvoir de décision. En pleine crise, qui tranche ? L'office manager, le prestataire IT ou le patron ? Si ces rôles ne sont pas écrits noir sur blanc dès aujourd'hui, vous allez perdre des heures au téléphone pendant l'attaque.

Lors de la phase d'endiguement, le personnel doit uniquement déconnecter physiquement l'accès réseau. Redémarrer ou débrancher la prise fait disparaître les traces du malware stockées dans la RAM. Dès que le câble réseau est retiré, l'expert externe a beaucoup plus de chances d'analyser la mémoire vive et de remonter à la source.

Dès demain matin, faites ces 3 choses en priorité : 1) Imprimez le numéro d'urgence de votre prestataire IT et collez-le au tableau. 2) Faites une sauvegarde hebdomadaire sur disque dur externe et verrouillez-le dans un coffre. 3) Dites à l'équipe qu'en cas de doute, on ne touche à rien sauf à couper la connexion Internet sans éteindre le PC. La moitié de la préparation sera déjà faite.

On a été pris de court par un ransomware similaire il y a deux ans. On a dû débourser 6.500 EUR auprès d'une équipe externe pour récupérer le serveur et faire l'analyse forensic. Si on avait rédigé un protocole d'urgence trois mois plus tôt, on aurait évité plus de la moitié de ces frais.

j'ai pas compris un truc pourquoi c'est mauvais d'éteindre le pc ? genre si on coupe le courant le virus s'arrête de tourner, c'est pas plus logique de débrancher direct ?

N'achetez surtout pas les gros classeurs de frameworks vendus par les consultants. Ils essaient de faire remplir des formulaires de cent pages à des petites boîtes, et le jour où ça pète, personne n'ouvre ces classeurs. À part une checklist basique, tout le reste c'est de la perte de temps.

En gros, le cycle se résume à 4 temps : préparer le plan de contact et les backups avant l'incident, isoler le PC du réseau au moindre doute, nettoyer avec le technicien IT, et une fois fini, noter où ça a pêché pour blinder le système.

Je suis passé par là, laissez-moi vous raconter. Si le chemin de notification est long, la notification n'arrive pas ; une notification manquante signifie un événement détecté tardivement.

Prendre des notes pendant deux semaines donne de meilleurs résultats qu'une estimation de six mois. Bien sûr, cela change si votre situation est différente.

Je ne suis pas d'accord sur ce point. Aucun processus sans suivi ne s'améliore, car vous ne savez pas quoi corriger.

Si vous écrivez le résultat ici, cela aidera aussi d'autres personnes.

J'ai travaillé longtemps sur ce sujet. Prendre des notes pendant deux semaines donne de meilleurs résultats qu'une estimation de six mois.

Si c'est une première, commencez petit l'échelle viendra plus tard. J'espère que cela vous sera utile.

Je partage mon expérience. Tout va bien les trois premiers mois, les problèmes arrivent au quatrième.

C'est mon avis, je ne l'écris pas comme une vérité absolue.

Je vais résumer le sujet, car plusieurs réponses différentes ont été données. Plus il est difficile de revenir sur une décision, plus il faut la prendre lentement.

Si vous écrivez le résultat ici, cela aidera aussi d'autres personnes.

La discussion part dans tous les sens, je recentre. Plus il est difficile de revenir sur une décision, plus il faut la prendre lentement.

Si vous écrivez le résultat ici, cela aidera aussi d'autres personnes.

Je trouve difficile d'être aussi catégorique côté cycle de vie de la réponse aux incidents. Si le chemin de notification est long, la notification n'arrive pas ; une notification manquante signifie un événement détecté tardivement.

À votre place, j'irais par cette voie.

Enregistré.

Je parle du point de vue du fournisseur, c'est mon côté. La plupart des incidents ne viennent pas d'une faille, mais d'un mot de passe divulgué.

À votre place, j'irais par cette voie.

J'ai vécu exactement la même chose il y a deux ans. Une sauvegarde non testée n'est pas une sauvegarde.

Le fait que la sauvegarde soit accessible sur le même réseau et avec la même identité en fait une cible potentielle. Corrigez-moi si je me trompe.

Je vais expliquer comment c'est fait en pratique. Plus il est difficile de revenir sur une décision, plus il faut la prendre lentement.

C'est confirmé par l'expérience.