Обсуждение сценария использования

Команда специалистов по науке о данных и DevOps в Anno.Ai недавно столкнулась с проблемой создания масштабируемого конвейера машинного обучения (ML) для обработки данных захвата пакетов (PCAP) для сценария использования кибер-аналитики. Команда решила создать этот конвейер на базе Kubeflow, масштабируемой инфраструктуры машинного обучения с открытым исходным кодом, для размещения нашего конвейера и задач обработки.

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

  • Какие страны и места были в моей сети за последние 24 часа?
  • Где моя сеть?
  • Как выглядит базовый ежедневный трафик в моей сети?

Итак, что такое Kubeflow?

Более подробный пост здесь описывает, что такое Kubeflow и с чего начать. Вкратце: Kubeflow - это набор инструментов с открытым исходным кодом, предназначенный для автоматизации и масштабирования операций по разработке машинного обучения, который изначально использовался внутри компании Google как упрощенный способ запуска заданий TensorFlow в Kubernetes. Kubeflow достигает этого за счет использования преимуществ фреймворков оркестровки контейнеров, часто Kubernetes. По своей сути Kubeflow предлагает сквозную оркестровку стека машинного обучения для эффективного развертывания, масштабирования и управления сложными рабочими процессами машинного обучения. Kubeflow позволяет развертывать модели в контейнерах на предприятии независимо от производственной платформы (GCP, AWS; OpenShift, Rancher, локальная инфраструктура; периферийные устройства и т. Д.). Kubeflow использует подход микросервисов при создании рабочих процессов машинного обучения в масштабе предприятия. Это позволяет специалистам по обработке данных эффективно сотрудничать и создавать решения для машинного обучения многократного использования, тем самым устраняя дублирование усилий.

Обзор нашей реализации Kubeflow

Наша команда DevOps разработала инструмент автоматической установки для установки Kubeflow на Amazon Web Services (AWS), AWS GovCloud и Google Cloud Platform. Установщик также был интегрирован с GitLab CI / CD, поэтому команды DevSecOps могли систематически развертывать Kubeflow из среды CI / CD. Развертывание Kubeflow было предварительно упаковано с установщиком Terraform, который устанавливал сеть между кластерами и другими необходимыми основополагающими деталями для развертывания наших кластеров Kubeflow. Мы построили нашу установку Kubeflow, основываясь на следующих предположениях и предпосылках:

Предположения

● Экземпляр MacOs / Linux с доступом в Интернет.

● Клиент Git

● Активная учетная запись AWS с учетными данными уровня администратора.

Предварительные требования к экземпляру (следующие компоненты использовались для поддержки развертывания и настройки Kubeflow на AWS).

● AWS CLI версии 1

● Terraform ›= 0,12

● КОПС ›= 1,16

● Шлем ›= 3.0

● kfctl 0.7–1.0-rc

Обзор нашего подхода к машинному обучению для определения базового уровня PCAP и обнаружения аномалий

Чтобы справиться с масштабом и плотностью функций данных PCAP, мы выбрали подход машинного обучения, основанный на структуре автоэнкодера Kitsune со следующими характеристиками, которые оказались привлекательными для нашего варианта использования:

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

Мы разработали инструментарий системы обнаружения вторжений (NIDS) на основе искусственной нейронной сети (ИНС), который работает онлайн, не контролируется и эффективен с точки зрения вычислений. Подход машинного обучения состоит из процесса извлечения признаков, процесса сопоставления признаков и процесса обнаружения аномалий. В базовом алгоритме машинного обучения используется ансамбль нейронных сетей, называемых автоэнкодерами, для различения нормального и аномального трафика. Характеристики, извлеченные из сетевого трафика, отображаются на видимые нейроны ансамбля, затем каждый автокодировщик пытается восстановить характеристики экземпляра. Среднеквадратичный показатель (RMSE) определяет, когда этот процесс восстановления дает ошибку. Значения RMSE из ансамбля подаются в автоэнкодер окончательного вывода, который объединяет их, чтобы определить, близок ли входящий трафик к базовой линии сети или является ли он аномальным.

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

Подход без учителя, используемый в модели автоэнкодера, может быть развернут как уже обученная модель в среде заказчика (начиная с потенциально более высокой точности, но на основе обучения из предыдущих наборов данных) или развернут с нуля. Развертывание архитектуры автоэнкодера с нуля позволило бы изучить все уникальные поведения сети без каких-либо априорных знаний, тем самым гарантируя, что модель точно соответствует сетевым шаблонам в развернутой среде. Автоэнкодер также можно развернуть в качестве предварительно обученной модели, если группа специалистов по науке о данных Anno.Ai сочтет, что данные PCAP целевой среды и шаблоны тесно связаны с данными обучения, используемыми для предварительно обученной модели.

Почему Kubeflow подходит для этого варианта использования

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

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

