On doit préparer un plan de réponse aux incidents de sécurité, est-ce que les modèles en ligne suffisent ?

Le plus gros manque dans ces templates, ce sont les consignes d'isolation technique. Quand une machine est infectée par un ransomware, il faut débrancher le câble réseau et faire un dump de la RAM plutôt que de couper l'alimentation brute. Ces détails techniques doivent figurer sous forme de points d'action concis dans le plan.

Prenez le modèle et gardez juste la structure des titres. Quand on a rédigé notre premier plan on a simplement mis le numéro de portable de tout le monde et désigné un back-up pour la personne censée couper le serveur en cas d'urgence. On l'a imprimé et affiché sur le tableau au bureau, c'est ce qu'il y a de plus clean.

Dans votre contrat, quel est le délai imposé par votre client pour le notifier en cas de fuite de données ? Si vous ne placez pas ce timing précis au cœur de votre plan, vous serez considérés en rupture de contrat.

On est passés par un audit corporate similaire le mois dernier. On a fourni un plan épuré de 6 pages. L'auditeur a validé direct ce document court avec des rôles bien définis plutôt qu'un copier-coller de 50 pages.

Personne ne va se poser pour lire un PDF de 40 pages en pleine crise. Si vous n'avez pas déroulé au moins une fois le scénario sur table avec toute l'équipe, votre plan n'est qu'un bout de papier bon à pipeauter l'auditeur.

Ayez impérativement ces trois contacts sous la main dans votre plan : 1) La hotline d'urgence 24/7 de votre hébergeur, 2) La ligne directe de l'avocat de l'entreprise, 3) Le contact d'un expert externe en cybersécurité mobilisable rapidement.

qd on s'est fait pirater on avait un template mais les mdp étaient bloqués sur le serveur où yavait le doc. imprimez le plan sur papier et gardez-le dans un tiroir sans faute, croyez-moi.

ça se passe comment concrètement ce que vous appelez un exercice sur table ? on se réunit avec l'équipe et on discute juste du scénario ou bien il faut techniquement couper des systèmes pour tester ?

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

Je vais résumer le sujet, car plusieurs réponses différentes ont été données. La sécurité n'est pas absolue ; c'est rendre l'attaque trop coûteuse pour valoir l'effort.

Vous avez raison, je suis aussi passé par là. Tous ceux qui se pressent sur plan de reponse aux incidents se heurtent au même obstacle.

Bien sûr, cela change si votre situation est différente.

Oui, la situation est exactement ainsi concernant plan de reponse aux incidents. Tout va bien les trois premiers mois, les problèmes arrivent au quatrième.

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

Résumé rapide pour les nouveaux : Le vrai problème n'est pas le chiffre, mais la base sur laquelle il est calculé.

Je me permets une petite mise en garde. Les environnements de test oubliés sont plus souvent des portes d'entrée que les systèmes de production.

Si vous avez des questions, écrivez-moi, je répondrai au mieux.

Désolé, mais ce n'est pas vrai dans tous les cas. 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.

Merci de partager le résultat.

La discussion part dans tous les sens je recentre. Les gens défendent l'habitude, pas le processus. La résistance vient de là.

J'espère que cela vous sera utile.

Mon regard a changé après avoir vécu cela. Tout point non écrit est un point que les deux parties se rappelleront différemment plus tard.

Voilà, désolé si je me suis étendu.

Mes doutes sont levés, merci. Si la double authentification est activée, un mot de passe volé seul ne suffit pas.

Si c'est une première, commencez petit, l'échelle viendra plus tard. C'est confirmé par l'expérience.