Audit et réglementation : une responsabilité que vous pouvez prouver

Dans de nombreux départements informatiques, les semaines précédant un audit suivent le même rituel. Plusieurs personnes mettent de côté leur travail habituel et rassemblent des preuves. Qui a approuvé ce changement ? Pourquoi cet utilisateur avait-il des droits d'administrateur ? Quand la configuration du pare-feu a-t-elle changé et qui l'a modifiée ? Les réponses existent, mais elles sont dispersées dans des e-mails, des discussions, des exports de différents outils et les souvenirs de personnes, dont certaines ont depuis quitté l'entreprise.

Dans le même temps, la pression pour fournir des preuves ne cesse de croître. La réglementation de la cybersécurité, telle que NIS2 et la législation nationale qui la met en œuvre, met généralement l'accent sur la gestion des risques, la responsabilité de la direction et la capacité à démontrer que les mesures de sécurité fonctionnent réellement. Les obligations spécifiques varient selon le type d'organisation et sont mieux évaluées avec des spécialistes juridiques ou de la conformité. Le fil conducteur, cependant, est clair : faire les choses correctement ne suffit pas. Vous devez être en mesure de le prouver.

Pourquoi l'assemblage de preuves après coup échoue

Le problème ne vient rarement du fait qu'une organisation n'a pas de processus. Le problème vient du fait que ces processus ne laissent pas de traces par eux-mêmes.

• Les approbations se produisent en dehors du système. Le consentement à une interruption est reçu par e-mail, le changement est effectué ailleurs, et le lien entre eux n'existe que dans la tête du gestionnaire des changements.
• L'historique est écrasé. L'outil montre l'état actuel, mais pas ce qu'il était avant.
• Les actions automatisées sont invisibles. Les tâches planifiées modifient les données, mais personne ne sait exactement quand ou quoi elles ont fait.
• Les responsabilités restent sur papier. Une matrice RACI est contenue dans un document, et personne ne vérifie si elle correspond aux autorisations réelles.

Le résultat est un audit mené comme un projet, au lieu d'un audit comme un examen de routine des enregistrements.

Comment aborder la probabilité

La véritable préparation à l'audit est un sous-produit du travail quotidien. Si chaque action se produit dans un système qui l'enregistre, les preuves existent au moment où les choses se produisent. Quelques principes :

• enregistrer non seulement « qui et quand » mais aussi « ce qui a exactement changé », c'est-à-dire l'état avant et après,
• auditer ce que les machines font, pas seulement ce que les gens font,
• conserver les enregistrements suffisamment longtemps,
• décrire les responsabilités de manière à pouvoir être comparée avec les autorisations réelles.

Comment Eywo Stratum gère cela

Eywo Stratum conserve une traçabilité de toutes les actions, conservée pendant cinq ans. Pour les changements de configuration, il enregistre l'état avant et après, afin que vous puissiez voir non seulement que quelque chose a changé, mais exactement quoi. Les actions du planificateur, les tâches automatisées qui s'exécutent sans intervention humaine, sont également auditées.

Les éléments de la CMDB ont leur propre historique de version. Pour chaque changement, vous pouvez voir qui l'a effectué, quand, quoi a changé et d'où il vient : l'API de découverte, une importation, une modification manuelle ou une synchronisation avec une CMDB principale.

Les approbations se produisent dans le système. Les interruptions dans les changements, les demandes et d'autres éléments qui nécessitent une décision sont regroupés dans une file d'approbation unique. Une règle définit qui est le propriétaire, et un rejet est toujours accompagné d'une raison. L'enregistrement de qui a accepté quoi est créé en même temps que le changement.

Les responsabilités sont décrites dans une matrice RACI, et Eywo Stratum vérifie qu'elle est cohérente avec les autorisations. Si quelqu'un est répertorié comme responsable mais n'a pas de rôle qui lui permettrait d'approuver ou d'exécuter la tâche, cela apparaît. Les rôles sont définis (tout, client, équipe, élément), afin qu'il soit clair non seulement ce que quelqu'un peut faire, mais aussi sur quoi.

Conclusion

Un audit ne devrait pas être un projet. Lorsque la traçabilité est créée automatiquement, les approbations vivent dans le système et les responsabilités sont liées aux autorisations, la réponse à une question d'un auditeur est à quelques clics de distance. L'équipe continue de travailler, et la direction peut être confiante que la responsabilité peut être prouvée.

La traçabilité, l'historique de la CMDB et la matrice RACI sont inclus dans l'édition Standard.