Automatisierung von Erkennungsanpassungsanfragen mit Kibana-Fällen

Automatisierung von Erkennungsanpassungsanfragen mit elastischer Sicherheit

Bei Elastic ist das Infosec-Team der „Kunde Null“. Wir nutzen die neueste Version der Elastic-Produkte umfassend zur Absicherung unserer Organisation, was uns einzigartige Einblicke in die Lösung realer Sicherheitsherausforderungen ermöglicht. Eine der Möglichkeiten, mit denen wir die Effizienz des Security Operations Center (SOC) verbessert haben, besteht in der Schaffung eines nahtlosen, automatisierten Workflows, der es unseren Analysten ermöglicht, mit einem einzigen Klick direkt aus Kibana Cases eine Anfrage zur Erkennungsoptimierung zu öffnen.

In jedem SOC ist der Feedback-Mechanismus zwischen Sicherheitsanalysten und Erkennungsingenieuren entscheidend für die Aufrechterhaltung eines gesunden und effektiven Sicherheitszustands. Analysten an vorderster Front sind die ersten, die sehen, wie sich Erkennungsregeln in der realen Welt bewähren. Sie wissen, welche Warnmeldungen wertvoll sind, welche irrelevant sind und welche durch ein wenig Feinabstimmung verbessert werden könnten. Die durch zu viele Warnmeldungen verursachte Alarmmüdigkeit erhöht das Risiko, eine tatsächlich positive Warnmeldung zu übersehen. Die schnelle Korrektur von Fehlalarmen ist entscheidend für die Reaktion auf echte positive Ergebnisse. Die effiziente Erfassung dieses Warnfeedbacks kann eine Herausforderung sein – manuelle Prozesse wie das Versenden von E-Mails, das Öffnen von Tickets oder das Versenden von Direktnachrichten können inkonsistent, zeitaufwändig und schwer nachzuverfolgen sein.

Mit Elastic Security kann ein Analyst Warnmeldungen an einen neuen oder bestehenden Fall in Kibana anhängen , seine Untersuchung durchführen und mit einigen Anpassungen und Automatisierungen mit einem einzigen Klick direkt aus Kibana Cases eine Optimierungsanfrage initiieren. Dieser Artikel erklärt Ihnen Schritt für Schritt, wie wir diese Automatisierung entwickelt haben und wie Sie ein ähnliches System implementieren können, um den Feedback-Kreislauf zu schließen und Ihr Erkennungs- und Reaktionsprogramm zu optimieren.

Benutzerdefinierte Felder in Kibana-Fällen

Benutzerdefinierte Felder sind ein wichtiger Bestandteil dieser Automatisierung innerhalb der Kibana-Fälle. Mithilfe dieser benutzerdefinierten Felder können wir die benötigten Informationen direkt aus dem Tool erfassen, das die Analysten bereits verwenden. Diese benutzerdefinierten Felder werden in allen neuen und bestehenden Fällen angezeigt und bieten Analysten eine klare und einheitliche Möglichkeit, eine Erkennung zur Überprüfung zu kennzeichnen.

Hinweis: Die Möglichkeit, benutzerdefinierte Felder zu Fällen hinzuzufügen, wurde in Version 8.15 eingeführt. Weitere Einzelheiten finden Sie in der offiziellen Falldokumentation.

Jeder Kibana-Fall ist ein Dokument, das in einem dedizierten Elasticsearch-Index gespeichert ist: .kibana_alerting_cases. Das bedeutet, dass alle Ihre Falldaten für Abfragen, Aggregationen und Automatisierungen zur Verfügung stehen, genau wie jede andere Datenquelle in Elastic. Jedes Falldokument enthält eine Fülle von Informationen, aber einige Felder sind besonders nützlich für Kennzahlen und Automatisierung. Das Feld cases.status erfasst, ob ein Fall offen, in Bearbeitung oder abgeschlossen ist, während cases.created_at und cases.updated_at Zeitstempel liefern, die für die Berechnung von Kennzahlen wie der mittleren Bearbeitungszeit (MTTR) unerlässlich sind. Felder wie cases.severity und cases.owner ermöglichen es Ihnen, Ihre Kennzahlen detailliert zu analysieren, um zu sehen, wie das Team performt. Am wichtigsten für diesen Blog ist, dass das cases.custom_fields -Objekt ein Array der von Ihnen konfigurierten benutzerdefinierten Felder enthält. Mit Laufzeitfeldern lässt sich das Array benutzerdefinierter Felder analysieren, sodass Sie Abfragen, Dashboards, Visualisierungen und Erkennungsregeln erstellen können, die Workflows auslösen.

