Beantworten Sie Ihre Frage: Ja, Sie können und sollten Kennwortänderungen protokollieren, und daran ist nichts grundlegend Falsches, solange Sie dies nicht tun, z. Notieren Sie das Kennwort selbst. "

Was soll protokolliert werden?

Wenn Sie die Protokollierung aus Sicherheitsgründen entwerfen, möchten Sie folgende Fragen beantworten:

Wann ist das Ereignis aufgetreten?

• Datum und Uhrzeit des Ereignisses (Verwenden Sie das allgemeine Protokollformat)

Was war das Ereignis?

• Eine kurze Beschreibung des Ereignisses (z. B. Kennwortänderung)

Wer hat das Ereignis ausgelöst?

• Die Benutzer-ID, der Name, die E-Mail-Adresse oder eine eindeutige Kennung

Warum wurde das Ereignis ausgelöst?

• Dies ist nicht dasselbe wie "Was", obwohl viele Leute es auf diese Weise verwenden. Dies ist der Grund, warum das Ereignis ausgeführt wurde (z. B. Passwort aufgrund einer Richtlinie geändert, Benutzer manuell Passwort geändert, Dies kann sehr gut sein, um Lärm auszusortieren.

Szenarien

Eine der besten Methoden, um zu diskutieren, was zu sehen ist, ist über Szenarien und Fragen an das Team:

• Welche Informationen bietet die Veranstaltung?
• Ist die Veranstaltung erforderlich? rot für Compliance / Recht?
• Melden wir uns aus Detektivgründen an? (z. B. Auslösen eines SIEM) oder zur Korrektur? (z. B. Forensik nachträglich)
• Wer wird die Protokolle anzeigen?
• Wie werden wir die Protokolle schützen?

Beispiel:

James ist Teil des IR-Teams, das für die kritische Anwendung 'Non-Existence' von Made-Up Company verantwortlich ist. James möchte in der Lage sein, alle Kennwortänderungen zu sehen, um Änderungen zu erkennen, die außerhalb des normalen Richtlinienprozesses auftreten. Diese Ereignisse werden ausgelöst und untersucht, wenn eine Kennwortänderung ohne einen vom Support-Team protokollierten Vorfall erfolgt. Protokolle werden an die IR SIEM-Appliance gesendet, die mithilfe eines Regelsatzes Warnungen an das IR-Team auslöst, wenn ein Vorfall nicht mit einer Kennwortänderung außerhalb einer erforderlichen Richtlinienänderung korreliert werden kann.

(Vorsicht bei der Verwendung an einem Arbeitsplatz. Ich habe gerade dieses Beispiel erfunden.)

[Bearbeiten] - Die ursprüngliche Antwort wurde aktualisiert, um klarer zu sein. Vielen Dank an @SeldomNeedy für den Vorschlag.

Ich kann Ihnen keinen Grund geben, etwas nicht zu protokollieren. Sie müssen mir einen Grund nennen, warum Sie es protokollieren müssen.

Sie können theoretisch alles protokollieren, was die Benutzer tun (bis hin zur Bewegung des Mauszeigers, Klicks und wenn ein Fenster im Vordergrund steht oder nicht).

Aber müssen Sie alles protokollieren? Können Sie alles protokollieren, ohne die Leistung zu beeinträchtigen? Können Sie die Protokolle für einen nützlichen Zeitraum speichern?

Es gibt keinen Grund, nicht zu protokollieren, wenn der Benutzer sein Kennwort ändert. Sie können verhindern, dass die Benutzer ihr Kennwort zu oft ändern. Oder jede Funktion, die Sie auf dem Verlauf, den Gewohnheiten und Mustern der Kennwortänderung aufbauen können.

Sie können die Kennwortänderung sogar mit schwerwiegenden Sicherheitsverletzungen in Beziehung setzen, um festzustellen, wie "technisch" der Benutzer ist. P. >

Sie können eine Nachricht protokollieren, um anzuzeigen, dass der Benutzer das Kennwort geändert hat, sowie Informationen wie die IP-Adresse (um zu verfolgen, ob jemand versehentlich sein Kennwort geändert hat), von wo aus er das Kennwort geändert hat.

Bitte Vermeiden Sie die Protokollierung von PII-Informationen, die zu einem bestimmten Benutzer führen, wenn die Protokolldatei durchgesickert ist.

Sie nicht zu protokollieren ist ein größeres Sicherheitsrisiko als sie zu protokollieren, aber (wie alle anderen gesagt haben) seien Sie vorsichtig, was / wie Sie die Informationen protokollieren.

Andere Antworten weisen darauf hin, dass die Protokolle dies zulassen Wenn Ihre Administratoren das Verhalten von Verstößen erkennen und Benachrichtigungen an Benutzer senden, können sie Verstöße einzeln erkennen.

Ich denke, wir gehen alle davon aus, dass Sie Ihre Passwörter als Hashes mit zufälligen Salzen speichern. Nur eine Erinnerung daran, dass die Verwendung von zufälligen Salzen die Fähigkeit eines Angreifers, die gehashten Passwörter zu knacken, erheblich verlangsamt, da er den vollständigen Cracking-Prozess für jedes einzelne Salz ausführen muss (was hoffentlich für jedes Passwort im System und jedes Mal einzigartig ist geändert).

Wenn Sie einige neue Kennwortrichtlinien implementieren möchten, können Sie:

• Aufzeichnungen (möglicherweise keine "Protokolle") darüber führen, wann Kennwörter geändert wurden
• behalte eine gehashte Version des Passworts mit seinem zufälligen Salt

Mit diesen können Sie später Richtlinien implementieren für:

• Ablauf mit Nur der Zeitstempelabschnitt
• Passwortverlauf, indem das neue Passwort mit jedem der historischen Salze gehasht und mit den historischen Hashes verglichen wird, um sicherzustellen, dass der Benutzer alte Passwörter nicht wiederverwendet

In einer der obigen Antworten wird dies nebenbei erwähnt, und ich werde die beiden wichtigsten Dinge hervorheben, die Sie beachten sollten:

1. Pflegen Sie die Hash-Liste, um sicherzustellen, dass der Benutzer keine alten Pwords wiederverwendet.
2. Nicht speichern wann, daher können Hacker nicht mit Informationen zur Langlebigkeit von Pwords arbeiten. Z.B. UserX setzt das Pword-Ende eines jeden Monats zurück.
ol>