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

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

Предыстория

В 2019 году мы с коллегами решили разобраться, можно ли усилить сигнатурную систему обнаружения компьютерных атак с помощью машинного обучения. Причём так, чтобы обобщающая способность модели машинного обучения позволила обнаруживать новые, ранее неизвестные атаки (0-day), для которых эксперты ещё не успели выпустить сигнатуры.

Для построения прототипа использовали модель типа «случайный лес» (random forest), обученную на публичном датасете CICIDS2017. Исследование было успешно завершено в 2021 году, все подробности и результаты — в научной статье или в посте. Главный вывод: методы машинного обучения применимы на практике для обнаружения компьютерных атак.

Но сегодня предлагаем обсудить один из первых шагов проведенного исследования (да и вообще любого исследования в области машинного обучения). А точнее — поговорить про выбор набора данных для обучения.

Выбор набора данных для обучения. Почему CICIDS2017?

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

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

Это был выбор из двух альтернатив: на своих данных или на каком-то публичном датасете. Да, можно собрать свою виртуальную инфраструктуру с несколькими серверами и хостами, запустить генераторы атак и нормального трафика, собрать и разметить сетевой трафик, получив таким образом свой набор данных. Но тогда мы решили, что это займёт слишком много времени. И не ошиблись, двумя годами позже мы собрали собственный датасет, работа заняла почти год.

Другая альтернатива — использовать уже опубликованный сторонний набор данных. Как есть. Но какой датасет выбрать, если их много? Мы решили оценить цитируемость датасетов в академических работах, и тогда программа Publish or Perish подсказала нам лидеров (абсолютные значения цитируемости, к сожалению, не сохранились в черновиках 2019 года):

1. KDD Cup 1999

2. CICIDS 2017

3. NSL-KDD 2009

4. ISCX 2012

5. UNSW-NB15

6. Kyoto 2006

7. DARPA 1998

8. CTU-13

9. UGR-16

10. CIDDS-001

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

Коротко про датасет CICIDS2017

Датасет «Intrusion Detection Evaluation Dataset» CICIDS2017 подготовлен по результатам анализа сетевого трафика в изолированной среде, в которой моделировались действия 25 легальных пользователей, а также вредоносные действия нарушителей. Разработчик — Canadian Institute for Cybersecurity (CIC).

Набор объединяет более 50 Гб «сырых» данных в формате pcap и включает 8 предобработанных файлов в формате CSV, содержащих размеченные сессии с выделенными признаками в разные дни наблюдения. Краткое описание файлов и количественный состав набора данных представлены в таблицах ниже.

В обзорах набора данных CICIDS2017 (Intrusion2017, Panigrahi2018, Sharafaldin2018) отмечались проблемы дисбаланса классов, сложной файловой структуры, пропуска значений. Эти замечания мы приняли как некритичные, приступив к работе.

Проблемы датасета CICIDS2017

Повторимся, мы достаточно внимательно и аккуратно подошли к вопросу выбора набора данных для обучения модели. Собрали статистику, прочитали несколько обзоров, провели первые эксперименты. Идеального датасета не существует, поэтому мы приняли известные недостатки набора CICIDS2017 и взяли его в работу.

Теперь мы понимаем, что на тот момент главная проблема состояла в том, что известными были далеко не все недостатки.

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

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

Проблема 1. Некоторые признаки дублируются. Например, признак «Fwd Header Length» (суммарная длина заголовков пакетов в прямом направлении — от клиента к серверу) и «Fwd Header Length.1» являются идентичными. В работе «Network Intrusion Detection: A Comprehensive Analysis of CIC-IDS2017» ещё тщательнее проанализировали все дублирующиеся признаки.

Проблема 2. Идентификаторы сессий «Flow ID» имеют null значения (из 458968 записей после удаления осталось 170366 записей).

Проблема 3. Среди значений признаков «Flow Bytes/s» и «Flow Packets/s» встречаются нечисловые значения.

Чтобы разобраться с причинами первых проблем, решаем проверить оригинальное исследование: взять «сырой» трафик CICIDS2017 (напомним, датасет состоит из «сырых» данных в формате pcap и размеченных сетевых сессий в формате CSV), своим собственным инструментом, выделить в нём сетевые сессии и сформировать свой датасет. Наш датасет должен был совпасть с датасетом CICIDS2017.