Neben der Optimierung von Anfragen sind benutzerdefinierte Felder unglaublich vielseitig einsetzbar, um Kennzahlen zu erfassen und Fälle anzureichern. Wir haben beispielsweise ein benutzerdefiniertes Feld namens „ Komplexer Fall “, um Fälle zu kennzeichnen, deren Lösung länger als eine Stunde dauert. Dies hilft uns, Regeln zu identifizieren, für die möglicherweise bessere Untersuchungsleitfäden oder Automatisierungen erforderlich sind, um die Untersuchungszeit zu verkürzen. Wir verwenden außerdem benutzerdefinierte Felder wie „Erkennungsregel gültig“ und „True Positive Alarm“, um detailliertes Feedback zur Regelleistung und -genauigkeit zu erhalten. Dies ermöglicht es uns, in Kibana aussagekräftige Dashboards zu erstellen, um die operative Effektivität unseres SOC zu visualisieren.

Falls Sie noch keine Datenansicht für die Fallinformationen erstellt haben, müssen Sie dies tun, wenn Sie Laufzeitfelder und Datenvisualisierungen mit Ihren Fällen verwenden möchten.

Navigieren Sie zu Index Patterns: Gehen Sie in Kibana zu Stack Management > Data Views und klicken Sie auf 'Neue Datenansicht erstellen'.

Konfigurieren Sie die Datenansicht so, dass der Systemindex .kibana_alerting_cases abgebildet wird. Sie müssen auf die Schaltfläche „Versteckte und Systemindizes zulassen“ klicken, um dies zu ermöglichen. Für das Zeitstempelfeld empfehle ich die Verwendung des Feldes cases.updated_at , damit die Fälle nach der aktuellsten Aktivität angezeigt werden.

Erstellen benutzerdefinierter Felder

Es gibt zwei Arten von benutzerdefinierten Feldern: Text -Felder für Freitexteingaben und Toggle -Felder für einfache Ja/Nein-Rückmeldungen. Für unsere Automatisierung der Tuning-Anfrage verwenden wir jeweils ein Exemplar. Das Textfeld ist ein optionales Feld, mit dem zusätzliches Feedback vom Analysten erfasst werden kann, und das Umschaltfeld dient zum Auslösen der Automatisierung.

In Kibana gehen Sie zu Sicherheit > Fälle und klicken dann oben rechts auf Einstellungen . Auf der Einstellungsseite finden Sie den Abschnitt „Benutzerdefinierte Felder“ , in dem Sie die gewünschten neuen Felder hinzufügen können. Die Felder werden in der Benutzeroberfläche der Fälle in alphabetischer Reihenfolge angezeigt. Um sie in der gewünschten Reihenfolge zu halten, versehen wir unsere Felder mit Nummern.

Sie können die neuen benutzerdefinierten Felder erstellen. Die in der Benutzeroberfläche hinzugefügten Bezeichnungen sind nur für die Analysten bestimmt und werden nicht im Fallindex gespeichert. Diese Werte können beliebig sein.

Benutzerdefinierte Felder hinzufügen: Für diesen Workflow benötigen wir zwei Felder.

• Feld 1: Einstellung erforderlich (Umschalter)

  • Dies ist die Schaltfläche, auf die Analysten klicken, um eine Tuning-Anfrage zu initiieren.

    • Etikett: Open tuning request?
    • Typ: Umschalten
    • Standardwert: Aus

  • Feld 2: Details zur Tuning-Anfrage

    • Dieses Feld ermöglicht es dem Analysten, spezifische Details darüber anzugeben, was geändert werden muss, z. B. das Hinzufügen einer Ausnahme, das Herunterstufen des Schweregrades oder das Anpassen der Abfragelogik.
    • Name: Tuning request detail
    • Typ: Text

  • Standardwert: Aus

