In diesem Blogpost geben wir die Veröffentlichung unserer allerersten überwachten ML- und Security-Integration bekannt.

blog-banner-security-detection.png

blog-thumb-security-detection.png

Combining supervised and unsupervised machine learning for DGA detection

Kombinieren von überwachtem und unüberwachtem Machine Learning für die Erkennung von DGA

Für Machine Learning im Elastic Stack müssen Ihre Daten lediglich in Elasticsearch gespeichert sein. Lesen Sie, wie Sie mit wenigen Klicks nützliche Erkenntnisse aus Ihren Daten gewinnen und eine voll funktionsfähige End-to-End-ML-Pipeline aufbauen.

blog-banner-ml-anomaly-laptop.png

blog-thumb-ml-anomaly-laptop.png

Train, evaluate, monitor, infer: End-to-end machine learning in Elastic

Trainieren, evaluieren, überwachen, inferieren: End-to-End-Machine-Learning in Elastic

Angreifer (und deren Malware) nutzen zur Tarnung Domain-Generation-Algorithmen (DGA). Mit Elastic-Machine-Learning lassen sich jedoch Modelle erstellen, die helfen, solche Tricks zu durchschauen. Wie, das erfahren Sie in Teil 2 dieser Serie.

In <a href="/de/blog/machine-learning-in-cybersecurity-training-supervised-models-to-detect-dga-activity">Teil 1</a> dieser Blogpost-Serie haben wir uns angesehen, wie wir mit den <a href="/de/what-is/elasticsearch-machine-learning">Machine-Learning-Funktionen des Elastic Stack</a> ein überwachtes Klassifizierungsmodell zur Erkennung von Schad-Domains trainieren können. Im zweiten Teil beschäftigen wir uns damit, wie dieses trainierte Modell uns dabei hilft, die ingestierten Netzwerkdaten mit Klassifizierungsinformationen anzureichern. Das hilft uns bei der Suche nach potenzieller DGA-Aktivität in Packetbeat-Daten.
<h2>DGA-Erkennung mit dem Elastic Stack</h2>Schadprogramme müssen zur Erfüllung ihres Einsatzzwecks häufig mit einem vom Angreifer gesteuerten Server –&nbsp;„Command-&-Control“-Server oder auch „C&C“- bzw. „C2-Server“ genannt&nbsp;– kommunizieren. An dieser Stelle setzen Verteidigungsmaßnahmen an und sperren hartcodierte IP-Adressen oder URLs. Um diese Sperren zu umgehen, nutzen die Angreifer in ihrer Malware sogenannte „Domain-Generation-Algorithmen“ (DGAs). Wenn eine Malware einen C&C-Server kontaktieren muss, generiert sie mithilfe des DGA Hunderte oder Tausende von Domains und versucht, für jede dieser Domains eine IP-Adresse aufzulösen. Der Angreifer muss dann nur eine oder einige wenige der vom DGA generierten Domains registrieren – und schon kann er mit der Malware auf der infizierten Maschine kommunizieren. Um es Verteidigungsmaßnahmen zu erschweren, DGAs zu entdecken und zu sperren, werden die DGAs auf verschiedene Art und Weise geseedet und randomisiert.
Da DGA-Aktivität in der Regel mit DNS-Abfragen verbunden ist, manifestiert sie sich häufig in den DNS-Anforderungen, die von der infizierten Maschine ausgehen. Packetbeat kann DNS-Traffic erfassen und zur Analyse an Elasticsearch senden. In diesem Blogpost werfen wir einen Blick darauf, wie Sie die in Packetbeat enthaltenen DNS-Abfrage-Informationen mit einem Score anreichern können, der Auskunft über den Grad der Schädlichkeit der Domain gibt.
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt49f03548e4e6bc48/5f04ce44e224bf2d1883a92b/blog-dga-2-enriched-packetbeat.jpg" data-sys-asset-uid="blt49f03548e4e6bc48" alt="Angereicherte Packetbeat-Daten" style="display: block; margin: auto; width:650px;">
<figcaption>Abbildung 1: Beispiel für ein angereichertes Packetbeat-Dokument</figcaption><h2>Inferenzprozessoren und die Ingestions-Pipeline</h2>Wenn wir Packetbeat-Daten mit Prognosen eines Modells anreichern möchten, das darauf trainiert wurde, gutartige Domains von Schad-Domains zu unterscheiden, müssen wir eine Ingestions-Pipeline mit geeigneten Inferenzprozessoren konfigurieren. <a href="/guide/en/elasticsearch/reference/7.8/inference-processor.html">Inferenzprozessoren</a> sind eine Möglichkeit, anhand eines im Elastic Stack (oder in einer unserer unterstützten externen Bibliotheken) trainierten Modells Prognosen für neue Dokumente abzugeben, die in Elasticsearch ingestiert werden. Damit wir verstehen, wie all diese Teile zusammenpassen und welche Konfigurationen wir benötigen, schauen wir noch einmal auf Teil&nbsp;1 dieser Serie zurück.
In <a href="/de/blog/machine-learning-in-cybersecurity-training-supervised-models-to-detect-dga-activity">Teil&nbsp;1</a> haben wir die Schritte zum Trainieren eines Klassifizierungsmodells besprochen, mit dem prognostiziert werden kann, ob eine bestimmte Domain eine Schad-Domain ist. Einer dieser Schritte besteht darin, die Trainingsdaten –&nbsp;eine Gruppe von gutartigen und Schad-Domains anhand derer unser Modell lernt, wie es neue, bisher noch nicht gesehene Domains, einstufen soll&nbsp;– einem Feature-Engineering zu unterziehen. Dabei müssen die Roh-Domains manipuliert werden, um Features – Unigramme, Bigramme und Trigramme&nbsp;– zu extrahieren, die für das Modell nützlich sind. Dasselbe Feature-Engineering ist dann auch auf die Domains in unseren Packetbeat-Daten anzuwenden, von denen wir wissen möchten, ob sie schädlich sind.
Aus diesem Grund enthält unsere Ingestions-Pipeline neben einem Inferenzprozessor auch <a href="/guide/en/elasticsearch/reference/7.8/script-processor.html">Painless-Skript-Prozessoren</a>, mit denen beim Ingestieren aus den Packetbeat-DNS-Daten Unigramme, Bigramme und Trigramme extrahiert werden. Abbildung&nbsp;2 zeigt die komplette Pipeline.
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt076305e0def6b448/5f04ce78e224bf2d1883a92f/blog-dga-2-painless.png" data-sys-asset-uid="blt076305e0def6b448" alt="Painless-Skript zur Datenanreicherung" style="display: block; margin: auto; width:650px;">
<figcaption>Abbildung 2: Ingestions-Pipeline mit Painless-Skript-Prozessoren zum Extrahieren von N-Gramm-Features aus einer neuen ankommenden Domain und einem Inferenzprozessor zur Einstufung der Schädlichkeit der Domain</figcaption>Das Feld in den Packetbeat-Daten, das uns interessiert, ist das Feld <code>dns.question.registered_domain</code>. Es gibt zwar ein paar Randfälle, in denen dieses Feld nicht die uns interessierende Domain enthält, aber für die Illustration des Anwendungsfalls in diesem Blogpost reicht es, sich auf dieses Feld zu konzentrieren. Abbildung&nbsp;3 zeigt die uns interessierenden Felder in einem Packetbeat-Beispieldokument.
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt68491032263c0dfd/5f04cea0a6e8d0446e91d324/blog-dga-2-domain.png" data-sys-asset-uid="blt68491032263c0dfd" alt="Registrierte Domains" style="display: block; margin: auto; width:550px;">
<figcaption>Abbildung 3: Das Packetbeat-Feld, das uns interessiert, ist <code>dns.question.registered_domain</code></figcaption>Um Unigramme, Bigramme und Trigramme aus <code>dns.question.registered_domain</code> extrahieren zu können, benötigen wir ein Painless-Skript wie das in Abbildung&nbsp;4.
<pre class="prettyprint">POST _scripts/ngram-extractor-packetbeat 
{ 
 "script": { 
 "lang": "painless", 
 "source": """ 
 String nGramAtPosition(String fulldomain, int fieldcount, int n){ 
 String domain = fulldomain.splitOnToken('.')[0]; 
 if (fieldcount+n&gt;=domain.length()){ 
 return '' 
 } 
 else 
 { 
 return domain.substring(fieldcount, fieldcount+n) 
 } 
 } 
 for (int i=0;i&lt;ctx['dns']['question']['registered_domain'].length();i++){ 
 ctx['field_'+Integer.toString(params.ngram_count)+'_gram_'+Integer.toString(i)] = nGramAtPosition(ctx['dns']['question']['registered_domain'], i, params.ngram_count) 
 }
 """ 
 } 
}
</pre><figcaption>Abbildung 4: Painless-Skript zur Erweiterung einer Domain in Unigramme, Bigramme und Trigramme</figcaption>Nachdem die erforderlichen Features extrahiert wurden, passiert das Dokument beim Durchlaufen der Ingestions-Pipeline den Inferenzprozessor, wo das Klassifizierungsmodell, das wir in Teil&nbsp;1 trainiert haben, anhand der extrahierten Features eine Prognose ausgibt. Da wir unseren Index nicht mit all den zusätzlichen Features verstopfen möchten, die das Modell benötigt, fügen wir zu guter Letzt eine Reihe von Painless-Skript-Prozessoren hinzu, um die Felder mit den Unigrammen, Bigrammen und Trigrammen zu entfernen.
Am Ende der Ingestions-Pipeline wird somit ein Packetbeat-Dokument mit den neuen zusätzlichen Feldern ingestiert, die das Ergebnis der ML-Prognosen enthalten. Abbildung&nbsp;5 zeigt ein Beispiel für eine Ingestions-Pipeline-Konfiguration. Ausführliche Informationen finden Sie im <a href="https://github.com/elastic/examples/tree/master/Machine%20Learning/DGA%20Detection">Beispiele-Repository</a>.
<pre class="prettyprint">PUT _ingest/pipeline/dga_ngram_expansion_inference
{
 "description": "Expands a domain into unigrams, bigrams and trigrams and make a prediction of maliciousness",
 "processors": [
 {
 "script": {
 "id": "ngram-extractor-packetbeat",
 "params":{
 "ngram_count":1
 }
 }
 },
 {
 "script": {
 "id": "ngram-extractor-packetbeat",
 "params":{
 "ngram_count":2
 }
 }
 },
 {
 "script": {
 "id": "ngram-extractor-packetbeat",
 "params": {
 "ngram_count":3
 }
 }
 },
 {
 "inference": {
 "model_id": "dga-ngram-job-1587729368929",
 "target_field": "predicted_label",
 "field_mappings":{},
 "inference_config": { "classification": {"num_top_classes": 2} }
 }
},
 {
 "script": {
 "id": "ngram-remover-packetbeat",
 "params":{
 "ngram_count":1
 }
 }
 },
 {
 "script": {
 "id": "ngram-remover-packetbeat",
 "params":{
 "ngram_count":2
 }
 }
 },
 {
 "script": {
 "id": "ngram-remover-packetbeat",
 "params": {
 "ngram_count":3
 }
 }
 }
 ]
}
</pre><figcaption>Abbildung 5: Beispiel für eine Ingestions-Pipeline-Konfiguration</figcaption>Da nicht in jedem Packetbeat-Dokument eine DNS-Anforderung enthalten ist, müssen wir dafür sorgen, dass die Ingestions-Pipeline nur dann ausgeführt wird, wenn die benötigten DNS-Felder im ingestierten Dokument vorhanden sind. Dazu können wir mithilfe eines <a href="/guide/en/elasticsearch/reference/current/conditionals-with-multiple-pipelines.html">Pipeline-Prozessors</a> (siehe Konfiguration in Abbildung&nbsp;6) prüfen, ob die gewünschten Felder vorhanden sind und Werte enthalten, und dann die Verarbeitung des Dokuments an die in Abbildung&nbsp;5 definierte Pipeline <code>dga_ngram_expansion_inference</code> umleiten. Die unten gezeigte Konfiguration eignet sich für einen Prototyp, aber für einen Produktionsanwendungsfall muss die Ingestions-Pipeline Fehlerbehandlungsmechanismen enthalten. Ausführliche Informationen zu Konfigurationen und entsprechende Anleitungen finden Sie im <a href="https://github.com/elastic/examples/tree/master/Machine%20Learning/DGA%20Detection">Beispiele-Repository</a>.
<pre class="prettyprint">PUT _ingest/pipeline/dns_classification_pipeline
{
 "description": "A pipeline of pipelines for performing DGA detection",
 "version": 1,
 "processors": [
 {
 "pipeline": {
 "if": "ctx.containsKey('dns') && ctx['dns'].containsKey('question') && ctx['dns']['question'].containsKey('registered_domain') && !ctx['dns']['question']['registered_domain'].empty",
 "name": "dga_ngram_expansion_inference"
 }
 }
 ]
}
</pre><figcaption>Abbildung 6: Pipeline, die so konfiguriert ist, dass sie nur bei den Dokumenten eine DGA-Erkennung durchführt, die DNS-Anforderungen aufzeichnen</figcaption><h2>Anwendung der Anomalieerkennung auf die Inferenzergebnisse als Analytics-Methode zweiter Ordnung</h2>Das Modell, das wir in Teil&nbsp;1 der Serie trainiert haben, hatte eine Falsch-positiv-Quote von 2&nbsp;%. Das mag zwar recht niedrig klingen, aber man darf nicht vergessen, dass der DNS-Traffic in der Regel mit sehr großen Datenmengen verbunden ist. Daher kann auch bei einer Falsch-positiv-Quote von „nur“ 2&nbsp;% die Zahl der als schädlich eingestuften Abfragen recht hoch sein. Um die Zahl der falsch positiven Ergebnisse zu reduzieren, könnte man sich daran machen, das Feature-Engineering zu intensivieren. Oder aber man unterzieht die Ergebnisse unserer Klassifizierung einer Anomalieerkennung. Sehen wir uns an, wie wir Letzteres im Elastic Stack bewerkstelligen können.
Als Erstes stellen wir fest, dass wir beim Plotten der Zahl der als schädlich eingestuften angereicherten Packetbeat-Dokumente gegen die Zeit eine Zeitreihe erhalten (Abbildung&nbsp;7).
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt44ea9e47a1528323/5f04cf3a9ccd4234d7143ad3/blog-dga-2-time-series.jpg" data-sys-asset-uid="blt44ea9e47a1528323" alt="DGA-Aktivität im Zeitverlauf" style="display: block; margin: auto;">
<figcaption>Abbildung 7: Ergebnis des Plottens der Zahl der als schädlich prognostizierten Packetbeat-Dokumente gegen die Zeit in einer Zeitreihe</figcaption>Als Zweites ist festzustellen, dass DGA-Malware häufig (wenn auch nicht immer) beim Versuch der aktiven Kommunikation mit dem C&C-Server eine ganze Welle von DNS-Anforderungen lostritt (d.&nbsp;h., die Malware geht viele der vom Algorithmus generierten Domains durch und versucht, die IP-Adresse jeder dieser Domains aufzulösen). In der Zeitreihenanalyse der prognostizierten Schad-Domains im Zeitverlauf (Abbildung&nbsp;6) sind Aktivitätsspitzen sowie geringes Rauschen zwischen den Spitzen zu bemerken. Die Spitzen zeigen, dass unser Klassifizierungsmodell innerhalb eines kurzen Zeitraums viele Domains als Schad-Domains eingestuft hat, sodass wir daher mit einiger Wahrscheinlichkeit davon ausgehen können, dass wir es mit einem echten DGA zu tun haben. Dagegen ist das Hintergrundrauschen zwischen den Spitzen sehr wahrscheinlich auf falsch positive Ergebnisse zurückzuführen. Genau diese Intuition ist es, die wir für die Erstellung eines <code>high_count</code>-Anomalieerkennungsjobs für diese Zeitreihe nutzen werden.
Wenn wir die Anomalieerkennungs-Zeitleiste und die Zeitreihe in Abbildung&nbsp;7 miteinander vergleichen, sehen wir, dass die Anomalie-Alerts, die wir erhalten, mit den Spitzen in der Zeitreihe (der echten DGA-Aktivität) korrespondieren und es in den Intervallen zwischen den Spitzen (dem Hintergrundrauschen der falsch positiven Ergebnisse) keine Alerts gibt.
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blte3fdc5b9e672c19e/5f04cf5ae438c33db80644f6/blog-dga-2-anomalies.png" data-sys-asset-uid="blte3fdc5b9e672c19e" alt="DGA-Anomalien im Zeitverlauf" style="display: block; margin: auto;">
<figcaption>Abbildung 8: Der Vergleich zwischen der Anomalieerkennungs-Zeitleiste und der Zeitreihendarstellung der Zahl der Schad-Domains im Zeitverlauf zeigt, dass dies ein vielversprechendes Verfahren zur Reduzierung falsch positiver Ergebnisse bei der DGA-Erkennung ist</figcaption>Auch wenn dieses Beispiel sehr einfach gehalten wurde und für den Einsatz in einer Produktionsumgebung sicherlich noch Einiges an Feinjustierung und Konfiguration erforderlich ist, zeigt es doch, dass Anomalieerkennungsjobs für eine Inferenzergebnis-Analyse zweiter Ordnung effektiv sein können.
<h2>Fazit
</h2>In diesem Blogpost haben wir ein trainiertes Klassifizierungsmodell verwendet, um Netzwerkdaten (Packetbeat-Dokumente) beim Ingestieren mit Informationen anzureichern. Der Anreicherungsprozess, der durch den Inferenzprozessor und Ingestions-Pipelines möglich gemacht wird, fügt jeder Domain, die in einer DNS-Anforderung abgefragt wird, eine prognostische Einstufungsinformation hinzu. Dieser kann entnommen werden, wie groß die Wahrscheinlichkeit ist, dass es sich um eine Schad-Domain handelt. Um die Zahl falsch positiver Alerts zu reduzieren, haben wir uns auch angeschaut, wie die Ergebnisse der Inferenz mit einem Anomalieerkennungsjob verifiziert werden können. Wir planen darüber hinaus, in <a href="/de/siem">Elastic SIEM</a> eine kuratierte Konfiguration und Modelle für die DGA-Erkennung bereitzustellen.
Wenn Sie sich ansehen möchten, wie das Ingestieren und Analysieren mit Ihren eigenen Netzwerkdaten funktioniert, können Sie <a href="/de/elasticsearch/service">Elasticsearch Service 14&nbsp;Tage lang kostenlos ausprobieren</a>. Außerdem können Sie <a href="/guide/en/machine-learning/current/ml-getting-started.html">Machine Learning kostenlos 30&nbsp;Tage lang ausprobieren</a>, indem Sie den <a href="/de/downloads">Elastic Stack herunterladen</a> und lokal eine Probelizenz verwenden. Oder Sie nutzen das kostenlose und offene <a href="/de/siem">Elastic SIEM</a>, um heute noch damit zu beginnen, Ihre Daten zu schützen.

