Naslaginformatie over het DNS-normalisatieschema advanced security information model (ASIM)

Het DNS-informatiemodel wordt gebruikt om gebeurtenissen te beschrijven die zijn gerapporteerd door een DNS-server of een DNS-beveiligingssysteem en wordt gebruikt door Microsoft Sentinel om bronagnostische analyses in te schakelen.

Zie Normalisatie en het Advanced Security Information Model (ASIM) voor meer informatie.

Schemaoverzicht

Het ASIM DNS-schema vertegenwoordigt de ACTIVITEIT van het DNS-protocol. Zowel DNS-servers als apparaten die DNS-aanvragen naar een DNS-server verzenden, registreren DNS-activiteit. De DNS-protocolactiviteit omvat DNS-query's, DNS-serverupdates en DNS-bulkgegevensoverdrachten. Omdat het schema protocolactiviteit vertegenwoordigt, wordt het beheerd door RFC's en officieel toegewezen parameterlijsten, waarnaar in dit artikel wordt verwezen indien van toepassing. Het DNS-schema vertegenwoordigt geen dns-servercontrolegebeurtenissen.

De belangrijkste activiteit die door DNS-servers wordt gerapporteerd, is een DNS-query, waarvoor het EventType veld is ingesteld op Query.

De belangrijkste velden in een DNS-gebeurtenis zijn:

• DnsQuery, dat de domeinnaam rapporteert waarvoor de query is uitgegeven.

• De SrcIpAddr (alias naar IpAddr), die het IP-adres vertegenwoordigt van waaruit de aanvraag is gegenereerd. DNS-servers bieden doorgaans het veld SrcIpAddr, maar DNS-clients bieden dit veld soms niet en alleen het veld SrcHostname .

• EventResultDetails, waarin wordt gerapporteerd of de aanvraag is geslaagd en zo niet, waarom.

• Indien beschikbaar, DnsResponseName, die het antwoord bevat dat door de server aan de query is verstrekt. Voor ASIM hoeft het antwoord niet te worden geparseerd en de indeling verschilt per bron.

  Als u dit veld wilt gebruiken in bron-agnostische inhoud, zoekt u de inhoud met de has operatoren of contains .

DNS-gebeurtenissen die op clientapparaten worden verzameld, kunnen ook gebruikers- en procesgegevens bevatten.

Richtlijnen voor het verzamelen van DNS-gebeurtenissen

DNS is een uniek protocol omdat het een groot aantal computers kan kruisen. Aangezien DNS gebruikmaakt van UDP, worden aanvragen en antwoorden ontkoppeld en zijn ze niet rechtstreeks aan elkaar gerelateerd.

In de volgende afbeelding ziet u een vereenvoudigde DNS-aanvraagstroom, met inbegrip van vier segmenten. Een aanvraag in de praktijk kan complexer zijn, waarbij meer segmenten betrokken zijn.

Omdat aanvraag- en antwoordsegmenten niet rechtstreeks met elkaar zijn verbonden in de DNS-aanvraagstroom, kan volledige logboekregistratie leiden tot aanzienlijke duplicatie.

Het meest waardevolle segment om te registreren is het antwoord op de client. Het antwoord bevat de domeinnaamquery's, het zoekresultaat en het IP-adres van de client. Hoewel veel DNS-systemen alleen dit segment registreren, zit er waarde in het vastleggen van de andere onderdelen. Een DNS-cache-vergiftigingsaanval maakt bijvoorbeeld vaak gebruik van valse reacties van een upstream-server.

Als uw gegevensbron volledige DNS-logboekregistratie ondersteunt en u ervoor hebt gekozen om meerdere segmenten te registreren, past u uw query's aan om gegevensduplicatie in Microsoft Sentinel te voorkomen.

U kunt bijvoorbeeld uw query wijzigen met de volgende normalisatie:

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

Parsers

Zie het overzicht van ASIM-parsers voor meer informatie over ASIM-parsers.

Out-of-the-box parsers

