Dois-je enregistrer qu'un utilisateur a changé son mot de passe?
Existe-t-il des problèmes de sécurité lors de la journalisation qu'un utilisateur a changé son mot de passe? Je me connecte déjà chaque fois qu'un administrateur modifie le mot de passe d'un utilisateur à des fins d'audit, mais y a-t-il une raison pour ne pas avoir de journal lorsque chaque utilisateur a changé son propre mot de passe?
Modifier: réponses aux questions ci-dessous
Quel est votre gain attendu de cela?
Principalement médico-légale. La possibilité de voir qui (user_id de admin ou self) a changé le mot de passe au cas où l'utilisateur prétend avoir été piraté.
Nous ne l'utilisons pas pour prendre en charge des schémas de gestion de mot de passe tels que le changement forcé de mot de passe ou l'interdiction de réutilisation de mot de passe.
Qui aurait accès à ces journaux?
Administrateurs système et éventuellement une petite équipe d'assistance.
De quel type de comptes parlons-nous?
Comptes d'utilisateurs sur une plate-forme d'apprentissage en ligne, c'est-à-dire enseignants et étudiants.
De plus, avez-vous des règles d'expiration de mot de passe?
Non, je parle de stocker quand chaque changement de mot de passe a été fait, pas seulement le dernier changement.
Quelles informations stockez-vous? (pas réellement demandé mais implicite)
Nous stockons l'ID utilisateur de l'utilisateur dont le mot de passe a été modifié, l'ID utilisateur de l'utilisateur effectuant la modification (il peut s'agir d'un administrateur ou d'un enseignant stagiaire), l'heure à laquelle le mot de passe a été modifié et l'URI utilisé pour modifier le mot de passe.
Pour répondre à votre question, oui, vous pouvez et DEVRIEZ enregistrer les modifications de mot de passe, et il n'y a rien de fondamentalement mauvais à le faire, tant que vous ne le faites pas, par exemple. enregistrer le mot de passe lui-même "
Que se connecter?
Lors de la conception de la journalisation à des fins de sécurité, vous souhaitez répondre à ces questions:
Quand l'événement s'est-il produit?
- La date et l'heure de l'événement (utilisez le format de journal commun)
Quel était l'événement?
- Une brève description de l'événement (par exemple, changement de mot de passe)
Qui a déclenché l'événement?
- L'identifiant, le nom, l'e-mail ou un identifiant unique
Pourquoi l'événement a-t-il été déclenché?
- Ce n'est pas la même chose que le "Quoi" même si beaucoup de gens l'utilisent de cette façon. C'est la raison pour laquelle l'événement a été exécuté. . Cela peut être très bon pour éliminer le bruit.
Scénarios
L'une des meilleures méthodes pour discuter de ce qu'il faut voir est via des scénarios et demander à l'équipe:
- Quelles informations l'événement fournit-il?
- L'événement est-il requis pour la conformité/légal?
- Sommes-nous en train de nous connecter pour des raisons de détective? (par exemple, déclenchement d'un SIEM) ou correctif? (Par exemple, Forensics après coup)
- Qui regardera les journaux?
- Comment allons-nous protéger les journaux?
Exemple:
James fait partie de l'équipe IR, qui est responsable de l'application critique "Non-existence" de la société de maquillage. James souhaite pouvoir voir toutes les modifications de mot de passe afin de détecter les modifications qui se produisent en dehors du processus de stratégie normal. Ces événements se déclencheront et feront l'objet d'une enquête si un changement de mot de passe se produit sans incident enregistré par l'équipe d'assistance. Les journaux seront envoyés à l'appliance IR SIEM qui utilisera un ensemble de règles pour déclencher des avertissements à l'équipe IR lorsqu'un incident ne peut pas être corrélé à un changement de mot de passe en dehors d'un changement de politique requis.
(Attention obligatoirement pour l'utiliser sur un lieu de travail. Je viens de créer cet exemple.)
[modifier] - Mise à jour de la réponse initiale pour être plus claire. Merci à @SeldomNeedy pour la suggestion.
Je ne peux pas vous donner de raison de ne pas enregistrer quelque chose; vous devez me donner une raison pour laquelle vous devez vous connecter.
Vous pouvez théoriquement enregistrer tout ce que les utilisateurs font (jusqu'au mouvement du pointeur de la souris, aux clics et lorsqu'une fenêtre est au premier plan ou non).
Mais, avez-vous AVEZ BESOIN DE pour tout enregistrer? Can vous enregistrez tout sans sacrifier les performances? Can vous stockez les journaux pendant une période utile?
Il n'y a aucune raison de ne pas se connecter lorsque l'utilisateur change son mot de passe. Vous pouvez empêcher les utilisateurs de changer leur mot de passe trop souvent. Ou toute fonctionnalité que vous pouvez construire sur l'historique, les habitudes et les modèles de changement de mot de passe.
Vous pouvez même corréler le changement de mot de passe avec les principales failles de sécurité pour déterminer le degré de "technicité" de l'utilisateur.
Vous pouvez enregistrer un message pour indiquer que l'utilisateur a changé le mot de passe ainsi que des informations comme ipaddress (pour suivre si quelqu'un a changé son mot de passe par inadvertance) d'où il a changé le mot de passe.
Veuillez éviter de consigner les informations PII qui reviendront à un utilisateur spécifique en cas de fuite du fichier journal.
L'une des réponses ci-dessus le mentionne en passant et je soulignerai les deux éléments clés que vous devriez examiner:
- Maintenez la liste de hachage pour vous assurer que l'utilisateur ne réutilise pas les anciens mots de passe.
- Ne stockez pas quand, donc les pirates ne peuvent pas travailler avec les informations de longévité de pword. Par exemple. UserX réinitialise pword à la fin de chaque mois.
Ne pas les enregistrer est plus un risque pour la sécurité que de les enregistrer, mais (comme tout le monde l'a dit), faites attention à quoi/comment vous enregistrez les informations.
D'autres réponses soulignent que les journaux permettront à vos administrateurs de détecter le comportement des violations, et l'envoi de notifications aux utilisateurs leur permettra de détecter les violations individuellement.
Je pense que nous supposons tous que vous stockez vos mots de passe comme des hachages avec des sels aléatoires. Juste un rappel que l'utilisation de sels aléatoires ralentira considérablement la capacité d'un attaquant à casser les mots de passe hachés, car ils doivent effectuer le processus de craquage complet pour chaque sel unique (qui, espérons-le, est unique pour chaque mot de passe du système et à chaque fois qu'ils le sont). modifié).
Si vous souhaitez mettre en œuvre de nouvelles politiques de mot de passe, vous pouvez:
- tenir des registres (peut-être pas des "journaux") de la date de changement des mots de passe
- garder une version hachée du mot de passe, avec son sel aléatoire
Ceux-ci vous permettent de mettre en œuvre ultérieurement des stratégies pour:
- expiration, en utilisant uniquement la partie horodatage
- l'historique des mots de passe, en hachant le nouveau mot de passe avec chacun des sels historiques et en le comparant aux hachages historiques, pour garantir que l'utilisateur ne réutilise pas les anciens mots de passe