Réponse à incident

Réponse à incident : Ensemble des actions menées pour contenir, corriger puis documenter un événement de sécurité avéré, du signalement à la clôture.

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.

Où intervient Réponse à incident dans un projet

Réponse à incident protège les données confiées par les utilisateurs. Sur mobile, la question se pose deux fois : sur le téléphone, qui peut être perdu ou compromis, et sur le serveur.

Ce que le mot recouvre exactement dépend du projet. Ce qui suit vaut pour la plupart des applications mobiles françaises, et sert de point de départ à la discussion.

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

Le cahier des charges doit prévoir qui teste « Réponse à incident » et à quel moment. Une revue de sécurité programmée après la mise en ligne arrive trop tard pour changer quoi que ce soit.

À é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.

Rien n’oblige à tout figer dès le premier jour. Ce qui reste ouvert doit alors être signalé comme tel, avec la date à laquelle la décision sera prise.

Pour le cadre général, le guide des prix donne les fourchettes constatées en France et le modèle de cahier des charges la structure qui les rend opposables.

Les contrôles à prévoir

Réponse à incident se vérifie par un tiers, avec un rapport écrit et une liste de corrections datées.

• Contrôler qu’aucun secret ne traîne dans le code livré.
• Passer en revue la liste des personnes ayant accès à la production.
• Réclamer la preuve d’un test de restauration de sauvegarde.

Ces vérifications s’inscrivent au cahier de recette, avec un nom en face de chacune. Une case sans responsable reste vide.

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.
• Reprendre la formulation d’un autre projet sans vérifier qu’elle décrit bien celui-ci.

Termes liés

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

• Menace interne
• Conformité continue
• EBIOS Risk Manager
• Gestionnaire de mots de passe
• Tableau de bord sécurité

Questions fréquentes

Qu’est-ce que « Réponse à incident » ?

Ensemble des actions menées pour contenir, corriger puis documenter un événement de sécurité avéré, du signalement à la clôture. La définition tient en une phrase, son application dépend du projet. C’est pour cette raison qu’elle doit figurer dans le cahier des charges plutôt que dans un échange de courriels.

À quel moment traiter le sujet ?

Dès la conception, puis en contrôle avant la mise en ligne. Une faille corrigée sur plan coûte une discussion ; la même faille corrigée après le lancement coûte un correctif, une republication et parfois une notification.

Comment savoir si le budget annoncé est cohérent ?

En comparant le périmètre écrit aux fourchettes constatées en France, détaillées poste par poste sur le guide des prix. Un chiffre isolé ne veut rien dire sans le périmètre qui va avec.

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