JSOC: як виміряти доступність Security Operation Center?

    Добрий день. Ми продовжуємо серію статей «з-за лаштунків» Jet Security Operation Center. Коли йдеться про «хмарному» сервісі, завжди постає питання про кількість «9 після коми» в показниках його доступності. Мені б хотілося розповісти про те, з чого складається доступність SOC з точки зору «заліза» і ВО і якими засобами ми контролюємо цю доступність. Стаття буде набагато більш технічною, тому попрошу читачів запастися терпінням.
 
Підсумкова мета нашого сервісу (JSOC) — виявлення та оперативний аналіз виникаючих у замовників інцидентів ІБ. Це створює три основних вимоги до його доступності:
 
 
     
Платформа збору та обробки інформації повинна бути доступна і працездатна. Якщо інформації про події та інциденти нікуди вступати, ні про яке виявленні інцидентів мови йти не може.
 
 Інформація з джерел подій ІБ повинна бути максимально повною: ми повинні отримувати всі необхідні події аудиту, на підставі яких побудовані наші сценарії щодо виявлення інцидентів.
  
 В момент, коли система зафіксувала інцидент, ми повинні мати можливість максимально оперативно зібрати і проаналізувати всю інформацію, необхідну для її розслідування.
 
 
Ці вимоги породжують три різних рівня моніторингу доступності сервісу JSOC.
 
 

Рівень 1. Інфраструктура JSOC


 Тут все досить просто і не відрізняється від глибокого моніторингу будь-якого іншого IT-додатки. Розглянемо типову схему підключення нашого клієнта:
 
 image
 
 
За такої схеми моніторинг доступності контролює:
 
 
     
Мережну доступність компонент:
 
     
доступність ядра SIEM-системи з платформи VDI, і, відповідно, можливість роботи з системою інженерів моніторингу;
  
 працездатність каналу між майданчиками: наявність мережевий зв'язності між серверами конекторів і ядром системи;
  
 зв'язок між серверами конекторів і ключовими джерелами клієнта, які підключені для збору подій;
  
 наявність доступу з ядра SIEM-системи до додаткових серверам обробки та аналізу подій
 
 
 Показники продуктивності рівня апаратної частини і ОС:
 
     
завантаження і продуктивність процесорів;
 
 використання і розподіл оперативної пам'яті;
  
 наявність вільного місця в файлових розділах;
  
 загальні показники продуктивності дискової підсистеми.
 
 
 Аналіз стану мережевих компонент:
 
     
кількість помилок обробки пакетів на мережевому обладнанні;
 
 інформацію за якістю роботи site-2-site тунелю між майданчиками (стан сесії, відсоток втрат і т.д.);
 
 утилізацію мережевих інтерфейсів на всьому проміжному устаткуванні;
 
 навантаження на інтернет-канал, створювану передачею трафіку.
 
 
 Моніторинг стану ключових системних і прикладних служб на рівні ОС:
 
     
стан сервісів ОС, необхідних для роботи JSOC;
 
 стан і основні показники (тривалість роботи, використання ресурсів) по процесам ArcSight.
 
 
 Контроль на наявність помилок системних журналів:
 
     
мережеве обладнання та міжмережеві екрани;
 
 засоби віртуалізації;
 
 ОС на компонентах ядра і серверах конекторів.
 
 
 Моніторинг журналів конекторів і ядра ArcSight на наявність помилок.
 
 
 Моніторинг цих показників повністю здійснюється через Zabbix. По кожному показнику збирається статистика і налаштовані тригери на задані порогові значення: warning — 20% від максимального значення, critical — 2-5% від максимального значення. В цілому тут немає нічого незвичайного, і зайвий раз описувати, напевно, немає необхідності.
  
Підсумком цієї моделі є можливість оперативного отримання інформації про зовнішніх і внутрішніх проблемах в роботі сервісу, потенційно «вузьких місцях» з точки зору інфраструктури. Але всі зазначені параметри не дають нам розуміння цілісності наявної у нас інформації та того, чи ми бачимо в мережі замовника все, що потрібно, і чи можемо оперативно прореагувати на інцидент.
 
 

Рівень 2. Цілісність інформації від джерел


Це приводить нас до другої задачі: необхідно контролювати, яка інформація надходить до нас з систем-джерел, наскільки вона повна і актуальна, наскільки коректно вона розбирається системою. У разі SIEM-системи критичність набувають наступні параметри:
 
     
контроль не тільки стану джерел, але і вступників типів подій;
 все що надійшли події повинні коректно Парс системою. Нам потрібно чітко розуміти, що події обробляються коректно і наші правила будуть працювати;
 потік подій, який передається системою-джерелом, повинен надходити в JSOC з мінімальними втратами. Дані ми збираємо в режимі, близькому до real-time.
 