Но датасеты не совпали. Дальнейшие исследования показали наличие проблем в исходном коде инструмента CICFlowMeter, который использовался при сборе и формировании набора данных CICIDS 2017.

Для поиска таких проблем мы обработали pcap файл с записанным трафиком своим собственным сниффером, выделили сетевые сессии и их признаки, сравнили с датасетом Thursday-WorkingHours-Morning-WebAttacks.pcap_ISCX.csv, пытаясь понять и исправить расхождения. Да, расхождения есть.

Анализируем сессию «Flow ID» = «192.168.10.14-65.55.44.109-59135-443-6», «Source IP» = «65.55.44.109». У канадских исследователей два последних пакета выделены в отдельную сессию? Внимательно просматриваем исходники их сниффера и находим подтверждение в методе addPacket. Да, действительно, при поступлении первого пакета с флагом FIN сессия считается завершенной. А возможные последующие пакеты (FIN, FIN ACK, ACK) будут выделены в отдельную сессию.

Такое решение нарушает спецификацию протокола TCP, которая предусматривает, что флаг FIN просто указывает на то, что отправитель завершил передачу данных. Однако TCP-соединение должно прерываться только тогда, когда обе стороны отправили друг другу пакет FIN. В исследовании «Troubleshooting an Intrusion Detection Dataset: the CICIDS2017 Case Study» авторы уточняют, что эти так называемые «TCP придатки» составляют 25,9% (!) от всего набора данных. И важно отметить, что эти отдельно выделенные сессии размечены и тем самым вносят ошибки в набор данных.

Проблема 4. Сессии завершаются некорректно: при первом появлении в сессии пакета с флагом FIN. Возможные следующие пакеты с флагами FIN, FIN ACK и ACK, фактически относящиеся к первой незавершенной сессии, попадают во вторую сессию. Это приводит к появлению в наборе данных большого количества сессий, состоящих из одного-двух пакетов, с нулевой длиной полезной нагрузки.

Также узнаем из исследования коллег, что инструмент CICFlowMeter содержит ещё одну ошибку: не рассматривается случай сброса TCP-соединения при поступлении пакета с флагом RST. Да, в последней версии инструмента ошибка исправлена, но датасет не был обновлён.

Проблема 5. Сессии завершаются некорректно: не учитывается случай завершения сессии при поступлении пакета с флагом RST.

При проверке всех условий завершения сессий обнаружили ещё одну проблему.

Проблема 6. В исходном коде инструмента CICFlowMeter установлено значение таймаута для сессии «flowTimeout», равное 120 секундам. Однако в описании набора данных CICIDS2017 и в документации инструмента указывается другое значение таймаута — 600 секунд.

Идём дальше. Для той же сессии в прямом направлении зафиксирован один пакет («Total Fwd Packets» = 1), при этом общая длина переданных пакетов в прямом направлении «Total Length of Fwd Packets» = 6. По данным Wireshark, длина пакета = 0. Откуда разница в 6 байт? «Спускаемся» от TCP до Ethernet и обнаруживаем «неучтенные» 6 байт в виде дополнения (padding) фрейма Ethernet. Мы соглашаемся с Wireshark и считаем, что не нужно включать эти 6 байт в длину TCP пакета.

Проблема 7. Ошибочно рассчитывается длина TCP пакета — длина дополнения (padding) фрейма Ethernet прибавляется к длине TCP пакета.

Проверяем остальные признаки для этой сессии, совпадают все значения, кроме «Average Packet Size» = 9. Как при двух пакетах по 6 байт получить значение 9, неясно. При этом «Packet Length Mean» = 6, совпадает.

Начинаем проверять другие сессии, и оказывается, что часто встречаются небольшие расхождения в признаках: «Packet Length Mean», «Packet Length Std», «Packet Length Variance», «Average Packet Size». Вскрытие (восстановление исходных слагаемых по значениям средних) показало, что при срабатывании таймаута сессии длина отбрасываемого пакета ошибочно учитывается в статистике.