Machine learning in cybersecurity: Detecting DGA activity in network data

Machine Learning in der Cybersicherheit: Erkennen von DGA-Aktivität in Netzwerkdaten

Angreifer (und deren Malware) nutzen zur Tarnung Domain-Generation-Algorithmen (DGA). Mit Elastic-Machine-Learning lassen sich jedoch Modelle erstellen, die helfen, solche Tricks zu durchschauen.

Werbeanrufe von irgendwelchen Telefonnummern können nerven. Und da hilft es auch nichts, die Nummer zu sperren, denn der nächste Anruf kommt von einer neuen Nummer. Dieselben schmutzigen Tricks werden von Cyberkriminellen verwendet: Malware-Entwickler setzen Domain-Generation-Algorithmen (DGAs) ein, die die Quelle ihrer Command‑&-Control-Infrastruktur verschleiern, um nicht aufgespürt zu werden und Security-Analysten das Leben schwerzumachen, die dieses Treiben unterbinden möchten.

In dieser zweiteiligen Serie werden wir mithilfe von <a href="/de/what-is/elasticsearch-machine-learning">Elastic-Machine-Learning</a> ein Modell zur Erkennung solcher Domain-Generation-Algorithmen erstellen und evaluieren. In diesem Teil&nbsp;1 behandeln wir die folgenden Themen:

