Нещодавно, Splunk додав ще одну модель ліцензування - ліцензування на основі інфраструктури (). Вони вважають кількість ядер CPU під серверами зі Splunk. Дуже нагадує ліцензування Elastic Stack, там вважають кількість нод Elasticsearch. SIEM-системи традиційно недешеве задоволення і зазвичай стоїть вибір між заплатити багато і дуже багато. Але, якщо застосувати кмітливість, можна зібрати подібну конструкцію.
Виглядає крипово, але іноді така архітектура працює у проді. Складність вбиває безпеку, а загальному випадку вбиває все. Насправді, для таких кейсів (я для зниження вартості володіння) існує цілий клас систем - Central Log Management (CLM). Про це , Вважаючи їх недооціненими. Ось їх рекомендації:
- Використовуйте можливості та інструментальні засоби CLM, якщо існують обмеження щодо бюджету та персоналу, вимоги до моніторингу безпеки та конкретні вимоги до варіантів використання.
- Впроваджуйте CLM для розширення функцій збору та аналізу журналів, коли SIEM-рішення виявилося занадто дорогим або складним.
- Інвестуйте в інструменти CLM з ефективним сховищем, швидким пошуком та гнучкою візуалізацією для покращення розслідування/аналізу інцидентів безпеки та підтримкою пошуку загроз.
- Переконайтеся, що застосовні фактори та міркування враховані, перш ніж впроваджувати рішення CLM.
У цій статті поговоримо про відмінності підходів до ліцензування, розберемося з CLM та розповімо про конкретну систему такого класу. . Деталі під катом.
На початку цієї статті я розповів про новий підхід до ліцензування Splunk. Види ліцензування можна порівняти з тарифами на прокат автомобілів. Уявімо, що модель за кількістю CPU - це економічний автомобіль з необмеженим пробігом і бензином. Можна їхати куди завгодно без обмежень на відстані, але не можна їхати дуже швидко і, відповідно, проїжджати багато кілометрів на день. Ліцензування за обсягом даних схоже на спортивний автомобіль з моделлю оплати щоденного кілометражу. Можна хвацько навалювати і на великі відстані, але за перевищення денного ліміту кілометражу доведеться заплатити більше.
Щоб отримати вигоду від використання ліцензування навантаження, потрібно мати найменше можливе співвідношення ядер CPU до кількості завантажуваних ГБ даних. На практиці це означає щось на кшталт:
- Найменша можлива кількість запитів до завантажених даних.
- Найменша кількість можливих користувачів рішення.
- Як можна більш прості та нормалізовані дані (щоб не потрібно було витрачати цикли CPU на подальшу обробку та аналіз даних).
Найпроблемніша річ тут — нормалізовані дані. Якщо ви хочете, щоб SIEM була агрегатором усіх журналів в організації, це вимагає величезних зусиль при розборі та постобробці. Не забувайте, що потрібно продумати архітектуру, яка не розвалиться від навантаження, тобто. потрібні додаткові сервери і, отже, додаткові процесори.
Ліцензування за обсягом даних ґрунтується на кількості даних, що відправляються в пащу SIEM. Додаткові джерела даних караються рублем (або іншою валютою) і це змушує задуматися про те, що не дуже хотілося збирати. Щоб обхитрити таку модель ліцензування, можна обкусати дані до їхньої інжекції в SIEM-систему. Один із прикладів такої нормалізації перед інжекцією — Elastic Stack та деякі інші комерційні SIEM.
У результаті маємо, що ліцензування за інфре ефективно, коли потрібно збирати лише певні дані з мінімальною передобробкою, а ліцензування за обсягом не дозволить збирати все. Пошук проміжного рішення наштовхує на такі критерії:
- Спрощення агрегації та нормалізації даних.
- Фільтрування шумових та найменш важливих даних.
- Надання можливостей аналізу.
- Відправлення відфільтрованих та нормалізованих даних до SIEM
В результаті цільовим SIEM-системам не потрібно буде витрачати додаткову потужність CPU на обробку і можна отримати вигоду з виявлення лише найважливіших подій без зниження видимості того, що відбувається.
В ідеалі, таке проміжне рішення має також забезпечувати можливості виявлення та реагування в реальному часі, які можна використовувати для зниження впливу потенційно небезпечних дій та агрегації всього потоку подій у зручний та простий квант даних у бік SIEM. Ну а далі SIEM можна використовувати для створення додаткових агрегацій, кореляції та процесів оповіщення.
Те саме загадкове проміжне рішення не що інше як CLM, про яке я згадував на початку статті. Ось таким його бачить Gartner:
Тепер можна спробувати розібратися, наскільки InTrust відповідає рекомендаціям Gartner:
- Ефективне сховище для об'ємів і типів даних, які потрібно зберігати.
- Висока швидкість пошуку.
- Можливості візуалізації — не те, що потрібно для базового CLM, але пошук погроз це як BI-система для забезпечення безпеки та аналізу даних.
- Збагачення даних для доповнення необроблених даних корисними контекстними даними (на зразок геолокації та інших).
Quest InTrust використовує власну систему зберігання зі стисненням даних до 40:1 та високою швидкістю дедуплікації, що знижує накладні витрати на зберігання для систем CLM та SIEM.
Консоль IT Security Search з google-like пошуком
Спеціалізований модуль із веб-інтерфейсом IT Security Search (ITSS) може підключатися до даних про події в репозиторії InTrust і надає простий інтерфейс для пошуку загроз. Інтерфейс спрощений настільки, що працює як Google для даних журналу подій. ITSS використовує тимчасові шкали для результатів запиту, може об'єднувати та групувати поля подій та ефективно допомагає при пошуку загроз.
InTrust збагачує події Windows ідентифікаторами безпеки, іменами файлів та ідентифікаторами входу до системи безпеки. InTrust також нормалізує події до простої схеми W6 (Who, What, Where, When, Whom та Where From — хто, що, де, коли, кого і звідки), щоб дані з різних джерел (власні події Windows, логи Linux або syslog) можна було бачити в єдиному форматі та на єдиній консолі пошуку.
InTrust підтримує функції оповіщення та виявлення в реальному часі, а також дії у відповідь, які можна використовувати в якості EDR-подібної системи, щоб мінімізувати збитки, викликані підозрілою активністю. Вбудовані правила безпеки виявляють, але не обмежуються виявленням таких загроз:
- Password-spraying.
- Kerberoasting.
- Підозріла PowerShell-активність, наприклад, виконання Mimikatz.
- Підозріли процеси, наприклад, LokerGoga ransomware.
- Шифрування за допомогою логів CA4FS.
- Входи із привелигерованим акаунтом на робочих станціях.
- Атаки із підбором пароля.
- Підозрювальне використання локальних груп користувачів.
Тепер покажу кілька скріншотів самого InTrust, щоб скластися враження про його можливості.
Передібрані фільтри для пошуку потенційних уразливостей
Приклад набору фільтрів для збирання сирих даних
Приклад використання регулярних виразів для створення реакції на подію
Приклад із правилом пошуку вразливостей PowerShell
Вбудована база знань із описом уразливостей
InTrust — це потужний інструмент, який можна використовувати як самостійне рішення, так і в складі SIEM-системи, як я описав вище. Напевно, основна перевага цього рішення, що його можна використовувати відразу після установки, т.к. InTrust має велику бібліотеку правил виявлення погроз та реакцій на них (наприклад, блокування користувача).
У статті я не розповів про коробкові інтеграції. Але одразу після установки можна налаштувати відправку подій у Splunk, IBM QRadar, Microfocus Arcsight або через вебхук будь-яку іншу систему. Нижче наведено приклад інтерфейсу Kibana з подіями з InTrust. З Elastic Stack інтеграція теж є і, якщо ви використовуєте безкоштовну версію Elastic, InTrust може використовуватися як інструмент для виявлення загроз, виконання попереджувальних сповіщень і відправлення повідомлень.
Сподіваюся, стаття дала мінімальне уявлення про цей продукт. Чи готові віддати InTrust вам на тест або провести пілотний проект. Заявку можна залишити в на нашому сайті.
Почитайте інші наші статті на тему інформаційної безпеки:
(популярна стаття)
Джерело: habr.com
