Warnmeldungen: Vertrauliche Daten

Document created by RSA Information Design and Development on Apr 17, 2018
Version 1Show Document
  • View in full screen mode
 

Dieses Thema erklärt, wie ESA vertrauliche Daten, wie z. B. Benutzernamen oder IP-Adressen, die von Core-Services stammen, behandelt. Die Rolle des Datenschutzbeauftragten (Data Privacy Officer, DPO) kann Metaschlüssel identifizieren, die vertrauliche Daten enthalten und verschleierte Daten anzeigen sollten. ESA zeigt vertrauliche Metadaten weder an noch speichert es sie. Folglich übergibt ESA keine vertraulichen Daten an NetWitness Respond.

Optional kann ESA eine verschleierte Version der vertraulichen Daten einem Ereignis hinzufügen. Zum Beispiel identifiziert der DPO user_dst als vertraulich. ESA kann eine verschleierte Version, wie etwa user_dst_hash, zu einem Ereignis hinzufügen. Die verschleierten Metadaten sind nicht vertraulich, sodass ESA sie auf dieselbe Weise anzeigen und speichern kann wie alle anderen nicht vertraulichen Metadaten.

Weitere Informationen über die Strategie und Vorteile der Datenverschleierung finden Sie im Leitfaden Datenschutzmanagement.

Dieses Thema erklärt Folgendes:

  • Wie ESA sensible Daten behandelt, die von Core-Services stammen
  • Wie Lecks vertraulicher Daten in einer erweiterten EPL-Regel vorzubeugen ist

Wie ESA sensible Daten behandelt, die von Core-Services stammen

Wenn ESA sensible Daten von Core-Services empfängt, gibt ESA nur die verschleierte Version der Daten weiter. ESA speichert keine vertraulichen Daten noch zeigt es sie an.

Die folgenden Funktionen sind betroffen:

  • Ausgaben: ESA leitet keine vertraulichen Daten an Ausgaben weiter, dazu gehören Warnmeldungen, Benachrichtigungen und MongoDB-Speicher.
  • Erweiterte EPL-Regeln: Wenn eine EPL-Aussage einen Alias für einen vertraulichen Metaschlüssel erstellt, kommt es zu einem Leck vertraulicher Daten. Dieses Thema illustriert, wie das passiert, damit Sie es verhindern können.
  • Erweiterungen: Wenn ein vertraulicher Metaschlüssel in der Verknüpfungsbedingung verwendet wird, kommt es zu einem Leck vertraulicher Daten. Dieses Thema illustriert, wie das passiert, damit Sie es verhindern können.

Erweiterte EPL-Regel

Wenn eine EPL-Abfrageaussage einen vertraulichen Metaschlüssel umbenennt, sind die Daten nicht geschützt.

ESA identifiziert einen vertraulichen Metaschlüssel über den Namen:

ip_src ist der vertrauliche Metaschlüssel.
ip_src_hash ist die nicht vertrauliche, verschleierte Version.

Zur Unterstützung des Datenschutzes darf der vertrauliche Metaschlüssel in einer EPL-Abfrage nicht umbenannt werden. Wenn ein vertraulicher Metaschlüssel umbenannt wird, sind die Daten nicht mehr geschützt.

Beispiel: In einer Regel wie select ip_src as ip_alias... enthält ip_alias die vertraulichen Daten. Diese sind aber nicht geschützt, weil ESA nur ip_src kennt, nicht aber ip_alias. In diesem Fall würden die IP-Adressen nicht verschleiert. Echte Werte würden angezeigt.

Erweiterungsquelle

Wenn ein vertraulicher Metaschlüssel in einer Verknüpfungsbedingung verwendet wird, können vertrauliche Daten nicht angezeigt werden.

Die Erweiterungsdatenbank, der andere Teil der Verknüpfungsdatenbank, hat eine Spalte, die dem vertraulichen Metaschlüssel entspricht. Dieser Querverweis bezieht sich auf tatsächliche Werte, nicht verschleierte Werte. Folglich werden tatsächliche Werte angezeigt.

Im folgenden Beispiel werden beide Teile der Verknüpfungsbedingung hervorgehoben.

Datenerweiterungsquelle für Verschleierung

  • ip_src enthält vertrauliche Daten.
  • ipv4 wird der Warnmeldung hinzugefügt und ist als nicht vertrauliches Datenelement gefährdet

Da der ipv4-Wert derselbe ist wie der ip_src-Wert, enthält ipv4 vertrauliche Daten und zeigt sie an. 

Next Topic:ESA-Regeltypen
You are here
Table of Contents > So erzeugt ESA Warnmeldungen > Vertrauliche Daten

Attachments

    Outcomes