🔵Дополнительная информация

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

В телекоме(user -> eNODEb -> S-GW), я себе представляю два варианта применения(тут сразу надо сделать дисклеймер, так как тут будет очень много терминологии которая возможно будет непонятна большей части аудитории из за сугубо телеком терминов, если вы хотите узнать об этом больше, то всегда можете почитать документацию по non-3GPP конекту с EPC нодами, в частности их диаграммы): это либо анализ в control plane(S1-MME, GTP-C) или в user plane(GTP-U через S1-U и S5).

В первом варианте, поток сигнальных сообщений между eNodeB, MME, S-GW, P-GW: Attach, Bearer Setup, Handover, Paging. Признаки на сообщение: тип процедуры, IMSI hash, временные интервалы между сообщениями процедуры, размер payload, sequence number gaps. Нормальные процедуры формируют устойчивые петли в state-space (Attach -> Authentication -> Security Mode -> ESM Info -> Default барьер), что отлично реализуется через persistent homology. Атаки типа signaling storms или четещ IMSI кэтчеры +GTP packets(к примеру для получения доступа к EPC ноде через ePDG) нарушают эти петли или создают новые.

Во втором случае, сет фичей ближе к классическому network IDS: размер пакета, IAT, TEID-статистики, QCI, distribution по APN. К аномалия так же относятся data exfiltration через бэкдор-APN, abnormal handover patterns, baseband attacks типа IMSI leak через RRC.

С трейдами интереснее, допустим что есть какой то трейдер, который получает поток ITCH/OUCH/FIX-сообщений. К фичам относятся типы сообщений (Add, Modify, Delete, Trade), частоты по типам, message size distribution, sequence gaps, gateway latency jitter. Топологические аномалии здесь - это в основном баги в инфре: проблемы с feed handler, gateway congestion, exchange-side disruptions, network reordering. Это классический мониторинг приложений, по этому TDA здесь реально полезен, тк message flow имеет сложную структуру связностей.

Вторым вариантом является анализ LOB динамики. Это уже не просто анализ трафика от биржи к трейдеру, а анализ контента сообщений(не путать с DPI). Здесь фичи это состояние orderbook: n уровней bid/ask, объёмы, queue position changes, trade imbalance, order-to-trade ratio. К ананомалиям относятся spoofing, layering, momentum ignition, quote stuffing.

Топологически это интересно, так как все эти манипуляции имеют крайне понятные сигнатуры в эволюции ордербуке.

Но тут вопросом является задержка, если мы рассматриваем варианты применения в hft, то бюджет на inline детект примерно равен паре микросекунд. В теории, вычисление комплекса m = 256 входит в эти рамки на FPGA, если использовать агрегированные окна(допустим в снапшоты ордербука каждый 100 мс), но невозможно на tick by tick данных. По этому мне кажется, что логичнее это использовать в проде либо как post trade анализ(для поиска toxic flow) или как feature generation для downstream моделей, то есть мы используем персистентность на скользящем окне как входные данные для обычной модели, которая и будет применять сами решения.