Referenz zum Schema für die DNS-Normalisierung des erweiterten Sicherheitsinformationsmodells (Advanced Security Information Model, ASIM) (öffentliche Vorschau)

Das DNS-Informationsmodell dient zur Beschreibung von Ereignissen, die von einem DNS-Server oder einem DNS-Sicherheitssystem gemeldet werden. Es wird von Microsoft Sentinel verwendet, um quellenagnostische Analysen zu ermöglichen.

Weitere Informationen finden Sie unter Normalisierung und das erweiterte Sicherheitsinformationsmodell (ASIM).

Schemaübersicht

Das ASIM-DNS-Schema stellt die DNS-Protokollaktivität dar. Sowohl DNS-Server als auch Geräte, die DNS-Anforderungen an einen DNS-Server senden, protokollieren DNS-Aktivitäten. Die DNS-Protokollaktivität umfasst DNS-Abfragen, DNS-Serverupdates und DNS-Massendatenübertragungen. Da das Schema die Protokollaktivität darstellt, wird es von RFCs und offiziell zugewiesenen Parameterlisten bestimmt, auf die in diesem Artikel gegebenenfalls verwiesen wird. Das DNS-Schema stellt keine DNS-Serverüberwachungsereignisse dar.

Die wichtigste Aktivität, die von DNS-Servern gemeldet wird, ist eine DNS-Abfrage, bei der das Feld EventType auf Query festgelegt ist.

Die wichtigsten Felder eines DNS-Ereignisses sind:

• DnsQuery, das den Domänennamen angibt, für den die Abfrage ausgegeben wurde.

• SrcIpAddr (mit dem Alias IpAddr), das die IP-Adresse darstellt, von der die Anforderung generiert wurde. DNS-Server bieten in der Regel das Feld SrcIpAddr, DNS-Clients bieten dieses Feld jedoch manchmal nicht und bieten nur das Feld SrcHostname.

• EventResultDetails, das angibt, ob die Anforderung erfolgreich war, und falls nicht, warum.

• Falls verfügbar, DnsResponseName, das die Antwort enthält, die vom Server für die Abfrage bereitgestellt wurde. ASIM erfordert keine Analyse der Antwort und das Format variiert je nach Quelle.

  Um dieses Feld in quellenunabhängigen Inhalten zu verwenden, müssen Sie den Inhalt mithilfe der Operatoren has oder contains durchsuchen.

DNS-Ereignisse, die auf dem Clientgerät gesammelt werden, können auch Benutzer- und Prozessinformationen enthalten.

Leitlinien zum Sammeln von DNS-Ereignissen

DNS ist insofern ein besonderes Protokoll, als es sich über eine große Anzahl von Computern erstrecken kann. Da DNS außerdem UDP verwendet, sind Anforderungen und Antworten voneinander entkoppelt und stehen nicht in direktem Zusammenhang.

Die folgende Abbildung zeigt einen vereinfachten DNS-Anforderungsflow, einschließlich vier Segmenten. Eine reale Anforderung kann komplexer sein, sobald mehr Segmente beteiligt sind.

Da Anforderungs- und Antwortsegmente im DNS-Anforderungsflow nicht direkt miteinander verbunden sind, kann die vollständige Protokollierung zu erheblicher Duplizierung führen.

Das wertvollste zu protokollierende Segment ist die Antwort an den Client. Die Antwort enthält die Abfragen des Domänennamens, das Abfrageergebnis und die IP-Adresse des Clients. Zwar protokollieren viele DNS-Systeme nur dieses Segment, aber es ist sinnvoll, auch die anderen Teile zu protokollieren. Ein DNS-Cache-Poisoning-Angriff nutzt beispielsweise häufig gefälschte Antworten von einem vorgelagerten Server aus.

Wenn Ihre Datenquelle die vollständige DNS-Protokollierung unterstützt und Sie sich entschieden haben, mehrere Segmente zu protokollieren, passen Sie Ihre Abfragen an, um in Microsoft Sentinel Datenduplizierung zu vermeiden.

Beispielsweise können Sie Ihre Abfrage mit der folgenden Normalisierung ändern:

_Im_Dns | where SrcIpAddr != "127.0.0.1" and EventSubType == "response"

Parser

Weitere Informationen zu ASIM-Parsern finden Sie in der Übersicht über ASIM-Parser.

Sofort einsatzbereite Parser

Um Parser zu verwenden, die alle sofort einsatzbereiten ASIM-Parser vereinheitlichen, und um sicherzustellen, dass Ihre Analyse über alle konfigurierten Quellen hinweg ausgeführt wird, verwenden Sie den vereinheitlichenden Parser _Im_Dns als Tabellennamen in Ihrer Abfrage.

Die Liste der DNS-Parser, die Microsoft Sentinel einsatzbereit zur Verfügung stellt, finden Sie in der ASIM-Parserliste.

Hinzufügen eigener normalisierter Parser

