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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Связанный контент

• Более подробное сравнение планов данных журнала и более общие сведения о типах журналов см. в обзоре журналов Azure Monitor | Планы таблиц.

• Чтобы настроить таблицу в плане вспомогательных журналов, см. статью "Настройка таблицы со вспомогательным планом" в рабочей области Log Analytics.

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