<ul>
	<li>Schritte zum Extrahieren unabhängiger Variablen (Features) aus den Domain-Rohinformationen</li>
	<li>Schritte zum Finden geeigneter Variablen</li>
	<li>Trainieren und Evaluieren eines Machine-Learning-Modells mit dem <a href="/de/products">Elastic Stack</a></li>
</ul>
In Teil 2 wird es dann darum gehen, wie sich das trainierte Modell in einer Ingestions-Pipeline bereitstellen lässt, damit es <a href="/de/beats/packetbeat">Packetbeat</a>-Daten beim Ingestieren mit Informationen anreichern kann. Die entsprechenden Konfigurationsdateien und unterstützendes Material sind im <a href="https://github.com/elastic/examples/tree/master/Machine%20Learning/DGA%20Detection">Beispiele-Repository</a> zu finden.&nbsp;

Wenn Sie das Ganze mit Ihren eigenen Daten durchexerzieren möchten, empfehle ich Ihnen, das Angebot zu nutzen, <a href="/de/elasticsearch/service">unseren Elasticsearch Service kostenlos auszuprobieren</a>. Sie erhalten für den Probezeitraum vollen Zugriff auf alle unsere Machine-Learning-Funktionen. Okay, legen wir los.

<h2>DGA: Hintergrundinformationen</h2>
Viele Schadprogramme versuchen nach erfolgreichem Eindringen in das Zielsystem, einen Remote-Server –&nbsp;„Command-&-Control-Server“, „C&C-Server“ oder „C2-Server“ genannt&nbsp;– zu kontaktieren, um Daten zu übertragen und Anweisungen oder Aktualisierungen zu erhalten. Das bedeutet, dass das Schadprogramm entweder die IP-Adresse des C&C-Servers oder die Domain kennen muss. Wenn diese IP-Adresse oder Domain im Schadprogramm hartcodiert ist, ist es für Verteidigungsmaßnahmen relativ leicht, diese Kommunikation zu unterbinden: Die Domain muss lediglich einer Sperrliste hinzugefügt werden.&nbsp;

