Plan de réponse aux incidents pour une boîte de 10 personnes : que faut-il sans un document de 50 pages ?

La première chose à faire, c'est de ne pas garder ce plan sur le serveur de la boîte. Quand un rançongiciel débarque, vous ne pouvez plus accéder à votre propre serveur. Gardez une copie papier chez le dirigeant et le responsable technique et une copie dans un dossier cloud externe indépendant. Et pour communiquer, il faut définir dès le départ un canal autre que l'e-mail de la boîte.

On gère une agence de taille similaire à Munich. L'an dernier, le compte e-mail d'un de nos clients a été piraté. Comme on n'avait pas écrit à l'avance qui appelle qui, on a perdu les 4 premières heures dans la panique interne et à se poser des questions entre nous. Après ça, on a fait un organigramme d'une page. Ça nous a pris que 3 heures à préparer, mais lors d'un petit problème DNS ensuite, on s'est organisés en 20 minutes.

Côté technique, la plus grosse erreur c'est de débrancher le serveur dans la panique ou de le redémarrer tout de suite. Les données volatiles en RAM sont effacées et vous ne pouvez plus déterminer par où l'attaquant est entré. Le plan doit clairement inclure la règle « ne pas éteindre la machine, juste débrancher le câble réseau ou désactiver la carte réseau du serveur virtuel ».

Si vous opérez en Allemagne, ne négligez pas le volet juridique. Votre plan de réponse aux incidents doit inclure clairement, conformément à l'article 33 du RGPD, l'obligation de notification sous 72 heures à l'autorité de contrôle compétente et, le cas échéant, le processus d'information des personnes concernées. Les entreprises ratent souvent ce délai à cause du chaos interne.

Ces formulaires d'audit que vos clients envoient sont des checklists corporate. Le plan de deux pages que vous allez préparer marche très bien en interne, mais l'auditeur corporate peut chercher des trucs comme un centre d'opérations 24/7. Écrivez le plan, mais quand vous le présentez au client, posez un cadre clair en disant « plan agile adapté à une structure organisationnelle de 10 personnes », sinon vous allez vous compliquer la vie pour rien.

PS : c'est demandé plus bas, j'ai répondu dans le deuxième message.

dans notre équipe on est 8 aussi, quand un truc similaire nous est arrivé on a réalisé que personne ne connaissait le numéro de l'avocat. la liste des numéros d'urgence et l'adresse de contact de secours de chacun c'est le plus critique. le fichier peut bien s'appeler plan de réponse aux incidents le contenu doit rester un résumé de 2 pages.

Votre client, dans l'audit, il demande juste l'existence du plan ou il exige aussi le dernier rapport de test et une validation tierce ? Certains audits veulent juste voir un compte rendu d'exercice, d'autres demandent un rapport d'audit externe. Vous avez vérifié l'annexe sécurité dans votre contrat ?

Ne vous mettez pas trop de pression, pas besoin de vous noyer dans les modèles corporate. Ajoutez aussi à votre plan une classification simple du niveau de l'incident : Faible (un seul utilisateur touché), Moyen (interruption de service mais données en sécurité), Élevé (fuite de données ou perte critique de données). Cette classification clarifie beaucoup qui prévenir et quand.

Je suis dans la même situation, c'est pourquoi je pose la question. Si le chemin de notification est long, la notification n'arrive pas ; une notification manquante signifie un événement détecté tardivement.

Les solutions qui fonctionnent à petite échelle s'effondrent en grandissant, j'ai appris cela trop tard. Si vous écrivez le résultat ici, cela aidera aussi d'autres personnes.

Je suis d'accord, j'aimerais même souligner ce point. La plupart des incidents ne viennent pas d'une faille, mais d'un mot de passe divulgué.

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

J'aurais une question, sans vouloir m'éloigner du sujet. Une modification des coordonnées bancaires n'est jamais confirmée par le canal d'origine.

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.

Merci beaucoup, je teste dès aujourd'hui.

je vais essayer. bon avant de décider, regardez quelles données vous avez en main.

je suis aussi cureiux de savoir si d'autres font autrement.

Ce sujet est archivé.

Chez nous, ça s'est passé comme ça. Le fait que la sauvegarde soit accessible sur le même réseau et avec la même identité en fait une cible potentielle.

Je suis aussi curieux de savoir si d'autres font autrement.

Sujet très actuel.

je vais résumer le sujet car plsuieurs réponses différentes ont été données. la plupart des pertes de temps s'accumulent sur les tâches en attente de validation.

j'espère que cela vous sera utile.

Oui, la situation est exactement ainsi concernant plan de réponse aux incidents. Prendre une mesure sans faire d'inventaire, c'est laisser une porte ouverte sans le savoir.