Як підготувати / побудувати функції для виявлення аномалії (дані безпеки мережі)

Моя мета - проаналізувати мережеві журнали (наприклад, 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-адреса тощо тощо, не приносить нічого.

Тому я хотів би запитати, як обробляються текстові поля / функції, побудовані зазвичай для того, щоб зробити неможливим виявлення аномалії / випередження?

EDIT: структура даних.

У таблиці бази даних близько 100 стовпців, що містять інформацію з Active Directory Events. З цих 100 стовпців я вибираю найважливіші (з моєї точки зору): SubjectUser, TargetUser, SourceIPaddress, SourceHostName, SourcePort, Комп'ютер, DestinationIPaddress, DestinationHostName, DestinationPort, Action, Status, FilePath, EventID, WeekDay, DayTime.

Події - це події Active Directory, де EventID визначає, що було зареєстровано (наприклад, створення квитка Kerberos, вхід користувача, вихід з користувача тощо).

Зразок даних виглядає наступним чином:

+ ------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- - +
| ID | SubjectUser | TargetUser | SourceIPaddress | SourceHostName | SourcePort | Комп'ютер | ПризначенняIPadadress | DestinationHostName | DestinationPort | Дія | Статус | Файл | Шлях | EventID | WeekDay | DayTime |
+ ------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- - +
| 171390673 |? |? |? |? |? | domaincontroller1.domain.com | 1.1.1.1 | domaincontroller1.domain.com |? | / Аутентифікація / Перевірка | / Успіх | | 4624 | 1 | 61293 |
+ ------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- - +
| 173348232 | |? |? |? |? | domaincontroller2.domain.com | 2.2.2.2 | domaincontroller2.domain.com |? | / Аутентифікація / Перевірка | / Успіх | | 4624 | 1 | 61293 |
+ ------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- - +
| 180176916 |? |? |? |? |? | domaincontroller2.domain.com | 2.2.2.2 | domaincontroller2.domain.com |? | / Аутентифікація / Перевірка | / Успіх | | 4624 | 1 | 61293 |
+ ------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- - +
| 144144725 |? | John.Doe | 3.3.3.3 | domaincontroller3.domain.com | 2407 | domaincontroller3.domain.com | 3.3.3.4 | domaincontroller3.domain.com |? | / Аутентифікація / Перевірка | / Успіх | | 4624 | 3 | 12345 |
+ ------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- - +

Всього у мене є близько 150 мільйонів подій. У різних подіях заповнюються різні поля, і не всі події пов'язані з входом / відходом користувача.

Я точно не є експертом з виявлення аномалії . Однак це цікава область, і ось два мої центи. По-перше, враховуючи вашу зауваження, що "відстань махаланобіса може бути застосована лише до нормально розподілених функцій". Я зіткнувся з деякими дослідженнями, які стверджують, що цю метрику все ж можна використовувати у випадках, коли ненормовані дані. Погляньте на себе в цьому документі та в цьому технічному звіті .

Я також сподіваюся, що ви знайдете корисні наступні ресурси щодо непідконтрольного виявлення аномалії (AD) в контексті безпеки ІТ-мережі , використовуючи різні підходи та методи: в цьому документі представлено геометричну рамку для непідконтрольного AD; цей документ , в якому використовується підхід кластеризації на основі щільності та сітки ; Ця слайди презентації , де згадується використання карт самоорганізації для AD.

Нарешті, я пропоную вам поглянути на мої відповіді, які, на мою думку, мають відношення до теми, і, таким чином, можуть бути корисними: відповідь на підходи щодо кластеризації , відповідь на кластеризацію , що не базується на відстані, і відповідь на варіанти програмного забезпечення для AD .

Перш за все, я думаю, що є деякі речі, на які, можливо, доведеться піти у відставку.

Одне важке обмеження, яке я бачу в цій проблемі, - це те, що ви, мабуть, повинні бути готові мати досить високу помилкову позитивну оцінку. Наскільки мені відомо, базовий показник записів, що входять до мережевої аномалії, є досить низьким (необхідне цитування). Назвемо це коефіцієнтом 1000: 1 заради аргументації. Тоді навіть якщо ви спостерігаєте за шаблоном, який в 100 разів частіше трапляється, якщо запис є вторгненням, то якщо він легітимний, Правило Байєса говорить, що задні шанси 10: 1, що трафік все ще легітимний.

Інша проблема полягає в тому, що деякі втручання важко виявити навіть в принципі . Наприклад, якщо хтось із соціальних служб привів мене до того, щоб подарувати їм мій комп'ютер, а потім вони увійшли в цю службу і завантажили один секретний файл, над яким я працював, це було б досить важко знайти. В основному, достатньо рішучий нападник може зробити свою нав'язливу поведінку майже довільно близькою до нормальної поведінки системи.

Крім того, ваші супротивники - це розумні, а не статистичні процеси, тому, якщо ви почнете виявляти якусь закономірність і вимикати її, вони можуть просто відповісти, більше не дотримуючись цієї схеми. Ось чому, наприклад, ви побачите безліч спам-повідомлень з пробілами між усіма літерами (пропонуючи вам " V I A G R A" або що завгодно). Спам-фільтри з'ясували, що рядок "віагра" - це спам, тому зловмисники просто почали робити щось інше.

З-за цього я думаю, що варто досить подумати над тим, які типи вторгнень, на вашу думку, варті зусиль, щоб мати можливість виявити. Тут звичайно є низько висячі фрукти, тому не дозволяйте ідеалам бути ворогом добра і намагайтеся придумати алгоритм, який може виявити всі вторгнення.

Що осторонь, поговоримо про низько висячі фрукти. Тут я думаю, що для вас може бути результативним перенести свою одиницю аналізу з окремих записів, на групу записів.

Наприклад, ви сказали, що половина всіх записів має унікальні комбінації полів. Але, мабуть, наприклад, більшість вихідних IP-адрес відображаються в більш ніж одній записи - саме інші поля в запиті змінюються і роблять комбінацію унікальною. Якщо ви групуєте запити за IP-адресою, ви можете задавати такі питання:

• Здається, деякі IP-адреси автентифікують як незвично багато користувачів (або незвично мало)?
• Чи мають деякі IP-адреси незвичайно велику кількість збоїв аутентифікації?
• Чи мають деякі IP-адреси незвичну схему часу доступу (наприклад, багато активності близько 3 ранку у часовому поясі або запити кожні 1 секунду протягом дня)?

Ви можете робити подібні речі для інших груп, наприклад, ім’я користувача:

• Чи автентифікується цей користувач з іншого комп’ютера, коли він раніше використовував той самий комп'ютер для всіх запитів?
• Невже цей користувач раптом торкається тієї частини файлової системи, якої вони ніколи не торкалися?

Я не знаю жодних нестандартних класифікаторів, які здаються особливо придатними для цього, оскільки потенційна поведінка ваших користувачів настільки різноманітна, і вас, мабуть, найбільше цікавлять зміни в поведінці з часом. Це означає, що ви, мабуть, хочете побудувати якусь модель того, що кожен користувач / IP / що завгодно може зробити в майбутньому, і позначте будь-які відхилення від цієї моделі. Але це досить інтенсивний процес, якщо ваші користувачі мають різні моделі поведінки!

Через цю складність, я думаю, наразі може бути більш продуктивним такий вид дослідницько-режимового аналізу, який я окреслював вище. Це, ймовірно, повідомить вам про те, які типи моделей є найцікавішими, і тоді ви можете почати використовувати химерні статистичні алгоритми для виявлення цих шаблонів.

Я думаю, що в першу чергу потрібно мати набір даних, який записує дані за період без атак. Цей набір даних повинен фіксувати варіанти, які притаманні системі, яка нормально поводиться. Я хочу наголосити на тому, що мова йде не про наявність анотованого набору даних.

Далі я б спробував поєднати всі (або підмножину) метрик в одну. Цей новий показник повинен відображати суму "сюрпризу". Наприклад, система з низьким значенням означає, що система працює нормально, пік високого значення / плато означає, що відбувається деяка швидка зміна. Тут я думаю про графіки стилів CUSUM або Shewhart.

Чи можете ви навести кілька прикладів наявних даних? Це в основному рядки, цифри, показники 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, яка використовує алгоритми виявлення аномалій. Опис системи та алгоритмів доступний у моїй роботі До системи комплексного аналізу подій безпеки у масштабних мережах

Крім того, я написав короткий підсумок про те, як поводитися з такими даними у своїй відповіді на подібне запитання щодо Cross Validated