От сигнатур к ML IDS: чему IDS Suricata может научить модель?

В настоящее время для противодействия компьютерным атакам применяются разнообразные средства защиты информации:

• межсетевые экраны;

• системы обнаружения вторжений уровня сети;

• системы обнаружения вторжений уровня хоста;

• межсетевые экраны нового поколения (NGFW);

• SIEM системы (также называемые – событийные системы обнаружения компьютерных атак);

• криптографические средства защиты сетей связи;

• и другие классы средств.

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

Системы обнаружения атак уровня сети

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

Следовательно, решение задачи обнаружения модифицированных и, желательно, новых компьютерных атак с использованием эвристических или интеллектуальных методов (ML IDS) является актуальной и перспективной.

Формулировки задачи построения ML IDS уровня сети:

1. Провести классификацию сетевого трафика, разделив его на 2 (или более) класса: «чистый» сетевой трафик и компьютерная атака (деструктивное воздействие). Если есть возможность, то класс компьютерных атак разбивают на подклассы и тогда можно говорить о много классовой классификации.

2. выявить аномалию (аномальное сетевое соединение / сетевую сессию / сетевой пакет) в сети связи.

Принципиальные отличия в формулировках задач построения ML IDS:

• при построении классификатора сетевого трафика для обучения ML IDS требуется размеченный датасет, содержащий образцы (вектора признаков), принадлежащие всем распознаваемым классам, что в «реальной» жизни может быть затруднительно.

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

• при построении системы выявления аномалий исследователю известен только один вид трафика: “чистый” сетевой трафик, не содержащий признаков деструктивных воздействий.

Подробнее про процесс разработки ML IDS, а также атаках на ML IDS можно прочитать в статье “Состязательные атаки против системы обнаружения вторжений, основанной на применении методов машинного обучения“. 

В данной публикации пойдет речь о построении системы обнаружения вторжений уровня сети с использованием методов машинного обучения (далее ML IDS).

Попыток построить ML IDS уровня сети с использованием классификаторов достаточно много и в статьях результаты зачастую очень хорошие (например, “Синтез модели машинного обучения для обнаружения компьютерных атак на основе набора данных CICIDS2017”).

Однако сами авторы признаются, что высокое качество классификации наблюдается исключительно на их стендах (инфраструктуре), там, где происходило обучение моделей, а их перенос на другие сети связи показывает более низкие результаты. Это связано с тем, что наиболее известные инструменты сбора и разметки сетевого трафика для ML IDS уровня сети формируют вектора признаков, содержащих признаки, непосредственно зависящие от физической структуры сети, в которой производился сбор сетевого трафика, настроек сетевого оборудования, а также конкретных реализаций сетевых сервисов. Отличия же в них приводят к возникновению ошибок классификатора и снижению точности модели.

О чем же эта статья?

В связи с вышесказанным у авторов статьи возникли вопросы:

• можно ли построить ML IDS уровня сети на уже эксплуатируемой сети связи?

• можно ли обучить ML IDS не атакуя защищаемый ресурс намеренно? Другими словами: можно ли обучить ML IDS опираясь на зарегистрированные классическими средствами обнаружения вторжений события (например, IDS Suricata)?

• какие возникают при этом трудности?

• какое при этом ожидать качество классификации?

• какие при этом будут ограничения?

Для ответа на эти вопросы была выдвинута гипотеза о возможности построения ML IDS уровня сети с применением событий безопасности, зарегистрированных IDS Suricata, для разметки датасетов.

Для формирования векторов признаков сетевого трафика был разработан собственный инструмент расчета значений вектора признаков сетевого трафика для каждого сетевого соединения session_analyzer (в проведенном нами исследовании использовался только протокол TCP, в общем случае инструмент позволяет проводить анализ и других протоколов).

