Условия появления записи
Установите агент, manager и путь, на котором ожидается изменение. FIM наблюдает выбранные объекты по действующей конфигурации, поэтому перед выводом нужна карта охвата на момент события. Сверьте режим: периодическая проверка, realtime или who-data дают разную детализацию. Зафиксируйте установленную версию и ruleset, список исключений и доступный период хранения. Эта карточка описывает обработанный manager alert, а не исходный системный вызов и не универсальное событие любого HIDS. Для чтения уже собранных данных менять настройки мониторинга не требуется.
Как найти нужные записи
Пример jq читает локальную JSONL-копию alerts.json с объектом alert в каждой строке. Он не обращается к агенту и не изменяет контролируемый файл. Замените ID агента и путь на исследуемые, затем добавьте временные границы с учётом формата ваших данных. Если экспорт содержит hit._source или другую оболочку, сначала осмотрите структуру и явно выберите объект источника; приведённый фильтр рассчитан на прямую форму manager. Сохраните исходный файл отдельно от результата выборки, чтобы фильтрация не стала единственным сохранившимся свидетельством.
Что показывает пример
Путь /srv/demo/app.conf находится в modified-событии; changed_attributes сообщает об изменении sha256. Разные условные значения до и после показывают, какие поля сравнивать, но не являются хешами настоящего файла. В примере нет who-data, поэтому пользователя или процесс установить из него нельзя. Rule 550 и decoder отражают базовое правило в прочитанном официальном ruleset; локальное дочернее правило может дать другой номер и уровень. Для выбора события надёжнее совместно читать тип syscheck.event, агент и путь, а не искать только число 550.
Интерпретация и проверка изменения
Сначала опишите, какой атрибут действительно различается. Изменение прав и изменение содержимого — разные наблюдения; не переносите вывод с одного на другое. Затем сопоставьте время с заявкой, развёртыванием, обновлением пакета или действиями владельца приложения. Наличие согласованного изменения не должно автоматически закрывать все соседние события: проверьте, совпали ли объект, исполнитель и ожидаемый результат. Отсутствие согласования также не делает событие доказанной атакой. Если нужен просмотр различий содержимого, учитывайте, был ли report_changes доступен и не содержит ли экспорт чувствительные данные.
Следующий шаг
При наличии who-data проверьте audit.process и audit.user в исходном alert и сопоставьте их с отдельным аудитом хоста. Если этих полей нет, запросите процессные свидетельства за обоснованное окно; не назначайте владельца файла автором изменения. Для Linux может помочь сохранённая цепочка Audit, для Windows — журнал файлового доступа при действовавшем аудите. После проверки сохраните таблицу «наблюдение — подтверждающий источник — предел вывода». Решение о восстановлении файла или блокировке относится к отдельной процедуре реагирования, а не к чтению этого события.
Если записи нет
Проверьте, входил ли путь в охват, существовало ли исходное состояние и не действовало ли исключение. Сверьте режим, расписание и состояние агента, затем наличие данных на manager. Отсутствие alert в интерфейсе может относиться к порогу правил или доставке в indexer, поэтому разделяйте эти этапы. Пустой результат по rule 550 также возможен при локальном дочернем правиле: повторите поиск по агенту, пути и типу. Зафиксируйте период и проверенные условия; отсутствие доступной записи не подтверждает неизменность файла. Ошибка чтения файла, отказ в доступе или ошибка разбора JSON не являются пустой выборкой. Для этого шага нужны права чтения выданной копии; при их отсутствии запросите доступную копию у владельца источника, сохранив сообщение об ошибке.