Доступність JSOC: показники та вимірювання

Ми продовжуємо серію матеріалів, присвячених Security Operations Center, і представляємо вашій увазі другий випуск.

Сьогоднішня стаття присвячена «магічним дев'ятках» доступності й готовності сервісів. Ми розповімо, із чого складаються сервісні показники хмарного SOC з точки зору «заліза» і якими засобами вони контролюються в Solar JSOC.

Основна мета сервісу Solar JSOC – виявлення та оперативний аналіз інцидентів інформаційної безпеки у замовників. Це створює п'ять основних умов для його доступності[1]:

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

  2. Інформація з джерел подій ІБ повинна бути максимально повною: нам необхідно отримувати всі необхідні події аудиту, на підставі яких побудовані сценарії щодо виявлення інцидентів. Повнота повинна відображати як необхідний перелік типів подій (початок/кінець з'єднання, аутентифікація та ін), так і потрібні для розслідування поля всередині одиничного події (адресація, зони, процеси, параметри події).

  3. В момент фіксації інциденту технічними засобами процес збору і аналізу інформації, має бути максимально оперативними.

  4. Безвідмовна реєстрація в системі кейс-менеджменту і гарантований маршрут доставки оповіщення до потрібного замовника.

  5. Цілодобовий безшовний розбір інцидентів в рамках гарантованого SLA.
Саме ці п'ять постулатів, які лягли в основу використовуваної нами нашої системи моніторингу, яка використовує аналогічну кількість рівнів.

Рівень 1. Інфраструктура Solar JSOC
Тут я хотів би навести схему підключення типового замовника, використаний мною в першій статті:



Використання даної схеми розділяє процес контролю доступності на такі підсистеми:

  1. Мережеву доступність компонент:

    • доступність ядра SIEM-системи для можливості роботи з системою інженерів моніторингу;
    • працездатність каналу між майданчиками ядра Solar JSOC і клієнтом: наявність мережної зв'язності між серверами конекторів і ядром системи;

    • зв'язок між серверами конекторів і ключовими джерелами клієнта, які підключені для збору подій;
    • наявність доступу з ядра SIEM-системи до додаткових серверів обробки та аналізу подій, а також системі кейс-менеджменту.

  2. Аналіз стану мережних компонент:

    • кількість помилок обробки пакетів на мережному обладнанні;
    • інформація за якістю роботи site-2-site тунелю між майданчиками (стан сесії, відсоток втрат і т. д.);

    • утилізація мережевих інтерфейсів на всьому проміжному устаткуванні;
    • навантаження на інтернет-канал, створювана передачею трафіка.

  3. Показники рівня продуктивності апаратної частини і ОС:

    • завантаження і продуктивність процесорів;
    • використання і розподіл оперативної пам'яті;

    • наявність вільного місця в файлових розділах (системного, продуктивного і розділу для створення резервних копій);
    • загальні показники продуктивності дискової підсистеми.

  4. Моніторинг стану ключових системних і прикладних служб на рівні ОС:
  5. Контроль на наявність помилок системних журналів:

    • мережеве обладнання і міжмережеві екрани;
    • засоби віртуалізації;

    • ОС на компонентах ядра і серверах коннекторів.

  6. Моніторинг журналів конекторів і ядра ArcSight на наявність помилок.
  7. Контроль за продуктивністю бази даних ArcSight (параметри запису/читання).
Моніторинг цих показників повністю здійснюється або через Zabbix, або внутрішніми засобами ArcSight. По кожному показнику збирається статистика і налаштовані тригери на задані граничні значення: warning – 20 % від максимального значення, critical – 2-5 % від максимального значення. В цілому все досить стандартно, тому не будемо витрачати час на докладний опис і рушимо далі.

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

Рівень 2. Повнота інформації від джерел
Це приводить нас до другої задачі – необхідність контролю параметрів інформації, що надходить до нас від систем-джерел: повноти, актуальності, коректності її парсингу. У разі SIEM-системи критичність набувають такі параметри:

  • контроль не тільки стану джерел, але і надходять типів подій;
  • виявлення і запобігання помилок парсинга: необхідно чітке розуміння коректної обробки події для успішної роботи кореляційних правил;
  • прагнення до отримання подій в режимі real-time з мінімальними втратами.
Очевидно, що завдання контролювати дані, що надходять, і аналізувати їх на повноту і цілісність – це, в першу чергу, завдання самого SIEM. На жаль, «з коробки» не завжди можна одержати прийнятні результати. Існують певні обмеження:

  1. «З коробки» не враховується можливість підключення до одного SIEM-системі декількох замовників.

    Тому хоч ArcSight і має досить якісним механізмом визначення стану підключених систем (у разі падіння конекторів, проблем з доступністю кінцевих джерел або наявності кеша на коннекторе працюють вбудовані кореляційні правила + візуалізація), всі «коробкові» правила і дашборды не підходять для завдань хмарного SOC.

  2. Обмежений функціонал за визначенням відсутності інформації з джерела подій за принципом «не було жодної події за останні N годин».

    Перша складність (або особливість, кому як більше подобається) в тому, що контроль йде по джерелу (Microsoft Windows, Websense Proxy, McAfee ePolicy) і різні типи подій ніяк не враховуються. Друга складність – рішення «з коробки» не дозволяє здійснювати контроль за подіями, виходячи з їх нормальної кількості і відхилення від профілю.

    Як приклад розглянемо збір подій з міжмережевого екрану Cisco ASA з необхідним рівнем аудиту. Однією з найбільш важливих завдань при контролі даного устаткування є виявлення і обробка VPN-сесій віддаленого доступу, терминируемых міжмережевим екраном. При цьому в загальному потоці подій вони становлять менше 1%. Їх відсутність (наприклад, в силу зміни налаштувань аудиту) в загальному обсязі подій може просто залишитися непоміченим.
Але на тлі викладених вище обмежень, ArcSight існують якісні механізми контролю самого контенту:

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

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

    Ця подія називається «Unparsed Event», і повідомлення про нього може бути доставлено як поштою, так і за допомогою створення кейса безпосередньо в консолі ArcSight. Цей механізм допомагає успішно вирішувати завдання номер 2 по формуванню уявлення про повноти отримуваної інформації.

  2. Механізм контролю міток часу надходять подій і часу ArcSight.

    Разом з визначенням кешування подій на коннекторе це практично готове рішення задачі по оперативності збору і аналізу інформації. Крім того, попутно виявляються факти неправильної налаштування часу на пристроях.
Але, як уже зазначалося в попередній статті, HP ArcSight – це, в першу чергу, framework. І ми, створюючи Solar 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
28 Jun 2016 15:23:36 MSK Solar Security Solar_Windows Srv Connector Status — OK ex-hub1 джерело мережну — 10.199.*.* 164152 Microsoft Microsoft Windows

Тепер же в JSOC по кожній нашій категорії подій свій статус:
Timestamp CustomerName ConnectorName EventName DeviceName EventCount DeviceVendor DeviceProduct
28 Jun 2016 15:23:36 MSK Solar Security Solar_Windows Srv Connector Status — OK ex-hub1 джерело мережну — 10.199.*.* 35423 Microsoft Object Access:File Share
28 Jun 2016 15:23:36 MSK Solar Security Solar_Windows Srv Connector Status — OK ex-hub1 джерело мережну — 10.199.*.* 7576 Microsoft Logon/Logoff:Logon
28 Jun 2016 15:23:36 MSK Solar Security Solar_Windows Srv Connector Status — OK ex-hub1 джерело мережну — 10.199.*.* 1530 Microsoft Detailed Tracking:Process Creation

Для кожного нового джерела проводиться тривале динамічне профілювання за обсягом і кількістю подій, що надходять з нього в ArcSight. Як правило, одиницею вимірювання профілю є 1 годину, тривалість профілювання становить 1 місяць. Основна мета профілізації – визначити середні та максимальні значення кількості подій від джерел у різні проміжки часу (робочий день, ніч, вихідні і т. д.).

Після того, як профіль побудований, можна оцінювати повноту інформації, що надходить. Наприклад, з допомогою таких правил:

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

  • У разі якщо кількість подій за останній годину на 20 % менше/більше, ніж baseline з аналогічним інтервалам в нашому профілі, це вважається відхиленням і, отже, приводом детальніше розібратися в ситуації.

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

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

Вийшло приблизно наступне: поруч два дашборда з одного і того ж ESM (один стандартний, інший наш). У стандартному моніторингу проблем немає. А наша версія відображає проблеми з підключенням коннектора до джерел, відсутність подій певної категорії і збільшений потік подій від одного з пристроїв.



Залишається одна маленька, але важлива проблема: частина подій аудиту на цільових системах виникає дуже рідко. Наприклад, додавання користувача в групу адміністраторів доменних в Active Directory або події щодо зміни конфігурації мережевого пристрою (збираються за допомогою tacacs-server Cisco ACS) і т. д. При цьому сам факт появи такої події найчастіше вже є інцидентом ІБ навіть без додаткового побудови складних ланцюжків кореляції подій.

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

Варто відзначити, що, незважаючи на високий рівень контролю за подіями, побудований в рамках описаної вище моделі, ми, тим не менш, на регулярній основі проводимо бойові випробування системи аудиту та нашої команди розбору інцидентів. Методологія така: замовник самостійно або з нашою допомогою) виконує набір дій на джерелах, підключених до Solar JSOC, викликаючи спрацьовування різних сценаріїв (брутфорс на системі, зміна ACL на МЕ, запуск сесії віддаленого адміністрування, сканування мережі тощо). Ми, по-перше, фіксуємо факт отримання всієї вихідної інформації в Solar JSOC, по-друге, зайвий раз підтверджуємо коректність роботи кореляційних правил, ну, і нарешті, перевіряємо реакцію і рівень аналізу інциденту першою лінією команди Solar JSOC.

