Изменение содержимого для использования расширенной информационной модели безопасности (ASIM)

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

Вы можете найти нормализованное, нестандартное содержимое в коллекциях Microsoft Sentinel и каталоге решений Microsoft Sentinel, создать собственное нормализованное содержимое или изменить существующее пользовательское содержимое для использования нормализованных данных.

В этой статье объясняется, как преобразовать существующие правила аналитики Microsoft Sentinel для использования нормализованных данных ASIM с расширенной информационной моделью безопасности (ASIM).

Чтобы понять, как нормализованное содержимое вписывается в архитектуру ASIM, см. схему архитектуры ASIM.

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

Чтобы включить нормализацию пользовательского содержимого Microsoft Sentinel, выполните следующие действия:

Пример нормализации для правил аналитики

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

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

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

_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

Нормализованная версия, не зависящая от источника, имеет следующие отличия:

  • Используются парсеры _Im_Dns или imDnsнормализованные парсеры вместо парсера Infoblox.

  • Нормализованные парсеры извлекают только события DNS-запросов, поэтому нет необходимости проверять тип события, как это делается в версии Infoblox с помощью where ProcessName =~ "named" and Log_Type =~ "client".

  • Поле SrcIpAddr используется вместо Client_IP.

  • Фильтрация параметров анализатора используется для параметра ResponseCodeName, что устраняет необходимость в явных условиях where.

Примечание.

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

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

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

Дополнительные сведения о следующих элементах KQL, используемых в примерах нормализации ЗАПРОСОВ DNS, см. в документации Kusto:

Дополнительные сведения о KQL см. в статье Общие сведения о язык запросов Kusto (KQL).

Другие ресурсы

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

Дополнительные сведения см. на следующих ресурсах:

  • Last updated on