Wenn Sie benutzerdefinierte Parser für das DNS-Informationsmodell implementieren, verwenden Sie das Format vimDns<vendor><Product> für die Benennung Ihrer KQL-Funktionen. Im Artikel Verwalten von ASIM-Parsern erfahren Sie, wie Sie Ihre benutzerdefinierten Parser dem vereinheitlichenden DNS-Parser hinzufügen.

Filtern von Parser-Parametern

Die DNS-Parser unterstützen Filterparameter. Diese Parser sind optional, können aber die Abfrageleistung verbessern.

Die folgenden Filterparameter sind verfügbar:

Verwenden Sie zum Beispiel Folgendes, um nur DNS-Abfragen vom letzten Tag zu filtern, die den Domänennamen nicht auflösen konnten:

_Im_Dns (responsecodename = 'NXDOMAIN', starttime = ago(1d), endtime=now())

Verwenden Sie Folgendes, um nur DNS-Abfragen nach einer angegebenen Liste von Domänennamen zu filtern:

let torProxies=dynamic(["tor2web.org", "tor2web.com", "torlink.co"]);
_Im_Dns (domain_has_any = torProxies)

Einige Parameter können sowohl eine Liste von Werten des Typs dynamic als auch einen einzelnen Zeichenfolgenwert akzeptieren. Um eine Literalliste an Parameter zu übergeben, die einen dynamischen Wert erwarten, verwenden Sie explizit ein dynamisches Literal. Beispiel: dynamic(['192.168.','10.'])

Normalisierter Inhalt

Eine vollständige Liste der Analyseregeln, die normalisierte DNS-Ereignisse verwenden, finden Sie unter Sicherheitsinhalt von DNS-Abfragen.

Schemadetails

Das DNS-Informationsmodell orientiert sich am OSSEM-DNS-Entitätsschema.

Weitere Informationen finden Sie in der Referenz zu den DNS-Parametern der Internet Assigned Numbers Authority (IANA) .

Allgemeine ASIM-Felder

Allgemeine Felder mit bestimmten Richtlinien

In der folgenden Liste werden Felder erwähnt, die bestimmte Richtlinien für DNS-Ereignisse enthalten:

Alle allgemeinen Felder

Felder, die in der folgenden Tabelle angezeigt werden, sind für alle ASIM-Schemas gleich. Jede oben angegebene Richtlinie setzt die allgemeinen Richtlinien für das Feld außer Kraft. Beispielsweise kann ein Feld im Allgemeinen optional, aber für ein bestimmtes Schema obligatorisch sein. Weitere Informationen zu den einzelnen Feldern finden Sie im Artikel ASIM: Allgemeine Felder.

Felder für „Quellsystem“

Felder für „Quellbenutzer“

Quellprozessfelder

Felder für „Zielsystem“

DNS-spezifische Felder

Inspektionsfelder

Mit den folgenden Feldern wird eine Inspektion dargestellt, die ein DNS-Sicherheitsgerät durchgeführt hat. Die bedrohungsbezogenen Felder stellen eine einzige Bedrohung dar, die entweder der Quelladresse, der Zieladresse, einer der IP-Adressen in der Antwort oder der DNS-Abfragedomäne zugeordnet ist. Wenn mehrere Bedrohungen identifiziert wurden, können Informationen zu anderen IP-Adressen im Feld AdditionalFields gespeichert werden.

Veraltete Aliase und Felder

Die folgenden Felder sind Aliase, die aus Gründen der Abwärtskompatibilität beibehalten werden. Sie wurden am 31. Dezember 2021 aus dem Schema entfernt.

• Query (alias to DnsQuery)
• QueryType (alias to DnsQueryType)
• QueryTypeName (alias to DnsQueryTypeName)
• ResponseName (alias to DnsReasponseName)
• ResponseCodeName (alias to DnsResponseCodeName)
• ResponseCode (alias to DnsResponseCode)
• QueryClass (alias to DnsQueryClass)
• QueryClassName (alias to DnsQueryClassName)
• Flags (alias to DnsFlags)
• SrcUserDomain

Schemaupdates

In der Version 0.1.2 des Schemas wurde Folgendes geändert:

• Das Feld EventSchema wurde hinzugefügt.
• Ein dediziertes Flagfeld wurde hinzugefügt, das das kombinierte Flags-Feld ergänzt: DnsFlagsAuthoritative, DnsFlagsCheckingDisabled, DnsFlagsRecursionAvailable, DnsFlagsRecursionDesired, DnsFlagsTruncated und DnsFlagsZ.

In der Version 0.1.3 des Schemas wurde Folgendes geändert:

• Das Schema dokumentiert jetzt explizit die Felder Src*, Dst*, Process* und User*.
• Es wurden weitere Dvc*-Felder hinzugefügt, die mit der aktuellen Definition allgemeiner Felder übereinstimmen.
• Hinzufügung von Src und Dst als Aliase zu einem führenden Bezeichner für das Quell- und das Zielsystem.
• Hinzufügung der optionalen Aliase DnsNetworkDuration und Duration.
• Hinzufügung der optionalen Felder „Geo Location“ und „Risk Level“.