<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt79b409f8d7fe0f42/5eeab3f76b547b2c37e3a7ee/blog-dga-1-malware.png" data-sys-asset-uid="blt79b409f8d7fe0f42" alt="" style="display: block; margin: auto;">
<figcaption>Abbildung 1: Ein Schadprogramm geht die vom DGA generierten Domains durch, um diejenige zu finden, die als C&C-Server registriert ist.&nbsp;
</figcaption>
Um diese Verteidigungsmaßnahmen zu umgehen, können die Entwickler der Malware einen DGA hinzufügen. DGAs generieren Hunderte oder Tausende von zufällig aussehenden Domains. Die Malware auf der infizierten Maschine geht dann jede einzelne dieser generierten Domains durch und versucht, die Domain-Namen aufzulösen, um zu sehen, welche der Domains als C&C-Server registriert worden ist. Aufgrund der schieren Menge und Zufälligkeit der Domains ist es für einen regelbasierten Verteidigungsansatz schwierig, diesen Kommunikationskanal auszuschalten. Auch Analysten haben daran zu knabbern, denn DNS-Traffic ist in der Regel mit einem sehr hohen Datenaufkommen verbunden. Beide dieser Faktoren machen dies zu einem idealen Anwendungsfall für das Machine Learning.&nbsp;

<h2>Trainieren eines Machine-Learning-Modells zur Klassifizierung von Domains</h2>
Beim überwachten Machine Learning setzen wir dem Machine-Learning-Modell einen „gelabelten“ Trainingsdatensatz mit gutartigen und Schad-Domains vor, damit es lernen kann, gutartige von Schad-Domains zu unterscheiden. Anschließend wird dieses Modell dazu eingesetzt, bisher noch nicht bekannte Domains als gutartig oder schädlich einzustufen.&nbsp;

Es gibt verschiedene Arten von DGAs – nicht alle sehen gleich aus. Einige DGAs generieren zufällig aussehende Domains, während andere Wortlisten nutzen. In Produktionsumgebungen können andere Variablen und Modelle genutzt werden, um die Merkmale der verschiedenen Algorithmen zu erfassen. In diesem Beispiel trainieren wir ein einzelnes Modell auf der Grundlage der Merkmale der gängigsten Algorithmen.

Zum Trainieren unseres Modells nutzen wir einen Datensatz, der aus gutartigen Domains sowie Schad-Domains aus verschiedenen Malware-Familien besteht.&nbsp;

<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blta81a7ecea3bfbb26/5eeab4068d39260a3ded679b/blog-dga-1-datasets.png" data-sys-asset-uid="blta81a7ecea3bfbb26" alt="" style="display: block; margin: auto; width:650px;">
<figcaption>Abbildung 2: Beispiel-Domains, generiert von den Malware-Familien <code>cryptolocker</code>, <code>banjori</code> und <code>suppobox</code>
</figcaption>
<h3>Feature-Engineering</h3>
Zum Erstellen eines effektiven Machine-Learning-Modells werden unabhängige Variablen („Features“) benötigt, die die charakteristischen Merkmale der von den DGAs generierten Domains erfassen können. Daher müssen wir dem Modell mitteilen, welche Aspekte der Zeichenfolge für die Unterscheidung zwischen gutartigen und Schad-Domains wichtig sind. Dieser Schritt wird im Machine-Learning-Universum „Feature-Engineering“ genannt.

