РАСЧЕТ ОПТИМАЛЬНОЙ ГЛУБИНЫ ПРОВЕДЕНИЯ РЕТРОСПЕКТИВНОГО АНАЛИЗА ПО ПОИСКУ СЛЕДОВ КОМПРОМЕТАЦИИ В ИТ-ИНФРАСТРУКТУРЕ ОРГАНИЗАЦИИ

CALCULATION OF THE OPTIMAL DEPTH OF RETROSPECTIVE ANALYSIS TO SEARCH FOR TRACES OF COMPROMISE IN THE ORGANIZATION'S IT INFRASTRUCTURE

Sintsov Mikhail Igorevich

Graduate student, Departments of complex security of the Fuel and Energy Complex, National University of Oil and Gas «Gubkin University», Russia, Moscow

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

Abstract. The article discusses the calculation of the depth of retrospective analysis when searching for traces of compromise in the IT infrastructure. It is substantiated that a single search interval does not take into account the differences between event sources, attack stages, and types of compromise indicators. Based on the analysis of domestic scientific works on SIEM, retrospective event processing, compromise indicators, and log storage, a model for selecting the optimal search interval is proposed.

Ключевые слова: ретроспективный анализ, компрометация, SOC, SIEM, EDR, dwell time, индикаторы компрометации, журналы событий.

Keywords: retrospective analysis, compromise, SOC, SIEM, EDR, dwell time, compromise indicators, event logs.

Ретроспективный анализ применяется, когда организация получает новый индикатор компрометации, сведения киберразведки или гипотезу threat hunting и должна проверить прошлые события в SIEM, EDR, DNS, proxy, firewall, IPS, журналах операционных систем, Active Directory, VPN и облачных сервисах. Слишком короткий интервал поиска не позволяет обнаружить ранние следы атаки, а чрезмерно широкий интервал перегружает хранилище, увеличивает число ложных совпадений и усложняет работу аналитика.

В отечественных научных работах данная задача раскрывается через несколько направлений. И. Д. Королев, В. И. Попов и С. А. Коноваленко рассматривают инцидент как последовательность распределенных во времени событий и связывают повышение вероятности обнаружения с ретроспективной обработкой таких цепочек [1]. В. О. Шабля, С. А. Коноваленко и Р. В. Едунов описывают состав источников событий для SIEM: межсетевые экраны, IDS/IPS, журналы серверов и рабочих станций, web-фильтрацию, средства аутентификации, DLP и инвентаризацию активов [6]. А. Р. Очередько, В. С. Герасименко, М. М. Путято и А. С. Макарян показывают, что механизмы корреляции и прогнозирования в SIEM требуют развития, поскольку существующие алгоритмы не всегда достаточно полно используют методы выявления киберугроз [4]. Следовательно, глубина поиска должна зависеть от источника: журналы ОС, AD и EDR полезны для восстановления действий нарушителя, а сетевые журналы чаще дают более шумную, но важную хронологию соединений.

Отдельное значение имеют работы об индикаторах компрометации. Р. В. Мещеряков и С. Ю. Исхаков анализируют стандарты и методы обмена IOC, а также проблемы обработки динамических потоков threat intelligence [3]. Д. А. Туманов и Е. С. Абрамов предлагают оценивать источники индикаторов по отраслевой применимости и уровню доверия, поскольку избыточность IOC ведет к перегрузке аналитиков [5]. Отсюда следует, что IP-адрес, доменное имя, URL, hash файла, учетная запись и поведенческий шаблон нельзя проверять на одинаковую глубину. А. В. Кузнецов связывает срок хранения событий с объемом данных, пропускной способностью, отказоустойчивостью и физическим объемом хранилища [2]. Поэтому расчетная глубина не может превышать фактически доступный срок хранения. Отраслевые отчеты Mandiant, Verizon и IBM нужны только как статистический фон: они показывают, что скрытое присутствие злоумышленника и длительный цикл выявления инцидентов сохраняются даже при развитии SOC, EDR и XDR [7-9].

Для расчета предлагается использовать модель:

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

Таблица 1.

Рекомендуемые стартовые горизонты ретроспективного поиска

Данные таблицы задают стартовую матрицу, а не жесткое правило. Аналитик сначала определяет этап атаки, затем источник событий и тип индикатора. Один и тот же домен управления может требовать 30-60 дней поиска в proxy рядовой рабочей станции, но 180 дней в DNS-журналах контроллеров домена, серверов резервного копирования или облачной инфраструктуры.

Общий порядок расчета с использованием предложенной модели приведен на Рисунке 1.

Рисунок 1. Логика расчета оптимальной глубины ретроспективного поиска

Поясним модель условным примером. SOC получает подтвержденное доменное имя командного сервера, связанное с этапом закрепления. Поиск проводится по DNS-журналам критичного сервера резервного копирования. Внутренняя политика требует не менее 90 дней анализа, DNS хранится 180 дней. Для этапа закрепления принимается 120 дней, для DNS как источника - 1,2, для доменного имени - 1,3, для критичного актива - 1,4, для подтвержденного источника threat intelligence - 1,1.  

Расчет имеет вид:

Полученное значение означает, что запрос следует выполнить на всю доступную глубину DNS-хранилища. При поиске по IP-адресу от непроверенного источника итоговый интервал может быть уменьшен, а при поиске по учетной записи, домену, сертификату или имени службы - увеличен. Практически поиск следует делить на горячий уровень 0-30 дней, теплый уровень 31-90 дней и холодный уровень 91-365 дней. Холодный уровень запускается адресно: по критичным активам, устойчивым индикаторам, расследованиям APT, событиям в облаках, виртуализации, резервном копировании и доменной инфраструктуре.

Оптимальная глубина ретроспективного анализа не является постоянной величиной. Российские научные работы дают основания для такого вывода: инцидент имеет распределенную во времени природу, SIEM обрабатывает разнородные источники, индикаторы компрометации различаются по устойчивости, а срок хранения журналов ограничивает техническую возможность поиска. Предложенная модель связывает эти условия в единую расчетную процедуру. Единое правило 30 или 90 дней можно применять только как минимальную организационную границу. Для расследования скрытных кампаний, компрометации учетных записей, атак на доменную инфраструктуру, облака и резервное копирование требуется расширенный интервал. Для быстро устаревающих IP-индикаторов по шумным сетевым источникам интервал может быть уменьшен. Приведенные в расчете значения коэффициентов определены экспертно автором. В рамках дальнейших исследований возможно усовершенствование предложенной модели путем проработки дополнительных параметров расчета/формул для каждого из предложенных коэффициентов с учётом ретроспективно опыта использования данных параметров.