Engineering

Vergleich: Zeit- und Populationsanalyse in Elastic Machine Learning

Von
Rich Collier

Mit Elastic Machine Learning können Anwender zwei wichtige Arten von Anomalien entdecken: temporäre (zeitbedingte) Anomalien und populationsbasierte Anomalien (in Bezug auf alle anderen). Worin unterscheiden sich jedoch diese beiden Arten, und unter welchen Umständen macht es Sinn, eine dieser Analysen zu verwenden? Dieser Blogeintrag behandelt Details, Vorteile und bewährte Vorgehensweisen für diese Analysen auf Basis von allgemeinen Faustregeln.

Lassen Sie uns zunächst die Begriffe temporäre und populationsbasierte Anomalien definieren. Dazu benötigen wir einige Fakten:

Erkennung zeitbedingter Anomalien

  • Das Standardverhalten von Elastic Machine Learning, sofern Sie die Analyse nicht explizit als populationsbasiert festgelegt haben
  • Ein Vergleich des Verhaltens einer Entität mit sich selbst über einen Zeitraum
  • Kann aufgeteilt werden (mit „byfieldname“ oder „partitionfieldname“), um individuelle Baselines für Instanzen von Objekten zu erstellen (z. B. eine eindeutige Baseline pro Host oder Benutzer)
  • Nicht besonders gut geeignet für hohe Kardinalitäten oder sehr spärliche Datenelemente (externe IP-Adressen von Besuchern einer Website können beispielsweise sehr spärlich sein und gleichzeitig eine hohe Kardinalität von Hunderttausenden oder mehr haben) Dabei können Leistungsprobleme auftreten, wenn die Speicherlimits für den Job nicht vom Standardwert angehoben werden. Selbst in diesem Fall ist eine Populationsanalyse jedoch wahrscheinlich als Ansatz besser geeignet.

Erkennung von Populationsanomalien

  • Wird nur aufgerufen, wenn „overfieldname“ verwendet (oder der Population-Job-Assistent in Kibana ausgeführt) wird Das als „overfieldname“ deklarierte Feld definiert die Population.
  • Eine Peer-Analyse von Mitgliedern einer Population, oder genauer gesagt ein Vergleich zwischen einer einzelnen Entität und einem kollektiven, über einen Zeitraum beobachteten Modell aller Peers.
  • Kann ebenfalls aufgeteilt werden (mit „byfieldname“ oder „partitionfieldname“), um Unterpopulationen zu erstellen Normalerweise gut geeignet für hohe Kardinalitäten oder spärliche Datenelemente, da einzelne Mitglieder zu einem kollektiven Verhaltensmodell beitragen.

Beispiel-Anwendungsfall

Nachdem wir die Begriffe geklärt haben, besprechen wir jetzt einen hypothetischen Anwendungsfall, der uns möglicherweise bei der Auswahl des richtigen Ansatzes hilft.

Angenommen, wir möchten die Anzahl der von einem internen Dokumentserver heruntergeladenen Dokumente überwachen. Der Dokumentserver enthält Dokumente, die für praktisch alle der über 50.000 Mitarbeiter des Unternehmens relevant sind. Außerdem haben sämtliche Mitarbeiter jederzeit Zugang zu diesem Dokumentserver. Lassen Sie uns zuletzt annehmen, dass im Zugriffsprotokoll des Dokumentservers jeder Dokumentzugriff zusammen mit dem Benutzer protokolliert wird, der das Dokument herunterlädt.

Beispiel für zeitbedingte Anomalie

Angenommen, ich wähle die Erkennung zeitbedingter Anomalien mit der folgenden Struktur aus:

    "detectors": [
      {
        "function": "count",
        "partition_field_name": "user"
      }
    ]

In diesem Fall kann ich das Volumen der Downloads pro Benutzer einzeln über einen bestimmten Zeitraum nachverfolgen. Wenn also user=“Wilma“ normalerweise etwa 50 Dokumente pro Tag herunterlädt (sie arbeitetet in der Entwicklungsabteilung und nutzt die Dokumente auf dem Server ausgiebig), würde nur eine Anomalie vorliegen, wenn Wilma ihr Verhalten drastisch ändert und viel mehr oder weniger Dokumente als normal herunterlädt (z. B. 5.000 Dokumente pro Tag).