Проблема 8. Значения признаков «Packet Length Mean» (средняя длина полезной нагрузки в пакетах всего потока), «Packet Length Std» (среднеквадратическое отклонение значения длины пакета), «Packet Length Variance» (дисперсия длины пакета) и «Average Packet Size» (средний размер пакета, совпадает по определению с признаком «Packet Length Mean») рассчитываются ошибочно. Ошибка связана с двойным учетом первого пакета в структуре данных со статистикой длин пакетов сетевой сессии (1, 2, 3).

Проблема 9. Признаки «Packet Length Mean» и «Average Packet Size» должны иметь одинаковое значение, однако по причине логической ошибки имеют различные значения. Ошибка состоит в том, что при завершении сессии по таймеру граничный пакет попадает в статистику длин пакетов, а счетчик количества пакетов (знаменатель в выражении для расчета значения признаков «Packet Length Mean» и «Average Packet Size») увеличивается только для одного из признаков (1, 2).

Следующая проблема связана с анализом subflows. Логика расчёта соответствующей группы признаков была неочевидной, пришлось даже открыть issue. К сожалению, авторы не ответили в issue, спустя пару месяцев исправили ошибку, но нас не уведомили. Изменения мы заметили сами через год, когда вернулись к анализу исходного кода, проблему закрыли тоже сами. Да, проблема в коде устранена, но версия датасета не была обновлена, и не появился раздел «Исправления и ошибки» на официальном сайте датасета.

Проблема 10. Признаки «Subflow Fwd Packets», «Subflow Fwd Bytes», «Subflow Bwd Packets», «Subflow Bwd Bytes» рассчитаны некорректно из-за логической ошибки в коде CICFlowMeter на момент сбора датасета.

Итак, подытоживаем, какие ошибки в датасете CICIDS2017 нам известны сегодня (на август 2024 года):

1. Некоторые признаки дублируются. Например, признаки «Fwd Header Length» и «Fwd Header Length.1» являются идентичными.

2. Идентификаторы сессий «Flow ID» имеют null значения.

3. Среди значений признаков «Flow Bytes/s» и «Flow Packets/s» встречаются нечисловые значения.

4. Сессии завершаются некорректно: при первом появлении в сессии пакета с флагом FIN. Возможные следующие пакеты с флагами FIN, FIN ACK и ACK, фактически относящиеся к первой незавершенной сессии, попадают во вторую сессию. Это приводит к появлению в наборе данных большого количества сессий, состоящих из одного-двух пакетов, с нулевой длиной полезной нагрузки.

5. Сессии завершаются некорректно: не учитывается случай завершения TCP сессии при поступлении пакета с флагом RST. В последней версии инструмента CICFlowMeter ошибка исправлена, но датасет не был обновлён.

6. В исходном коде инструмента CICFlowMeter установлено значение таймаута для сессии «flowTimeout», равное 120 секундам. Однако в описании набора данных CICIDS 2017 и в документации инструмента указывается другое значение таймаута — 600 секунд.

7. Ошибочно рассчитывается длина TCP пакета — длина дополнения (padding) фрейма Ethernet прибавляется к длине TCP пакета.

8. Значения признаков «Packet Length Mean», «Packet Length Std», «Packet Length Variance» и «Average Packet Size» рассчитываются ошибочно.

9. Признаки «Packet Length Mean» и «Average Packet Size» должны иметь одинаковое значение, однако по причине логической ошибки имеют различные значения.

10. Признаки «Subflow Fwd Packets», «Subflow Fwd Bytes», «Subflow Bwd Packets», «Subflow Bwd Bytes» рассчитаны некорректно из-за логической ошибки в коде CICFlowMeter на момент сбора датасета.

Список из 10 пунктов выглядит красиво, но, к сожалению, это ещё не всё.

Ещё проблемы

Через два года, приступив к сбору собственного датасета веб-атак, мы фактически повторили часть экспериментов разработчиков набора данных CICIDS2017. И свои результаты сопоставили с оригинальными, обнаружив новые проблемы.

Эти проблемы носят другой характер, их точно нельзя назвать ошибками. Скорее, это обнаруженные особенности сбора датасета CICIDS2017, показывающие его неполноту:

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

