Как выявлять аномалии в ИБ: стратегии, которые работают в реальных условиях

Аномалия ≠ атака, но игнорировать ее рискованно. Современные системы безопасности тонут в телеметрии, а автоматическое выявление отклонений становится основным инструментом в борьбе со сложными и скрытыми угрозами. Однако в условиях динамичных ИТ-сред и маскировки под легитимную активность, классические методы дают слишком много ложных тревог, нагружая SOC-команды. Cyber Media разбирает, какие методы обнаружения аномалий сегодня применяются на практике, как выбрать подходящую модель и обеспечить ее интерпретируемость.

Что такое аномалии и зачем их искать

В идеальной системе телеметрия описывает ожидаемое поведение: трафик соответствует шаблонам, процессы запускаются согласно расписанию, а пользователи соблюдают политики. Но в реальных инфраструктурах «нормальное» поведение меняется динамично — и именно отклонения от этого фона могут указывать на инциденты или потенциальные угрозы.

В контексте ИБ аномалия — это статистически значимое отклонение от ранее зафиксированной нормы. Ключевой нюанс: аномалия не всегда равна атаке, но именно они помогают выявлять неизвестные или скрытые угрозы, которые не ложатся на сигнатурные или жестко заданные поведенческие модели.

Классификация аномалий:

• Точечные аномалии — одиночные события, существенно отличающиеся от нормального паттерна. Пример: запуск подозрительного процесса на сервере.
• Контекстные аномалии — события, которые в одном контексте считаются нормой, а в другом — отклонением. Пример: доступ к базе данных вне рабочего времени.
• Коллективные аномалии — совокупность отдельных действий, которые сами по себе не аномальны, но в совокупности указывают на подозрительную активность. Пример: последовательное сканирование портов с разных конечных точек.

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

Основные методы обнаружения аномалий

Методов выявления аномалий — десятки, если не сотни. Но все они так или иначе укладываются в несколько крупных классов, отличающихся подходом к определению «нормального» поведения. Выбор подхода зависит от доступных данных, инфраструктуры, зрелости SOC и критичности объектов мониторинга.

Статистические подходы

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

• Z-оценка. Измеряет, насколько далеко текущее значение от среднего по распределению. Например, если обычная нагрузка на CPU — 20%, а тут внезапно 95%, возникает подозрение.
• IQR. Отсекает экстремальные значения, основываясь на квартилях. Применяется, когда данные нестабильны, но при этом сохраняется общая форма распределения.
• Гауссовские модели. Предполагают, что данные подчиняются нормальному распределению, и ищут выбросы за пределами доверительных интервалов.

Плюсы таких методов — прозрачность и объяснимость. Минусы — слабая устойчивость к сложным паттернам и динамике: малейшее изменение «нормы» может породить лавину ложных срабатываний.

Машинное обучение без учителя

Когда сигнатур недостаточно, а поведение слишком вариативно, в игру вступает машинное обучение. Особенно полезны методы без учителя — те, где не нужно заранее решать, что нормально, а что нет. Модель сама учится распознавать выбросы на фоне общего поведения:

• Кластеризация. Разбивает события на группы. Все, что не похоже на остальные, — подозрительно.
• Автоэнкодеры. Нейросети, обучающиеся сжимать и восстанавливать данные. Если восстановление плохо — перед нами нечто, выходящее за рамки нормы.
• Isolation Forest. Строит дерево решений, пытающееся «отделить» объекты от других. Аномалии — это те, кто отделяется слишком легко.

Такие методы лучше справляются с нестандартным поведением, особенно в микросервисных и облачных средах. Но требуют аккуратного отбора признаков и понимания, что «аномалия» — не всегда угроза.

Гибридные подходы и поведенческий анализ

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

Поведенческий анализ — отдельный класс систем, строящий модели «нормального» поведения пользователей и устройств. Выход за рамки шаблона это триггер возможной компрометации, lateral movement или инсайдерскую активность.

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