Als u parsers wilt gebruiken waarmee alle out-of-the-box ASIM-parsers worden samengevoegd en ervoor wilt zorgen dat uw analyse wordt uitgevoerd in alle geconfigureerde bronnen, gebruikt u de samenvoegingsparseer _Im_Dns als de tabelnaam in uw query.

Raadpleeg de lijst met ASIM-parsers voor de lijst met dns-parsers Microsoft Sentinel out-of-the-box biedt.

Uw eigen genormaliseerde parsers toevoegen

Bij het implementeren van aangepaste parsers voor het Dns-informatiemodel geeft u de KQL-functies een naam met behulp van de indeling vimDns<vendor><Product>. Raadpleeg het artikel ASIM-parsers beheren voor meer informatie over het toevoegen van uw aangepaste parsers aan de DNS-unifying-parser.

Parameters voor filteren van parser

De DNS-parsers ondersteunen filterparameters. Hoewel deze parameters optioneel zijn, kunnen ze uw queryprestaties verbeteren.

De volgende filterparameters zijn beschikbaar:

Als u bijvoorbeeld alleen DNS-query's wilt filteren van de laatste dag waarvoor de domeinnaam niet is omgezet, gebruikt u:

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

Als u alleen DNS-query's wilt filteren voor een opgegeven lijst met domeinnamen, gebruikt u:

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

Sommige parameters kunnen zowel een lijst met waarden van het type dynamic als één tekenreekswaarde accepteren. Als u een letterlijke lijst wilt doorgeven aan parameters die een dynamische waarde verwachten, gebruikt u expliciet een dynamische letterlijke waarde. Bijvoorbeeld:dynamic(['192.168.','10.'])

Genormaliseerde inhoud

Zie Beveiligingsinhoud van DNS-query's voor een volledige lijst met analyseregels die gebruikmaken van genormaliseerde DNS-gebeurtenissen.

Schemadetails

Het DNS-informatiemodel is afgestemd op het OSSEM DNS-entiteitsschema.

Zie de IANA-parameterreferentie (Internet Assigned Numbers Authority) voor meer informatie.

Algemene ASIM-velden

Algemene velden met specifieke richtlijnen

In de volgende lijst worden velden vermeld met specifieke richtlijnen voor DNS-gebeurtenissen:

Alle algemene velden

Velden die in de onderstaande tabel worden weergegeven, zijn gemeenschappelijk voor alle ASIM-schema's. Elke hierboven opgegeven richtlijn overschrijft de algemene richtlijnen voor het veld. Een veld kan bijvoorbeeld in het algemeen optioneel zijn, maar verplicht voor een specifiek schema. Zie het artikel Algemene ASIM-velden voor meer informatie over elk veld.

Bronsysteemvelden

Brongebruikersvelden

Bronprocesvelden

Doelsysteemvelden

DNS-specifieke velden

Inspectievelden

De volgende velden worden gebruikt om een inspectie aan te geven die door een DNS-beveiligingsapparaat wordt uitgevoerd. De velden met betrekking tot bedreigingen vertegenwoordigen één bedreiging die is gekoppeld aan het bronadres, het doeladres, een van de IP-adressen in het antwoord of het DNS-querydomein. Als meer dan één bedreiging is geïdentificeerd als een bedreiging, kan informatie over andere IP-adressen worden opgeslagen in het veld AdditionalFields.

Afgeschafte aliassen en velden

De volgende velden zijn aliassen die worden onderhouden voor achterwaartse compatibiliteit. Ze zijn op 31 december 2021 uit het schema verwijderd.

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

Schema-updates

De wijzigingen in versie 0.1.2 van het schema zijn:

• Het veld EventSchemais toegevoegd.
• Toegewezen vlagveld toegevoegd, waarmee het gecombineerde veld Vlaggen wordt vergroot: DnsFlagsAuthoritative, DnsFlagsCheckingDisabled, DnsFlagsRecursionAvailable, DnsFlagsRecursionDesired, DnsFlagsTruncated, en DnsFlagsZ.

De wijzigingen in versie 0.1.3 van het schema zijn:

• Het schema bevat nu expliciet de Src*velden , Dst*en User*Process*.
• Er zijn meer Dvc* velden toegevoegd die overeenkomen met de meest recente algemene velddefinitie.
• Dst En Src toegevoegd als aliassen aan een voorloop-id voor de bron- en doelsystemen.
• Optioneel DnsNetworkDuration en Durationtoegevoegd, een alias.
• Optionele velden Geo-locatie en Risiconiveau toegevoegd.

De wijzigingen in versie 0.1.4 van het schema zijn:

• De optionele velden ThreatIpAddr, ThreatField, ThreatName, ThreatConfidence, ThreatOriginalConfidence, ThreatOriginalRiskLevel, , ThreatIsActive, ThreatFirstReportedTime, en ThreatLastReportedTime.

De wijzigingen in versie 0.1.5 van het schema zijn:

• De velden , , , , , DstDvcScopeId, DstDvcScope, , DvcScopeIden DvcScope. SrcDvcScopeSrcDvcScopeIdSrcUserSessionIdSrcUserScope

De wijzigingen in versie 0.1.6 van het schema zijn:

• De velden DnsResponseIpCountry, DnsResponseIpRegion, DnsResponseIpCity, DnsResponseIpLatitudeen DnsResponseIpLongitude.

De wijzigingen in versie 0.1.7 van het schema zijn:

• De velden SrcDescription, , , DstDescription, DstOriginalRiskLevelSrcUserScopeId, , NetworkProtocolVersion, Rule, RuleName, , RuleNumber, en ThreatId. SrcOriginalRiskLevel

Bronspecifieke discrepanties

Het doel van normalisatie is om ervoor te zorgen dat alle bronnen consistente telemetrie bieden. Een bron die niet de vereiste telemetrie biedt, zoals verplichte schemavelden, kan niet worden genormaliseerd. Bronnen die doorgaans alle vereiste telemetrie bieden, zelfs als er enkele discrepanties zijn, kunnen echter worden genormaliseerd. Discrepanties kunnen van invloed zijn op de volledigheid van queryresultaten.

De volgende tabel bevat bekende discrepanties:

DNS-antwoord verwerken

In de meeste gevallen bevatten geregistreerde DNS-gebeurtenissen geen antwoordinformatie, die groot en gedetailleerd kan zijn. Als uw record meer antwoordgegevens bevat, slaat u deze op in het veld ResponseName zoals deze wordt weergegeven in de record.

U kunt ook een extra KQL-functie opgeven met de naam _imDNS<vendor>Response_, die het niet-geparseerde antwoord als invoer neemt en dynamische waarde retourneert met de volgende structuur:

[
    {
        "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"
    }
    ...
]

De velden in elke woordenlijst in de dynamische waarde komen overeen met de velden in elk DNS-antwoord. De part vermelding moet , answerauthorityof additional bevatten om het deel in het antwoord weer te geven waartoe de woordenlijst behoort.

DNS-vlaggen verwerken

Parseren en normaliseren is niet vereist voor vlaggegevens. Sla in plaats daarvan de vlaggegevens van het rapportageapparaat op in het veld Vlaggen . Als het bepalen van de waarde van afzonderlijke vlaggen eenvoudig is, kunt u ook de velden voor toegewezen vlaggen gebruiken.

U kunt ook een extra KQL-functie opgeven met de naam _imDNS<vendor>Flags_, die het niet-geparseerde antwoord of toegewezen vlagvelden als invoer gebruikt en een dynamische lijst retourneert, met booleaanse waarden die elke vlag in de volgende volgorde vertegenwoordigen:

• Geverifieerd (AD)
• Gezaghebbend (AA)
• Uitgeschakeld (CD) controleren
• Recursie beschikbaar (RA)
• Recursie Desired (RD)
• Afgekapt (TC)
• Z

Volgende stappen

Zie voor meer informatie:

• Bekijk de ASIM-webinar of bekijk de dia's
• Overzicht van Advanced Security Information Model (ASIM)
• ASIM-schema's (Advanced Security Information Model)
• ASIM-parsers (Advanced Security Information Model)
• ASIM-inhoud (Advanced Security Information Model)