• Анализ сессий с XSS атаками показал, что в наборе данных отмечены адреса только двух участвующих сторон: источника атаки и атакуемого веб-приложения. Реализация отраженных XSS атак без учёта третьей стороны носит ограниченный характер.

• В описании набора данных CICIDS2017 не указано, по какому протоколу осуществлялся доступ к атакуемому веб-приложению. Анализ исходных pcap файлов позволяет установить, что использовался протокол HTTP. Отсутствуют размеченные сессии для протокола HTTPS, доля трафика которого в реальных сетях существенно превышает долю трафика протокола HTTP.

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

Какой он, идеальный датасет?

Разобрав проблемы одного из наиболее цитируемых в мире датасетов для обучения систем обнаружения атак, невольно задаёшься вопросом: «Так каким он должен быть, идеальный датасет?»

Начать поиски ответа предлагается со статьи «A Survey of Network-based Intrusion Detection Data Sets», где представлен следующий перечень требований к идеальному датасету:

• Быть публично доступным.

• Содержать актуальный сетевой трафик.

• Сетевой трафик должен охватывать продолжительный временной интервал и содержать как все виды атак, так и нормальное пользовательское поведение, а также полезную нагрузку.

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

Авторы подчёркивают, что такой датасет в настоящий момент не существует. И он вряд ли когда-либо будет создан.

Мы согласны с тезисом, что невозможно создать идеальный датасет. Но считаем, что создание приближенных к идеальным, эталонных наборов данных необходимо в интересах развития предметной области. И одной из своих ближайших задач выбрали разработку таких наборов данных.

Разработчики датасета CICIDS2017 в работе «An Evaluation Framework for Intrusion Detection Dataset» представили свои требования. Главные среди них: обеспечить разнообразие сетевого оборудования, компьютеров и операционных систем в тестовой инфраструктуре, разнообразие потоков сетевого трафика по разным направлениям, разнообразие протоколов и типов атак, разметить данные атак и чистый трафик.

И ещё несколько важных для нас дополнений из статьи «Troubleshooting an Intrusion Detection Dataset: the CICIDS2017 Case Study». Набор данных должен быть воспроизводимым. А также должен быть снабжён документацией и метаданными сбора данных, включая подробную информацию о сетевой инфраструктуре и смоделированных сценариях атак.

Свой обобщённый взгляд на проблему сбора идеального датасета мы представили в статье: «Методика сбора обучающего набора данных для модели обнаружения компьютерных атак».

Выводы

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

2. Да, у нас есть вопросы по аккуратности разметки данных набора CICIDS2017. Да, известны десятки проблем этого датасета. Но при этом мы благодарим авторов CICIDS2017 за их труд: на этих данных обучены сотни (если не тысячи) моделей обнаружения атак во всём мире. Канадские исследователи опубликовали этот датасет и избавили всех нас от, пожалуй, самого скучного и трудоёмкого этапа машинного обучения: сбора и подготовки исходных данных.

3. Мы огорчены, что наши отчёты об обнаруженных проблемах, отправленные по разным каналам в CIC (на рабочую почту CIC, в личной переписке с авторами, в issues на github), остались без ответа. Уверены, публичное исправление ошибок только усилило бы датасет. Если когда-либо мы решимся опубликовать свой датасет, то будем более открытыми к критике сообщества.

4. Использование публичных датасетов — удел академических исследователей. Для сравнения своей модели с работами других авторов на одних и тех же данных неизвестного качества — да, подойдёт. Разработчики «боевых» систем используют свои собственные датасеты, непубличные.

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

В заключение следует сказать, что история с проблемами датасета CICIDS2017 для нас завершена. В апреле 2024 года во всех открытых issues в репозитории инструмента разметки CICFlowMeter поступил одинаковый ответ от автора. Примерного содержания: «Дорогие друзья, мы рады анонсировать первую версию нового инструмента разметки NetFlowLyzer, в котором решены проблемы CICFlowMeter».

Значит, пора перевернуть страницу. И до новых встреч в новых постах, где мы проверим новый инструмент разметки и новые датасеты, собранные с его помощью!

В титульном изображении использован плакат «Нет!» Виктора Говоркова.