Проблема ложных срабатываний в динамичных средах

Ложноположительные срабатывания — это боль каждого SOC. Кажется, модель что-то нашла, а на деле — очередной алерт о штатной активности. В динамичных средах, особенно в микросервисных архитектурах с CI/CD, эта проблема только усугубляется.

Микросервисные приложения живут по своим правилам: сотни короткоживущих контейнеров, постоянные релизы, нестабильные зависимости, автоматическое масштабирование — все это создает крайне вариативный ландшафт поведения. То, что вчера было «аномалией», сегодня — новая норма после обновления.

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

Артем Аксянов

Директор управления веб-разработки Университета «Синергия»

В нашем случае мы сталкиваемся с тем, что в микросервисных архитектурах с CI/CD классические модели детекции «слепнут» из-за постоянных изменений. Например, после деплоя резко растут ошибки 5xx или меняются паттерны нагрузки — это не атака, а артефакт обновления.

Снизить ложные срабатывания в таких ситуациях нам помогает мониторинг с системой обновлений. Например, когда сервис обновляется, мы на 1-2 часа снижаем «тревожность» для связанных с ним метрик (ошибки, задержки). Условно, это как поставить галочку «не беспокоить» после деплоя.

Еще один вариант — группируем уведомления. То есть, вместо 100 оповещений об ошибках 500 создаем одно сообщение: «Сервис Х: 500 ошибок после обновления». Получается, это как собрать все жалобы в один тикет — команда быстрее разберется.

Также используем динамические пороги. Вместо жестких цифр, например, «1000 запросов в секунду — это аномалия», используем гибкие значения. Скажем, если вчера в это время было 800 запросов, а сегодня 1200 — это норма, а вот 2000 — уже повод проверить. Допустим, после обновления платежного шлюза у нас выросло число ошибок. Система знает, что это деплой, и не бомбардирует команду алертами. Но если в это же время придет волна запросов с подозрительных IP, это уже отметится как угроза.

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

Именно поэтому так важны адаптивные модели и грамотная инженерия признаков, которые учитывают контекст и позволяют выделять действительно подозрительное поведение на фоне «бурлящей» нормы.

Feature engineering против APT: как извлечь правильные признаки

Красивая модель — это хорошо, но без качественных признаков она видит в телеметрии не больше, чем человек без очков в тумане. Особенно это критично, когда речь идет о продвинутых угрозах — APT-группах, маскирующихся под легитимную активность.

Задача feature engineering — извлечь из потока данных такие параметры, по которым можно отличить «плохое» от «хорошего». Звучит просто, но на практике все упирается в баланс: слишком простые признаки дадут море FP, слишком сложные — сделают модель непрозрачной и непригодной для объяснения.

Эффективные подходы включают:

• Агрегацию по времени и сущностям. Например, количество уникальных внешних IP-адресов, к которым подключался процесс за последние 15 минут.
• Статистические характеристики поведения. Средняя длина сессий, отклонения в объеме трафика, темп создания файлов.
• Контекстные связи. Кто запустил процесс, с какими правами, какие события были до и после, как часто этот сценарий встречается в организации.

Например, если внутреннее ПО из стандартной директории Windows регулярно ходит по подозрительным доменам через DNS over HTTPS — это уже звоночек. Или на первый взгляд безобидные команды в фоне по итогу приводят к инъекции DLL в другой процесс. А бывает, что какой-нибудь powershell внезапно запускается с набором аргументов, которые встречаются в инфраструктуре реже, чем 1 раз в 100 000 случаев.

Илья Одинцов

Менеджер по продукту NGR Softlab

Для AI маскировка под легитимные операции не такая сложная задача, как для человека. Существует паттерн, который подстраивается под конкретного заказчика. Например, мы точно знаем, что типовой рабочий день сотрудника отдела продаж с 9 до 18 или же, расширяя вилку, с 8 до 19 на случай, если он приходит раньше или задерживается. Имея эту информацию, мы начинаем обучение модели, и затем через несколько месяцев получаем MVP-модель со средними значениями и медианными отклонениями. На выходе получается следующий паттерн:

