Справочник по схеме нормализации DNS с расширенной информационной безопасностью (ASIM)

Информационная модель DNS используется для описания событий, сообщаемых DNS-сервером или системой безопасности DNS, и используется Microsoft Sentinel для включения аналитики, не зависящей от источника.

Дополнительные сведения см. в разделе Нормализация и расширенная информационная модель безопасности (ASIM).

Обзор схемы

Схема DNS ASIM представляет действие протокола DNS. Как DNS-серверы, так и устройства, отправляющие DNS-запросы на DNS-сервер, регистрируют действия DNS. Действие протокола DNS включает запросы DNS, обновления DNS-сервера и массовую передачу данных DNS. Так как схема представляет действие протокола, она регулируется RFC и официально назначенными списками параметров, на которые ссылаются в этой статье при необходимости. Схема DNS не представляет события аудита DNS-сервера.

Наиболее важным действием, о котором сообщают DNS-серверы, является ЗАПРОС DNS, для которого EventType поле имеет значение Query.

Наиболее важные поля в событии DNS:

• DnsQuery, который сообщает доменное имя, для которого был выдан запрос.

• SrcIpAddr (псевдоним IpAddr), представляющий IP-адрес, с которого был создан запрос. DNS-серверы обычно предоставляют поле SrcIpAddr, но DNS-клиенты иногда не предоставляют это поле и предоставляют только поле SrcHostname .

• EventResultDetails, который сообщает, был ли запрос успешным, а если нет, то почему.

• Если доступно, DnsResponseName, который содержит ответ, предоставленный сервером для запроса. ASIM не требует синтаксического анализа ответа, и его формат зависит от источника.

  Чтобы использовать это поле в содержимом, не зависящем от источника, выполните поиск в содержимом с помощью has операторов или contains .

События DNS, собираемые на клиентском устройстве, также могут содержать сведения о пользователе и процессе .

Рекомендации по сбору событий DNS

DNS — это уникальный протокол, который может пересекать большое количество компьютеров. Кроме того, так как DNS использует UDP, запросы и ответы не связаны друг с другом напрямую.

На следующем рисунке показан упрощенный поток запросов DNS, включающий четыре сегмента. Реальный запрос может быть более сложным, с большим числом сегментов.

Так как сегменты запросов и ответов не связаны друг с другом напрямую в потоке запросов DNS, полное ведение журнала может привести к значительному дублированию.

Наиболее ценным сегментом для ведения журнала является ответ клиенту. Ответ предоставляет запросы доменного имени, результат поиска и IP-адрес клиента. Хотя многие системы DNS регистрируют только этот сегмент, в журнале других частей есть значение. Например, атака с отравлением кэша DNS часто использует поддельные ответы от вышестоящий сервера.

Если источник данных поддерживает полное ведение журнала DNS и вы решили записать несколько сегментов, настройте запросы, чтобы предотвратить дублирование данных в Microsoft Sentinel.

Например, можно изменить запрос со следующей нормализацией:

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

Парсеров

Дополнительные сведения о средствах синтаксического анализа ASIM см. в обзоре средства синтаксического анализа ASIM.

Встроенные средства синтаксического анализа

Чтобы использовать средства синтаксического анализа, которые унифицировывают все встроенные средства синтаксического анализа ASIM и обеспечивают выполнение анализа во всех настроенных источниках, используйте унифицированный синтаксический анализатор _Im_Dns в качестве имени таблицы в запросе.

Список средств синтаксического анализа DNS, Microsoft Sentinel предоставляет встроенные средства синтаксического анализа, см. в списке средств синтаксического анализа ASIM.

Добавление собственных нормализованных анализаторов

При реализации пользовательских средств синтаксического анализа для информационной модели Dns назовите свои функции KQL в формате vimDns<vendor><Product>. Сведения о том, как добавить пользовательские средства синтаксического анализа в средство синтаксического анализа DNS, см. в статье Управление средствами синтаксического анализа ASIM .

Фильтрация параметров средства синтаксического анализа

Средства синтаксического анализа DNS поддерживают параметры фильтрации. Хотя эти параметры являются необязательными, они могут повысить производительность запроса.

Доступны следующие параметры фильтрации:

Например, чтобы отфильтровать только DNS-запросы за последний день, в который не удалось разрешить доменное имя, используйте:

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

Чтобы отфильтровать только DNS-запросы по указанному списку доменных имен, используйте:

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

Некоторые параметры могут принимать как список значений типа dynamic , так и одно строковое значение. Чтобы передать литерал списка параметрам, которые ожидают динамическое значение, явно используйте динамический литерал. Пример: dynamic(['192.168.','10.'])

Нормализованное содержимое

Полный список правил аналитики, использующих нормализованные события DNS, см. в разделе Содержимое безопасности DNS-запросов.

Сведения о схеме

Информационная модель DNS согласована со схемой сущности DNS OSSEM.

Дополнительные сведения см. в справочнике по параметру DNS IANA.

Общие поля ASIM

Общие поля с определенными рекомендациями

В следующем списке упоминаются поля с определенными рекомендациями по событиям DNS:

Все общие поля

Поля, отображаемые в таблице ниже, являются общими для всех схем ASIM. Любое указанное выше руководство переопределяет общие рекомендации для поля. Например, поле может быть необязательным в целом, но обязательным для конкретной схемы. Дополнительные сведения о каждом поле см. в статье Общие поля ASIM .

Поля исходной системы