Das Ermitteln der Variablen, die am besten geeignet sind, gutartige von Schad-Domains zu unterscheiden, ist ein iterativer Vorgang. Nehmen wir an, wir haben mit ein paar einfachen Variablen, wie Domain-Namen-Länge und Domain-Namen-Entropie, begonnen, aber die sich daraus ergebenden Modelle konnten hinsichtlich ihrer Zuverlässigkeit nicht mit anderen Methoden wie LSTM mithalten. Diese Modelle nutzen die sequenziellen Merkmale der Zeichenfolgen, weshalb wir uns andere Variablen angesehen haben, die Sequenzen effektiver encodieren.

Nachdem wir es mit den verschiedensten Feature-Engineering-Methoden versucht haben, sind wir zu dem Schluss gekommen, dass das beste Merkmal zur Unterscheidung zwischen gutartigen und Schad-Domains das Vorhandensein unterschiedlich langer Subzeichenfolgen ist.&nbsp;

<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltdeba08fd148fe3a6/5eeab41a7253820a4364d9eb/blog-dga-1-n-grams.png" data-sys-asset-uid="bltdeba08fd148fe3a6" alt="" style="display: block; margin: auto; width:650px;">
<figcaption>Abbildung 3: Aufteilung einer Eingabe-Domain namens „iglxbvkw“ in Unigramme, Bigramme und Trigramme&nbsp;
</figcaption>
Diese Subzeichenfolgen werden üblicherweise als „N-Gramme“ bezeichnet. Bei der Ermittlung geeigneter Variablen ist es wichtig, die Zahl der Variablen (Dimensionalität des Training-Datensatzes) und die Komplexität ihrer Berechnung gegen den Nutzen für das Modell aufzuwiegen. Nach mehreren Iterationen und Tests von N-Grammen verschiedener Längen haben wir festgestellt, dass N-Gramme ab einer Länge von 4 dem Modell keine signifikanten prädiktiven Informationen hinzufügen, sodass wir uns bei unserem Variablensatz auf Unigramme, Bigramme und Trigramme beschränken können. Abbildung 3 zeigt, wie diese Variablen aus einer Beispiel-Domain generiert werden.

Zum Generieren eines Elasticsearch-Index, bei dem jede DGA-Domain in Unigramme, Bigramme und Trigramme aufgeteilt wird, können Sie den originalen Ausgangsindex mit einem Painless-Skript-Prozessor zum Reindexieren durch eine Ingestions-Pipeline schicken. Ein Beispiel dafür sehen Sie in Abbildung&nbsp;4 unten.&nbsp; Ausführliche Konfigurationen, Anleitungen und verschiedene Anpassungsoptionen finden Sie im <a href="https://github.com/elastic/examples/tree/master/Machine%20Learning/DGA%20Detection">Beispiele-Repository</a>.&nbsp;

