Правильна кухня

Добрий день, колеги. Ось і підійшов черга третьою статті, присвяченій Security Operations Center.

Сьогоднішня публікація зачіпає найбільш важливий аспект будь-якого SOC – контент, пов'язаний з виявленням та аналізом потенційних інцидентів інформаційної безпеки. Це, в першу чергу, архітектура кореляційних правил у SIEM-системі, а також супутні листи, тренди, скрипти, налаштування коннекторів. У статті я розповім про весь шлях обробки вихідних логів, починаючи з обробки подій коннекторами SIEM-системи і закінчуючи використанням цих подій в кореляційних правилах і надалі життєвому циклі вже инцидентного спрацювання.



Як згадувалося в попередніх статтях, серцем нашого SOC є SIEM-система HPE ArcSight ESM. У статті я розповім про доопрацювання даної платформи за більш ніж чотирирічний процес еволюції і опишу поточний варіант налаштувань.

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

  1. скорочення часу підключення нового клієнта та налаштування коннекторів;
  2. профілювання основних активностей в інфраструктурі;
  3. зниження кількості помилкових спрацьовувань;
  4. підвищення інформативності та повноти сповіщення клієнта про зафіксованих потенційних інциденти.
Будь-яка SIEM має «з коробки» набір встановлених правил, які, зіставляючи події від джерел і накопичуючи порогові значення, можуть сповістити клієнта про зафіксованої аномалії – потенційний інцидент. Навіщо ж тоді потрібно дороге впровадження цієї системи, її налаштування, а також її підтримка силами інтегратора та власного аналітика?
Для відповіді на це питання я розповім, як влаштований життєвий цикл подій, що потрапляють у SIEM з джерел, який шлях від спрацювання правила до створення інциденту і сповіщення замовника.

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

Наприклад: Логи juniper netscreen для відстеження arp-спуфінга містять інформацію про ip-адреси і mac-адреси в різних рядках:

iso.3.6.1.4.1.3224.17.1.3.1.2.274 = IpAddress: 192.168.30.94
iso.3.6.1.4.1.3224.17.1.3.1.2.275 = IpAddress: 172.16.9.231
iso.3.6.1.4.1.3224.17.1.3.1.2.276 = IpAddress: 172.16.9.232
iso.3.6.1.4.1.3224.17.1.3.1.3.274 = Hex-STRING: AC 22 0B 74 91 4C
iso.3.6.1.4.1.3224.17.1.3.1.3.275 = Hex-STRING: 20 CF 30 9A 17 11
iso.3.6.1.4.1.3224.17.1.3.1.3.276 = Hex-STRING: 80 C1 6E 93 A0 56

При написанні коннектора можна відразу зробити merge для відображення всієї інформації в одній події. При цьому ключове поле merge в даному випадку – це iso.3.6.1.4.1.3224.17.1.3.1.*.276.


Далі предобработанное подія відправляється в ядро системи HPE ArcSight, де відбувається його подальша обробка. В рамках Solar JSOC ми використовували всі етапи обробки подій, щоб розширити можливості моніторингу інцидентів і отримання інформації про кінцевих системах.

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

На жаль, можливості будь SIEM-системи за кількістю оброблюваних подій в секунду (EPS) і за обсягом наступних обчислень і обробки вихідних подій обмежені. В Solar JSOC на одну інсталяцію ArcSight ми заводимо кількох замовників, і потік подій від них досить високий. Загальний скоуп зафіксованих інцидентів досягає 100-150, що передбачає використання декількох сотень правил для обчислення, заповнення листів, генерації інцидентів та інше. При цьому для нас дуже важлива стабільність роботи системи і швидкий пошук подій за active channel'ам.

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

Наприклад, замість використання pre-persistence rules для уніфікації подій аутентифікації в різних системах, у тому числі, на мережевому обладнанні, ми на рівні map-файлів коннекторів вводимо категорії.

Map-файл для Cisco Router виглядає так:

event.eventClassId,set.event.deviceAction,set.categoryOutcome,set.event.categoryDeviceGroup
SEC_LOGIN:LOGIN_SUCCESS,Login,Success,/JSOC/Authentication
SEC_LOGIN:LOGIN_FAILURE,Login,Failure,/JSOC/Authentication
SYS:LOGOUT,Logout,Success,/JSOC/Authentication

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

Замість



пишемо:


Інше виноситься регулярними виразами в map-файл.

Яскравий приклад застосування фільтрації подій теж пов'язаний з DNS-серверами. На сервері коннекторів HPE ArcSight SmartConnector ми включаємо резолв імен хостів за адресами на коннекторах Windows і мережевому обладнанні. Таким чином кількість DNS-запитів з сервера коннекторів буває дуже значним, і всі ці події явно не потрібні для виявлення інцидентів, тому їх можна успішно фільтрувати для зниження навантаження на ESM.

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

Коли необхідно підключити, наприклад, NetScreen, який не дуже популярний у російських компаній, до Solar JSOC можна додавати події «permit» у всі правила, що стосуються, наприклад:
  • прямого доступу в інтернет в обхід проксі;
  • звернення до потенційно небезпечних хостам за версіями різних репутаційних баз;

  • сканування протоколів прикладного рівня і багато іншого.
А можна використовувати категоризацію чи готові фільтри. В Solar JSOC використовуються обидва методи в різних випадках. В даному випадку ми використовуємо фільтр Firewall_Pass:




Як видно з вищенаведених прикладів, ми використовуємо як штатну категоризацію ArcSight, якщо вона підходить під наші вимоги, так і власну, яка нам здалася універсальної.

Контент кореляційних правил

В рамках Solar JSOC ми прийшли до висновку, що зв'язка «базові-профілюючі-инцидентные правила» відмінно працює. Давайте зупинимося на кожному типі по порядку.

Базові правила

Базові правила служать для додавання події відсутньої інформації – імені користувача, інформації про власника облікового запису з кадрової системи, додатковий опис хостів з CMDB. Все це реалізовано в Solar JSOC і допомагає нам швидше розбирати інциденти і отримувати всю необхідну інформацію в обмеженому пулі подій. Зроблено це для того, щоб у нашої першої лінії завжди була можливість вкластися у відведені за SLA 20 хвилин на критичні інциденти і зробити при цьому дійсно якісний і повний розбір.

Профілюючі правила

