TS Total Sight. Засіб збору подій, аналізу інцидентів та автоматизації реагування на погрози

TS Total Sight. Засіб збору подій, аналізу інцидентів та автоматизації реагування на погрози

Доброго дня, у минулих статтях ми познайомились із роботою ELK Stack. А тепер обговоримо можливості, які можна реалізувати фахівцю з ІБ у використанні цих систем. Які логи можна і потрібно завести в еластичномудослідженні. Розглянемо, яку статистику можна отримати, налаштовуючи дашборди і чи є у цьому прибуток. Як можна впровадити автоматизацію процесів ІБ, використовуючи стек ELK. Складемо архітектуру роботи системи. У сумі, реалізація всього функціоналу це дуже велике та важке завдання, тому рішення виділили в окрему назву - TS Total Sight.

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

  1. Статистика та візуалізація;
  2. Виявлення інцидентів ІБ;
  3. пріоритизація інцидентів;
  4. Автоматизація процесів ІБ.

Далі детальніше розглянемо окремо.

Виявлення інцидентів ІБ

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

Можна навести стандартні приклади засобів захисту і не тільки звідки слід налаштувати пересилання логів:

  1. Будь-які засоби NGFW (Check Point, Fortinet);
  2. Будь-які сканери уразливостей (PT Scanner, OpenVas);
  3. Web Application Firewall (PT AF);
  4. Аналізатори Netflow (Flowmon, Cisco StealthWatch);
  5. AD-сервер.

Після того, як налаштували відправлення логів та конфігураційні файли в Logstash, можна скорелювати і порівняти з інцидентами, що надходять з різних засобів безпеки. Для цього зручно використовувати індекси, в яких зберігатимемо всі інциденти, що стосуються конкретного пристрою. Іншими словами, один індекс - це все інциденти до одного пристрою. Реалізувати такий розподіл можна двома способами.

Перший варіант це налаштувати конфіг Logstash. Для цього необхідно продублювати лог по певних полях в окрему одиницю з іншим типом. І потім надалі використовувати цей тип. У прикладі клонуються логи по блейду IPS міжмережевого екрану Check Point.

filter {
    if [product] == "SmartDefense" {
        clone {
	    clones => ["CloneSmartDefense"]
	    add_field => {"system" => "checkpoint"}
	}
    }
}

Для того щоб зберегти в окремий індекс такі події в залежності від полів логів, наприклад, такий як Destination IP сигнатури атаки. Можна використовувати подібну конструкцію:

