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

Чтобы захватить такую запись, можно проверять за каждый запуск несколько прошедших суток или отдельно обрабо- тать нужный период после восстановле- ния связи. Первый вариант приведет к повторной обработке части событий и увеличит нагрузку. Поэтому глубину регулярной проверки мы выбираем с уче- том задержек доставки, которые встре- чаются в нашей инфраструктуре. Запускаем ретропроверки и работаем с повторными находками Для регулярной ретрокорреляции важно продумать, как система будет обрабатывать пересекающиеся периоды и что аналитики будут делать с повтор- ными находками. Нужно настроить запус- ки так, чтобы объем дополнительной работы SIEM оставался разумным, и новые сведения не терялись среди старых срабатываний. Нужно понимать, что ретрокорреляция увеличивает вычислительную нагрузку на систему. Допустим, правило запус- кается раз в неделю и проверяет послед- ние три недели. Каждый запуск повторно обрабатывает данные за две недели, чтобы вместе с ними проверить посту- пившие дополнения. Расход ресурсов сильно зависит и от количества таких заданий, поэтому имеет смысл включать в регулярный ретроанализ только те сценарии, которым нужен возврат к исто- рическим данным. Повторная обработка может дать и повторные срабатывания. Аналитику предстоит выяснить, нашло ли правило уже разобранные записи или обнаружи- ло дополнительные события, связанные с прежним инцидентом. Повторное сра- батывание того же правила на тех же событиях может не добавлять сведений к расследованию. Однако дополнитель- ные события могут изменить его резуль- таты, но сначала нужно установить, когда произошли отраженные в них дей- ствия. Допустим, команда расследовала некий инцидент, приняла меры и закрыла карточку. А затем очередная ретропро- верка обнаружила связанные с ним события, которых аналитики еще не видели. Новые сведения могут потребо- вать вернуться к закрытому расследо- ванию. Мы предусмотрели для этого в RuSIEM настройку "Переоткрыть инци- дент, если закрыт". Она позволяет вер- нуть прежнюю карточку в работу при обнаружении повторного инцидента, свя- занного с теми же объектами. Система дополняет карточку новыми событиями, а аналитик сопоставляет их с выводами предыдущего расследования и приня- тыми мерами. Некоторые команды, впрочем, учиты- вают повторные инциденты отдельно. Они могут отключить возможность пере- открытия – тогда система создаст новую карточку с новыми уведомлениями. От найденных событий к расследованию Ретрорасследование может начаться и с очевидных последствий атаки. Ком- пания "Аксон" обратилась к нам несколь- ко лет назад после того, как злоумыш- ленники зашифровали часть серверов и потребовали выкуп. Заказчик про- игнорировал требование. Злоумышлен- ники прислали повторное уведомление спустя сутки и зашифровали еще десять серверов. Мы оперативно развернули RuSIEM и подключили основные источники. Новые события позволяли наблюдать за про- исходящим, но для расследования тре- бовались сведения о действиях до шиф- рования. Заказчик сохранил их в системе лог-менеджмента, которая работала без корреляции. Мы импортировали эти дан- ные в RuSIEM и использовали их при расследовании и устранении последствий. Нашей команде удалось отразить атаку и вернуть инфраструктуру и данные. Обратите внимание, что сохраненные логи дали нам возможность изучить предысторию, хотя SIEM подключили уже после шифрования. Расследование в такой ситуации нельзя ограничить перечнем пострадавших серверов: он показывает известные последствия, но не все ресурсы, к которым мог получить доступ злоумышленник. Мы проверяем вовлеченные учетные записи и взаимо- действия между узлами, чтобы восста- новить последовательность действий. Обнаруженные связи определяют, какие системы нужно обследовать дополни- тельно и что необходимо устранить, чтобы закрыть использованный путь доступа. Отрицательный результат требует доказательной базы А что, если ретропроверка заверши- лась без срабатываний? Такой резуль- тат, конечно, позволяет сказать, что заданные признаки не обнаружены. Но прежде чем делать вывод об отсутствии атаки, нужно убедиться, что проверка теоретически могла ее выявить: необхо- димые события попали в анализ, а пра- вило способно распознать в них искомую последовательность. Для этого мы начинаем с данных: проверяем, передавали ли нужные источ- ники события за выбранный период и сохранились ли после нормализации поля, которые использует правило. Источник мог отключиться, часть запи- сей – потеряться, а нужные сведения – не попасть в результат разбора. Правило не сможет проверить условия, для кото- рых нет данных, сколько бы раз мы ни запускали его на той же выборке. Полнота данных еще не подтверждает правиль- ность логики обнаруже- ния. Проверить ее можно на учениях: воспроизвести известный сценарий, убе- диться, что необходимые события собра- ны, и запустить на них ретрокорреляцию. Ожидаемое срабатывание покажет, что правило распознает этот сценарий на полученных данных. Если срабатывания нет, мы сопоставляем условия правила с записями и выясняем, на каком этапе возникло расхождение – при сборе, нор- мализации или проверке связей между событиями. Тест показывает, что правило находит атаку, которую мы воспроизвели. Но реальный злоумышленник мог действо- вать по-другому. Нам нужно проверить, учитывает ли правило другие способы провести ту же атаку. Возможно, для их обнаружения потребуются события из других источников и дополнительные условия поиска. Мы записываем, за какой период иска- ли признаки атаки, какие логи исполь- зовали и какое правило запускали. Отдельно указываем, каких данных не хватило. Тогда другой аналитик поймет, что уже проверено, а что осталось неизвестным. Если недостающие логи поступят или появится новое правило, он сможет повторить нужную проверку. Заключение Работа с ретроспективной корреляци- ей начинается с предположения о том, что мы могли пропустить что-то важное в прошлом. Мы определяем, какие следы оставила бы такая гипотетическая атака, проверяем наличие нужных данных и описываем условия поиска в правиле. Такой подход помогает включить ретро- проверки в работу SOC с конкретной задачей и понятными границами резуль- тата. Мы активно развиваем возможность ретроспективного анализа не только в текущем продукте, но и в существенно переработанной версии RuSIEM, которую готовим к выпуску на новом ядре в 2026 г. Она также будет поддерживать исто- рическую корреляцию, чтобы аналитики могли применять новые сведения об угрозах и правила обнаружения к накоп- ленным событиям. l • 23 SIEM www.itsec.ru АДРЕСА И ТЕЛЕФОНЫ РУСИЕМ см. стр. 86 NM Реклама