Поделиться через


Планы хранения журналов в Microsoft Sentinel

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

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

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

Внимание

Тип журнала вспомогательных журналов в настоящее время находится в предварительной версии. Дополнительные юридические условия, применимые к функциям Azure, которые предоставляются в бета-версии, предварительной версии или еще не выпущены в общедоступной версии по другим причинам, см. на странице Дополнительные условия использования Azure для предварительных версий в Microsoft Azure.

Microsoft Sentinel общедоступен в единой платформе операций безопасности Майкрософт на портале Microsoft Defender. Для предварительной версии Microsoft Sentinel доступен на портале Defender без XDR Microsoft Defender или лицензии E5. Дополнительные сведения см . на портале Microsoft Defender в Microsoft Sentinel.

Категории приема данных

Корпорация Майкрософт рекомендует классифицировать данные в Microsoft Sentinel на две общие категории:

  • Основные данные безопасности — это данные , содержащие критическое значение безопасности. Эти данные используются для упреждающего мониторинга в режиме реального времени, запланированных оповещений и аналитики для обнаружения угроз безопасности. Данные должны быть легко доступны для всех интерфейсов Microsoft Sentinel в практически реальном времени.

  • Вторичные данные безопасности — это дополнительные данные , часто в больших объемах, подробные журналы. Эти данные имеют ограниченный уровень безопасности, но он может обеспечить дополнительную богатство и контекст для обнаружения и расследований, помогая получить полное представление об инциденте безопасности. Он не должен быть легкодоступен, но должен быть доступен по требованию по мере необходимости и в соответствующих дозах.

Основные данные безопасности

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

  • Частый мониторинг. Правила обнаружения угроз (аналитики) выполняются в этих данных с частыми интервалами или практически в режиме реального времени.

  • Охота по запросу. Сложные запросы выполняются на этих данных для выполнения интерактивной, высокопроизводительной охоты на угрозы безопасности.

  • Корреляция. Данные из этих источников коррелируются с данными из других основных источников данных безопасности для обнаружения угроз и создания историй атак.

  • Регулярные отчеты. Данные из этих источников легко доступны для компиляции в регулярные отчеты о работоспособности безопасности организации как для лиц, принимающих решения, так и для обеспечения безопасности и общих решений.

  • Аналитика поведения. Данные из этих источников используются для создания профилей поведения базовых показателей для пользователей и устройств, что позволяет выявлять неустраиваемое поведение как подозрительное.

Некоторые примеры основных источников данных включают журналы из антивирусных или корпоративных систем обнаружения и реагирования (EDR), журналов проверки подлинности, следов аудита с облачных платформ, веб-каналов аналитики угроз и оповещений из внешних систем.

Журналы, содержащие основные данные безопасности, должны храниться с помощью плана журналов Аналитики , описанного далее в этой статье.

Вторичные данные безопасности

Эта категория охватывает журналы, отдельные значения безопасности которых ограничены, но являются важными для предоставления комплексного представления инцидента безопасности или нарушения безопасности. Как правило, эти журналы являются большим объемом и могут быть подробными. Ниже приведены варианты использования операций безопасности для этих данных:

  • Threat Intelligence. Основные данные можно проверить на наличие списков индикаторов компрометации (IoC) или индикаторов атак (IoA), чтобы быстро и легко обнаруживать угрозы.

  • Нерегламентированная охота и расследования. Данные можно запрашивать в интерактивном режиме в течение 30 дней, упрощая важный анализ для поиска угроз и расследований.

  • Крупномасштабные поиски. Данные можно получать и искать в фоновом режиме при масштабировании петабайтов, а храниться эффективно с минимальным объемом обработки.

  • Сводка с помощью правил сводки. Суммирование журналов больших объемов в статистические сведения и хранение результатов в качестве основных данных безопасности. Дополнительные сведения о сводных правилах см. в разделе "Агрегированные данные Microsoft Sentinel" с помощью правил сводки.

Примерами источников дополнительных журналов данных являются журналы доступа к облачному хранилищу, журналы NetFlow, журналы TLS/SSL-сертификатов, журналы брандмауэра, журналы прокси-сервера и журналы Интернета вещей. Дополнительные сведения о том, как каждый из этих источников приносит ценность для обнаружения безопасности, не требуя времени, см. в статье "Источники журналов" для приема вспомогательных журналов.

Журналы, содержащие вторичные данные безопасности, должны храниться с помощью плана вспомогательных журналов (теперь в предварительной версии), описанного далее в этой статье.

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

Планы управления журналами

Microsoft Sentinel предоставляет два различных плана хранения журналов или типы для размещения этих категорий приема данных.

Каждый из этих планов сохраняет данные в двух разных состояниях:

  • Интерактивное состояние хранения — это начальное состояние, в котором данные приема. Это состояние позволяет различным уровням доступа к данным, в зависимости от плана, а затраты на это состояние зависят от плана.

  • Состояние долгосрочного хранения сохраняет старые данные в исходных таблицах до 12 лет, при крайне низкой стоимости независимо от плана.

Дополнительные сведения о состояниях хранения см. в статье "Управление хранением данных" в рабочей области Log Analytics.

На следующей схеме приведены итоги и сравниваются эти два плана управления журналами.

Схема доступных планов журналов в Microsoft Sentinel.

План журналов Аналитики

План журналов Аналитики хранит данные в интерактивном состоянии хранения в течение 90 дней по умолчанию, расширяемый до двух лет. Это интерактивное состояние, в то время как дорогое, позволяет запрашивать данные неограниченной производительностью без оплаты за запрос.

По окончании интерактивного периода хранения данные попадают в состояние долгосрочного хранения , оставаясь в исходной таблице. Долгосрочный срок хранения не определен по умолчанию, но его можно определить до 12 лет. Это состояние хранения сохраняет данные с крайне низкой стоимостью для соблюдения нормативных требований или внутренних политик. Доступ к данным в этом состоянии можно получить только с помощью задания поиска или восстановления для извлечения ограниченных наборов данных в новую таблицу в интерактивном хранении, где можно перенести все возможности запроса для его хранения.

План вспомогательных журналов

План вспомогательных журналов хранит данные в интерактивном состоянии хранения в течение 30 дней. В вспомогательном плане это состояние имеет очень низкие затраты на хранение по сравнению с планом аналитики. Однако возможности запросов ограничены: запросы взимается за гигабайты отсканированных данных и ограничены одной таблицей, а производительность значительно ниже. Хотя эти данные остаются в интерактивном состоянии хранения, вы можете выполнять сводные правила для этих данных, чтобы создавать таблицы агрегированных, сводных данных в плане журналов Аналитики, чтобы получить полные возможности запросов для этих статистических данных.

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

Базовый план журналов

Третий план, известный как базовые журналы, предоставляет аналогичные функции плана вспомогательных журналов, но при более высокой интерактивной стоимости хранения (хотя и не так высоко, как план журналов аналитики). Хотя план вспомогательных журналов остается в предварительной версии, базовые журналы могут быть вариантом долгосрочного хранения с низкой стоимостью, если ваша организация не использует функции предварительной версии. Дополнительные сведения о базовом плане журналов см. в документации по Azure Monitor.