output {
    if [type] == "CloneSmartDefense"{
    {
         elasticsearch {
    	 hosts => [",<IP_address_elasticsearch>:9200"]
    	 index => "smartdefense-%{dst}"
    	 user => "admin"
    	 password => "password"
  	 }
    }
}

І таким чином можна зробити збереження в індекс всіх інцидентів, наприклад, за адресою IP, або по доменного імені машини. У цьому випадку зберігаємо в індекс "smartdefense-%{dst}", за адресою IP адреси сигнатури.

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

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

І зрозуміло, найголовніше питання, а що взагалі можна корелювати та виявити?

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

  1. Найочевидніший і на мій погляд найцікавіший варіант для тих у кого є рішення NGFW і сканер уразливостей. Це порівняння логів IPS і результатів сканування вразливостей. Якщо була задетектована атака (не блокована) системою IPS, і ця вразливість не закрита на кінцевій машині виходячи з результатів сканування - необхідно трубити у всі труби, оскільки існує велика ймовірність того, що вразливість була проексплуатована.
  2. Багато спроб логіну з однієї машини в різні місця може символізувати про шкідливу активність.
  3. Завантаження користувачів вірусних файлів через відвідування у величезній кількості потенційно небезпечних сайтів.

Статистика та візуалізація

Найочевидніше і зрозуміліше, для чого потрібен ELK Stack - це зберігання та візуалізація логів, у минулих статтях було показано, як можна завести логи від різних пристроїв, використовуючи Logstash. Після того, як логи йдуть в Elasticsearch, можна налаштувати дашборди, про які теж згадували у минулих статтях, з необхідною для вас інформацією та статистикою у вигляді візуалізації.

приклади:

  1. Дашбоард за подіями Threat Prevention із найбільш критичними подіями. Тут можна відобразити якісь сигнатури IPS були виявлені, звідки територіально вони виходять.

    TS Total Sight. Засіб збору подій, аналізу інцидентів та автоматизації реагування на погрози

  2. Дашбоард щодо використання найбільш критичних додатків, за якими може зливатися інформація.

    TS Total Sight. Засіб збору подій, аналізу інцидентів та автоматизації реагування на погрози

  3. Результати сканування з будь-якого сканера безпеки.

    TS Total Sight. Засіб збору подій, аналізу інцидентів та автоматизації реагування на погрози

  4. Логи з Active Directory користувачам.

    TS Total Sight. Засіб збору подій, аналізу інцидентів та автоматизації реагування на погрози

  5. Дашбоард підключення VPN.

У цьому випадку, якщо налаштувати дашбоарди на оновлення кожні кілька секунд, можна отримати досить зручну систему для моніторингу подій у реальному часі, яку далі можна використовувати для найшвидшого реагування на інциденти ІБ, якщо поставити дашборди окремим екраном.

Пріоритизація інцидентів

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

Автоматизація процесів ІБ

І однією з найцікавіших елементів є автоматизація впливів на інциденти ІБ. Раніше цей функціонал ми реалізовували для Splunk, трохи докладніше, можете прочитати в цій статті. Основна ідея в тому, що політика IPS ніколи не перевіряється і не оптимізується, хоча в деяких випадках є найважливішою частиною інформаційної безпеки. Наприклад через рік після впровадження NGFW та відсутності дій з оптимізації IPS, у вас накопичиться велика кількість сигнатур з дією Detect, які не блокуватимуться, що сильно знижує стан ІБ в організації. Далі деякі приклади того, що можна автоматизувати:

  1. Переклад сигнатури IPS з Detect на Prevent. Якщо на критичні сигнатури не працює Prevent, то це не порядок, і серйозний пролом у системі захисту. Змінюємо дію у політиці на такі сигнатури. Реалізувати цей функціонал можна, якщо пристрій NGFW має функціонал REST API. Це можливо тільки володіючи навичками програмування, треба висмикувати потрібну інформацію з Elastcisearch і виконати запити API на сервер управління NGFW.
  2. Якщо з однієї IP-адреси в мережевому трафіку виявилося або заблокувалося безліч сигнатур, то є сенс заблокувати на деякий час цю IP-адресу в політиці Firewall. Реалізація також складається із використання REST API.
  3. Запускати перевірку хоста сканером уразливостей, якщо на цей хост припадає велика кількість сигнатур IPS або інших засобів безпеки, якщо це OpenVas, то можна написати скрипт, який буде підключатися по ssh на сканер безпеки і запускати сканування.

TS Total Sight. Засіб збору подій, аналізу інцидентів та автоматизації реагування на погрози

TS Total Sight

У сумі реалізація всього функціоналу це дуже велике та важке завдання. Не маючи навичок програмування, можна налаштувати мінімальний функціонал, якого може бути достатньо для використання в продуктивності. Але, якщо вас цікавить весь функціонал, ви можете звернути увагу на TS Total Sight. Більш детально ви можете ознайомитись на нашому сайті. В результаті вся схема роботи та архітектура буде виглядати таким чином:

TS Total Sight. Засіб збору подій, аналізу інцидентів та автоматизації реагування на погрози

Висновок

Ми розглянули, що можна реалізувати за допомогою ELK Stack. У наступних статтях окремо розглянемо детальніше функціонал TS Total Sight!

Так що слідкуйте за оновленнями (Telegram, Facebook, VK, TS Solution Blog), Яндекс.Дзен.

Джерело: habr.com

Додати коментар або відгук