Новый индикатор – старая атака: ретропроверки в SIEM

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

Мы задаем параметры ретропроверки исходя из того, какую активность хотим обнаружить:

1. Источники данных – какие журналы нужны для проверки и какие сведения мы рассчитываем из них получить.
2. Глубина анализа – за какой период обрабатывать накопленные события: например, за сутки, неделю или месяц.
3. Расписание – когда и как часто запускать проверку либо выполнять ее однократно.
4. Условия связывания событий – по каким признакам объединять записи: учетной записи, узлу, адресу или сочетанию полей.
5. Временное окно правила – какой интервал допустим между событиями, которые мы ищем как связанную последовательность.
6. Время для сопоставления – используем ли мы время регистрации события на источнике или время его получения системой.

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

Возьмем другой пример – поиск медленного подбора пароля, при котором попытки входа разделены длительными паузами. Чтобы обнаружить такую активность, мы выбрали события за месяц, но правило при этом осталось прежним: оно ищет серию неуспешных входов за полторы минуты. Увеличение глубины анализа не изменит его поведение – попытки, распределенные на неделю, по-прежнему не попадут в одно окно. Значит, нам нужно расширить и окно правила, а также задать признаки, по которым оно свяжет эти попытки, например учетную запись и узел. Тогда правило сможет проверить, складываются ли отдельные ошибки входа в последовательность, требующую расследования.

Рассмотрим еще одну ситуацию: филиал передал часть событий и потерял связь с головной площадкой на несколько часов. Оставшиеся записи поступили в SIEM после восстановления канала, когда окно потокового правила уже закрылось. Система получила их с большим интервалом, хотя действия на источниках могли произойти с разницей в несколько секунд. Задержка доставки помешала правилу связать эти события при первоначальной обработке. С помощью ретроанализа мы можем повторно проверить соответствующий период, включив в анализ и прежние, и запоздавшие записи. Правило должно сопоставлять их по времени регистрации на источниках, чтобы восстановить последовательность действий независимо от порядка доставки. Тогда короткое окно, предусмотренное для этой последовательности, можно сохранить: расширять его на несколько часов сбоя связи не требуется. Отметим, что такой подход предполагает согласование часов на источниках. Ошибочные временные метки исказят интервалы между событиями и при повторной проверке.

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

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

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

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

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

Допустим, команда расследовала некий инцидент, приняла меры и закрыла карточку. А затем очередная ретропроверка обнаружила связанные с ним события, которых аналитики еще не видели. Новые сведения могут потребовать вернуться к закрытому расследованию. Мы предусмотрели для этого в RuSIEM настройку "Переоткрыть инцидент, если закрыт". Она позволяет вернуть прежнюю карточку в работу при обнаружении повторного инцидента, связанного с теми же объектами. Система дополняет карточку новыми событиями, а аналитик сопоставляет их с выводами предыдущего расследования и принятыми мерами.

Некоторые команды, впрочем, учитывают повторные инциденты отдельно. Они могут отключить возможность переоткрытия – тогда система создаст новую карточку с новыми уведомлениями.

Ретрорасследование может начаться и с очевидных последствий атаки. Компания "Аксон" обратилась к нам несколько лет назад после того, как злоумышленники зашифровали часть серверов и потребовали выкуп. Заказчик проигнорировал требование. Злоумышленники прислали повторное уведомление спустя сутки и зашифровали еще десять серверов.

Мы оперативно развернули RuSIEM и подключили основные источники. Новые события позволяли наблюдать за происходящим, но для расследования требовались сведения о действиях до шифрования. Заказчик сохранил их в системе лог-менеджмента, которая работала без корреляции. Мы импортировали эти данные в RuSIEM и использовали их при расследовании и устранении последствий. Нашей команде удалось отразить атаку и вернуть инфраструктуру и данные.

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

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

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

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

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

Мы записываем, за какой период искали признаки атаки, какие логи использовали и какое правило запускали. Отдельно указываем, каких данных не хватило. Тогда другой аналитик поймет, что уже проверено, а что осталось неизвестным. Если недостающие логи поступят или появится новое правило, он сможет повторить нужную проверку.

Работа с ретроспективной корреляцией начинается с предположения о том, что мы могли пропустить что-то важное в прошлом. Мы определяем, какие следы оставила бы такая гипотетическая атака, проверяем наличие нужных данных и описываем условия поиска в правиле. Такой подход помогает включить ретропроверки в работу SOC с конкретной задачей и понятными границами результата.

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