Share via

Ändern von Inhalten zur Verwendung des erweiterten Sicherheitsinformationsmodells (ASIM) (Öffentliche Vorschauversion)

  • Artikel

Zu den normalisierten Sicherheitsinhalten in Microsoft Sentinel gehören Analyseregeln, Hunting-Abfragen und Arbeitsmappen, die mit vereinheitlichenden Normalisierungsparsern arbeiten.

Sie finden normalisierte, integrierte Inhalte in Microsoft Sentinel-Katalogen und -Lösungen. Alternativ können Sie Ihre eigenen normalisierten Inhalte erstellen oder bestehende benutzerdefinierte Inhalte ändern, um normalisierte Daten zu verwenden.

In diesem Artikel wird erläutert, wie Sie vorhandene Microsoft Sentinel-Analyseregeln so konvertieren, dass Sie normalisierte Daten mit dem erweiterten Sicherheitsinformationsmodell (ASIM) verwenden.

Informationen dazu, wie normalisierte Inhalte in die ASIM-Architektur passen, finden Sie im Architekturdiagramm zu ASIM.

Tipp

Sehen Sie sich auch das ausführliche Webinar zu normalisierten Parsern und Inhalten in Microsoft Sentinel oder die Folien an. Weitere Informationen finden Sie in den nächsten Schritten.

Wichtig

ASIM befindet sich derzeit in der Vorschauphase. In den zusätzlichen Nutzungsbestimmungen für Microsoft Azure-Vorschauen finden Sie weitere rechtliche Bedingungen, die für Azure-Features gelten, die sich in der Beta- oder Vorschauversion befinden oder anderweitig noch nicht zur allgemeinen Verfügbarkeit freigegeben sind.

Ändern von benutzerdefiniertem Inhalt zur Verwendung der Normalisierung

So aktivieren Sie Ihren benutzerdefinierten Microsoft Sentinel-Inhalt für die Normalisierung:

  • Ändern Sie Ihre Abfragen so, dass alle für die Abfrage relevanten vereinheitlichenden Parser verwendet werden.

  • Ändern Sie die Feldnamen in der Abfrage so, dass die Namen der normalisierten Schemafelder verwendet werden.

  • Ändern Sie ggf. die Bedingungen so, dass die normalisierten Werte der Felder in der Abfrage verwendet werden.

Beispielnormalisierung von Analyseregeln

Als Beispiel dient die DNS-Analyseregel Rare client observed with high reverse DNS lookup count, die auf DNS-Ereignisse angewandt wird, die von Infoblox-DNS-Servern gesendet werden:

let threshold = 200;
InfobloxNIOS
| where ProcessName =~ "named" and Log_Type =~ "client"
| where isnotempty(ResponseCode)
| where ResponseCode =~ "NXDOMAIN"
| summarize count() by Client_IP, bin(TimeGenerated,15m)
| where count_ > threshold
| join kind=inner (InfobloxNIOS
    | where ProcessName =~ "named" and Log_Type =~ "client"
    | where isnotempty(ResponseCode)
    | where ResponseCode =~ "NXDOMAIN"
    ) on Client_IP
| extend timestamp = TimeGenerated, IPCustomEntity = Client_IP

Bei dem folgenden Code handelt es sich um die quellunabhängige Version, bei der durch Normalisierung für jede Quelle, die DNS-Abfrageereignisse enthält, die gleiche Erkennung erfolgt: Im folgenden Beispiel werden integrierte ASIM-Parser verwendet:

_Im_Dns(responsecodename='NXDOMAIN')
| summarize count() by SrcIpAddr, bin(TimeGenerated,15m)
| where count_ > threshold
| join kind=inner (imDns(responsecodename='NXDOMAIN')) on SrcIpAddr
| extend timestamp = TimeGenerated, IPCustomEntity = SrcIpAddr

Ersetzen Sie die erste Zeile durch den folgenden Code, um im Arbeitsbereich bereitgestellte ASIM-Parser zu verwenden:

imDns(responsecodename='NXDOMAIN')

Unterschiede zwischen integrierten und im Arbeitsbereich bereitgestellten Parsern

Die beiden Optionen im obigen Beispiel sind funktional identisch. Die normalisierte, quellenunabhängige Version weist die folgenden Unterschiede auf:

  • Die normalisierten Parser _Im_Dns und imDns werden anstelle des Infoblox-Parsers verwendet.

  • Die normalisierten Parser rufen nur DNS-Abfrageereignisse ab, sodass eine Überprüfung des Ereignistyps, wie sie in der Infoblox-Version über where ProcessName =~ "named" and Log_Type =~ "client" erfolgt, nicht erforderlich ist.

  • Dieses Feld SrcIpAddr wird anstelle von Client_IP verwendet.

  • Die Filterung von Parserparametern wird für ResponseCodeName verwendet, damit keine expliziten where-Klauseln erforderlich sind.

Hinweis

Abgesehen von der Unterstützung normalisierter DNS-Quellen ist die normalisierte Version kürzer und einfacher zu verstehen.

Wenn das Schema oder die Parser keine Filterparameter unterstützen, sind die Änderungen ähnlich, mit der Ausnahme, dass die Filterbedingungen aus der ursprünglichen Abfrage beibehalten werden. Beispiel:

let threshold = 200;
imDns
| where isnotempty(ResponseCodeName)
| where ResponseCodeName =~ "NXDOMAIN"
| summarize count() by SrcIpAddr, bin(TimeGenerated,15m)
| where count_ > threshold
| join kind=inner (imDns
    | where isnotempty(ResponseCodeName)
    | where ResponseCodeName =~ "NXDOMAIN"
    ) on SrcIpAddr
| extend timestamp = TimeGenerated, IPCustomEntity = SrcIpAddr

Nächste Schritte

In diesem Artikel werden die Inhalte für das erweiterte Sicherheitsinformationsmodell (Advanced Security Information Model, ASIM) erläutert.

Weitere Informationen finden Sie unter