On nous demande de suivre le cadre NIST pour la réponse aux incidents — on l'adapte ou on fait notre propre plan ?

Sans gestion des logs, impossible de passer l'audit d'adaptation NIST. Mettez en place au moins une structure simple qui transfère les logs de serveurs, les connexions admin et les activités de pare-feu vers un espace de stockage distinct et en lecture seule. Si un incident survient et que vous ne pouvez pas prouver que l'attaquant n'a pas effacé les logs, votre phase d'analyse ne tient plus debout.

En rédigeant le doc, clarifiez bien ces trois points : 1) Sur quoi se basent les niveaux d'incident (faible, moyen, critique) ? 2) Quel est le délai d'engagement pour notifier le client et les autorités légales, en heures ? 3) À qui est délégué le pouvoir si le décideur est injoignable ? L'auditeur va direct regarder ces trois éléments.

Les équipes d'audit des grands comptes arrivent généralement avec des checklists toutes faites. Parce qu'ils mentionnent NIST, vous allez chercher à pondre un plan ultra parfait, alors que l'auditeur se contente de cocher des cases sur sa fiche. Ne vous épuisez pas, préparez un brouillon simple répondant aux exigences minimales et validez-le en amont avec le client.

On a passé un audit similaire l'année dernière. Avec un plan simple de 12 pages et le compte-rendu d'un exercice sur table de deux heures fait six mois plus tôt, on a validé l'audit du grand compte du premier coup. Aucun consultant externe, tout a été bouclé en interne en deux semaines de boulot.

Tout d'abord, définissez les rôles de votre équipe par intitulé de poste et non par nom propre. Si vous écrivez dans le document qu'Ahmet éteint le serveur, le plan devient caduc dès qu'il quitte la boîte. En écrivant des fiches de poste du type « L'Administrateur Système lance le confinement, le Chargé de Clientèle gère la communication », les mises à jour deviennent ultra simples.

L'exercice sur table dont vous parlez, ça se passe comment exactement ? du coup on se réunit juste dans une salle entre collègues pour discuter d'un scénario, ou il faut vraiment couper des serveurs et faire des tests techniques réels ?

Concernant les délais de notification d'incident, faites bien attention au contrat principal et aux accords de confidentialité (NDA) signés avec votre client. Le délai de notification dans votre plan NIST ne doit pas être plus long que celui engagé contractuellement, sinon cela peut engager votre responsabilité juridique.

Si je résume ce qui a été dit, l'idée n'est pas d'écrire des tonnes de pages : il faut définir les rôles, sécuriser les logs, poser un flux de confinement simple et documenter tout ça avec un exercice sur table une fois par an. À l'échelle d'une PME, pas besoin de plus.

c'est une bonne idée d'avoir ouvert ce sujet. prendre des notes pendant deux semaines donne de meilleurs résultats qu'une estimation de six mois.

une sauvegarde non testée n'est pas une sauvegarde. genre bon courage.

Ce sujet est archivé. Si c'est une première, commencez petit, l'échelle viendra plus tard.

Tout point non écrit est un point que les deux parties se rappelleront différemment plus tard.

Je vous conseille de ne pas vous presser. Si vous obtenez trois réponses différentes sur un sujet, la question est mal posée.

À votre place, j'irais par cette voie.

Trois points à vérifier lors de cette opération. Commencez par un petit test ne vous engagez pas sur tout d'un coup.

Ce que tout le monde fait ne signifie pas que c'est la bonne chose. Si vous avez des questions, écrivez-moi je répondrai au mieux.

Je ne savais pas ça.

C'est globalement vrai, mais il manque un point. Aucun processus sans suivi ne s'améliore, car vous ne savez pas quoi corriger.

Je suis du même avis. Quand on décide sans mesurer, on revient toujours au même point.

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

Vous avez raison.

J'ai vécu la même chose.

Nous avons aussi bloqué au même endroit à une époque. Les solutions qui fonctionnent à petite échelle s'effondrent en grandissant, j'ai appris cela trop tard.

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