<pre class="prettyprint">POST _scripts/ngram-extractor-reindex 
{ 
 "script": { 
 "lang": "painless", 
 "source": """ 
 String nGramAtPosition(String fulldomain, int fieldcount , int n){ 
 String domain = fulldomain.splitOnToken('.')[0]; 
 if (fieldcount+n&gt;=domain.length()){ 
 return '' 
 } 
 else 
 { 
 return domain.substring(fieldcount, fieldcount+n) 
 } 
 } 
 for (int i=0;i&lt;ctx['domain'].length();i++){ 
 ctx[Integer.toString(params.ngram_count)+'-gram_field'+Integer.toString(i)] = nGramAtPosition(ctx['domain'], i, params.ngram_count) 
 } 
 """ 
 } 
}
</pre><figcaption>Abbildung 4:&nbsp;Beispiel für ein Painless-Skript zum Extrahieren von N-Grammen aus Domains in Eingabedaten
</figcaption>
Im Normalfall sind zusätzliche Vorverarbeitungsschritte nötig, um die Subzeichenfolgen der Längen 1, 2 und 3 für den Machine-Learning-Algorithmus in numerische Vektoren umzuwandeln. In unserem Fall kümmert sich aber Elastic Machine Learning um diese „Encodieren“ genannte Umwandlung in numerische Werte. Elastic Machine Learning sieht sich auch die Variablen an und wählt automatisch diejenigen aus, die die meisten Informationen enthalten.

<h2>Erstellen eines Klassifizierungsjobs mit Data Frame Analytics</h2>
Der nächste Schritt besteht darin, mithilfe der „Data Frame Analytics“-Benutzeroberfläche einen Klassifizierungsjob zu erstellen. Ich habe in den folgenden Screenshots einige der wichtigsten Aspekte hervorgehoben.

<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt41bc9b5e914391bd/5eeab4326b547b2c37e3a7f2/blog-dga-1-create-job.jpg" data-sys-asset-uid="blt41bc9b5e914391bd" alt="" style="display: block; margin: auto; width:350px;">
<figcaption>Abbildung 5: Der Data Frame Analytics Wizard führt Schritt für Schritt durch die Erstellung eines Klassifizierungsjobs
</figcaption>
Es sei darauf hingewiesen, dass wir mithilfe des Schiebereglers den Anteil der für das Training verwendeten Daten und damit ein Training-Test-Verhältnis festlegen können. Im Screenshot in Abbildung&nbsp;5 liegt der Anteil der für das Training verwendeten Daten bei 80&nbsp;%, das heißt, dass 80&nbsp;% der Dokumente im Ausgangsindex zum Trainieren des Modells verwendet werden, während 20&nbsp;% für das Testen verbleiben.

Nach Abschluss des Trainingsprozesses können wir zur Ergebnisansicht in der „Data Frame Analytics“-Benutzeroberfläche gehen und uns dort die Performance des Modells ansehen. Da wir unseren Ausgangsindex in einen Trainingssatz und einen Testsatz aufgeteilt haben, können wir für beide Anwendungsfälle Aussagen zur Performance des Modells treffen. Nun geben zwar sowohl die Informationen zur Performance des Trainingssatzes als auch die Angaben zur Performance des Testsatzes wertvolle Anhaltspunkte, uns interessiert aber hier vor allem die Performance des Modells beim Test-Datensatz, denn daraus lassen sich Rückschlüsse auf den Generalisierungsfehler des Modells ziehen. Dieser Fehler gibt an, wie gut das Modell in der Lage sein wird, Prognosen für Datenpunkte abzugeben, die es bisher noch nicht gesehen hat.&nbsp;

<h2>Evaluieren eines Machine-Learning-Modells</h2>
Nachdem wir das Training abgeschlossen haben, können wir uns zur Job-Management-Seite der Elastic-Machine-Learning-Benutzeroberfläche durchklicken und uns dort die Ergebnisse ansehen.&nbsp;

Auf der Ergebnisseite (siehe Abbildung&nbsp;6) finden wir zwei wichtige Informationen: eine Wahrheitsmatrix, die zusammenfasst, wie sich unser Modell geschlagen hat, und eine Ergebnistabelle, über die wir per Drilldown für einzelne Datenpunkte feststellen können, wie sie vom Modell eingestuft wurden. Zum Wechseln zwischen der Anzeige von Wahrheitsmatrix und Zusammenfassungstabelle des Testdatensatzes und des Trainingsdatensatzes stehen die Filterschaltflächen „Testing“ und „Training“ rechts oben über der Tabelle zur Verfügung.&nbsp;

