Не совсем понял. Когда мы говорим про состязательное обучение, по сути, мы - как разработчики модели - встаём на сторону атакующего. И сами реализуем состязательную атаку против своей модели, чтобы найти состязательные примеры, корректно их разметить, добавить в обучающую выборку, повысить устойчивость модели.
Задача поиска состязательного примера для модели классификации ставится так: взять исходный несостязательный пример (в нашем случае из класса "атака") и "немного" изменить в нём значения признаков так, чтобы модель для этого примера изменила метку класса в ответе (чтобы ответ вместо "атака" стал "не атака"). И если при этом сохраняется действие атаки у найденного состязательного примера, то такой пример действительно обманывает модель, и он будет являться эффективным состязательным примером.
При постановке задачи поиска задаётся условие: расстояние (в каком-то смысле) между найденным состязательным примером и исходным примером должно быть минимальным или "малым". Грубо говоря, мы сами при генерации состязательных примеров можем указать эпсилон, которым отрегулируем эту "малость". И, фактически, не допускать ситуации, когда значения признаков будут "сильно" изменяться.
А ещё есть отдельное направление: "Generating Constraint-based Adversarial Examples". Пример статьи.
Генассамблея ООН не соглашается с вашим тезисом и неделю назад принимает резолюцию по искусственному интеллекту под названием: "Использование возможностей безопасных, защищенных и надежных систем искусственного интеллекта для устойчивого развития".
Что есть входные данные для модели. Что за 64 элемента, как они выглядят? Пример бы помог разобраться.
Как собирали датасет? С помощью BruteXSS и SQLmap? И можно посмотреть на датасет?
В матрице ошибок 64 элемента, а в таблице с количеством элементов тестовой выборки - 500. Почему так?
У вас одна единственная ошибка в матрице ошибок, метрики близки к единице. Надо покупать вашу модель. А вы сами знаете слабые места модели? Как поведёт себя в отношении других инструментов атак, какова обобщающая способность?
Будет здорово, если откроете код. Jupyter-блокнот с комментариями и ссылка на него в Google Colab. Это снимет многие вопросы и даст обратную связь по существу.
По оформлению и пояснениям выглядит так, что вы готовы к научной публикации. Идея на перспективу: найти подходящий публичный датасет, повторить исследование на нём, опубликовать статью на paperswithcode и проверить модель в честном, открытом, публичном бою.
Статья отличная, ставлю плюс. Приятно видеть такие исследования в песочнице, успехов!
Грубый пример, почему модель показывает неудовлетворительное качество. Допустим, сеть, где модель предобучалась, низкоскоростная. Тогда модель «запомнит», что при атаке типа brute force межпакетная задержка составляет 1 секунду, а при типовом пользовательском трафике — 1 минуту. Пусть признак «межпакетная задержка» будет единственным значимым.
Представим, что теперь мы эту предобученную модель запускаем на реальном трафике в высокоскоростной сети. Где при атаке brute force реальная межпакетная задержка сильно меньше — условно 1 миллисекунда. А нормальный трафик поступает с межпакетной задержкой 1 секунда. Модель начнет сильно ошибаться, выдавая ложные срабатывания «атака» при наблюдении типового пользовательского трафика.
Что делать? На поверхности два варианта:
1) Применить масштабирующее преобразование к данным обучения с целью опосредованного приведения в соответствие характеристик исходной сети (в которой осуществлялся сбор набора данных обучения) и защищаемой сети. В этом случае из признакового пространства следует исключить признаки, которые имеют различные значения при одинаковых условиях сбора трафика, но потенциально не масштабируемые.
2) Дообучить модель на данных, собранных в защищаемой сети, с целью повышения обобщающей способности модели и качества классификации.
По первому пункту (Elastic SIEM). Хорошие данные для обучения — секрет успеха. Совсем хорошо, когда эти данные собраны в реальной защищаемой сети. Банально, но убедился еще раз в эксперименте. Как в «боевой» системе собрать отдельно «чистый» и «грязный» трафик, чтобы хорошо обучить модель разделять их, — тот еще вопрос.
По второму пункту (Synology Router RT2600ac). Большое количество ложных срабатываний — известное слабое место эвристических систем обнаружения атак/вторжений. Но их сильная сторона — потенциальная возможность обнаруживать ранее неизвестные атаки. В теории выглядит так: рядом с сигнатурным анализатором (хорошо обнаруживает известное) ставим эвристический ML анализатор (хорошо обнаруживает неизвестное) и повышаем качество системы в целом.
Половина сайтов с информацией — нерабочие и сырые. Информация разбросана по куче разных мест. Описание api в google doc файле.
Да, путь разработчика сторонних интеграций не самый легкий. Мы для себя ведем отдельный документ, куда складываем все ссылки на все справки. И всё равно, навскидку не скажем, почему время сервисной печати printTime становится доступным в Delivery API только в момент печати накладной и так ли это будет при самовывозе.
Скудный функционал api, желания заказчика просто не реализовать без костылей.
У нас были ситуации, когда не хватало функционала Delivery API, но нужные методы находили или в Server API (например, вхождение заготовок в блюда), или в Front API (например, произвольная смена статуса заказа).
Тестовой среды нет.
Тестовую среду мы смогли получить, когда выразили желание стать партнером и получили доступ к партнерскому кабинету с демо-лицензиями. И это был квест тот еще. Для разработчиков плагинов для фронта в одной из справок есть раздел «Отладка».
Все временами падает.
Мы даже в комментариях к коду себе заметку оставляем: «Если при запуске скриптов с официальным тестовым аккаунтом наблюдаются ошибки, например [RabbitMq queue is not found (code 701)], стоит обратиться с запросом в поддержку».
И на Хабре давно зарегистрированы, и ник совсем не напоминает «джинсу», и ответ про сохраняющиеся сбои замечательный, и без такой подводки сразу личное сообщение, конечно же, не пишется.
Нет, после такого программного комментария мне дальше бесполезно оправдываться, мол, друзья, пост не рекламный.
Для автора (и, надеюсь, для читателей) ценность этой статьи — в истории по шагам, как провинциальная доставка еды может «вырасти» за год-два и что собственно было сделано для этого. И в том, какие грабли подстерегают рестораторов и автоматизаторов.
Сразу было понятно, что свои контакты будут лишними, даже упоминание города может превратиться в обсуждениях в самопиар. Но прятать название системы автоматизации, имена партнеров, интеграторов, конкурентов — нет, автор не может согласиться. Автор должен стремиться к уменьшению неопределенности знания, а не наоборот.
И будет ли этот рассказ полезен читателям, если убрать конкретное название системы автоматизации, архитектуру, бюджет, исходный код интеграций, отзыв о работе поддержки? Любое упоминание инструментов, которые мы используем, — к сожалению, всегда можно назвать рекламой (читаем словарь: «реклама — привлечение внимания к объекту рекламирования с целью формирования или поддержания интереса...»).
Эта статья прошла редакционный фильтр не с первого раза, как раз из-за вопросов рекламного характера. Были вырезаны лишние ссылки, лишние коммерческие имена собственные, введены сокращения по тексту. В общении с модератором автор открыл для себя дополнительный раздел правил Хабра: «Ослабляем гайки в правилах Хабра». Финальное решение редакции: если статья нарушает правила, но несёт знание и ценность для аудитории, статья не банится, скрывается в черновиках и отправляется автору на переработку.
На будущее автор для себя решил: с подобным форматом повествования черновик лучше заранее направить в редакцию.
1. Среди десятка разных источников событий и коннекторов предложенный в примере вариант c веб-сервером показался нам наиболее удачным. В итоговом сценарии открываем одновременно 4 окна: 1 — окно браузера с тестовым веб-приложением, 2 — окно коннектора, 3 — окно ядра корреляции, 4 — окно с консолью администратора. И слушатели, самостоятельно моделируя перебор пароля, наблюдают взаимосвязь разработанных компонентов и «превращение» отдельных событий безопасности в инцидент. Возможно субъективно, но пример с авторизацией в Windows кажется менее наглядным. Хотя, когда остается время и аудитория подготовленная, после предложенного ApacheConnector довольно быстро появляются и WMIConnector, и MysqlConnector, и SSHConnector, и другие.
2. XAMPP — быстро. MongoDB — чтобы познакомить с NoSQL/NewSQL. RabbitMQ — чтобы познакомить с брокерами сообщений на примере одного из самых популярных. PHP и C# — личные предпочтения.
3. Архитектура заимствована из известных источников (см. по тексту публикации). Наша задача состояла в том, чтобы с минимальными расхождениями продемонстировать рабочий пример, поясняющий суть процесса обработки событий безопасности. Эксперты, конечно же, заметят отличия (например, нормализация у нас реализована рядом с ядром корреляции, а по-хорошему нужно сдвигать ближе к коннектору), но спишем это на допустимую погрешность в целях повышения наглядности и простоты.
4. Уверены, предложенный пример поясняет функциональную модель SIEM системы лучше, чем в примере со стеком ELK. Разработки во втором случае меньше, но правильно ли это? Когда «своими руками» прочитал событие безопасности из файла, передал в канал, нормализовал, обработал, сформировал инцидент, отправил в хранилище и на экран консоли, то сразу разобрался.
Соглашаемся с тем, что вариантов передачи исходных событий от источника (в примере — веб-сервер Apache) к обработчику (ядру корреляции) известно множество. В самом начале даже предпринимались попытки использовать связку Filebeat > Logstash > RabbitMQ для этих целей (отказались по причине нетривиальности настроек). Детальное сравнение различных реализаций в рамках проекта не проводилось.
В наших условиях использование связки «простой пример приложения, отслеживающего изменения лог-файла источника данных» > RabbitMQ обусловлено в большей степени образовательными целями: познакомить слушателей с брокерами сообщений (как классом программных решений) и показать простоту реализации интерфейса в исходном коде коннектора.
Если честно, «сложного тут вообще» было немного: "… вместо запланированных нескольких часов пришлось разбираться весь день. И еще два дня на подготовку исследования для Хабра."
Статья писалась с простой целью — сэкономить время другим читателям Хабра на тот случай, если они столкнутся с подобной задачей (и я надеюсь, поисковики начнут выдавать этот пост для тех, кто ищет «парсинг сертификатов x.509 с#», рядом с публикацией Разбираем x.509 сертификат как хорошее дополнение). Так что, позвольте считать время, потраченное на поиск решения, показателем сложности.
Согласен, альтернативных решений может быть много. BouncyCastle выбран по понятной причине — чаще попадался на StackOverflow во время погружения в задачу, при этом простые примеры нужного нам обхода дерева после нескольких попыток так и не обнаружились.
Одна из идей третьей части (разработка парсера) — показать, что базовыми средствами .NET не очень удобно (читай, просто и логично) «прогуливаться» по дереву в поисках нужного OID'а.
Не совсем понял. Когда мы говорим про состязательное обучение, по сути, мы - как разработчики модели - встаём на сторону атакующего. И сами реализуем состязательную атаку против своей модели, чтобы найти состязательные примеры, корректно их разметить, добавить в обучающую выборку, повысить устойчивость модели.
Задача поиска состязательного примера для модели классификации ставится так: взять исходный несостязательный пример (в нашем случае из класса "атака") и "немного" изменить в нём значения признаков так, чтобы модель для этого примера изменила метку класса в ответе (чтобы ответ вместо "атака" стал "не атака"). И если при этом сохраняется действие атаки у найденного состязательного примера, то такой пример действительно обманывает модель, и он будет являться эффективным состязательным примером.
При постановке задачи поиска задаётся условие: расстояние (в каком-то смысле) между найденным состязательным примером и исходным примером должно быть минимальным или "малым". Грубо говоря, мы сами при генерации состязательных примеров можем указать эпсилон, которым отрегулируем эту "малость". И, фактически, не допускать ситуации, когда значения признаков будут "сильно" изменяться.
А ещё есть отдельное направление: "Generating Constraint-based Adversarial Examples". Пример статьи.
Генассамблея ООН не соглашается с вашим тезисом и неделю назад принимает резолюцию по искусственному интеллекту под названием: "Использование возможностей безопасных, защищенных и надежных систем искусственного интеллекта для устойчивого развития".
Есть вопросы по машинному обучению:
Что есть входные данные для модели. Что за 64 элемента, как они выглядят? Пример бы помог разобраться.
Как собирали датасет? С помощью BruteXSS и SQLmap? И можно посмотреть на датасет?
В матрице ошибок 64 элемента, а в таблице с количеством элементов тестовой выборки - 500. Почему так?
У вас одна единственная ошибка в матрице ошибок, метрики близки к единице. Надо покупать вашу модель. А вы сами знаете слабые места модели? Как поведёт себя в отношении других инструментов атак, какова обобщающая способность?
Будет здорово, если откроете код. Jupyter-блокнот с комментариями и ссылка на него в Google Colab. Это снимет многие вопросы и даст обратную связь по существу.
По оформлению и пояснениям выглядит так, что вы готовы к научной публикации. Идея на перспективу: найти подходящий публичный датасет, повторить исследование на нём, опубликовать статью на paperswithcode и проверить модель в честном, открытом, публичном бою.
Статья отличная, ставлю плюс. Приятно видеть такие исследования в песочнице, успехов!
Грубый пример, почему модель показывает неудовлетворительное качество. Допустим, сеть, где модель предобучалась, низкоскоростная. Тогда модель «запомнит», что при атаке типа brute force межпакетная задержка составляет 1 секунду, а при типовом пользовательском трафике — 1 минуту. Пусть признак «межпакетная задержка» будет единственным значимым.
Представим, что теперь мы эту предобученную модель запускаем на реальном трафике в высокоскоростной сети. Где при атаке brute force реальная межпакетная задержка сильно меньше — условно 1 миллисекунда. А нормальный трафик поступает с межпакетной задержкой 1 секунда. Модель начнет сильно ошибаться, выдавая ложные срабатывания «атака» при наблюдении типового пользовательского трафика.
Что делать? На поверхности два варианта:
1) Применить масштабирующее преобразование к данным обучения с целью опосредованного приведения в соответствие характеристик исходной сети (в которой осуществлялся сбор набора данных обучения) и защищаемой сети. В этом случае из признакового пространства следует исключить признаки, которые имеют различные значения при одинаковых условиях сбора трафика, но потенциально не масштабируемые.
2) Дообучить модель на данных, собранных в защищаемой сети, с целью повышения обобщающей способности модели и качества классификации.
По первому пункту (Elastic SIEM). Хорошие данные для обучения — секрет успеха. Совсем хорошо, когда эти данные собраны в реальной защищаемой сети. Банально, но убедился еще раз в эксперименте. Как в «боевой» системе собрать отдельно «чистый» и «грязный» трафик, чтобы хорошо обучить модель разделять их, — тот еще вопрос.
По второму пункту (Synology Router RT2600ac). Большое количество ложных срабатываний — известное слабое место эвристических систем обнаружения атак/вторжений. Но их сильная сторона — потенциальная возможность обнаруживать ранее неизвестные атаки. В теории выглядит так: рядом с сигнатурным анализатором (хорошо обнаруживает известное) ставим эвристический ML анализатор (хорошо обнаруживает неизвестное) и повышаем качество системы в целом.
У нас были ситуации, когда не хватало функционала Delivery API, но нужные методы находили или в Server API (например, вхождение заготовок в блюда), или в Front API (например, произвольная смена статуса заказа).
Тестовую среду мы смогли получить, когда выразили желание стать партнером и получили доступ к партнерскому кабинету с демо-лицензиями. И это был квест тот еще. Для разработчиков плагинов для фронта в одной из справок есть раздел «Отладка».
Мы даже в комментариях к коду себе заметку оставляем: «Если при запуске скриптов с официальным тестовым аккаунтом наблюдаются ошибки, например [RabbitMq queue is not found (code 701)], стоит обратиться с запросом в поддержку».
Нет, после такого программного комментария мне дальше бесполезно оправдываться, мол, друзья, пост не рекламный.
Сразу было понятно, что свои контакты будут лишними, даже упоминание города может превратиться в обсуждениях в самопиар. Но прятать название системы автоматизации, имена партнеров, интеграторов, конкурентов — нет, автор не может согласиться. Автор должен стремиться к уменьшению неопределенности знания, а не наоборот.
И будет ли этот рассказ полезен читателям, если убрать конкретное название системы автоматизации, архитектуру, бюджет, исходный код интеграций, отзыв о работе поддержки? Любое упоминание инструментов, которые мы используем, — к сожалению, всегда можно назвать рекламой (читаем словарь: «реклама — привлечение внимания к объекту рекламирования с целью формирования или поддержания интереса...»).
Эта статья прошла редакционный фильтр не с первого раза, как раз из-за вопросов рекламного характера. Были вырезаны лишние ссылки, лишние коммерческие имена собственные, введены сокращения по тексту. В общении с модератором автор открыл для себя дополнительный раздел правил Хабра: «Ослабляем гайки в правилах Хабра». Финальное решение редакции: если статья нарушает правила, но несёт знание и ценность для аудитории, статья не банится, скрывается в черновиках и отправляется автору на переработку.
На будущее автор для себя решил: с подобным форматом повествования черновик лучше заранее направить в редакцию.
1. Среди десятка разных источников событий и коннекторов предложенный в примере вариант c веб-сервером показался нам наиболее удачным. В итоговом сценарии открываем одновременно 4 окна: 1 — окно браузера с тестовым веб-приложением, 2 — окно коннектора, 3 — окно ядра корреляции, 4 — окно с консолью администратора. И слушатели, самостоятельно моделируя перебор пароля, наблюдают взаимосвязь разработанных компонентов и «превращение» отдельных событий безопасности в инцидент. Возможно субъективно, но пример с авторизацией в Windows кажется менее наглядным. Хотя, когда остается время и аудитория подготовленная, после предложенного ApacheConnector довольно быстро появляются и WMIConnector, и MysqlConnector, и SSHConnector, и другие.
2. XAMPP — быстро. MongoDB — чтобы познакомить с NoSQL/NewSQL. RabbitMQ — чтобы познакомить с брокерами сообщений на примере одного из самых популярных. PHP и C# — личные предпочтения.
3. Архитектура заимствована из известных источников (см. по тексту публикации). Наша задача состояла в том, чтобы с минимальными расхождениями продемонстировать рабочий пример, поясняющий суть процесса обработки событий безопасности. Эксперты, конечно же, заметят отличия (например, нормализация у нас реализована рядом с ядром корреляции, а по-хорошему нужно сдвигать ближе к коннектору), но спишем это на допустимую погрешность в целях повышения наглядности и простоты.
4. Уверены, предложенный пример поясняет функциональную модель SIEM системы лучше, чем в примере со стеком ELK. Разработки во втором случае меньше, но правильно ли это? Когда «своими руками» прочитал событие безопасности из файла, передал в канал, нормализовал, обработал, сформировал инцидент, отправил в хранилище и на экран консоли, то сразу разобрался.
В наших условиях использование связки «простой пример приложения, отслеживающего изменения лог-файла источника данных» > RabbitMQ обусловлено в большей степени образовательными целями: познакомить слушателей с брокерами сообщений (как классом программных решений) и показать простоту реализации интерфейса в исходном коде коннектора.
Статья писалась с простой целью — сэкономить время другим читателям Хабра на тот случай, если они столкнутся с подобной задачей (и я надеюсь, поисковики начнут выдавать этот пост для тех, кто ищет «парсинг сертификатов x.509 с#», рядом с публикацией Разбираем x.509 сертификат как хорошее дополнение). Так что, позвольте считать время, потраченное на поиск решения, показателем сложности.
Одна из идей третьей части (разработка парсера) — показать, что базовыми средствами .NET не очень удобно (читай, просто и логично) «прогуливаться» по дереву в поисках нужного OID'а.