Моя цель - проанализировать сетевые журналы (например, Apache, syslog, аудит безопасности Active Directory и т. Д.), Используя кластеризацию / обнаружение аномалий для целей обнаружения вторжений.
Из журналов у меня много текстовых полей, таких как IP-адрес, имя пользователя, имя хоста, порт назначения, порт источника и т. Д. (Всего 15-20 полей). Я не знаю, есть ли какие-либо атаки в журналах, и хочу выделить наиболее подозрительные события (выбросы).
Обычно обнаружение аномалий отмечает точки с низкой вероятностью / частотой как аномалии. Однако половина записей журнала содержит уникальную комбинацию полей. Таким образом, половина записей в наборе данных будет иметь наименьшую возможную частоту.
Если я использую обнаружение аномалий на основе кластеризации (например, нахожу кластеры, а затем выбираю точки, которые находятся далеко от всех центров кластеров), мне нужно найти расстояние между различными точками. Так как у меня 15-20 полей, это будет многомерное пространство, где измерения - это имя пользователя, порт, IP-адрес и так далее. Однако расстояние Махаланобиса можно применять только к нормально распределенным объектам. Это означает, что нет способа найти расстояние между точками данных и построить кластеры ...
Например, давайте представим, что у меня есть пользователи Алиса, Боб, Кэрол, Дейв, Ева и Фрэнк в наборе данных из 20 записей. Они могут иметь следующее количество случаев в базе данных: 2,5,2,5,1,5. Если я просто сопоставить имена пользователей с номерами, например,
Alice --> 1
Bob --> 2
Carol --> 3
Dave --> 4
Eve --> 5
Frank --> 6
Тогда мое распределение вероятностей для имен пользователей будет выглядеть следующим образом:
p (1) = 0,1, p (2) = 0,25, p (3) = 0,1, p (4) = 0,25, p (5) = 0,05, p (6) = 0,25
Конечно, это не нормальный дистрибутив, и это также не имеет особого смысла, так как я мог бы сопоставить имена пользователей любым другим способом ...
Таким образом, простое сопоставление полей, таких как имя пользователя, действие, номер порта, IP-адрес и т. Д., С номерами ничего не приносит.
Поэтому я хотел бы спросить, как обрабатываются текстовые поля / функции, обычно создаваемые для того, чтобы сделать возможным обнаружение аномалии / выброса без присмотра?
РЕДАКТИРОВАТЬ: структура данных.
У меня есть около 100 столбцов в таблице базы данных, содержащей информацию из событий Active Directory. Из этих 100 столбцов я выбираю наиболее важные (с моей точки зрения): SubjectUser, TargetUser, SourceIPaddress, SourceHostName, SourcePort, компьютер, DestinationIPaddress, DestinationHostName, DestinationPort, действие, статус, FilePath, EventID, WeekDay, DayTime.
События - это события Active Directory, где EventID определяет, что было зарегистрировано (например, создание билета Kerberos, вход пользователя в систему, выход пользователя из системы и т. Д.).
Пример данных выглядит следующим образом:
+ ------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- - + | ID | SubjectUser | TargetUser | SourceIPaddress | SourceHostName | SourcePort | Компьютер | DestinationIPaddress | DestinationHostName | DestinationPort | Действие | Состояние | FilePath | EventID | WeekDay | WeekTay | DayTime | + ------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- - + | 171390673 | |? |? |? |? | domaincontroller1.domain.com | 1.1.1.1 | domaincontroller1.domain.com |? | / Authentication / Проверка | / Успех |? | 4624 | 1 | 61293 | + ------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- - + | 173348232 |? |? |? |? |? | domaincontroller2.domain.com | 2.2.2.2 | domaincontroller2.domain.com |? | / Authentication / Проверка | / Успех |? | 4624 | 1 | 61293 | + ------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- - + | 180176916 | |? |? |? |? | domaincontroller2.domain.com | 2.2.2.2 | domaincontroller2.domain.com |? | / Authentication / Проверка | / Успех |? | 4624 | 1 | 61293 | + ------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- - + | 144144725 | | John.Doe | 3.3.3.3 | domaincontroller3.domain.com | 2407 | domaincontroller3.domain.com | 3.3.3.4 | domaincontroller3.domain.com |? | / Authentication / Проверка | / Успех |? | 4624 | 3 | 12345 | + ------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- - +
Всего у меня около 150 миллионов событий. В разных событиях заполнены разные поля, и не все события связаны с входом / выходом пользователя из системы.
источник
Ответы:
Я определенно не эксперт по обнаружению аномалий . Тем не менее, это интересная область, и вот мои два цента. Во-первых, учитывая ваше замечание, что «расстояние Махаланобиса может быть применено только к нормально распределенным объектам». Я наткнулся на какое-то исследование, в котором утверждается, что этот показатель все еще можно использовать в случае ненормальных данных. Посмотрите сами на этот документ и этот технический отчет .
Я также надеюсь, что вы найдете полезными следующие ресурсы по обнаружению неконтролируемых аномалий (AD) в контексте безопасности ИТ-сети с использованием различных подходов и методов: в этом документе представлена геометрическая основа для AD без контроля; эта статья , в которой используется кластеризационный подход на основе плотности и сетки ; слайды этой презентации , в которых упоминается использование самоорганизующихся карт для AD.
Наконец, я предлагаю вам взглянуть на следующие мои ответы, которые, на мой взгляд, имеют отношение к теме и, таким образом, могут быть полезны: ответ на подходы кластеризации , ответ на кластеризацию без учета расстояний и ответ на варианты программного обеспечения для AD .
источник
Прежде всего, я думаю, что есть некоторые вещи, которым вы, возможно, придется смириться.
Одно серьезное ограничение, которое я вижу по этой проблеме, заключается в том, что вы, вероятно, должны быть готовы к довольно высокому уровню ложных срабатываний. Насколько я знаю, базовая скорость записей, являющихся частью сетевой аномалии, довольно низка (необходима цитата). Давайте назовем это коэффициентами 1000: 1, ради аргумента. Затем, даже если вы наблюдаете шаблон, который в 100 раз более вероятен, если запись является вторжением, тогда, если это законно, правило Байеса гласит, что последующие шансы равны 10: 1, что трафик все еще является законным.
Другая проблема заключается в том, что некоторые вторжения трудно обнаружить даже в принципе . Например, если кто-то с социальной точки зрения заставит меня отдать им мой компьютер, а затем они войдут в эту службу и загрузят один сверхсекретный файл, над которым я работал, это будет довольно сложно найти. По сути, достаточно решительный злоумышленник может сделать свое навязчивое поведение почти произвольно близким к нормальному поведению системы.
Более того, ваши противники - интеллектуальные, а не статистические процессы, поэтому, если вы начнете обнаруживать какой-то шаблон и отключать его, они могут просто ответить, не следуя этому шаблону. Вот почему, например, вы увидите много спам-сообщений с пробелами между всеми буквами (предлагая вам "
V I A G R A" или что-то еще). Спам-фильтры выяснили, что строка «виагра» была спамом, поэтому злоумышленники просто начали делать что-то еще.Из-за этого, я думаю, стоит задуматься о том, какие типы вторжений, по вашему мнению, стоит усилий, чтобы их можно было обнаружить. Здесь, безусловно, есть низко висящие плоды, поэтому не позволяйте идеалу быть врагом добра, а постарайтесь придумать алгоритм, который может обнаружить все вторжения.
Кроме того, давайте поговорим о низко висящих фруктах. Здесь, я думаю, вам может быть полезно перенести свою единицу анализа с отдельных записей на группу записей.
Например, вы сказали, что половина всех записей имеет уникальные комбинации полей. Но предположительно, например, большинство исходных IP-адресов появляются в более чем одной записи - это другие поля в запросе, которые меняются и делают комбинацию уникальной. Если вы группируете запросы по IP, вы можете задать такие вопросы:
Вы можете сделать аналогичные вещи для других группировок, например, имя пользователя:
Я не знаю ни одного готового классификатора, который кажется особенно подходящим для этого, потому что потенциальное поведение ваших пользователей настолько различно, и вы, вероятно, в основном интересуетесь изменениями поведения с течением времени. Это означает, что вы, вероятно, захотите построить какую-то модель того, что каждый пользователь / IP / что-либо может сделать в будущем, и пометить любые отклонения от этой модели. Но это довольно интенсивный процесс, если у ваших пользователей разные модели поведения!
Из-за этой трудности, я думаю, что на данный момент может быть более продуктивным провести анализ в исследовательском режиме, который я изложил выше. Это, вероятно, сообщит вам о том, какие типы шаблонов являются наиболее интересными, и тогда вы сможете начать использовать причудливые статистические алгоритмы для обнаружения этих шаблонов.
источник
Я думаю, что в первую очередь вам нужно иметь набор данных, который записывает данные за период без атак. Этот набор данных должен охватывать изменения, присущие системе, которая ведет себя нормально. Я хотел бы подчеркнуть, что речь идет не о наличии аннотированного набора данных.
Далее я бы попытался объединить все (или подмножество) метрик в одну. Эта новая метрика должна отражать количество «сюрпризов». Например, низкое значение означает, что система работает нормально, высокое значение пика / плато означает, что есть некоторые быстрые изменения. Здесь я думаю о диаграммах стиля диаграмм CUSUM или Шухарта.
Можете ли вы привести примеры доступных данных? Это в основном строки, цифры, 1/0 показателей?
источник
Возможность состоит в том, чтобы изучить байесовскую сеть между функциями, имеющими некоторые фоновые данные, без атак. Изучение байесовской сети полезно, поскольку она выявляет условную независимость между функциями. Следовательно, вы не имеете дело со всеми возможными комбинациями функций. Например, если функция A влияет на B и C, а функции B и C вместе влияют на D, то вы изучите модель только для того, как A влияет на B, как влияет на C и как B и C совместно влияют на D. Эта модель потребует гораздо меньше параметры, чем все распределение вероятностей и является основной причиной, по которой байесовские сети используются вместо того, чтобы просто хранить все совместное распределение вероятностей. Чтобы проверить аномалию для данной байесовской сети, рассчитайте вероятность входящего набора данных, используя модель изученной байесовской сети. Если вероятность очень низкая,
источник
Я думал, что ответ от Бена Куна был прагматичным и проницательным.
Теперь мой собственный опыт включает в себя классификацию текстов, экспертные системы, кластеризацию и безопасность. Учитывая это, я хотел бы подумать, что мне есть, что добавить к разговору. Но предыдущие заявления Бена Куна подчеркивают, что прямые подходы могут привести к множеству ложных срабатываний. ИТ-специалисты, когда сталкиваются со многими ложными срабатываниями, обычно «отключаются», потому что у них просто нет времени постоянно преследовать ложные срабатывания.
Так что делать?
Конечно, логи с атаками могут быть полезны, но тогда у нас есть ловушка 22, если компании каким-то образом не обмениваются данными о атаках. В то время как некоторые стартапы Силиконовой долины могут преследовать подобную угрозу, что еще мы можем сделать?
Один из возможных подходов - создать симуляцию сети, а затем найти способ генерировать атаки на симуляцию. То есть, предположим, что мы создаем симуляцию, в которой черные шляпы (также симулированные) не известны заранее белым шляпам. Учитывая эти атаки, мы можем затем попытаться создать алгоритмы, которые должны обнаруживать эти атаки. Если черные шляпы действуют независимо от белых, то у нас будет настоящая битва, которая закончится. Если злоумышленники проникли в систему или не были обнаружены, белые шляпы в некоторой степени потерпели неудачу.
Можно даже создать структуру стимулов, когда аналитики по безопасности из команды «Черной шляпы» будут вознаграждены за их успехи (штаны или неизвестные атаки). Аналогичным образом, группа, состоящая из белых шляп, вознаграждена за то, что остановила штаны и / или обнаружила атаки.
В этой договоренности нет ничего идеального. Очевидно, что настоящие черные шляпы могут превосходить таланты "дружелюбной" команды в черной шляпе. Тем не менее, как человек, который имеет достаточный объем анализа данных, мне кажется, что очень трудно количественно оценить успех белых шляп без лучшего понимания черных шляп. Итог это. Если мы не можем знать, что делают настоящие черные шляпы, следующая лучшая вещь - это дружелюбные черные шляпы.
У меня тоже есть довольно необычная идея. Предположим, в дополнение к дружелюбным черным шляпам и белым шляпам есть команда серых шляп. Что значит быть серой шляпой? Идея проста. Серым шляпам разрешено смотреть на то, что делают дружественные черные шляпы и белые шляпы. Но почему?
Предположим, что дружественные черные шляпы запускают атаки, используя подходы A, B и C, и белые шляпы никогда не обнаруживают ни один из этих трех подходов. Что ж, серые шляпы уполномочены смотреть на то, что делают и дружественные черные шляпы, и белые шляпы, и они пытаются рассмотреть, какие принципы могут быть использованы для обнаружения этих необнаруженных атак. Если серая шляпа находит такие принципы, серая шляпа может затем поделиться этими принципами с белой шляпой без подробного описания точных атак.
Надежда состоит в том, что эти "подсказки", предоставленные командой по серой шляпе, дают команде белой шляпе толчок в правильном направлении, не раскрывая слишком много.
Оглядываясь назад, я прошу прощения, если мой ответ на самом деле не о конкретных методах. Очевидно, мой ответ не о конкретных методах. Но по моему опыту, многие проблемы в машинном обучении, в том числе в области безопасности, часто терпят неудачу, потому что данные неадекватны. Этот подход, использующий белые шляпы, серые шляпы и черные шляпы, может помочь получить данные, которые позволят компании по обеспечению безопасности (или ИТ-персоналу) не только количественно оценить эффективность своей защиты, но и обеспечить организационную структуру, которая подталкивает команду белых шляп. постепенно улучшать свою защиту и контроль.
Я действительно понятия не имею, оригинален ли предлагаемый мной подход. Я никогда не слышал о серых шляпах, но на самом деле я думаю, что роль серых шляп может иметь решающее значение для продвижения белой команды вперед, не раскрывая слишком много.
Примечание: мое использование термина «серая шляпа» здесь не является стандартным. См. Http://www.howtogeek.com/157460/hacker-hat-colors-explained-black-hats-white-hats-and-gray-hats/ . Так что вместо этого следует использовать другой термин, возможно, «полосатая шапка».
Но идея остается прежней: полосатая шляпа может помочь в посредничестве между работой дружественных черных шляп и защитников (белых шляп), так что определенные идеи и советы могут быть разумно разделены с белыми шляпами.
источник
Поскольку я разместил исходный вопрос, я провел много исследований по этой теме и теперь могу предоставить свои результаты в качестве ответа.
Прежде всего, в нашей лаборатории мы разрабатываем систему SIEM, которая использует алгоритмы обнаружения аномалий. Описание системы и алгоритмов доступно в моей статье « На пути к системе для комплексного анализа событий безопасности в крупных сетях».
Кроме того, я написал краткое резюме о том, как обращаться с такими данными, в своем ответе на аналогичный вопрос о перекрестной проверке.
источник