Wie bereits zuvor angemerkt muss ich mir darüber im Klaren sein, wie viele individuelle Benutzer ich mit ML überwachen möchte. Eine Analyse von 50.000 Benutzern ist vermutlich machbar, wenn wir das Speicherlimit für den ML-Job erhöhen. Außerdem muss ich jedoch darauf achten, dass die Benutzer nicht jeden Tag gleich viele Dokumente herunterladen. Die Aktivität kann sehr spärlich sein, da ein Benutzer möglicherweise heute einige Dokumente herunterlädt und dann erst wieder in einigen Monaten. Ohne einheitliche Beobachtungen für die einzelnen Benutzer ist es schwierig, eine exakte Baseline zu erhalten.

Noch wichtiger ist jedoch, was passiert, wenn eine neue Person (user=“Fred“) dazukommt, 5.000 Dokumente an einem Tag herunterlädt und dann nie wieder aktiv wird? Ist dies ein ungewöhnlicher Vorgang? Ist Fred eine Insiderbedrohung, oder hat eine auf Datendiebstahl ausgelegte Malware Freds Anmeldeinformationen verwendet, um Dokumente in der Hoffnung zu stehlen, diese aus dem Unternehmen herausleiten zu können? Die Erkennung zeitbedingter Anomalien liefert keine eindeutige Antwort. Wir wissen nicht wirklich, ob dieser Vorgang ungewöhnlich für Fred ist, da wir keine Verlaufsdaten von ihm zum Vergleich haben (wir haben nur eine Probe gesehen).

Beispiel für Populationsanomalie

Alternativ können wir das Problem wie folgt einer Populationsanomalieerkennung unterziehen:

    "detectors": [
      {
        "function": "count",
        "over_field_name": "user"
      }
    ]

Damit erhalten wir Folgendes:

  • Wir können alle Benutzer innerhalb eines „bucket_span“ (in diesem Fall ein Tag) verwenden, um ein kollektives Modell der üblichen Downloadmengen pro Benutzer kollektiv zu erstellen
  • Vergleich der an einem Tag gesehenen Benutzer mit dem kollektiven Modell

Wenn Wilma und ein Großteil ihrer Kohorten 10-75 Dokumente pro Tag herunterladen, liegt das kollektive Gesamtmodell der üblichen Nutzung in diesem Bereich. Wenn Fred eines Tages also 5.000 Dokumente herunterlädt, ist dies eine Anomalie, da wir Fred mit Wilma und all ihren Kohorten vergleichen. Fred wird als Ausreißer markiert.

Dabei gibt es jedoch einen wichtigen Punkt zu beachten. Wenn Wilma anstelle von Fred ebenfalls 5.000 Dokumente herunterlädt, wird Wilma als abnormaler Ausreißer markiert, nicht etwa weil sie viel mehr als normal heruntergeladen hat, sondern weil sie viel mehr heruntergeladen hat als das „typische“ Nutzungsmodell, das über einen Zeitraum anhand ihrer Daten und der Daten ihrer Kohorten erstellt wurde.

Dabei ist wichtig, dass Wilma in dieser Situation unabhängig von der Auswahl zwischen zeit- und populationsbasierter Analyse als Ausreißer markiert wird. Der Populationsansatz ist jedoch in diesem Fall aus den folgenden Gründen flexibler:

  1. Er ist weniger anfällig bei spärlichen Daten
  2. Er ist speichereffizienter für eine hohe Anzahl eindeutiger Benutzer, da keine individuellen Modelle pro Benutzer verwendet werden
  3. Er findet Ausreißer wie Fred, für die wenige oder keine Verlaufsdaten existieren
  4. Wilma wird weiterhin als Ausreißer erkannt, wenn sich ihr Verhalten drastisch genug ändert, um das kollektive Verhaltensmuster zu verlassen

Noch ein Tipp: Bei der Populationsanalyse ist es sinnvoll, möglichst gleichförmige Populationen aufzubauen. Wenn Sie also große Cluster von Benutzertypen haben (z. B. Entwickler und Personalabteilung), kann es unter Umständen Sinn machen, diese Benutzer in separate Gruppen aufzuteilen und zwei Analysen durchzuführen, anstatt zu erwarten, dass sich beide Gruppen ähnlich verhalten.

Ein letzter Hinweis: Wenn Sie bereits vorab wissen, dass Sie bestimmte Mitglieder einer Population ausschließen möchten, können Sie dazu entweder die Eingabedaten filtern oder Regeln zum Filtern der Ergebnisse verwenden.

Hoffentlich war diese Erläuterung hilfreich für die Unterscheidung der beiden Ansätze. Wenn Sie Machine Learning mit Ihren Daten ausprobieren möchten, können Sie den Elastic Stack herunterladen und die 30-tägige Probelizenz aktivieren oder einen kostenlosen Test in Elastic Cloud starten.