Поля исходного пользователя

Поля исходного процесса

Поля системы назначения

Поля, относящиеся к DNS

Поля проверки

Следующие поля используются для представления проверки, выполненной устройством безопасности DNS. Поля, связанные с угрозами, представляют собой одну угрозу, связанную либо с исходным адресом, адресом назначения, одним из IP-адресов в ответе или доменом ЗАПРОСА DNS. Если в качестве угрозы было определено несколько угроз, сведения о других IP-адресах могут храниться в поле AdditionalFields.

Устаревшие псевдонимы и поля

Следующие поля представляют собой псевдонимы, которые поддерживаются для обеспечения обратной совместимости. Они были удалены из схемы 31 декабря 2021 г.

• Query (псевдоним для DnsQuery)
• QueryType (псевдоним для DnsQueryType)
• QueryTypeName (псевдоним для DnsQueryTypeName)
• ResponseName (псевдоним для DnsResponseName)
• ResponseCodeName (псевдоним для DnsResponseCodeName)
• ResponseCode (псевдоним для DnsResponseCode)
• QueryClass (псевдоним для DnsQueryClass)
• QueryClassName (псевдоним для DnsQueryClassName)
• Flags (псевдоним для DnsFlags)
• SrcUserDomain

Обновления схемы

Изменения в схеме версии 0.1.2:

• Добавлено поле EventSchema.
• Добавлено выделенное поле флага, которое дополняет объединенное поле Флаги: DnsFlagsAuthoritative, DnsFlagsCheckingDisabled, DnsFlagsRecursionAvailable, DnsFlagsRecursionDesiredDnsFlagsTruncated, и DnsFlagsZ.

Изменения в схеме версии 0.1.3:

• Теперь схема явно документирует Src*поля , Dst*и Process*User* .
• Добавлены дополнительные Dvc* поля в соответствии с последним определением общих полей.
• Добавлены Src и Dst в качестве псевдонимов для ведущего идентификатора для исходной и целевой систем.
• Добавлены необязательный DnsNetworkDuration и Duration, псевдоним.
• Добавлены необязательные поля Географическое расположение и Уровень риска.

Изменения в схеме версии 0.1.4:

• Добавлены необязательные поля ThreatIpAddr, ThreatField, ThreatName, ThreatConfidence, ThreatOriginalConfidence, ThreatOriginalRiskLevel, ThreatIsActive, ThreatFirstReportedTimeи ThreatLastReportedTime.

Ниже перечислены изменения в схеме версии 0.1.5.

• Добавлены поля , , , , , DstDvcScopeId, DstDvcScope, DvcScopeIdи DvcScope. SrcDvcScopeSrcDvcScopeIdSrcUserSessionIdSrcUserScope

Изменения в схеме версии 0.1.6:

• Добавлены поля DnsResponseIpCountry, DnsResponseIpRegion, DnsResponseIpCity, DnsResponseIpLatitudeи DnsResponseIpLongitude.

Изменения в схеме версии 0.1.7:

• Добавлены поля SrcDescription, , SrcOriginalRiskLevelDstDescription, DstOriginalRiskLevel, , SrcUserScopeId, , NetworkProtocolVersion, Rule, RuleName, RuleNumberи ThreatId.

Расхождения в источнике

Целью нормализации является обеспечение согласованности данных телеметрии во всех источниках. Источник, не предоставляющий необходимые данные телеметрии, например обязательные поля схемы, не может быть нормализован. Однако источники, которые обычно предоставляют все необходимые данные телеметрии, даже если есть некоторые расхождения, можно нормализовать. Несоответствия могут повлиять на полноту результатов запроса.

В следующей таблице перечислены известные расхождения.

Обработка ответа DNS

В большинстве случаев зарегистрированные события DNS не включают в себя сведения об ответе, которые могут быть большими и подробными. Если запись содержит дополнительные сведения об ответе, сохраните ее в поле ResponseName , как оно отображается в записи.

Можно также предоставить дополнительную функцию KQL с именем _imDNS<vendor>Response_, которая принимает непараный ответ в качестве входных данных и возвращает динамическое значение со следующей структурой:

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

Поля в каждом словаре в динамическом значении соответствуют полям в каждом ответе DNS. Запись part должна включать answer, authorityили additional , чтобы отразить часть в ответе, к которому принадлежит словарь.

Обработка флагов DNS

Для данных флага не требуется синтаксический анализ и нормализация. Вместо этого сохраните данные флагов, предоставляемые устройством отчетов, в поле Флаги . Если определить значение отдельных флагов можно напрямую, можно также использовать выделенные поля флагов.

Можно также предоставить дополнительную функцию KQL с именем _imDNS<vendor>Flags_, которая принимает в качестве входных данных необследованный ответ или выделенные поля флагов и возвращает динамический список с логическими значениями, представляющими каждый флаг в следующем порядке.

• Проверка подлинности (AD)
• Полномочный (AA)
• Проверка отключена (CD)
• Рекурсия доступна (RA)
• Рекурсия требуется (RD)
• Усечение (TC)
• Z

Связанные материалы

• Обзор расширенной информационной модели безопасности (ASIM)
• Схемы расширенной информационной модели безопасности (ASIM)
• Средства синтаксического анализа расширенной информационной модели безопасности (ASIM)
• Содержимое расширенной информационной модели безопасности (ASIM)
• Вебинар Azure Sentinel. Нормализация Model-Understanding информации в Azure Sentinel