Verwendung von Laufzeitfeldern zur Zuordnung der benutzerdefinierten Felder

Eine Herausforderung bei der Arbeit mit benutzerdefinierten Feldern in Kibana Cases besteht darin, dass das Feld cases.custom_fields als Array von Objekten abgebildet wird, wobei jedes Objekt ein benutzerdefiniertes Feld mit seinem Namen und Wert darstellt. Diese Struktur erschwert es, bestimmte benutzerdefinierte Felder direkt in KQL abzufragen. Zum Beispiel kann man nicht einfach eine Abfrage wie cases.custom_fields.open_tuning_request : "true" verwenden. Um dies zu umgehen, können wir Laufzeitfelder verwenden, um die benutzerdefinierten Felder zu analysieren und abzufragen.

Laufzeitfelder sind Felder, die zur Abfragezeit ausgewertet werden. Sie ermöglichen es Ihnen, neue Felder spontan zu erstellen, ohne Ihre Daten neu indizieren zu müssen. Wir können Laufzeitfelder am Index .kibana_alerting_cases definieren, um mit einem einfachen Skript das Array cases.custom_fields zu analysieren und die benötigten Werte in neue, leicht abfragbare Felder zu extrahieren.

Für diesen Workflow erstellen wir zwei Laufzeitfelder, die den oben erstellten benutzerdefinierten Feldern zugeordnet werden:
* TuningRequired: Ein boolesches Feld, das den Wert true annimmt, wenn die Option „Tuning-Anfrage öffnen“ aktiviert ist.
* TuningDetail: Ein Textfeld, das die Kommentare des Analysten aus dem Feld "Details zur Tuning-Anfrage" enthält.

Bevor wir die Laufzeitfelder erstellen können, müssen wir zunächst die eindeutige ID (key) ermitteln, die Kibana jedem benutzerdefinierten Feld zuweist. Derzeit gibt es keine einfache Möglichkeit, diese ID in der Benutzeroberfläche anzuzeigen. Um es herauszufinden, haben wir folgenden Umweg verwendet:

1. Felder erstellen. Wenn Sie andere benutzerdefinierte Felder verwenden, sollten Sie diese nacheinander erstellen, um die Identifizierung der neuen Feldschlüssel zu vereinfachen. Wenn Sie nur die beiden oben genannten Felder haben, können Sie diese mithilfe des type -Werts unterscheiden, der entweder Text oder ein Schalter sein kann.
2. Erstellen Sie einen neuen Fall. Nach dem Hinzufügen des Feldes haben wir einen Testfall in Kibana erstellt und einige Daten in das Beschreibungsfeld eingefügt. Anschließend haben wir das Feld „Anpassung erforderlich“ auf „true“ gesetzt, während alle anderen benutzerdefinierten Felder auf „false“ oder leer waren.
3. Prüfen Sie die Fallakte. Anschließend navigierten wir zu Discover und fragten den Index .kibana_alerting_cases ab, um das Dokument für den neuen Fall zu finden. Durch die Untersuchung des cases.customFields -Arrays im Quelltext des Dokuments konnten wir das key finden, das mit unserem neuen benutzerdefinierten Feld verknüpft ist. Speichern Sie die Werte der key Felder zur Verwendung in den Laufzeitskripten.

Die cases.customFields -Daten sind wie folgt formatiert:

  [
    {
      "key": "4537b921-3ca4-4ff0-aa39-02dd6a3177bd",
      "type": "text",
      "value": "This alert is too noisy"
    },
    {
      "key": "cdf28896-c793-43d2-9384-99562e23a646",
      "type": "toggle",
      "value": true
    }
  ]

Erstellen der Laufzeitfelder

Sie können Laufzeitfelder über die Kibana-Benutzeroberfläche oder mithilfe der Elasticsearch-API in der Entwicklerkonsole hinzufügen. Falls Sie noch keine Datenansicht für die Fallinformationen erstellt haben, müssen Sie dies zuerst tun.