• Сотрудник отдела продаж.
• Обращается в систему с 8 до 19 часов.
• Запросы на просмотр: в среднем 20 в день.
• Запросы на изменения: не чаще 2 раз в неделю.
• Создание новых карточек и удаление старых: не чаще 3 раз в неделю.
• Ежемесячный отчет: несколько запросов в день.

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

По итогу заказчик получит ожидаемый результат, отражающий конкретные бизнес-процессы.

Такие признаки не лежат на поверхности — их нужно вытащить, проанализировать, верифицировать. Но именно они позволяют выстроить детекторы, которые не путают админа с атакующим и реагируют не на форму, а на суть поведения.

Объяснимость как фактор доверия: XAI в ИБ

Даже самая точная модель становится балластом, если ее поведение нельзя объяснить. В информационной безопасности это особенно чувствительно: аналитик не может просто «поверить» машине, он должен понимать, почему та сочла действие подозрительным. Именно поэтому объяснимость (XAI — explainable AI) становится критическим фактором доверия к системам обнаружения аномалий.

Николай Змитрович; Владимир Аникеев

Специалист по ML UserGate uFactor; Аналитик SOC UserGate uFactor

На данный момент мы используем атомарные модели, которые разработаны для поиска признаков конкретных типов вредоносной активности. Так, например, модель DGAPH обнаруживает вредоносные DGA и фишинг-домены (сейчас работаем над интеграцией модели в SIEM). Таким образом, результат работы модели достаточно легко интерпретировать. Для аналитиков новый инструмент является хорошим помощником в первичном анализе активности в больших или даже огромных массивах данных. С его помощью аналитик может сразу сосредоточиться на событиях, которые модель предсказывает как подозрительные. Это может значительно сократить время реагирования на инцидент.

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

Виталий Моргунов

Руководитель управления развития технологий BI.ZONE EDR

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

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

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

Методы XAI помогают разложить решение модели по полочкам:

• SHAP показывает, какие признаки повлияли на итоговое предсказание и насколько сильно. Это позволяет понять вклад каждого параметра в решение модели.
• LIME подменяет сложную модель локальной интерпретируемой и строит объяснение для конкретного случая — удобно, когда нужно быстро разобраться в единичном алерте.
• Attention-механизмы визуализируют, на какие части входной последовательности модель обратила внимание при анализе поведения.

Объяснимость — это не просто модный термин. Это рабочий инструмент, который сокращает время реакции, снижает усталость SOC-аналитиков и помогает выстроить доверие к машинному анализу. И, как показывает практика, именно объясненные предсказания чаще всего оказываются полезными в реальных инцидентах.

Вывод: на что делать ставку

Иногда самые простые методы — самые надежные. В ряде сценариев простая статистика или даже базовые пороговые правила показывают не худшие результаты по сравнению с продвинутыми ML-моделями, особенно если среда стабильна, а шумов мало. Главное это понимать контекст и не стремиться усложнять без необходимости.

При этом даже самая продвинутая модель не заменит человека. Без участия аналитика аномалия — это всего лишь странность, не более. Только человек может интерпретировать, сопоставить с бизнес-контекстом, понять, идет ли речь об ошибке, инсайде или атаке. Поэтому связка «машина + человек» остается оптимальной: машина ускоряет, человек осмысляет.

Основные тренды в аномальной аналитике сегодня — это снижение уровня ложных срабатываний, усиление explainability и внедрение XAI-инструментов, которые делают модели не просто точными, но понятными. Делать ставку стоит на адаптивные гибридные решения, способные подстраиваться под динамичную инфраструктуру, минимизируя нагрузку на SOC и не теряя в качестве детекции.