Menace interne

Menace interne : Risque venant d’une personne disposant déjà d’un accès légitime, traité par le cloisonnement et par une journalisation sérieuse.

Famille « Sécurité ». La définition ci-dessus suffit pour suivre une réunion. La suite sert à écrire une exigence que personne ne pourra interpréter à sa façon.

Où intervient Menace interne dans un projet

Sur un projet d’application, Menace interne se traite pendant la conception. Ajouter la sécurité à la fin revient à réécrire des parties déjà recettées, donc à les recetter de nouveau.

Le sujet se présente rarement seul. Il arrive au milieu d’une décision plus large, et c’est à ce moment qu’il faut savoir de quoi on parle.

Comment l’écrire dans un cahier des charges

Un cahier des charges sérieux relie « Menace interne » 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 :

• Les modalités d’authentification, second facteur compris s’il est requis.
• Le stockage des secrets, côté application comme côté serveur.
• La gestion des accès de production, et leur revue périodique.
• Le test de restauration des sauvegardes, réellement exécuté au moins une fois.

Le niveau de détail à viser est celui qui permet à deux prestataires différents de chiffrer la même chose. En dessous, les écarts de prix ne veulent rien dire.

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

À la recette, Menace interne se contrôle sur pièces : configuration, journaux, preuve de test. Pas sur une déclaration de bonne intention.

• Vérifier que les correctifs annoncés ont été retestés, et par qui.
• 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.

Ce qui n’est pas vérifié à la recette ne sera pas vérifié du tout : le jour de la mise en ligne, plus personne n’a le temps.

Ce qui tourne mal le plus souvent

Aucune de ces erreurs ne se voit le jour où elle est commise. Toutes se paient plus tard, au moment le moins commode.

• Traiter la sécurité en fin de projet, quand tout est déjà recetté.
• Stocker un secret dans le code de l’application, où il est lisible par qui veut le lire.
• Commander un audit sans budgéter les corrections qu’il va produire.
• Laisser les accès de production ouverts à d’anciens intervenants.
• 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 :

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

Questions fréquentes

Que signifie « Menace interne » ?

Risque venant d’une personne disposant déjà d’un accès légitime, traité par le cloisonnement et par une journalisation sérieuse. 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.

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.