Klicken Sie in der neuen Kibana-Falldatenansicht auf die Schaltfläche „Feld hinzufügen“, um das Flyout-Menü zum Erstellen eines neuen Laufzeitfelds zu öffnen.

Geben Sie den Namen des Feldes ein. In diesem Beispiel konfigurieren wir TuningRequired als neuen booleschen Feldtyp. Klicken Sie auf den Schalter „Wert festlegen“, um dies als neues Laufzeitfeld zu konfigurieren, das über ein Painless-Skript konfiguriert wird. Aktualisieren Sie dieses einfache Skript, um TUNING_REQUIRED_FIELD_KEY_UUID durch den Wert key aus dem benutzerdefinierten Feld „Tuning Required“ zu ersetzen, fügen Sie ihn in das Wertfeld ein und speichern Sie das neue Laufzeitfeld.

...
    if (params._source.containsKey('cases') &&
    params._source.cases != null &&
    params._source.cases.containsKey('customFields') &&
    params._source.cases.customFields != null) 
{
  for (def cf : params._source.cases.customFields) {
    if (cf != null &&
        cf.containsKey('key') &&
        cf.key != null &&
        cf.key.contains('TUNING_REQUIRED_FIELD_KEY_UUID') &&
        cf.containsKey('value') &&
        cf.value != null) {
      emit(cf.value);
      break;
    }
  }
}

Wiederholen Sie diesen Vorgang für das Feld TuningDetail . Denken Sie daran, den Wert key aus dem Textfeld im Painless-Skript dieses Feldes zu verwenden. Falls Sie in Ihren Fällen zusätzliche benutzerdefinierte Felder haben, die Sie für Dashboards oder Metriken verwenden möchten, können Sie diese ebenfalls mit demselben Verfahren zuordnen.

Wenn Sie Ihre Clustereinstellungen und Datenansichten „als Code“ steuern, können Sie auch Laufzeitfelder zu einer Indexzuordnung hinzufügen, indem Sie die Update Mapping API aus der Kibana Dev Tools-Konsole verwenden.

Automatisierung der Erstellung von Tuning-Anfragen

Diese Automatisierung kann auf zwei Arten ausgelöst werden: entweder über eine benutzerdefinierte Erkennungsregel (die eine neue Warnung erstellt und an einen Konnektor sendet, wenn ein Fall mit einer Tuning-Anforderung aktualisiert wird) oder über eine geplante externe Automatisierung, die die API abfragt.

Diese Automatisierung kann mithilfe beliebiger Automatisierungsplattformen wie Tines, GitHub Actions oder durch benutzerdefinierte Skripte erstellt werden. Dies ist die Logik, die wir für unsere Automatisierung verwenden:

Schritt 1: Suchen Sie nach Fällen, die kürzlich als … gekennzeichnet wurden TuningRequired

Mit dieser Elasticsearch-Abfrage können Sie alle Fälle finden, die innerhalb der letzten Stunde aktualisiert wurden und bei denen das Feld TuningRequired auf true gesetzt wurde. Diese Abfrage verwendet das Feld cases.updated_at als Zeitbereich. Die Laufzeitfeldzuordnungen müssen in die API-Anfrage aufgenommen werden, um die benutzerdefinierten Felder abzufragen.

Diese Abfrage gibt alle Falldokumente aus dem Index .kibana_alerting_cases zurück, die in der letzten Stunde aktualisiert wurden und deren Feld TuningRequired auf truegesetzt wurde.

