La journalisation, le contrôle qui meurt en silence.
ISO 27001:2022 A.8.15 (journalisation) exige que les événements pertinents pour la sécurité (connexions, erreurs, pannes, accès aux données sensibles) soient enregistrés, conservés pendant une période définie et protégés contre toute altération. Ce contrôle est essentiel pour A.8.16 (surveillance) et pour toute enquête ultérieure : il est impossible de détecter ou de reconstituer ce qui n'a jamais été enregistré. Et il est facile de l'affaiblir sans s'en apercevoir, car une ligne de journal est souvent supprimée lors d'un nettoyage.
The shapes the same control failure takes.
A.8.15 ne se brise rarement par un changement spectaculaire. Il se brise lorsqu'un événement pertinent pour la sécurité cesse d'être enregistré. Les formes récurrentes :
Un journal de sécurité est supprimé
Un appel de journalisation pour un événement d'authentification, un changement de privilège ou un accès à des données sensibles est supprimé lors d'un nettoyage car il semblait bruyant.
Un niveau de journal passe sous le niveau de production
Un événement de sécurité est déplacé vers un niveau (debug) qui n'est pas émis en production, il cesse donc silencieusement d'être enregistré là où cela compte.
L'acteur est omis de l'enregistrement
Un journal continue de se déclencher mais cesse d'inclure qui l'a déclenché, de sorte que l'événement ne peut plus être attribué lors d'une enquête.
Une nouvelle action privilégiée est déployée sans journalisation
Une nouvelle opération d'administration ou destructrice est ajoutée sans aucun enregistrement d'audit, de sorte qu'il n'y a rien à échantillonner plus tard.
La durée de conservation est raccourcie
La durée de conservation ou la rotation d'un journal est réduite en dessous de ce que le contrôle exige, de sorte que l'enregistrement disparaît avant que quiconque en ait besoin.
Les échecs d'authentification passés sous le niveau de journalisation de production.
Les journaux d'échec d'authentification sont bruyants en développement, donc une modification les déplace du niveau warning au niveau debug. En production, le niveau de journalisation est défini sur info, donc ces échecs disparaissent désormais complètement de l'enregistrement, précisément les événements dont vous avez le plus besoin lors de l'enquête sur une intrusion.
if (!valid) {- logger.warn("auth.failed", { userId, ip })+ logger.debug("auth.failed", { userId, ip }) return unauthorized()}Avec le niveau de production défini sur info, le passage des échecs d'authentification en debug signifie qu'ils ne sont plus enregistrés en production. A.8.15 exige que les événements pertinents pour la sécurité, y compris les échecs d'authentification, soient journalisés et conservés, et A.8.16 (surveillance) en dépend. Conservez-les au niveau warning ou acheminez-les vers le journal de sécurité plutôt que de les supprimer en production.
La journalisation est échantillonnée à partir d'événements réels.
Un auditeur vérifie que les événements pertinents pour la sécurité sont effectivement journalisés, conservés pendant la période indiquée dans votre politique et protégés contre toute altération. Il échantillonnera des types d'événements spécifiques (connexions, changements de privilèges, accès aux données sensibles). Une modification qui a silencieusement cessé d'émettre l'un de ces événements, en le supprimant ou en le passant sous le niveau de production, est l'écart qu'il détecte. La modification qui l'a introduit était généralement une pull request ordinaire qui semblait être une réduction du bruit.
Une revue, pas votre SIEM.
heygrc signale les modifications qui concernent A.8.15 et cite le contrôle afin que la correction ait lieu dans la pull request. Il n'exécute pas votre pipeline de journalisation ni votre surveillance. Il détecte le moment où un événement de sécurité cesse d'être enregistré, au niveau du diff.