Рівень 3. Швидкодія
Не менш важливим показником сервісу є виконання SLA. Тому дуже важливо забезпечити максимальну швидкодію системи при побудові звітів, каналів, репортов при розборі інциденту інженером моніторингу або аналітиком.

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

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



Другий − інформація щодо часу виконання співробітниками поточних звітів.

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

Рівень 4. Кейс-менеджмент і сповіщення замовника
При наявності великої кількості замовників і декількох інсталяцій SIEM-системи виникає необхідність працювати з єдиним вікном при розборі інцидентів. Стандартний кейс-менеджмент ArcSight не задовольняв усім нашим побажанням, тому було вирішено перейти на зовнішню тікет-систему, і ми вибрали Kayako.

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

Так само вдалося уникнути проблем з путаницами в інсталяціях, коли їх стало більше 4: всередині кожного кейсу в Kayako відразу присутній гіперпосилання на потрібний ArcSight ESM.

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

А поки повернемося до питань доступності.

Рівень 5. Люди і SLA
Одним з найважливіших моментів у наданні сервісу є своєчасний розбір надходять кейсів незалежно від їх кількості та часу доби.

В рамках JSOC ми розробили наступні механізми для вирішення даних питань:

  1. При введенні цілодобової зміни існує буферна зона за часом вранці і ввечері – перезмін з 9 до 10 ранку і з 8 до 9 вечора. Це етап, коли нічна і денна зміни перетинаються. Попередня зміна закриває ті кейси, які виникли до перезмінка, передає актуальну інформацію щодо замовника, вказує на важливі моменти, що відбулися в їх зміну (наприклад, атака на замовника, необхідність в регулярному моніторингу певних хостів тощо). Нова зміна включається в роботу і починає розбирати кейси, які приходять в перезмінок.

  2. Для позаштатних ситуацій з великою кількістю інцидентів існують резерви. Вдень це друга лінія моніторингу та аналітики. Вночі в зміні перебуває один інженер моніторингу, а другий завжди чекає «на низькому старті», готовий підключитися до розбору кейсів протягом 15 хвилин. Крім цього існує черговий аналітик, який володіє інформацією по всім замовникам і підключається до розслідування в разі ескалації критичності, експертизі або кількістю інцидентів. Або по всьому одночасно.
Дані методи дозволили нам гарантовано дотримуватися метрики SLA та оперативно розбирати будь-яку кількість інцидентів, зареєстрованих у наших замовників.

На цьому я закінчую другу статтю із серії. Наступна буде присвячена системі кейс-менеджменту, яку ми використовуємо при наданні сервісів.



  1. Далі я буду використовувати саме цей термін, хоча багато хто напевно упрекнут мене в неправильному вживанні усталених термінів. З точки зору ГОСТ Р 53480-2009 існує поняття «готовність», поняття «доступність» відсутня. Також існує IEC 60050, в якому використовуються декілька понять: accessibility, availability, capability. Але в рамках даної статті для простоти і економії часу я буду використовувати лише один «усталений» термін – доступність. Можливо, він не зовсім технічно коректний, але, на мій погляд, найкраще відображає завдання бізнесу.
Джерело: Хабрахабр

0 коментарів

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