Прием и анализ данных:

Мы использовали Kubeflow для масштабирования нашего парсера PCAP, написанного на языке GO. Это оказалось бесценным, поскольку для быстрого извлечения множества полей протокола, на которые мы нацелились, нам нужна была скорость не меньше всего остального. Мы использовали постоянное хранилище BLOB-объектов для хранения необработанных файлов PCAP, а затем использовали постоянные тома для удовлетворения наших потребностей в постоянном хранении данных по мере завершения каждого задания в конвейере.

Команда также сочла чрезвычайно полезным инструмент инженерии естественных данных Kubeflow, Argo. Argo также использует собственный контейнерный ETL таким образом, чтобы минимизировать операционные издержки. Масштабируемое выполнение, распараллеливание, версионные рабочие процессы и согласованное развертывание в средах разработки и производства - все это сделало процесс разработки данных эффективным.

Инженерия данных:

Мы использовали Kubeflow для очистки данных, чтобы гарантировать, что все наши измерения PCAP были извлечены и нормализованы (например, для преобразования временных меток в стандартное время UNIX). Мы обогатили наши данные PCAP геолокационной информацией с помощью базы данных MaxMind.

Kubeflow был особенно полезен и важен для масштабирования ресурсов, необходимых для разработки функций. В частности, для этого шага нам потребовались графические процессоры для запуска нашего Jupyter Notebook, который содержал наши шаги по разработке функций. Это требовало предоставления различных типов машин, отличных от того, что мы использовали ранее (для всех предыдущих и последующих заданий требовались только графические процессоры), и нам также отчаянно нужно было использовать возможности автомасштабирования для того, что в конечном итоге оказалось семнадцатичасовым процессом для извлечения наших функций. Гибкость автомасштабирования и возможность предоставлять различные типы машин с помощью графических процессоров сэкономили нам время и деньги на всех этапах конвейера. Эта передача обслуживания, однажды спроектированная и настроенная, также была бесшовной от кластера, который выполнял очистку, обогащение, проверку данных и т. Д., До кластера, который запускал процесс разработки функций.

* в качестве примечания по науке о данных, мы использовали наше геообогащение, выполненное на этапе обогащения, для быстрого кодирования одной из наших функций, которые мы использовали для анализа. Команда сопоставила внутренние и внешние IP-адреса, присвоив «1» каждому IP-адресу с внешней геолокацией и «0» тем, которые не вернули геолокацию, в качестве приблизительного способа оценки и прогнозирования внутренних и внешних IP-адресов.

Возможности управления версиями данных для Kubeflow 0.7 могли бы быть лучше, но мы надеемся, что выпуск 1.0 начнет предоставлять нам эти функции.

Построение моделей и обучение

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

Еще одним преимуществом способности Kubeflow отслеживать и проводить эксперименты была гибкость нашей команды в тестировании разнообразной инфраструктуры, которая лучше всего работала с моделью, которую мы выбрали для тестирования и развертывания. Работа с Kubeflow в облачной среде еще больше улучшила это, где можно было изучить различные соотношения вычислительной мощности / вычислительной мощности / ОЗУ, чтобы максимизировать цену и время. Возможность выполнять обучение в распределенной, распараллеливаемой и масштабируемой среде также значительно ускорила эти два этапа.

В Kubeflow 0.7 многие возможности визуализации упущены (например, визуализация экспериментов, производительность обучения модели, отслеживание артефактов и метаданных и т. Д. Из самого Kubeflow), однако фреймворк Kubeflow довольно хорошо интегрируется с Tensorboard в качестве инструмента визуализации. Мы надеемся, что встроенные в Kubeflow возможности визуализации, которые позволят специалистам по обработке данных легко и автоматически визуализировать итерации и процессы обучения модели, будут улучшены в версии 1.0. Есть также некоторые упущенные возможности (которые, как мы * думаем *, могут быть решены в версии 1.0) для визуализации и отслеживания данных и управления версиями моделей.

Модельные операции

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

НЕ ТО, ЧТО ЗАПУСТИЛ KUBEFLOW БЫЛИ ВСЕ КОТЯТА И РАДУГИ.

Команда обнаружила, что после того, как начальные конвейеры созданы и сформированы, а общие рабочие процессы в рамках предприятия определены, закрепление и повторное использование этих компонентов, а время, необходимое для их создания, постепенно становится короче и проще со временем, требуя все меньше и меньше улюлюканья и споры между командами специалистов по обработке и анализу данных и DevSecOps. Тем не менее, создание окружающей среды оставалось сложной задачей. Значительные усилия были потрачены на настройку уникальных образов машин, образов контейнеров и требуемых зависимостей, необходимых для кода ML, и сопоставление их с правильными пакетами (например, GPU против CPU против TPU). Масштабирование узлов для масштабируемых процессов в различных облачных средах также оказалось проблемой.