POST /.kibana_alerting_cases/_search  
{  
  "query": {  
    "bool": {  
      "must": [],  
      "filter": [  
        {  
          "bool": {  
            "should": [  
              {  
                "match": {  
                  "TuningRequired": true  
                }  
              }  
            ],  
            "minimum_should_match": 1  
          }  
        },  
        {  
          "range": {  
            "cases.updated_at": {  
              "format": "strict_date_optional_time",  
              "gte": "now-1h",  
              "lte": "now"  
            }  
          }  
        }  
      ],  
      "should": [],  
      "must_not": []  
    }  
  },  
 "runtime_mappings": {  
   "TuningDetail": {  
     "type": "keyword",  
     "script": {  
       "source": "if (\nparams._source.containsKey('cases') &&\nparams._source.cases != null &&\nparams._source.cases.containsKey('customFields') &&\nparams._source.cases.customFields != null\n) {\nfor (def cf : params._source.cases.customFields) {\nif (\ncf != null &&\ncf.containsKey('key') &&\ncf.key != null &&\ncf.key.contains('6cadc70a-7d68-4531-9861-7d5bc24c4c1c') &&\ncf.containsKey('value') &&\ncf.value != null\n) {\nemit(cf.value);\nbreak;\n}\n}\n}"  
     }  
   },  
   "TuningRequired": {  
     "type": "boolean",  
     "script": {  
       "source": "if (\nparams._source.containsKey('cases') &&\nparams._source.cases != null &&\nparams._source.cases.containsKey('customFields') &&\nparams._source.cases.customFields != null\n) {\nfor (def cf : params._source.cases.customFields) {\nif (\ncf != null &&\ncf.containsKey('key') &&\ncf.key != null &&\ncf.key.contains('496e71f2-2bce-47a2-93a8-00db0de2d1b4') &&\ncf.containsKey('value') &&\ncf.value != null\n) {\nemit(cf.value);\nbreak;\n}\n}\n}"  
     }  
   }  
 },  
  "fields": [  
    "TuningDetail",  
    "TuningRequired"  
  ]  
}

Jedes Mal, wenn ein Feld geändert oder ein Kommentar in einem Fall abgegeben wird, wird das Feld updated_at auf die aktuelle Zeit aktualisiert. Da jede Aktualisierung oder jeder Kommentar, der einem Fall hinzugefügt wird, diesen Zeitstempel aktualisiert, ist es möglich, dass ein einzelner Fall von dieser Automatisierung mehrmals zurückgegeben wird, wenn sie regelmäßig ausgeführt wird, während der Fall aktualisiert wird. Alle hierfür eingesetzten Automatisierungsprozesse sollten einen Deduplizierungsprozess beinhalten, um zu verhindern, dass in diesem Szenario derselbe Fall mehrfach verarbeitet wird.

Schritt 2: Analyse jedes einzelnen Falls

Durchlaufe alle Fälle, die von der vorherigen Abfrage zurückgegeben wurden, um sie nacheinander zu verarbeiten. Jedes zurückgegebene Dokument enthält das fields -Array mit den Werten aus den benutzerdefinierten Feldern sowie anderen nützlichen Feldern. Analysieren Sie jedes der folgenden Felder und speichern Sie es zur späteren Verwendung:

• Das Feld _id hat ein Format wie cases:{{case_ID}}. Die Fall-ID wird für zukünftige API-Anfragen in der Automatisierung verwendet, um Kommentare zum Fall hinzuzufügen oder alle dem Fall zugeordneten Benachrichtigungen abzurufen.
• cases.title ist der Titel des Falls
• cases.assignees ist derjenige, dem der Fall zugewiesen wurde
• cases.updated_by ist die Person, die den Fall zuletzt aktualisiert; dies ist oft die Person, die die Tuning-Anfrage einreicht, und kann hilfreich sein, um zu wissen, an wen man sich für weitere Informationen wenden kann.
• cases.tags kann nützlich sein, wenn Sie Tags verwenden, um Ihre Fälle zu sortieren oder zu identifizieren.

Schritt 3: Abrufen der dem Fall zugeordneten Benachrichtigungen

Für jeden Fall sollten Sie wissen, welche Warnmeldungen mit dem Fall verknüpft sind, damit Sie wissen, welche Warnmeldungen angepasst werden müssen. Dies kann mithilfe der Cases-API und dem Feld _id für den Fall erfolgen.

/api/cases/{caseId}/alerts

Diese Abfrage gibt ein Array aller alert id -Werte zurück, die dem Fall zugeordnet sind. Mithilfe dieses ID-Werts können Sie den Elasticsearch-Index .siem-signals* abfragen, um die vollständigen Informationen zu jeder Warnung zu finden, die dem zu optimierenden Fall zugeordnet ist.