<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt2835b4e08a0b8637/5eeab44b688c1c62a49ae2f2/blog-dga-1-data-frame.jpg" data-sys-asset-uid="blt2835b4e08a0b8637" alt="" style="display: block; margin: auto;">
<figcaption>Abbildung 6: Die „Data Frame Analytics“-Ergebnisseite bietet eine Wahrheitsmatrix und eine Tabelle mit Probendaten
</figcaption>
Ein häufig genutztes Mittel zur Anzeige der Performance eines Modells ist die Wahrheitsmatrix genannte Visualisierung. Sie gibt Auskunft über den Anteil der richtig positiv eingestuften Datenpunkte (Schad-Domains, die das Modell als Schad-Domains klassifiziert hat und die tatsächlich Schad-Domains waren), den Anteil der richtig negativ eingestuften Datenpunkte (gutartige Domains, die das Modell als gutartig eingestuft hat), den Anteil der falsch positiven Datenpunkte (fälschlich als Schad-Domains eingestufte gutartige Domains) und den Anteil der falsch negativen Datenpunkte (fälschlich als gutartig eingestufte Schad-Domains).&nbsp;

Wie ihr Name bereits sagt, lässt sich der Wahrheitsmatrix schnell entnehmen, ob ein Modell bei seinen Einstufungen im Wesentlichen die Wahrheit sagt oder beides oft durcheinanderbringt.&nbsp;

In Abbildung&nbsp;6 sehen wir für unser Modell im Hinblick auf den Testdatensatz eine Richtig-positiv-Quote von 98&nbsp;%. Das bedeutet, dass wir bei einer Implementierung dieses Modells in eine Produktionsumgebung hinsichtlich der Einstufung ankommender DNS-Daten mit einer Falsch-positiv-Quote von ca. 2&nbsp;% rechnen müssen. Dies mag zwar nach einer recht geringen Zahl aussehen, aber angesichts der großen Datenmengen beim DNS-Traffic käme dabei trotzdem eine ziemlich hohe Zahl von Alerts zustande. Daher werden wir uns in Teil&nbsp;2 ansehen, wie sich die Zahl der falsch positiven Alerts durch Anomalieerkennung reduzieren lässt.&nbsp;

<h2>Fazit</h2>
In diesem Blogpost haben wir uns einen Überblick darüber verschafft, wie sich mit <a href="/de/what-is/elasticsearch-machine-learning">Elastic Machine Learning</a> ein Machine-Learning-Modell für die DGA-Erkennung entwickeln und evaluieren lässt. Wir haben uns die Schritte zum Extrahieren unabhängiger Variablen („Features“) aus den rohen gutartigen und Schad-Domains angesehen und den Prozess zur Ermittlung geeigneter Variablen betrachtet. Schließlich haben wir einen Blick auf das Trainieren und Evaluieren eines Machine-Learning-Modells mit dem Elastic Stack geworfen.

Im zweiten Teil der Serie wird es darum gehen, wie man mithilfe von <a href="/guide/en/elasticsearch/reference/7.8/inference-processor.html">Inferenzprozessoren</a> in Ingestions-Pipelines dieses Modell so einsetzen kann, dass es ankommende Packetbeat-Daten mit prädiktiven Informationen zur Schädlichkeit der Domain anreichern kann. Außerdem sehen wir uns an, wie Anomalieerkennungsjobs die Zahl falsch positiver Alerts reduzieren können. Bis dahin empfehle ich Ihnen, <a href="/de/elasticsearch/service">unsere Machine-Learning-Funktionen kostenlos auszuprobieren</a> und sich so ein Bild davon zu machen, was für Einblicke und Erkenntnisse Sie gewinnen können, wenn Sie das Rauschen in Ihren Daten hinter sich gelassen haben.

Articles by Camilla Montonen

Kombinieren von überwachtem und unüberwachtem Machine Learning für die Erkennung von DGA

Trainieren, evaluieren, überwachen, inferieren: End-to-End-Machine-Learning in Elastic

Machine Learning in der Cybersicherheit: Erkennen von DGA-Aktivität in Netzwerkdaten

Machine Learning in der Cybersicherheit: Trainieren überwachter Modelle zur Erkennung von DGA-Aktivität

Produkte

Unternehmen

Ressourcen

Lösungen

Elastic (ELK) Stack

NEU

Articles by Camilla Montonen

Kombinieren von überwachtem und unüberwachtem Machine Learning für die Erkennung von DGA

Trainieren, evaluieren, überwachen, inferieren: End-to-End-Machine-Learning in Elastic

Machine Learning in der Cybersicherheit: Erkennen von DGA-Aktivität in Netzwerkdaten

Machine Learning in der Cybersicherheit: Trainieren überwachter Modelle zur Erkennung von DGA-Aktivität