La plupart des politiques informatiques disent ce qui devrait se passer. Un auditeur a besoin de savoir qui fait quoi, à quelle fréquence, et quelle preuve cela laisse. Réécrire nos politiques sous cette forme a changé bien plus que leur présentation.
Une politique informatique type se lit comme un bon conseil. Les sauvegardes doivent être effectuées régulièrement. Les accès doivent être revus. Les changements doivent être approuvés. Chaque phrase est sensée, et un auditeur ne peut presque rien en faire, car aucune ne dit qui s’en charge, à quelle fréquence, ni quelle preuve en subsiste ensuite.
Cette année, nous avons réécrit nos politiques informatiques sous forme de contrôles. Cela a pris plus de temps que prévu, et cela a davantage amélioré la réflexion que la mise en forme.
Chaque document s’ouvre désormais sur ses objectifs de contrôle, c’est-à-dire les résultats que les contrôles doivent garantir. Sous chaque objectif figurent des contrôles numérotés, et chaque contrôle comporte les quatre mêmes éléments :
Un responsable. Un rôle nommé, et non une équipe ou un service.
Une fréquence. Quotidienne, mensuelle, à chaque changement, à chaque nouvelle arrivée. « Régulièrement » n’est pas une fréquence.
Un élément probant. La trace que laisse le contrôle : un journal, une revue signée, un ticket, un rapport.
Une durée de conservation. Le temps pendant lequel cette preuve est conservée, pour qu’elle existe encore le jour où quelqu’un la demande.
C’est en renseignant ces quatre champs pour chaque contrôle que les vraies lacunes de la politique apparaissent. Si personne ne peut nommer le responsable, le contrôle n’a pas eu lieu. Si personne ne peut nommer la preuve, rien ne permet de démontrer qu’il a eu lieu.
Les contrôles d’un prestataire ne couvrent jamais tout. Certaines protections dépendent de ce que fait le client : gérer l’accès de ses propres utilisateurs à un système que nous hébergeons, nous prévenir quand quelqu’un quitte l’organisation, protéger ses propres identifiants. Ce sont les contrôles complémentaires chez l’entité utilisatrice (complementary user entity controls), et chaque document les énumère désormais explicitement.
Les mettre par écrit est utile aux deux parties. Le client voit exactement quelles obligations lui incombent, et nous cessons de laisser entendre que nous maîtrisons ce qui ne dépend pas de nous.
Un ensemble de contrôles se répartit sur de nombreux documents : accès, changements, sauvegarde, reprise, sécurité physique, journalisation, fournisseurs. Le risque est que deux documents couvrent le même terrain de façon légèrement différente, ou que chacun suppose que l’autre le couvre et qu’aucun ne le fasse.
Nous avons réglé ce problème en donnant à chaque frontière un responsable unique. Là où deux documents se touchent, l’un porte l’exigence et l’autre y renvoie, et tous deux le disent. Nous vérifions aussi par programme que chaque contrôle auquel un document renvoie existe bien dans l’autre.
La réécriture la plus importante est venue d’un changement d’architecture. L’accès était autrefois contrôlé en grande partie par la position sur le réseau : sur le VPN ou dans les bureaux, on était considéré comme fiable. Nous avons déplacé le périmètre vers l’identité : Entra ID et l’accès conditionnel (Conditional Access) décident qui entre en fonction de son identité et de l’appareil qu’il utilise.
De nombreuses clauses anciennes tiraient encore leur protection de l’emplacement sur le réseau. Chacune a été réécrite, soit comme contrôle d’identité, soit comme contrôle des mouvements latéraux précisant clairement qu’il ne s’agit pas d’un contrôle d’accès. Une politique qui décrit une architecture abandonnée sera évaluée au regard de celle qui est en service aujourd’hui.
Restructurer les documents a transformé un ensemble d’énoncés en un dispositif que l’on peut tester, attribuer à un responsable et prouver. Cela a aussi produit une matrice de contrôles unique, générée à partir des documents eux-mêmes, qui ne peut donc pas s’écarter de ce que disent les politiques.
Nous appliquons désormais la même structure aux missions clients qui exigent une assurance. Pour en savoir plus, consultez notre page cybersécurité.
Fait partie de la série Contrôles internes. Recevez les nouvelles analyses par e-mail ou suivez le flux RSS.
Un document de contrôle rédigé à partir de bonnes intentions décrit une organisation mieux gérée que la réalité. La relecture qui compte le plus est celle des personnes qui administrent les systèmes.
Des normes appliquées de la même façon sur chaque mission, c’est ce qui permet à une petite équipe de développement de garder son rythme au-delà du premier mois. Voici ce que cela donne en pratique.
L’IA change le rythme auquel le travail de livraison est produit. Elle ne change rien à la question de savoir qui en répond. C’est la place de cette ligne qui fait d’une livraison assistée par l’IA un avantage ou un risque.