Зрозуміло, що завдання контролювати надходять в себе дані і аналізувати їх на повноту і цілісність — це в першу чергу задача самого SIEM. На жаль, «з коробки» не завжди можна отримати прийнятні результати.
 
 
     
ArcSight володіє достатньо якісним механізмом визначення стану підключених систем. У випадку падіння конекторів, проблем з доступністю кінцевих джерел, наявності кеша на коннекторе — працюють вбудовані кореляційні правила + візуалізація.
 

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

Але при цьому весь контроль йде цілком по джерелу (Microsoft Windows, Cisco ASA і т.д.) і ніяк не враховується різний тип подій. Більш того, для всіх систем можна включити тільки загальний час контролю, немає аудиту змін в кількості подій порівняно з «нормальною» роботою.
Розглянемо, наприклад, збір подій з брандмауера Cisco ASA з необхідним рівнем аудиту. Однією з найбільш важливих задач при контролі даного обладнання для нас є виявлення та обробка VPN-сесій віддаленого доступу, термініруемих фаєрволом. При цьому в загальному потоці подій вони становлять менше 1%. І їх «пропажа» (наприклад, випадкове зміна налаштувань аудиту замовником) у загальному обсязі подій може залишитися просто непоміченим.
 
 
 Є вбудований механізм розбору подій і оцінки успішності його нормалізації, який може сигналізувати про те, що отримане подія не співпало з передвстановленим форматом і не потрапило в формат.
 

Ця подія називається «unparsed event» і повідомлення про нього може бути доставлено як поштою, так і за допомогою створення кейса безпосередньо в консолі ArcSight. Таким чином, це допомагає досить успішно вирішувати задачу номер 2.
 
 
 Є вбудований механізм оповіщення у випадках, коли різниця за часом між міткою на джерелі і на коннекторе доходить до певного порога.
  

А ось тут все нормально. За винятком того, що дані події ніяк не відображаються в загальних дашборда і на них немає алертів. Разом з визначенням кешування подій на коннекторе — це практично готове рішення задачі 3.
 
 
Але, як вже зазначалося раніше, HP ArcSight — в першу чергу framework. І ми, створюючи JSOC, стали майструвати свою модель контролю надходить. Ось що в підсумку вийшло.
 
 
     
Для початку ми «трохи» поміняли логіку визначення джерела. Під кожен тип джерела визначили категорії важливих для нас подій і виділили з них найбільш частотні, наявність яких можна взяти за основу.
 
Приміром, для Windows можна написати такий «маппинг»:
 
 4624, Logon / Logoff: Logon
4768, Account Logon: Kerberos Ticket Events
4663, Object Access: File System
4688, Detailed Tracking: Process Creation
4689, Detailed Tracking: Process Termination
4672, Logon / Logoff: Special Logon
5140, Object Access: File Share
і т.д.
 

Для Cisco ASA такий:
 
 602303,602304,713228,713050, VPN Connection
 302013-302016, SessionStatistic
 106023, AccessDenied
 і т.д.
 
ArcSight дозволяє досить просто робити такий маппинг через конфігураційні файли. У підсумку, раніше подія статусу джерела виглядало так (на прикладі Windows):
 
                      
Timestamp CustomerName ConnectorName EventName DeviceName EventCount DeviceVendor DeviceProduct
2 вересня 2014 17:37:29 MSK Jet Infosystems Jet_Windows Connector Device Status arc-srv1 — 10.31.120.25 13 Microsoft Microsoft Windows
Тепер же в JSOC по кожній нашій категорії подій свій статус:
                                          
Timestamp CustomerName ConnectorName EventName DeviceName EventCount DeviceVendor DeviceProduct
2 вересня 2014 17:37:29 MSK Jet Infosystems Jet_Windows Connector Device Status arc-srv1 — 10.31.120.24 126 Microsoft Object Access: File Share
2 вересня 2014 17:37:29 MSK Jet Infosystems Jet_Windows Connector Device Status arc-srv1 — 10.31.120.24 24 Microsoft Logon / Logoff: Logon
2 вересня 2014 17:37:29 MSK Jet Infosystems Jet_Windows Connector Device Status arc-srv1 — 10.31.120.24 53 Microsoft Microsoft Windows
 
 Для кожного «нового типу» джерела проводиться тривале динамічне профілювання за обсягом та кількістю подій, поступаємих з нього в ArcSight. Як правило, одиницею виміру профілю є 1:00, тривалість профілізації складає 1 місяць. Основна мета профілювання — визначити середні та максимальні значення кількості подій від джерел у різні проміжки часу (робочий день, ніч, вихідні і т.д.)
 
