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

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

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

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

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

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

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

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

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

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

• Частый мониторинг. Правила обнаружения угроз (аналитики) выполняются в этих данных с частыми интервалами или практически в режиме реального времени.
• Охота по запросу. Сложные запросы выполняются на этих данных с целью интерактивного, высокопроизводительного поиска угроз безопасности.
• Корреляция. Данные из этих источников коррелируются с данными из других основных источников данных безопасности для обнаружения угроз и создания историй атак.
• Регулярные отчеты. Данные из этих источников легко доступны для составления регулярных отчетов о состоянии безопасности организации как для специалистов по безопасности, так и для руководителей, принимающих общие решения.
• Аналитика поведения. Данные из этих источников используются для построения базовых профилей поведения ваших пользователей и устройств, что позволяет выявлять нестандартное поведение как подозрительное.

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

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

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

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

• Аналитика угроз. Основные данные можно проверить на наличие списков индикаторов компрометации (IoC) или индикаторов атак (IoA), чтобы быстро и легко обнаруживать угрозы.
• Спонтанная охота и расследования. Данные можно запрашивать в интерактивном режиме в течение 30 дней, упрощая важный анализ для поиска угроз и расследований.
• Крупномасштабные поиски. Данные могут загружаться и искаться в фоновом режиме в петабайтном масштабе, при этом хранятся эффективно и требуют минимальной обработки.
• Суммирование с помощью правил сводки. Суммирование журналов с большим объемом данных в сводную информацию и хранение результатов в качестве основных данных безопасности. Чтобы подробнее узнать о сводных правилах, см. Агрегирование данных Microsoft Sentinel с помощью сводных правил.

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

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

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

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

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

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

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

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

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

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

План аналитических журналов

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

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

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

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

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

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

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