POST /.siem-signals-*/_search  
{  
 "size": 1,  
 "query": {  
   "bool": {  
     "must": [],  
     "filter": [  
       {  
         "bool": {  
           "should": [  
             {  
               "match": {  
                 "_id": "{{alert_id}}"  
               }  
             }  
           ],  
           "minimum_should_match": 1  
         }  
       },  
       {  
         "range": {  
           "@timestamp": {  
             "format": "strict_date_optional_time",  
             "gte": "now-30d",  
             "lte": "now"  
           }  
         }  
       }  
     ],  
     "should": [],  
     "must_not": []  
   }  
 }  
}

Aus den Ergebnissen dieser Abfrage können Sie Informationen über die Warnung extrahieren, wie zum Beispiel den Namen und das Erstellungsdatum, sowie alle anderen Informationen, die für die Optimierung hilfreich sein könnten, wie zum Beispiel die Felder user.name oder process.name . Da einem Fall mehrere Warnungen zugeordnet sein können, sollten Sie die Warnungen anhand des Werts signal.rule.name deduplizieren.

Schritt 4: Öffnen einer Tuning-Anfrage.

Dieser Schritt ist abhängig von dem Ticketsystem, das Sie in Ihrer Umgebung verwenden. Unser Team nutzt GitHub-Issues, um Anpassungsanfragen zu verfolgen, und Slack für Benachrichtigungen. Dies könnte aber auch mit jedem anderen Ticket- oder Projektmanagementsystem erfolgen, das Automatisierung unterstützt.

Dies ist der Logikablauf, den wir für unsere Automatisierung verwenden, wobei wir sowohl GitHub als auch Slack nutzen, um Optimierungsanfragen zu verfolgen:

• Anhand des Namens der Warnung suchen wir nach bestehenden offenen Optimierungsanfragen.
  • Falls bereits eine Tuning-Anfrage vorliegt, aktualisieren wir diese mit den Details aus dem Fall und der neuen Anfrage.
  • Falls noch keine Anfrage existiert, erstellen wir eine neue Tuning-Anfrage und fügen die Informationen bei.
• Anschließend senden wir eine Slack-Benachrichtigung an den Slack-Kanal des Detection Engineering Teams. Diese enthält einen Link zur Tuning-Anfrage, einen Link zum Fall sowie Details zur Anfrage und zur Warnung.
• Anschließend verwenden wir die Cases API , um dem ursprünglichen Fall einen Kommentar mit einem Link zum Tuning-Anfrageproblem hinzuzufügen.
• Optionaler KI-Agent: Wir beginnen mit Experimenten zum Einsatz von KI-Agenten, um die Alarm- und Fallinformationen zu analysieren und anschließend einen noch besseren Kontext für die Anpassungsanfrage bereitzustellen. Gegebenenfalls können wir sogar Empfehlungen für die Änderungen der Erkennungsregeln abgeben.

Das Endergebnis dieser Automatisierung ist, dass unsere SOC-Analysten mit einem einzigen Klick aus ihrem Fall heraus ein detailliertes Ticket für die Erkennungsoptimierung erstellen können. Durch diese Automatisierung konnten wir die Anzahl der Fehlalarme deutlich reduzieren und die Effizienz unserer Erkennungsregeln insgesamt erheblich steigern.

Fazit

Durch die Verwendung von Kibana Cases mit benutzerdefinierten Feldern und die Integration mit Automatisierungsplattformen können Sie viele Ihrer manuellen Prozesse optimieren. Dieser automatisierte Workflow reduziert den manuellen Aufwand bei der Erfassung von Analysten-Feedback und gewährleistet so, dass wertvolle Erkenntnisse der Analysten schnell in konkrete Verbesserungen der Erkennungsregeln umgesetzt werden. Das Ergebnis ist ein effizienteres, genaueres und widerstandsfähigeres SOC, das sich schnell an neue Bedrohungen anpassen und die Alarmmüdigkeit reduzieren kann.

Sind Sie bereit, die Effizienz Ihres SOC zu optimieren und Ihre Erkennungsleistung zu verbessern? Entdecken Sie Elastic Security und beginnen Sie noch heute mit der Erstellung Ihrer eigenen automatisierten Tuning-Anforderungs-Workflows!