Plan de réponse

Plan de réponse : Procédure écrite à l’avance qui fixe les rôles, les étapes et les canaux de communication à activer pendant un incident.

Classé dans la famille « Sécurité », ce terme revient dans les échanges entre un client et son agence. Voici ce qu’il faut en comprendre avant d’en discuter le prix.

À quoi sert Plan de réponse

Plan de réponse relève de la sécurité applicative, un poste que les devis traitent souvent en une ligne et qui se rattrape mal une fois l’application en ligne.

Le sujet mérite trois minutes d’attention au cadrage. C’est le seul moment du projet où il ne coûte rien à traiter.

De la définition à la ligne de cahier des charges

Un cahier des charges sérieux relie « Plan de réponse » aux données concernées. Toutes ne méritent pas le même niveau de protection, et tout protéger au maximum coûte cher sans rien garantir de plus.

À écrire noir sur blanc, dans le chapitre qui correspond :

• Le référentiel de sécurité appliqué, nommé dans le contrat.
• Le classement des données manipulées, de la plus banale à la plus sensible.
• La revue de sécurité prévue avant la mise en ligne, et qui la mène.
• La procédure de correction d’une faille signalée, avec son délai d’engagement.

Une exigence bien écrite tient en trois lignes et se refuse en une. Si elle ne peut pas être refusée à la recette, elle n’est pas encore écrite.

Le modèle de cahier des charges du guide reprend ces rubriques dans l’ordre attendu par une agence, et la grille de lecture des devis montre à quoi ressemble un chiffrage comparable.

Ce que ça change au moment de la recette

Le contrôle de « Plan de réponse » ne s’arrête pas à l’application : les interfaces qu’elle appelle font partie du périmètre.

• Demander le rapport d’audit complet, pas la seule page de synthèse.
• Observer le comportement de l’application avec un jeton expiré.
• Vérifier que les contrôles d’accès sont bien refaits côté serveur.

Un prestataire sérieux propose ces contrôles de lui-même. Quand ce n’est pas le cas, c’est au client de les inscrire au cahier de recette.

Ce qui tourne mal le plus souvent

Ces erreurs ne viennent presque jamais d’un manque de compétence, mais d’un point qui n’a été écrit nulle part.

• Faire confiance aux contrôles réalisés dans l’application sans les refaire côté serveur.
• Journaliser des données sensibles pour faciliter le débogage, puis oublier de retirer les traces.
• Protéger l’application et négliger les interfaces qu’elle appelle.
• Considérer qu’une application sans données bancaires n’intéresse aucun attaquant.
• Employer le mot sans le définir, et laisser chaque partie prenante y mettre son propre sens.

Termes liés

Les entrées du glossaire déjà publiées sur des sujets voisins :

• Note de version
• Conformité continue
• EBIOS Risk Manager
• Gestionnaire de mots de passe
• Tableau de bord sécurité

Questions fréquentes

Qu’est-ce que « Plan de réponse » ?

Procédure écrite à l’avance qui fixe les rôles, les étapes et les canaux de communication à activer pendant un incident. Cette définition suffit pour une discussion de cadrage. Pour un contrat, il faut y ajouter ce que le terme recouvre exactement sur votre application.

Qui doit s’en charger ?

Le prestataire construit, un tiers vérifie. Faire auditer par celui qui a développé revient à faire corriger une copie par son auteur : utile, insuffisant pour un service exposé au public.

Par où commencer quand le sujet est nouveau ?

Par les parcours et les règles de gestion, pas par les outils. Le guide du cahier des charges donne l’ordre dans lequel poser les questions à une agence.

Toutes les définitions publiées sont rassemblées dans l’index du glossaire, classées de A à Z et par famille.