Общие рекомендации по подготовке данных для построения аналитической отчетности

Первым и основным требованием-рекомендацией является единое именование объектов контроля (в той или иной ситуации они могут быть как источниками/субъектами, так и получателями/объектами). Например, для пользователей это может быть логин в системе, samaccountname (для Windows) или какой-то uid, а для хостов – fqdn имя или просто имя хоста (IP адреса так же можно использовать, но в тех случаях, когда адресация фиксированная, при динамической результаты анализа будут искажены).

Поскольку платформа в основном оперирует и анализирует параметры поведения / действий / взаимодействия, а не конкретными атомарными (единичными) событиями, то использование расширенной схемы данных будет только вносить дополнительную нагрузку и не приносить большой пользы. Рекомендуется сохранять только те данные, которые позволят отслеживать отклонения в поведении / профиле объекта и строить необходимую аналитическую отчетность. При необходимости, справочная информация в виде всего текста сообщения или конфигурации, или SQL запроса и т.п. могут храниться для отображения при проведении расследования.

Для аналитической отчетности рекомендуется разрабатывать схему привязки к данным и использовать единые алиасы (псевдонимы). Это позволит в дальнейшем без проблем использовать глобальные и локальные фильтры в дашбордах. Например, если используете поле с датой и временем, то везде называйте его "Дата и время".

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

Поведенческое профилирование рекомендуется выполнять итеративно, корректируя параметры профилирования и фильтруя данные циклично. Обычно, настройка профилей заключается в первичном построении отчетности, составлении "белых списков" сущностей, корректировки чувствительности, дополнительной фильтрации событий для исключения "шумов". Полученные сведения учитываются в продублированных профилях либо вносятся во view, на которых дальше будут построены профили.