In der Version 0.1.4 des Schemas wurde Folgendes geändert:

• Die optionalen Felder ThreatIpAddr, ThreatField, ThreatName, ThreatConfidence, ThreatOriginalConfidence, ThreatOriginalRiskLevel, ThreatIsActive, ThreatFirstReportedTime und ThreatLastReportedTime wurden hinzugefügt.

In der Version 0.1.5 des Schemas wurde Folgendes geändert:

• Die Felder SrcUserScope, SrcUserSessionId, SrcDvcScopeId, SrcDvcScope, DstDvcScopeId, DstDvcScope, DvcScopeId und DvcScope wurden hinzugefügt.

In der Version 0.1.6 des Schemas wurde Folgendes geändert:

• Die Felder DnsResponseIpCountry, DnsResponseIpRegion, DnsResponseIpCity, DnsResponseIpLatitude und DnsResponseIpLongitude wurden hinzugefügt.

In der Version 0.1.7 des Schemas wurde Folgendes geändert:

• Die Felder SrcDescription, SrcOriginalRiskLevel, DstDescription, DstOriginalRiskLevel, SrcUserScopeId, NetworkProtocolVersion, Rule, RuleName, RuleNumber und ThreatId wurden hinzugefügt.

Quellspezifische Abweichungen

Ziel der Normalisierung ist es, sicherzustellen, dass alle Quellen konsistente Telemetriedaten bereitstellen. Eine Quelle, die nicht die erforderlichen Telemetriedaten bereitstellt, wie z. B. obligatorische Schemafelder, kann nicht normalisiert werden. Quellen, die in der Regel alle erforderlichen Telemetriedaten bereitstellen, können jedoch normalisiert werden, selbst wenn einige Abweichungen bestehen. Abweichungen können sich auf die Vollständigkeit der Abfrageergebnisse auswirken.

In der folgenden Tabelle sind bekannte Abweichungen aufgeführt:

Behandeln der DNS-Antwort

In den meisten Fällen enthalten die protokollierten DNS-Ereignisse keine Antwortinformationen, die umfangreich und detailliert sein können. Wenn Ihr Datensatz weitere Antwortinformationen enthält, speichern Sie diese im Feld ResponseName, so wie sie im Datensatz angezeigt werden.

Sie können auch eine zusätzliche KQL-Funktion mit dem Namen _imDNS<vendor>Response_ bereitstellen, die die nicht analysierte Antwort als Eingabe verwendet und einen dynamischen Wert mit der folgenden Struktur zurückgibt:

[
    {
        "part": "answer"
        "query": "yahoo.com."
        "TTL": 1782
        "Class": "IN"
        "Type": "A"
        "Response": "74.6.231.21"
    }
    {
        "part": "authority"
        "query": "yahoo.com."
        "TTL": 113066
        "Class": "IN"
        "Type": "NS"
        "Response": "ns5.yahoo.com"
    }
    ...
]

Die Felder in den einzelnen Wörterbüchern im dynamischen Wert entsprechen den Feldern in jeder DNS-Antwort. Der Eintrag part sollte entweder answer, authority oder additional enthalten, um den Teil der Antwort wiederzugeben, zu dem das Wörterbuch gehört.

Behandeln von DNS-Flags

Analyse und Normalisierung sind für Flagdaten nicht erforderlich. Speichern Sie stattdessen die vom meldenden Gerät bereitgestellten Flagdaten im Feld Flags. Wenn die Bestimmung des Wertes einzelner Flags unkompliziert ist, können Sie auch die dedizierten Flag-Felder verwenden.

Sie können auch eine zusätzliche KQL-Funktion namens _imDNS<vendor>Flags_ bereitstellen, die die nicht analysierte Antwort oder dedizierten Flag-Felder als Eingabe annimmt und eine dynamische Liste mit booleschen Werten zurückgibt, die jedes Flag in der folgenden Reihenfolge repräsentieren:

• Authentifiziert (AD)
• Autoritativ (AA)
• Überprüfung deaktiviert (CD)
• Rekursion verfügbar (RA)
• Rekursion gewünscht (RD)
• Abgeschnitten (TC)
• Z

Nächste Schritte

Weitere Informationen finden Sie unter

• Sehen Sie sich das ASIM-Webinar an, oder befassen Sie sich mit den Folien.
• Übersicht über das erweiterte Sicherheitsinformationsmodell (Advanced Security Information Model, ASIM)
• Schemas für das erweiterte Sicherheitsinformationsmodell (Advanced Security Information Model, ASIM)
• Parser für das erweiterte Sicherheitsinformationsmodell (Advanced Security Information Model, ASIM)
• Inhalte für das erweiterte Sicherheitsinformationsmodell (Advanced Security Information Model, ASIM)