Профілюючі правила для самих різних активностей відіграють одну з найважливіших ролей. Вони формують первинні дані, записувані в active list і в подальшому використовуються в наступних ситуаціях:

  1. Швидкий ретроспективний пошук активностей.
    До даних профілюючих правилами, наприклад, відноситься Profile_IA_Internet Access (Proxy). Це правило пише в аркуш всі переходи на сайти через проксі-сервер. Даний лист містить такі поля:



    Але лист має обмеження в 3 млн записів, тому щодня в нічний час ми заносимо дані в тренд, який має на порядок більше місця для зберігання.
    Даний лист використовується як при стандартному розслідування інцидентів, так і при ретроспективної перевірки індикаторів компрометації за тривалий проміжок часу – до 1 року.
  2. Створення і фіксація профілів.
    Наприклад, профілі аутентифікації або мережевого взаємодії з критичним хостам. Збір такого профілю займає від одного до двох тижнів, після чого вивантажується і відправляється клієнту. Відбувається узгодження і фіксація профілю, далі налаштовується инцидентное правило. Поява будь-якої активності, не потрапляє в профіль за заданими параметрами, викликає спрацьовування цього правила, розбір інциденту першою лінією і оповіщення клієнта.

    Для зручності зміни статусу ми використовуємо конфігураційний файл.



    При статусі (Сек йде збір профілю, при статусі Finished – починає працює инцидентное правило.
  3. Розрахунок середніх, максимальних і флуктуаційних показників.
    Правило «Аномальна статистика вірусної активності» працює саме за цим принципом. Ми вважаємо за певний період статистику щодо вірусних зараженням інфраструктури клієнта, і якщо в якийсь день відбувається сплеск – ми оповіщаємо клієнта про аномалії, так як вона може свідчити про спрямованих зловмисних дій з боку зловмисника.

Инцидентные правила

В Solar JSOC ми використовуємо наступні типи реєстрації аномальних активностей:

  1. за одиночного події з джерела;
  2. за кільком послідовним подій з одного або декількох джерел за виділений період;
  3. за настання одного і не настання іншої події за певний період;
  4. за досягнення порогового значення подій одного типу;
  5. за відхиленням статистичних показників від еталонного або середнього значення;
  6. осібно стоїть перевірка індикаторів компрометації.
Зупинимося докладніше на кожному з варіантів.

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

Одним з найбільш простих інцидентів є модифікацію критичних файлів на хості.



Правило дивиться безумовно файл /etc/hosts, а також всі критичні файли, зазначені в active list і узгоджені з клієнтом.

Послідовне спрацьовування кореляційних правил з кількох подій за період ідеально лягає в інфраструктурну безпеку.

Вхід під одним обліковим записом на робочу станцію і подальший вхід в цільову систему під іншим (або такий же сценарій з VPN і інформаційною системою) говорить про можливу крадіжку даних облікових записів. Така потенційна загроза зустрічається часто, особливо в повсякденній роботі адміністраторів (domain: a.andronov, Database: oracle_admin), і викликає велику кількість помилкових спрацьовувань, тому потрібні створення «білих списків» і додаткове профілювання.

Нижче наведено приклад спрацьовування на доступ до недозволеному сегменту мережі з пулу vpn:



А ось приклад третього типу інцидентних правил, яке налаштоване на детектування події виявлення вірусу і подальшого відсутності подій його видалення/лікування/приміщення на карантин:



Четвертий спосіб налаштування правил відмінно підходить для виявлення різних сканувань, брутфорса, епідемій та інше.

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



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

В якості прикладу можна навести кореляційне правило «INC_AV_Virus Anomaly Activity», яке відстежує перевищення середнього показника спрацьовувань антивіруса (обчислюється на підставі профілю) за певний період.



Що стосується перевірки індикаторів компрометації, то їх варто виділити окремим пунктом, тому що в їх відношенні здійснюється цілий комплекс робіт:

  1. проводиться ретроспективна перевірка індикаторів;
  2. індикатори заносяться в спеціальні листи для їх детектування в подальшому;
  3. після закінчення часу проводиться перегляд актуальності індикаторів компрометації.
Перший пункт включає в себе в першу чергу роботу з трендами і репортами, так як в них зберігається інформація за 6-12 місяців про відвідування інтернет-сайтів, запуску процесів, md5-суми запускаються в інфраструктурі виконуваних файлів, одержуваних від спеціалізованих засобів захисту або деяких антивірусних вендорів.

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

Розвиваючи Solar JSOC, ми зробили певні уроки, які стали основою для надання сервісу:

  1. Взаємодія з клієнтом і зворотний зв'язок від нього є найважливішим елементом в роботі Security Operations Center. Воно дозволяє краще зрозуміти процеси всередині замовника, а значить – створювати списки винятків для різних інцидентних правил і знизити кількість помилкових спрацьовувань в кілька разів. Для одного клієнта може бути абсолютно нормальним використання TOR на хості, а для іншого це прямий шлях до звільнення співробітника. У одних VPN-доступ мають тільки довірені адміністратори, які можуть працювати з усією інфраструктурою, у інших є доступ у половини співробітників, але працюють вони тільки зі своєю станцією.
  2. Збір профілів. Переважна більшість співробітників компанії працюють по одному і тому ж сценарію щодня. Його легко профілювати, отже, і аномалії виявляти досить просто. Тому в Solar JSOC ми використовуємо єдині правила, але параметри, списки, фільтри в них індивідуальні для кожного клієнта.
  3. Складні правила не працюють. Чим більше кількість уточнюючих умов і втягуються в кореляційне правило вихідних подій, тим менше шансів, що такий сценарій «злетить з коробки» у всіх замовників. Необхідно робити універсальні правила, а «підстроювання» робити на рівні винятків.
  4. SIEM повинна вирішувати тільки свої завдання. Не потрібно намагатися примушувати SIEM-систему вирішувати завдання Zabbix або рішення з детектування DDoS. Останнє мало того, що сильно «з'їдає» ресурси системи, так ще й не допоможе запобігти цей самий DDoS.
    При цьому хочеться відзначити: як би добре не була налаштована SIEM-система, false positive події будуть присутні завжди. Якщо їх немає, значить, SIEM мертвий. Але false positive також бувають різні. Скидання пароля топ-менеджера вночі може пояснюватися як несподіваним рішенням попрацювати з дому і неможливістю згадати пароль, так і діями зловмисника. Але бувають і ситуації, коли хибнопозитивні спрацьовування виникають на рівні техніки і на поточний момент не додані в инцидентное як правило штатні виключення. Саме тому важливо наявність кваліфікованих інженерів моніторингу, здатних виявити реальний інцидент. Фахівець повинен володіти набором знань з інформаційної безпеки, передбачати вектори можливих атак і знати кінцеві системи для аналізу подій.
Висновок

В якості висновку хотілося б підбити підсумок за рекомендаціями при організації власного SOC в компанії:

  1. Найважливішою ланкою SOC є SIEM-система, про питання вибору йшлося у першій статті циклу, але найбільш важливим моментом є її налаштування під потреби бізнесу і особливості інфраструктури.
  2. Створення кореляційних правил для виявлення різних сценаріїв атак і діяльності зловмисників – це величезний пласт робіт, які ніколи не закінчуються у зв'язку з постійним розвитком загроз. Саме тому необхідно наявність власного кваліфікованого аналітика в штаті компанії.
  3. Перша лінія інженерів моніторингу повинна формуватися на базі відділу інформаційної безпеки. Спеціаліст повинен вміти відрізняти хибнопозитивні спрацьовування від реальних інцидентів і проводити базовий аналіз подій. Для цього необхідні навички у сфері ІБ і розуміння можливих векторів атак.
В даній статті я не торкався питань реєстрації інциденту, його обробки першою лінією, критеріїв фільтрації помилкових спрацьовувань, механізму оповіщення клієнтів і проведення додаткових розслідувань. Цьому буде присвячена наступна стаття з циклу.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.