Необходимо отметить, что утилита session_analyzer – это аналог инструмента разметки сетевого трафика NTLFlowLyzer (https://github.com/ahlashkari/CICFlowMeter).

Исходные данные исследования

Для проведения эксперимента был развернут стенд на базе одной из известных компаний РФ и проведен натурный эксперимент.

В состав стенда входят два сервера, на которые заведен один и тот же сетевой трафик компании. Данный трафик включает в себя как обмен между пользователями компании (порядка 200 пользователей, выполняющих различные задачи в рамках своих должностных функций), так и выход сотрудников в сеть Интернет.

При этом:

• на первом сервере развернут сертифицированный NGFW, в состав которого входит система обнаружения вторжений уровня сети с актуальными решающими правилами (сигнатуры регулярно обновлялись, в том числе в процессе постановки эксперимента). Ядром данной системы обнаружения вторжений является модифицированная IDS Suricata (далее и будет применяться сокращение IDS Suricata);

• на втором сервере развернута разработанная нами утилита session_analyzer, на вход которой поступал тот же самый сетевой трафик, что и на IDS Suricata.

 Такая схема сбора и анализа сетевого трафика была выбрана по нескольким причинам:

• функционирование NGFW и session_analyzer в общем случае является весьма затратной темой (повышенные требования к производительности серверов);

• совмещение ML IDS c NGFW – это отдельная сложная и финансово затратная задача, требующая задействования команды разработчиков;

• хотелось провести предварительные исследования «малой кровью» и ответить на вопросы, поставленные в публикации, а также выявить «подводные камни» перед  внедрением ML IDS уровня сети в NGFW (в том числе, ответить на вопрос: стоит ли вообще внедрять ML IDS уровня сети в NGFW?).

Предварительное преобразование csv файла session_analyzer:

1. из всего множества рассчитываемых признаков извлекается только адресная информация и 10 значимых признаков: columns_x = [‘Average Packet Size’, ‘Flow Bytes/s’, ‘Max Packet Length’, ‘Fwd Packet Length Mean’, ‘Fwd IAT Min’, ‘Total Length of Fwd Packets’, ‘Fwd IAT Std’, ‘Flow IAT Mean’, ‘Fwd Packet Length Max’,’Fwd Header Length’];

2. добавляются 3 колонки:
   Label – метка класса (может принимать 2 значения: Benign или Attack);
   Origin – источник информации о метке класса (может принимать 2 значения: «session» или «suricata»);
   Sid – идентификатор события (в данном случае sid события IDS Suricata или 0, если вектор признаков «чистый» трафик).
   В дальнейшем, при обучении ML IDS всем «чистым» векторам будет присвоено численное значение 0 (негативное решение классификатора), атакам – численное значение 1 (позитивное решение классификатора).

3. проводится сопоставление векторов признаков с зарегистрированными событиями безопасности IDS Suricata и размечается датасет.

Важно! Множество из 10 значимых признаков выбрано на основе исследования, результаты которого представлены в статье “Синтез модели машинного обучения для обнаружения компьютерных атак на основе набора данных CICIDS2017”.

Особенности процесса сопоставления векторов признаков с зарегистрированными событиями безопасности IDS Suricata 

В общем случае утилиты IDS Suricata и session_analyzer могут быть расположены на разных, физически разнесенных, серверах (как в нашем случае) – это означает, что:

1. Один и тот же трафик поступает на вход двух утилит в разное время. Эксперименты показали, что разница может составлять несколько мили секунд для двух серверов стоящих в одной стойке рядом друг с другом.

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

   В таком случае, при разметке датасета (сопоставлении векторов признаков с зарегистрированными событиями безопасности IDS Suricata), необходимо предусмотреть, что для одного и того же потока данных может быть 2 сетевых соединения (до шлюза и после шлюза). У таких «одинаковых» сетевых соединений будет различаться  адресная информации (вступают в силу механизмы трансляции ip адресов и перенаправления портов транспортного уровня). В нашем случае, оказалось, что на session_analyzer поступает трафик с двух точек наблюдения – до и после шлюза компании.

   

   Этим двум соединениям до и после шлюза соответствует событие IDS Suricata (лишние поля вырезаны):
   2028762,”ET JA3 Hash – [Abuse.ch] Possible Trickbot”, “2025-06-27 13:49:45.207703”, “TCP”, “10.180.180.6”, 58557, “81.88.82.245”, 443

3. Время регистрации событий IDS Suricata (время зарегистрированной компьютерной атаки) и время соответствующего соединения (или же даже 2-х соединений) в session_analyzer различные.

   Это связано с тем, что в session_analyzer (и аналогичных утилитах) время, указанное в векторе признаков, характеризующих сетевое соединение, измеряется по первому сетевому пакету в потоке данных. В отличии от этого, в IDS Suricata (или других системах обнаружения компьютерных атак уровня сети) время компьютерной атаки обычно соответствует времени пакета, на котором произошло срабатывание анализатора. Эксперименты показали, что для некоторых сетевых атак на практике разница времени между двумя утилитами может превышать 20 секунд (гипотетически для медленной атаки – это время может быть еще больше).

Cбор сетевого трафика и предварительная обработка данных

Сбор и предварительная обработка сетевого трафика выполнялись в несколько этапов.

На 1 этапе две недели с 2025-06-26 по 2025-07-10 параллельно функционировали IDS Suricata и session_analyzer.

Результатом этого этапа стали 2 файла:

• лог с зарегистрированными компьютерными атаками IDS Suricata;

• лог с векторами признаков всех сетевых соединений сформированный session_analyzer за указанный период времени (каждая строчка лога представляет собой вектор значений признаков соединения и содержит 119 колонок);

На 2 этапе из лога IDS Suricata были извлечены все ip адреса, которые фигурировали в зарегистрированных событиях и из лога session_analyzer были удалены все строки, которые содержали ip адреса не встречающиеся в логах IDS Suricata (по факту в нашем случае – это примерно 25% всех соединений).

В итоге осталось 55548971 сетевых соединений (векторов, характеризующих каждое соединение).

На 3 этапе из лога session_analyzer убрали все лишние столбцы (признаки). Для этого в логе session_analyzer в каждом векторе с описанием сетевых соединений отставили только адресную информацию (время начала соединения и 5-tuple: ip адреса + порты транспортного уровня + номер протокола транспортного уровня) и 10 информативных признаков для синтеза ML модели;

На 4 этапе провели сопоставление двух логов: IDS Suricata и session_analyzer для того, чтобы каждому вектору, характеризующему сетевые соединения указать метку класса: Benign («чистый» трафик) и Attack (компьютерная атака). При этом, была разработана утилита сопоставления, учитывающая все особенности приема сетевого трафика, которые были описаны выше.

Таким образом, после предварительной обработки данных и сопоставления 2-х логов датасет содержит 55548971 строк, при этом векторов чистого трафика (Benign) = 55491506, векторов компьютерных атак (Attack) = 57465.

Множество атак содержит 111 различных sid. В таблице ниже представлены атаки и их количество (атаки, которые за весь период наблюдения встречались 1 раз из таблицы убраны).

55 млн. строк – это достаточно много (с одной стороны по продолжительности сбора данных о сетевом трафике, с другой стороны по требуемому объему оперативной памяти при дальнейшем обучении моделей) и для упрощения анализа при проведении исследования все множество векторов разбиваем на файлы по 10 млн строк.

Все 55 млн. строк сортируем по меткам времени появления вектора признаков, характеризующих сетевые соединения – это позволит ответить на вопрос: сколько времени требуется наблюдать за трафиком компании для обучения и получения качественной ML модели.

Распределение всех векторов по классам и по времени появления представлены ниже в таблице.

Ура! Датасет готов. Можно попробовать синтезировать ML модель.

Построение ML IDS

Для построения классификатора сетевого трафика была использована библиотека catboost. Количество признаков – 10, все признаки – числовые. Эксперименты проводились на ПЭВМ: Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz, 32 Gb DDR3.

Настройки классификатора при обучении (данные значения настроек использовались во всех экспериментах: значения выбраны эвристически исходя из различных рекомендаций исследователей и разработчиков):

iterations = 1000, depth = 8,
CatBoostClassifier(iterations=iterations, verbose=250, depth=depth,
task_type="CPU", eval_metric='F1').

Важно помнить! Безусловно, надо подбирать рациональные значения всех гиперпараметров ML модели, но в данном исследовании этого не делалось, а упор сделан на все «подводные» камни процесса построения ML IDS в целом!

Эксперимент 1.

Обучили модель на файле dataset_1.csv (2,5 дня наблюдения за сетью, в том числе в рабочие дни: 18 % всех чистых векторов, 6,5% всех атак).

Эксперимент 1. Оценка качества классификатора сетевого трафика

Выводы по эксперименту: пока что, все плохо!

1. Обучение произведено на файле dataset_1.csv и качество классификации на нем же плохое: слишком много «пропуска цели», а следовательно и значение recall тоже низкое. Т.е. выборки плохо разделимы с использованием выбранного математического аппарата, существующего признакового пространства и/или разметки датасета.

2. На остальных файлах (участках времени) всё плохо не только с попуском цели, но и достаточно высокий уровень ложных срабатываний, что обычно говорит о том, что в обучающей выборке недостаточно «чистых» векторов, т.е. обучающая выборка не репрезентативна и надо добавить векторов со следующего временного участка. Однако в нашем случае, в явном виде такой вывод сделать нельзя, т.к. на  dataset_4.csv и dataset_5.csv (выходные дни и совсем небольшое количество атак) качество классификации «чистого» трафика неплохое.

Что же делать дальше?

Высокий уровень пропуска цели и в целом невозможность разделения векторов на обучающей выборке, в совокупности с применением catboost (одна из лучших в мире реализаций RandomForest) говорит о том, что скорее всего разметка датасета неправильная и есть вектора имеющие одинаковые (или очень близкие) значения признаков, но разные метки классов. Все такие вектора для простоты обозначения будем по тексту публикации называть «плохими» векторами.

Тогда на следующем этапе исследования:

• найдем все вектора, расстояние между которыми равны 0, но они относятся к разным классам (это однозначно неправильная разметка датасета);

• найдем все вектора, расстояние между которыми имеют «очень маленькое» значение (данное значение было подобрано экспериментально);

• проведем анализ: какие именно атаки (sid правил IDS Suricata) попали во множество «плохих»?

• заменим метку класса найденных векторов на Benign.

Эксперимент 2.

Для поиска векторов имеющих одинаковые значения признаков, но разные метки классов, воспользуемся расчетом Евклидова расстояния между векторами (не забываем при этом нормализовать значения каждого признака). Поиск осуществляем только на файле dataset_1.csv (он у нас обучающий).

В результате поиска векторов с одинаковыми (или очень близкими) значениями признаков, но разными метками классов было найдено 24 sid (объединим их в логические группы и представим текстовое описание семантики решающего правила).

Для практически всех вышеперечисленных компьютерных атак имелись полностью совпадающие вектора из множества «чистых» векторов (т.е. расстояние между ними было равно 0).

Исключения составили события с sid: 1006217, 2035593 и 2047703. Для этих событий минимальное расстояние между векторами было < 0.00005. Что это означает на практике хорошо видно на рисунке ниже (dist = 0.000001).

Т.е. небольшая разница была в значениях признаков, которые зависят от времени (задержек в сети, используемых сетевых технологиях и т.п.).

Дополнительным интересным результатом явилось еще и то, что некоторые атаки в принципе имеют практически 0 значения всех признаков (такое возможно при условии, что NGFW заблокировало соединение по первому пакету). Это означает, что для этих атак признаковое пространство необходимо изменять.

Так, например, атаки “HackTool.Nmap.TCP.ServerRequest” и “ET DROP Dshield Block Listed Source group 1” в заданном признаковом пространстве вообще не различимы (см. рисунок ниже). Имеются и другие примеры наблюдаемого явления.

Ниже представлены результаты модификации набора данных (путем изменения метки класса на Benign для всех векторов, имеющих «плохие» sid), повторного обучения ML модели и оценки качества классификации. Настройки процедуры обучения ML модели, выбранные значения гиперпараметров модели и используемый набор данных остаются как и в эксперименте 1.

После модификации набора данных векторов с меткой класса Benign – 55531544, векторов с меткой Attack – 17427 (было 57465).

Обучим заново ML IDS и оценим качество полученного классификатора.

Эксперимент 2. Оценка качества классификатора сетевого трафика

Время обучения модели 19 мин 36 сек, время классификации 55 млн. векторов – 7 мин 21,4 сек.

Выводы по эксперименту

1. Не смотря на улучшение качества классификации в целом, уровень «пропуска» цели и ложных срабатываний остается высоким.

2. При этом, достаточно большое значение «FN-false negative» (и как следствие значение recall)  на файлах dataset_2/3/4/5/6.csv показывает, что:

• необходимо исследовать: появились ли новые зарегистрированные атаки на временных интервалах, следующих за обучающим интервалом (т.е. на dataset_2/3/4/5/6.csv)?;

• объем обучающей выборки с атаками явно недостаточный и требуется переобучить модель с новыми данными.

Исследование состава зарегистрированных событий безопасности IDS Suricata на разных интервалах времени

Для того, чтобы понять какие события правильно классифицируются, а какие нет, была построена таблица, в ней указано, какие атаки встречались на каждом временном участке и сколько из этих атак было НЕ обнаружено (т.е. на примере самой первой строки sid = 2028762, в файле на котором обучались (dataset_1.csv) было таких событий 688 и все обнаружены, на dataset_2 было 1424 атаки из ни не обнаружено 5 и т.д.).

Обозначения. В таблицах ошибок ниже жирным шрифтом выделено плохое качество классификации векторов с признаками.
Для наглядности можно применить раскраску таблицы цветами (к сожалению, сайт не поддерживает раскраску таблиц), становится очень хорошо видно, что отдельные события безопасности хорошо распознаются, другие не в какую не хотят правильно классифицироваться, какие события были в процессе обучения представлены, а какие – нет:
– зеленый цвет – качество классификации приемлемое;
– красный цвет – качество плохое (надо обратить внимание на это решающее правило);
– желтый цвет (только в колонке dataset_1, т.е. на обучающем наборе данных) – sid не встречался в процессе обучения (решающее правило не срабатывало).

Эксперимент 2. Таблица ошибок “пропуск” цели

Выводы по исследованию состава зарегистрированных событий безопасности IDS Suricata на разных интервалах времени:

• не все атаки хорошо распознаются на обучающем наборе данных, и необходимо провести анализ каким образом срабатывают такие правила (дальнейший анализ показал, что большинство из красных областей – это срабатывания решающих правил, основанных на адресной информации);

• ряд атак на обучающем наборе данных классифицируются правильно с хорошим качеством, а на остальных участках времени – плохо. Для того, чтобы понять почему так бывает можно рассмотреть правило строка 5: sid = 2014819; краткое описание: «ET INFO Packed Executable Download», если посмотреть на него, то видно, что критерий принятия решения – это все файлы формата PE, причем откомпилирован не в Visual Studio и то с ограничениями. Очевидно, что ложных срабатываний в таком случае будет огромное количество, что и видно на практике;

• плохая обобщающая способность. Библиотека catboost – это реализация RandomForest и это сказывается в случае, если ряд признаков (как в нашем случае) в датасете связаны с временем. На практике это означает, что ряд атак, в нашем случае – почти все, которые отсутствовали на обучающем наборе данных либо плохо (плохая обобщающая способность), либо вообще не распознаются и требуется переобучение модели, чтобы обучающая выборка была «репрезентативной» (строки 8, 9, 11, 13, 14 и многие другие).

 Что же делать?

На следующем шаге исследования обратим внимание на правила из “красной” зоны и заново обучим модель на первом и втором временном интервале. Таким образом, с точки зрения практики, первого временного интервала для обучения не достаточно (выборка не репрезентативна, если посмотреть выше на таблицу, то первый временной интервал – это всего лишь один рабочий день – пятница и потом наступают выходные), увеличим временной интервал для сбора сетевого трафика.

Эксперимент 3.

Предварительная обработка данных: убрать все адресные решающие правила (т.е. правила, критерием срабатывания которых является обращение по конкретному ip адресу или диапазону адресов, или обращение к TLS серверам с конкретным SNI (или SNI префиксом).

Перечислим sid «плохих» для построения ML модели правил:

2060504,2050884,28000001,2041933,28000974,2052581,1006585,2060505,2057746,2053282,2033967,2063118,2046071,2049202,1006554,1006556,1006555,1006557,1800920,1802600,1801497,1803186,1801678,1802605,1800324,1801470,1802765,1802434,1800572,1800496,1802677,1800742,1801285,1801368,1802634,1801601,1800766,1801379,1802764,1800722,1802174,1802654,1800213,1803394,1803583,1801944,1801673,1802363,1800330,1006258,1006260,1006557,1800324,1800766,1801368,1801379,1801470,1801497,1801601,1801678,1802634,1802765,2029634,2033967,2050884,2062715 – это правила с адресной информацией.

После модификации набора данных векторов с меткой класса Benign – 55540391, векторов с меткой Attack – 8580 (первоначально было 57465).

При обучении объединим два временных диапазона dataset_1.csv и dataset_2.csv, т.е. обучение осуществлялось в течение 6 дней (включая трафик выходных дней).

Эксперимент 3. Оценка качества классификатора сетевого трафика.

Время обучения модели 39 мин 49 сек, время классификации 55 млн. векторов – 8 мин 41,6 сек.

Эксперимент 3. Таблица ошибок “пропуска” цели

Выводы по эксперименту:

качество модели стало лучше, но с датасетом надо еще работать. «Глазами» изучить с первого раза все 111 решающих правил IDS Suricata у автора не получилось и скорее всего адресные правила удалены были не все (т.к. «пропуск» цели достаточно большой на файлах dataset_3.csv и dataset_6.csv, а на файле dataset_2.csv много ошибок обучения).

Эксперимент 4.

Предварительная обработка данных такая же как и в предыдущем эксперименте – убрать все адресные решающие правила (т.е. правила, критерием срабатывания которых является обращение по конкретному ip адресу или диапазону адресов, или обращение к TLS серверам с конкретным SNI (или SNI префиксом).

Анализ перечисленных выше в эксперименте 3 ошибок «пропуска цели» выявили следующие категории «плохих» sid:

• поиск SNI: 2058779, 2039595, 2054227, 2047894, 2050282, 2024833;

• поиск SNI с опцией dotprefix: 2027695, 2050633, 2063071, 2047866;

• поиск сертификата с конкретными данными: 2029322, 28000196, 28000040, 28000002, 28000957;

• поиск конкретных IP адресов: 2400004;

• анализ TCP Flags: 1006319.

Остальные решающие правила исключать нельзя – они опираются на поиск контекстный поиск внутри данных TCP соединения (анализ заголовков http, анализ содержимого передаваемых по протоколу http файлов и т.п.).

После модификации набора данных векторов с меткой класса Benign – 55540495, векторов с меткой Attack – 8476 (первоначально было 57465).

При обучении объединим два временных диапазона dataset_1.csv и dataset_2.csv, т.е. обучение осуществлялось в течение 6 дней (включая трафик выходных дней).

Эксперимент 4. Оценка качества классификатора сетевого трафика.

Время обучения модели 39 мин 58 сек, время классификации 55 млн. векторов – 7 мин 56 сек.

Эксперимент 4. Таблица ошибок «пропуска» цели.

Выводы по эксперименту:

на третьем временном интервале появились новые события безопасности, на которых обучения ML IDS не проводилось и классификатор из не “видит”. В качестве эксперимента попробуем переобучить систему и добавить ошибочные вектора из файла dataset_3.

Эксперимент 5.

Исходными данными для эксперимента возьмем датасеты эксперимента 4 + добавим только ошибочные вектора (вектора с “пропуском” цели) из файла dataset_3.

Эксперимент 5. Оценка качества классификатора сетевого трафика.

Время обучения модели 39 мин 38 сек, время классификации 55 млн. векторов – 8 мин 12 сек.

Эксперимент 5. Таблица ошибок «пропуска» цели.

Выводы по эксперименту 5:

• добавление в обучающую выборку новых векторов атак, которые ранее не встречались, может приводить к положительному результату (строки 10, 11, 21, 22, 23, 24) однако могут появляться дополнительные ложные срабатывания (для выяснения причин необходимо оценить близость новых векторов до «чистых»);

• иногда добавление информации об атаках не приносит ни какого результата или качество распознавания этих атак не высокое (строки 8, 20, 25, 26);

• интересная для анализа строка 2 (событие «ET INFO Packed Executable Download», суть данного правила раскрыта выше). Добавление новой информации о такой атаке с одной стороны позволяет уменьшить пропуск цели на обучающей выборке, а вот обобщающая способность совсем не высокая (ошибки в последнем столбце). При этом, скорее всего, такие правила добавляют ложные срабатывания;

• как бы не проходило обучение, но есть атаки, которые все равно не распознаются (например, строки 6, 8). По идеи их необходимо убирать из датасета (устанавливать метку класса Benign).

Общие выводы по проведенному исследованию

1. ML IDS уровня сети можно построить на уже эксплуатируемой сети связи, опираясь при этом на события безопасности, зарегистрированные с помощью IDS Suricata.

2. Разметка датасетов с использованием данных срабатываний сигнатурных анализаторов (IDS Suricata / Snort и т.п.) имеет преимущество – тонкая настройка решающих правил сигнатурных анализаторов позволяет убрать большое количество «ложных» срабатываний, на которые операторы систем обнаружения вторжений не «обращают» внимание.

3. Не все срабатывания IDS Suracata (sid зарегистрированных атак) можно использовать для разметки датасетов:
   – много решающих правил сигнатурных анализаторов опираются на поиск исключительно адресной информации: SNI TLS соединений, конкретные IP адреса, обращения к конкретным веб-страницам. Если при разметке датасета будут применены такие sid очень высокая вероятность появления дополнительных «ложных» срабатываний и «пропуска» цели ML IDS;
   – для качественного распознавания некоторых атак (sid) необходимо изменение признакового пространства (в проведенном выше исследовании, к таким атакам были отнесены различные способы сканирования портов).

4. На этапе разметки датасета важно проводить оценку близости векторов признаков сетевых соединений, имеющих разные метки классов. Появление векторов с одинаковыми, или очень близкими значениями векторов признаков, но разными метками классов приводит к существенному ухудшению точности ML моделей. Одной из причин появления одинаковых значениями признаков в векторах, но разными метками классов является несовершенство самого признаковое пространства (т.е. требуется изменения признаков).

5. Обучающая выборка должна была репрезентативной. ML модель возможно необходимо обучить заново в следующих ситуациях:
   –  появление новых типов (sid) компьютерных атак;
   – модификация или удаление решающих правил сигнатурных анализаторов (раньше был sid и были вектора им соответствующие в датасете, теперь такие же вектора будут иметь другую метку класса);
   – изменение количества сотрудников в компании или изменение их трудовых функций (изменение сетевой нагрузки и как следствие влияние трафика пользователей на задержки, маршрутизацию / балансировку трафика в сети и т.п.);
   – изменение сетевого оборудования или набора локальных сетевых сервисов компании (изменение задержек в сети связи, маршрутизации / балансировки трафика в сети и т.п.).

6. Для качественного обучения ML IDS, в нашем случае, требуется 1 недели наблюдения за сетевым трафиком компании (включая, выходные и рабочие дни).

7. На этапе оценки качества обученной ML модели важно провести анализ ошибок классификации.
   Причины ошибок:
   – некачественные решающие правила сигнатурных анализаторов (IDS Suricata);
   – состязательные атаки на ML модель.

8. Набор значимых признаков для распознавания разных типов компьютерных атак различный (очевидно, что для распознавания атак типа brute force и для распознавания сканирования портов признаки, отличающие их друг от друга, будут различные).

9. При сопоставлении событий безопасности IDS Suricata с векторами, характеризующими соответствующие сетевые соединения (session_analyzer или аналогичные утилиты) необходимо учесть следующее:
   – метка времени срабатывания решающего правила IDS Suricata чаще всего не совпадает со временем начала сетевого соединения;
   – одному и тому же событию безопасности IDS Suricata может соответствовать 2 сетевых соединения – это зависит от точки наблюдения за трафиком (например, session_analyzer может наблюдать за трафиком как до, так и после шлюза). Подробнее можно посмотреть выше в подразделе «Особенности приема сетевого трафика».

10. Качество ML IDS классификатора по метрики F1-меры при должной разметке датасета может достигать 0.98.

Недостатки проведенного исследования

• Использование бинарной классификации при построении ML IDS, что в при практическом внедрении в существующие средства NGFW является на наш взгляд не приемлемым. Нельзя ответить на вопрос – какой класс атаки был зарегистрирован и как реагировать на такое событие?

• При построении ML IDS защищаемым объектом была пользовательская сеть, а не конкретный ресурс, по этому на основании полученных результатов невозможно ответить на вопрос: какие классы атак на реальный объект защиты (например, web-сервер) возможно обнаруживать с помощью технологии ML IDS уровня сети.

В наших будущих публикациях постараемся ответить Вам, дорогие читатели, на эти вопросы. До скорой встречи!