Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Анализ времени запроса
Как обсуждалось в обзоре ASIM, Microsoft Sentinel использует как время запроса, так и нормализацию на этапе приема, чтобы воспользоваться преимуществами каждого из них.
Чтобы использовать нормализацию времени запроса, используйте унифицирующие анализаторы времени запроса, например _Im_Dns в запросах. Нормализация с помощью синтаксического анализа времени запроса имеет несколько преимуществ:
- Сохранение исходного формата: нормализация времени запроса не требует изменения данных, таким образом сохраняя исходный формат данных, отправленный источником.
- Избежание потенциального дублирования данных: так как нормализованные данные являются лишь представлением исходных данных, нет необходимости хранить и оригинальные, и нормализованные данные.
- Упрощенная разработка. Так как средства синтаксического анализа времени запроса представляют представление данных и не изменяют данные, они легко разрабатывать. Разработку, тестирование и исправление парсера можно выполнять на существующих данных. Кроме того, средства синтаксического анализа можно исправить при обнаружении проблемы, а исправление применяется к существующим данным.
Анализ времени приема
Хотя средства синтаксического анализа времени запросов ASIM оптимизированы, синтаксический анализ времени запроса может замедлить запросы, особенно в больших наборах данных.
Анализ данных на этапе приема позволяет преобразовывать события в нормализованную схему по мере их поступления в Microsoft Sentinel и хранения в нормализованном формате. Анализ времени приема менее гибкий и синтаксический анализ сложнее разрабатывать, но так как данные хранятся в нормализованном формате, обеспечивают более высокую производительность.
Нормализованные данные можно хранить в собственных нормализованных таблицах Microsoft Sentinel или в пользовательской таблице, использующей схему ASIM. Пользовательская таблица со схемой, почти идентичной схеме ASIM, также обеспечивает преимущества нормализации времени загрузки.
В настоящее время ASIM поддерживает следующие собственные нормализованные таблицы в качестве целевого назначения для нормализации времени загрузки:
- ASimAuditEventLogs для схемы события аудита.
- ASimAuthenticationEventLogs для схемы проверки подлинности .
- ASimDhcpEventLogs для схемы DHCP Event.
- ASimDnsActivityLogs для схемы DNS .
- ASimFileEventLogs для схемы Файлового события.
- ASimNetworkSessionLogs для схемы сетевого сеанса .
- ASimProcessEventLogs для схемы события процесса .
- ASimRegistryEventLogs для схемы событий реестра .
- ASimUserManagementActivityLogs для схемы управления пользователями .
- ASimWebSessionLogs для схемы веб-сеанса.
Преимущество собственных нормализованных таблиц заключается в том, что они включены по умолчанию в средства синтаксического анализа ASIM. Пользовательские нормализованные таблицы можно включить в унифицированные средства синтаксического анализа, как описано в разделе "Управление синтаксического анализа".
Объединение нормализации времени поступления и времени запроса
Запросы всегда должны использовать унифицирующие парсеры времени запроса, такие как _Im_Dns, чтобы воспользоваться как нормализацией во время запроса, так и во время приема. Встроенные нормализованные таблицы включаются в запрашиваемые данные с помощью парсера-заглушки.
Парсер заглушек — это парсер, который используется во время выполнения запроса и принимает в качестве входных данных нормализованную таблицу. Так как нормализованная таблица не требует синтаксического анализа, синтаксический анализатор-заглушка эффективен.
Анализатор заглушки отображает результат вызова запроса, который добавляет данные в собственную таблицу ASIM.
- Псевдонимы — чтобы не тратить место в хранилище на повторяющиеся значения, псевдонимы не хранятся в собственных таблицах ASIM и добавляются при выполнении запроса с помощью парсеров заглушек.
- Константные значения — как и псевдонимы, и по той же причине нормализованные таблицы ASIM не хранят постоянные значения, например, EventSchema. Парсер заглушек добавляет эти поля. Нормализованная таблица ASIM используется многими источниками, а средства синтаксического анализа данных на этапе приема могут изменить выходную версию. Таким образом, такие поля, как EventProduct, EventVendor и EventSchemaVersion, не являются константами и не добавляются анализатором заглушки.
- Фильтрация — парсер заглушек также реализует фильтрацию. Хотя собственные таблицы ASIM не требуют средства анализа фильтрации для повышения производительности, фильтрация необходима для поддержки включения в унифицированный синтаксический анализатор.
- Обновления и исправления - Использование анализатора заглушки позволяет быстрее устранять проблемы. Например, если данные были загружены неправильно, IP-адрес может не быть извлечен из поля сообщения во время обработки. IP-адрес можно извлечь с помощью анализатора заглушки во время выполнения запроса.
При использовании пользовательских нормализованных таблиц создайте собственный анализатор заглушки для реализации этой функции и добавьте его в унифицированные синтаксические анализаторы, как описано в разделе «Управление анализаторами». Используйте средство анализа заглушки для нативной таблицы, например средство анализа заглушки для нативной таблицы DNS и его аналог фильтрации, в качестве отправной точки. Если ваша таблица полунормализована, используйте парсер-заглушку для выполнения дополнительного анализа и нормализации.
Дополнительные сведения о написании синтаксического анализа см. в разделе "Разработка синтаксического анализа ASIM".
Реализация нормализации времени приема
Чтобы нормализовать данные при приеме, необходимо использовать правило сбора данных (DCR). Процедура реализации DCR зависит от метода, используемого для приема данных. Дополнительные сведения см. в статье «Преобразование или настройка данных на этапе загрузки в Microsoft Sentinel».
Запрос преобразования KQL является ядром DCR. Версия KQL, используемая в правилах сбора данных (DCR), немного отличается от версии, используемой в других частях Microsoft Sentinel, чтобы удовлетворить требования к обработке событий в конвейере. Поэтому необходимо изменить любой парсер, используемый во время запроса, чтобы использовать его в DCR. Для получения дополнительной информации о различиях и о том, как преобразовать парсер времени запроса в парсер времени приема, прочитайте о ограничениях KQL DCR.
Дальнейшие действия
Дополнительные сведения см. в разделе: