Журнал "Information Security/ Информационная безопасность" #4, 2026

Допустим, обращение нашлось. Оно, конечно, еще не доказывает компроме- тацию, но дает веское основание для расследования. Опытный аналитик спо- собен проверить такую гипотезу ручным поиском, но ежедневные обновления с тысячами IoC требуют многократного повторения поисковых операций, а про- верка последовательностей действий предполагает еще и сопоставление события по нескольким условиям. Для таких ситуаций в современных SIEM 1 предусмотрена возможность ретроспек- тивной корреляции, которая позволяет записать логику в правила и автомати- зировать ее выполнение. А затем ана- литик разбирает найденные совпадения и уточняет условия, если результаты проверки дают для этого основания. Настройка ретрокорреляции Мы задаем параметры ретропроверки исходя из того, какую активность хотим обнаружить: 1. Источники данных – какие журналы нужны для проверки и какие сведения мы рассчитываем из них получить. 2. Глубина анализа – за какой период обрабатывать накопленные события: например, за сутки, неделю или месяц. 3. Расписание – когда и как часто запускать проверку либо выполнять ее однократно. 4. Условия связывания событий – по каким признакам объединять записи: учетной записи, узлу, адресу или соче- танию полей. 5. Временное окно правила – какой интервал допустим между событиями, которые мы ищем как связанную после- довательность. 6. Время для сопоставления – исполь- зуем ли мы время регистрации события на источнике или время его получения системой. Вернемся к примеру с новым IoC. Допустим, база индикаторов обновляет- ся раз в неделю и мы запускаем про- верку после каждого обновления. Такое расписание еще не означает, что искать совпадения нужно только в событиях за прошедшую неделю. Домен, который попал в базу, мог использоваться для атаки месяц назад или раньше. Поэтому глубину анализа мы выбираем отдельно: определяем, насколько давнюю актив- ность хотим проверить, и выясняем, сохранились ли логи за этот период. Возьмем другой пример – поиск мед- ленного подбора пароля, при котором попытки входа разделены длительными паузами. Чтобы обнаружить такую активность, мы выбрали события за месяц, но правило при этом осталось прежним: оно ищет серию неуспешных входов за полторы минуты. Увеличение глубины анализа не изменит его пове- дение – попытки, распределенные на неделю, по-прежнему не попадут в одно окно. Значит, нам нужно расширить и окно правила, а также задать при- знаки, по которым оно свяжет эти попытки, например учетную запись и узел. Тогда правило сможет прове- рить, складываются ли отдельные ошибки входа в последовательность, требующую расследования. Рассмотрим еще одну ситуацию: филиал передал часть событий и поте- рял связь с головной площадкой на несколько часов. Оставшиеся записи поступили в SIEM после восстановления канала, когда окно потокового правила уже закрылось. Система получила их с большим интервалом, хотя действия на источниках могли произойти с раз- ницей в несколько секунд. Задержка доставки помешала правилу связать эти события при первоначальной обра- ботке. С помощью ретроанализа мы можем повторно проверить соответ- ствующий период, включив в анализ и прежние, и запоздавшие записи. Пра- вило должно сопоставлять их по вре- мени регистрации на источниках, чтобы восстановить последовательность дей- ствий независимо от порядка доставки. Тогда короткое окно, предусмотренное для этой последовательности, можно сохранить: расширять его на несколько часов сбоя связи не требуется. Отме- тим, что такой подход предполагает согласование часов на источниках. Ошибочные временные метки исказят интервалы между событиями и при повторной проверке. Запоздавшие записи должны попасть в период, который охватит очередная проверка. Допустим, мы каждую ночь анализируем события за предыдущие сутки. Запись, доставленная через два дня, останется за пределами анализа: ее период уже проверен, а следующий запуск обработает более свежие данные. 22 • СПЕЦПРОЕКТ Новый индикатор – старая атака: ретропроверки в SIEM редставим ситуацию: SIEM получила обновление базы IoC, а в нем – вновь обнаруженный домен, который исследователи связали с атакой. Настроенные правила теперь смогут обна- руживать обращения к нему в текущем потоке событий. Но злоумышленник мог использовать этот домен против нашей компании и до обновления. Значит, нам нужно вер- нуться к накопленным логам и проверить, встречались ли такие обращения раньше. П Василий Кочканиди, аналитик РуСИЕМ Даниил Вылегжанин, руководитель отдела предпродажной подготовки РуСИЕМ Фото: РуСИЕМ Фото: РуСИЕМ 1 https://rusiem.com/