У минулих статтях ми трохи ознайомилися зі стеком elk і налаштуванням конфігураційного файлу Logstash для парсера логів, в цій статті перейдемо до найважливішого з точки зору аналітики, що ви хочете побачити від системи і заради чого все створювалося - це графіки та таблиці об'єднані в дашборди. Сьогодні ми ближче ознайомимося із системою візуалізації КібанаРозглянемо як створювати графіки, таблиці, і в результаті побудуємо простенький дашборд на основі логів з міжмережевого екрану Check Point.
Першим кроком роботи з kibana - це створення index pattern, логічно, це база єдиних індексів за певним принципом. Зрозуміло, це виключно налаштування для того, щоб Kibana зручніше шукала інформацію за всіма індексами одночасно. Задається вона в порівнянні рядка, допустимо "checkpoint-*" і назви індексу. Наприклад, "checkpoint-2019.12.05" підійде під патерн, а просто "checkpoint" вже немає. Окремо варто згадувати, що в пошуку шукати інформацію з різних патерн індексів одночасно не можна, трохи пізніше в наступних статтях ми побачимо що API запити робляться або за назвою індексу, або як раз по одному рядку патерну, картинка клікабельна:
Після цього перевіряємо в меню Discover, що всі логи індексуються і налаштований правильний парсер. Якщо виявляться якісь невідповідності, наприклад, змінити тип даних з рядка на ціле число, необхідно відредагувати конфігураційний файл Logstash, в результаті нові логи записуватимуться правильно. Для того, щоб старі логи до зміни набули потрібного вигляду, допомагає лише процес реіндексації, у наступних статтях ця операція буде розглянута більш детально. Переконаємося, що все гаразд, картинка клікабельна:
Логи опинилися на місці, отже, можна розпочати побудову дашбордів. На основі аналітики дашбордів від security продуктів можна зрозуміти стан ІБ в організації, наочно побачити вразливі місця в поточній політиці, і надалі виробити способи їх усунення. Збудуємо невеликий дашборд, використовуючи кілька засобів візуалізації. Дашборд складатиметься з 5 компонентів:
- таблиця для підрахунку сумарної кількості логів за блейдами
- таблицю з критичних сигнатур IPS
- кругову діаграму за подіями Threat Prevention
- діаграма по найпопулярнішим відвідуваним сайтам
- діаграма з використання найбільш небезпечних програм
Для створення фігур візуалізації потрібно перейти в меню Візуалізувати, та вибрати потрібну фігуру, яку хочемо побудувати! Ходімо по порядку.
Таблиця для підрахунку сумарної кількості логів за блейдами
Для цього виберемо фігуру Таблиця даних, провалюємося в оснастку для створення графіків, зліва проставляється налаштування фігури, справа то як вона виглядатиме в поточних налаштуваннях. Спочатку продемонструю як виглядатиме готова таблиця, після цього пройдемо за налаштуваннями, картинка клікабельна:
Більш детальні налаштування фігури, картинка клікабельна:
Розберемо налаштування.
Спочатку налаштовується метрика, це значення, яким будуть агрегуватися всі поля. Метрики обчислюються з урахуванням значень, витягнутих тим чи іншим способом із документів. Значення зазвичай витягуються з полів документа, але можуть бути згенеровані з використанням скриптів. В даному випадку ставимо в Aggregation: Count (Сумарна кількість логів).
Після цього ділимо таблицю за сегментами (полями), якими вважатиметься метрика. Цю функцію виконує налаштування Buckets, яке у свою чергу складається з 2 варіантів налаштування:
- split rows - додавання колон і в подальшому поділ таблиці на рядки
- split table - розподіл на кілька таблиць за значеннями певного поля.
В Відра можна додати кілька поділок до створення кількох стовпців чи таблиць, обмеження тут швидше стоять логічні. В aggregation можна вибрати яким способом відбуватиметься поділ на сегменти: ipv4 range, date range, Terms тощо. Найбільш цікавим вибором є саме Умови використання и Significant Terms, Поділ на сегменти проводиться за значеннями певного поля індексу, різниця між ними полягає в кількості значень, що повертаються, і їх відображення. Оскільки ми хочемо поділити таблицю за назвою блейдів, вибираємо поле. product.keyword і задаємо розмір у кількості 25 значень, що повертаються.
Замість рядків в elasticsearch використовується 2 типи даних - текст и ключове слово. Якщо ви хочете здійснити повнотекстовий пошук, ви повинні використовувати тип text, дуже зручна річ при написанні свого пошукового сервісу, наприклад, шукаєте згадку слова у конкретному значенні поля (тексту). Якщо ви хочете тільки точний збіг, ви повинні використовувати тип keyword. Також тип даних keyword слід використовуватиме полів, які вимагають сортування чи агрегації, тобто, у разі.
В результаті Elasticsearch вважає кількість логів за певний час з агрегуванням за значенням у полі продукції. У Custom Label задаємо назву колони, яка відображатиметься в таблиці, задаємо час за який збираємо логи, запускаємо промальовування — Kibana відправляє запит до elasticsearch, чекає на відповідь і після візуалізує отримані дані. Таблиця готова!
Кругова діаграма за подіями Threat Prevention
Певний інтерес представляє інформація, а скільки взагалі у відсотковому співвідношенні реакцій виявляти и запобігати на інциденти ІБ у поточній безпековій політиці. Для цього добре підходить кругова діаграма. Вибираємо в Visualize - Кругова діаграма. Також у метриці задаємо агрегацію за кількістю ліг. У buckets ставимо Terms => action.
Начебто все правильно, але в результаті показуються значення по всіх блейдах, потрібно відфільтрувати тільки за тими блейдами, які працюють в рамках Threat Prevention. Тому обов'язково налаштовуємо фільтр для того, щоб шукати інформацію тільки по блейдах відповідальні за інциденти ІБ - product: (Anti-Bot OR New Anti-Virus OR DDoS Protector OR SmartDefense OR Threat Emulation). Картинка клікабельна:
І більш детальні налаштування, картинка клікабельна:
Таблиця за подіями IPS
Далі дуже важливим з погляду ІБ є перегляд та перевірка подій по блейду IPS и Емуляція загрози, які не блокуються поточною політикою, щоб потім або перевести сигнатуру в prevent, або якщо трафік валідний - не перевіряти сигнатуру. Таблицю створюємо також як і для першого прикладу, тільки з тією відмінністю, що створюємо кілька колон: protections.keyword, severity.keyword, product.keyword, originsicname.keyword. Обов'язково налаштовуємо фільтр для того, щоб шукати інформацію тільки по блейдах відповідальні за інциденти ІБ - product: (SmartDefense OR Threat Emulation). Картинка клікабельна:
Більш детальні налаштування, картинка клікабельна:
Діаграми по найпопулярнішим відвідуваним сайтам
Для цього створюємо фігуру Вертикальна смуга. Метрику також використовуємо count (вісь Y), а на осі X як значення будемо використовувати назву відвіданих сайтів - "appi_name". Тут є невелика хитрість, якщо запустити налаштування в поточному варіанті, то всі сайти будуть відзначатись на графіку одним кольором, для того щоб зробити їх різнокольоровими використовуємо додаткове налаштування - split series, яка дозволяє ділити вже готову колону на ще кілька значень, залежно від вибраного поля, звичайно! Це саме поділ можна або використовувати як одна різнокольорова колона за значеннями в режимі stacked, або в режимі normal для того, щоб створити кілька колон за певним значенням з осі X. У даному випадку тут ми використовуємо те саме значення, що і по осі X, це дає можливість зробити всі колонки різнобарвними, праворуч зверху вони позначатимуться квітами. У фільтрі задаємо — product:«URL Filtering» для того, щоб побачити інформацію тільки по відвіданим сайтам, картинка клікабельна:
Налаштування:
Діаграма з використання найбільш небезпечних програм
Для цього створюємо фігуру – Vertical Bar. Метрику також використовуємо count (вісь Y), а на осі X в якості значень будемо використовувати назву використовуваних додатків - "appi_name". Найбільш важливим є завдання фільтра - product: "Application Control" AND app_risk: (4 OR 5 OR 3) AND action: "accept". Фільтруємо логи по блейду Application control, беремо тільки ті сайти, які категоризовані як сайти з ризиком Critical, High, Medium і тільки в тому випадку, якщо на ці сайти дозволено. Картинка клікабельна:
Налаштування, клікабельно:
Дашборд
Перегляд та створення дашбордів знаходиться в окремому пункті меню. Інформаційна панель. Тут все просто, створюється новий дашборд, до нього додається візуалізація, розставляється по місцях і все!
Створюємо дашборд, яким можна буде зрозуміти базову ситуацію стану ІБ в організації, зрозуміло, лише на рівні Check Point, картинка клікабельна:
На основі цих графіків ми можемо зрозуміти, які критичні сигнатури не блокуються на міжмережевому екрані, куди ходять користувачі, які найбільш небезпечні програми вони використовують.
Висновок
Ми розглянули можливості базової візуалізації у Kibana та побудували дашборд, але це лише мала частина. Далі в курсі окремо розглянемо налаштування карт, роботу з системою elasticsearch, познайомимося з API запитами, автоматизацією та багато чого ще!
Так що слідкуйте за оновленнями (, , , ), .
Джерело: habr.com