Після того, як профіль побудувався, ми вже можемо оцінювати «цілісність» поступаемой інформації. Окремі правила моніторингу в ArcSight налаштовані таким чином:
 
     
відсутність подій визначається не по заданому інтервалу, а в порівнянні з профілем (якщо від даного джерела в цей проміжок часу дійсно не повинно бути подій, наприклад — подій щодо зміни конфігурації мережевого пристрою);
 за відхиленнями: у разі якщо число подій за останню годину на 20% менше / більше, ніж baseline по аналогічним інтервалам в нашому профілі — це привід детальніше розібратися в ситуації;
 
 визначення нових джерел (події є, але даний джерело відсутнє в профілі).
 
 
Таким чином, реалізоване «довге» динамічне профілізація дозволяє нам оперативно відслідковувати проблеми в передачі даних і контролювати цілісність що надходить до нас інформації.
 
Приклад такого статусу для одного з джерел (проксі сервер):
 image
 
 
 Допрацювали стандартні правила і дашборда. Додали інформацію про замовників, додали два окремих профілю по трекінгу статусів для конекторів і підключених пристроїв. Всі правила в підсумку заведені в єдину структуру генерації інцидентів і по кожному з них (так само як і при моніторингу системних компонент) створюється кейс.
 
Вийшло приблизно наступне: поруч два дашборда з одного і того ж ESM (один стандартний, інший наш). У стандартному моніторингу проблем немає. А в нашій версії — видно явні проблеми з підключенням до джерел, відсутність подій певної категорії і збільшений потік подій від одного з пристроїв.
 
 image
 
 image
 
 
 Залишається одна дуже маленька, але важлива проблема: частина подій аудиту на цільових системах виникають дуже рідко. Наприклад, додавання користувача в групу доменних адміністраторів в Active Directory або події щодо зміни конфігурації мережевого пристрою (збираються за допомогою tacacs-server Cisco ACS) і т.д. При цьому сам факт появи такої події найчастіше вже є інцидентом ІБ навіть без додаткової кореляції побудови складних ланцюжків подій.
 
І тут «останнім доводом королів» залишається стара і звична скріптотехніка: за погодженням із замовником ми Емуліруем тестове подія на цільовій системі з деякою частотністю і тим самим переконуємося, що випадкові помилки в роботі з аудитом не стануть причиною невиявлення інциденту.
 
Варто відзначити, що, незважаючи на високий рівень контролю за подіями, побудований в рамках описаної вище моделі, ми, тим не менш, на регулярній основі (не рідше ніж раз на місяць) проводимо бойові випробування системи аудиту і нашої команди розбору інцидентів. При цьому методологія така: замовник самостійно (або з нашою допомогою) виконує набір дій, що тягнуть виявлення інциденту. Ми зі свого боку, по-перше, фіксуємо факт отримання всієї вихідної інформації в JSOC, а по-друге, зайвий раз підтверджуємо коректність роботи кореляційних правил, ну і нарешті, — перевіряємо реакцію і рівень аналізу інциденту 1-ой лінією нашої команди JSOC.
 
 
 
 

Рівень 3. Швидкодія


 
Залишився останній показник виміру — швидкодію системи при побудові звітів та розслідуванні інциденту аналітиком. В нашому випадку потенційні затримки тягнуть за собою порушення SLA, тому ми, звичайно ж, не могли залишити це питання осторонь.
 
В даному випадку, як правило, досить визначити набір операцій і звітів, необхідних для розслідування самих критичних або частотних інцидентів і проводити вимірювання часу їх виконання на середньозважений кейсі замовника. Інформацію про швидкість виконання ми беремо відразу з двох джерел.
 
Перший — звіти і операції, що їх за розкладом і демонструють нам «еталонні» показники швидкодії. В даному випадку ми зробили два типи звітів, які виконуються за розкладом: звіт за свідомо пустому фільтру і звіт за типовими подіям (той самий моніторинг джерел) з підсумовуванням по полях. За результатами роботи цих звітів ми так само збираємо статистику і дивимося динаміку змін:
 
 
 
Другий — інформація за часом виконання поточних звітів співробітниками.
 
 За сим я б хотів закінчити розповідь про те, що на нашу думку забезпечує доступність ядра JSOC і як ми вирішуємо задачу з її контролю. Дякуємо за увагу.
 
 
    
Джерело: Хабрахабр

0 коментарів

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