Pull to refresh
149.6
Инфосистемы Джет
российская ИТ-компания

JSOC: как измерить доступность Security Operation Center?

Reading time 8 min
Views 2.9K
Добрый день. Мы продолжаем серию статей «из-за кулис» Jet Security Operation Center. Когда речь идет об «облачном» сервисе, всегда встает вопрос о количестве «9 после запятой» в показателях его доступности. Мне бы хотелось рассказать о том, из чего складывается доступность SOC с точки зрения «железа» и ПО и какими средствами мы контролируем эту доступность. Статья будет гораздо более технической, поэтому попрошу читателей запастись терпением.

Итоговая цель нашего сервиса (JSOC) − выявление и оперативный анализ возникающих у заказчиков инцидентов ИБ. Это создает три основных требования к его доступности:

  1. Платформа сбора и обработки информации должна быть доступна и работоспособна. Если информации о событиях и инцидентах некуда поступать, ни о каком выявлении инцидентов речи идти не может.
  2. Информация с источников событий ИБ должна быть максимально полной: мы должны получать все требуемые события аудита, на основании которых построены наши сценарии по выявлению инцидентов.
  3. В момент, когда система зафиксировала инцидент, мы должны иметь возможность максимально оперативно собрать и проанализировать всю информацию, необходимую для его расследования.

Эти требования порождают три разных уровня мониторинга доступности сервиса JSOC.

Уровень 1. Инфраструктура JSOC


Здесь все достаточно просто и не отличается от глубокого мониторинга любого другого IT-приложения. Рассмотрим типовую схему подключения нашего клиента:

image


При такой схеме мониторинг доступности контролирует:

  1. Сетевую доступность компонент:
    • доступность ядра SIEM-системы с платформы VDI, и, соответственно, возможность работы с системой инженеров мониторинга;
    • работоспособность канала между площадками: наличие сетевой связности между серверами коннекторов и ядром системы;
    • связь между серверами коннекторов и ключевыми источниками клиента, которые подключены для сбора событий;
    • наличие доступа с ядра SIEM-системы к дополнительным серверам обработки и анализа событий
  2. Показатели производительности уровня аппаратной части и ОС:
    • загрузку и производительность процессоров;
    • использование и распределение оперативной памяти;
    • наличие свободного места в файловых разделах;
    • общие показатели производительности дисковой подсистемы.
  3. Анализ состояния сетевых компонент:
    • количество ошибок обработки пакетов на сетевом оборудовании;
    • информацию по качеству работы site-2-site туннеля между площадками (состояние сессии, процент потерь и т.д.);
    • утилизацию сетевых интерфейсов на всем промежуточном оборудовании;
    • нагрузку на интернет-канал, создаваемую передачей трафика.
  4. Мониторинг состояния ключевых системных и прикладных служб на уровне ОС:
    • состояние сервисов ОС, необходимых для работы JSOC;
    • состояние и основные показатели (длительность работы, использование ресурсов) по процессам ArcSight.
  5. Контроль на наличие ошибок системных журналов:
    • сетевое оборудование и межсетевые экраны;
    • средства виртуализации;
    • ОС на компонентах ядра и серверах коннекторов.
  6. Мониторинг журналов коннекторов и ядра ArcSight на наличие ошибок.

Мониторинг этих показателей полностью осуществляется через Zabbix. По каждому показателю собирается статистика и настроены триггеры на заданные пороговые значения: warning – 20 % от максимального значения, critical – 2−5 % от максимального значения. В целом здесь нет ничего необычного, и лишний раз описывать, наверное, нет необходимости.

Итогом этой модели является возможность оперативного получения информации о внешних и внутренних проблемах в работе сервиса, потенциально «узких местах» с точки зрения инфраструктуры. Но все указанные параметры не дают нам понимания целостности имеющейся у нас информации и того, видим ли мы в сети заказчика все, что требуется, и можем ли оперативно прореагировать на инцидент.

Уровень 2. Целостность информации от источников


Это приводит нас ко второй задаче: необходимо контролировать, какая информация поступает к нам с систем-источников, насколько она полна и актуальна, насколько корректно она разбирается системой. В случае SIEM-системы критичность приобретают следующие параметры:
  • контроль не только состояния источников, но и поступающих типов событий;
  • все поступившие события должны корректно парситься системой. Нам нужно четко понимать, что события обрабатываются корректно и наши правила будут работать;
  • поток событий, передаваемый системой-источником, должен поступать в JSOC с минимальными потерями. Данные мы собираем в режиме, близком к real-time.

Понятно, что задача контролировать поступающие в себя данные и анализировать их на полноту и целостность – это в первую очередь задача самого SIEM. К сожалению, «из коробки» не всегда можно получить приемлемые результаты.

  1. ArcSight обладает достаточно качественным механизмом определения состояния подключенных систем. В случае падения коннекторов, проблем с доступностью конечных источников, наличии кэша на коннекторе – работают встроенные корреляционные правила + визуализация.

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

  2. Так же есть базовый функционал по определению факта отсутствия информации с источника событий по принципу: «не было ни одного события за последние N часов».

    Но при этом весь контроль идет целиком по источнику (Microsoft Windows, Cisco ASA и т.д.) и никак не учитывается различный тип событий. Более того, для всех систем можно включить только общее время контроля, нет аудита изменений в количестве событий по сравнению с «нормальной» работой.
    Рассмотрим, к примеру, сбор событий с межсетевого экрана Cisco ASA с требуемым уровнем аудита. Одной из наиболее важных задач при контроле данного оборудования для нас является выявление и обработка VPN-сессий удаленного доступа, терминируемых межсетевым экраном. При этом в общем потоке событий они составляют менее 1 %. И их «пропадание» (например, случайное изменение настроек аудита заказчиком) в общем объеме событий может остаться просто незамеченным.

  3. Есть встроенный механизм разбора событий и оценки успешности его нормализации, который может сигнализировать о том, что полученное событие не совпало с предустановленным форматом и не попало в формат.

    Это событие называется «unparsed event» и уведомление о нем может быть доставлено как по почте, так и посредством создания кейса непосредственно в консоли ArcSight. Таким образом, это помогает достаточно успешно решать задачу номер 2.

  4. Есть встроенный механизм оповещения в случаях, когда разница по времени между меткой на источнике и на коннекторе доходит до определенного порога.

    А вот тут все нормально. За исключением того, что данные события никак не отображаются в общих дашбордах и на них нет алертов. Вместе с определением кэширования событий на коннекторе – это практически готовое решение задачи 3.

Но, как уже отмечалось ранее, HP ArcSight − в первую очередь framework. И мы, создавая JSOC, стали мастерить свою модель контроля поступающей информации. Вот что в итоге получилось.

  1. Для начала мы «немного» поменяли логику определения источника. Под каждый тип источника определили категории важных для нас событий и выделили из них наиболее частотные, наличие которых можно взять за основу.

    К примеру, для 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

  2. Для каждого «нового типа» источника проводится длительное динамическое профилирование по объему и количеству событий, поступаемых с него в ArcSight. Как правило, единицей измерения профиля является 1 час, длительность профилирования составляет 1 месяц. Основная цель профилирования – определить средние и максимальные значения количества событий от источников в разные промежутки времени (рабочий день, ночь, выходные и т.д.)

    После того, как профиль построился, мы уже можем оценивать «целостность» поступаемой информации. Отдельные правила мониторинга в ArcSight настроены следующим образом:
    • отсутствие событий определяется не по заданному интервалу, а по сравнению с профилем (если от данного источника в этот промежуток времени действительно не должно быть событий, например − событий по изменению конфигурации сетевого устройства);
    • по отклонениям: в случае если число событий за последний час на 20 % меньше/больше, чем baseline по аналогичным интервалам в нашем профиле – это повод детальнее разобраться в ситуации;
    • определение новых источников (события есть, но данный источник отсутствует в профиле).

    Таким образом, реализованное «длинное» динамическое профилирование позволяет нам оперативно отслеживать проблемы в передаче данных и контролировать целостность поступающей к нам информации.

    Пример такого статуса для одного из источников (прокси сервер):
    image

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

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

    image

    image

  4. Остается одна очень маленькая, но важная проблема: часть событий аудита на целевых системах возникают очень редко. Например, добавление пользователя в группу доменных администраторов в Active Directory или события по изменению конфигурации сетевого устройства (собираются посредством tacacs-server Cisco ACS) и т.д. При этом сам факт появления такого события зачастую уже является инцидентом ИБ даже без дополнительной корреляции построения сложных цепочек событий.

    И здесь «последним доводом королей» остается старая и привычная скриптотехника: по согласованию с заказчиком мы эмулируем тестовое событие на целевой системе с некоторой частотностью и тем самым убеждаемся, что случайные ошибки в работе с аудитом не станут причиной не выявления инцидента.

    Стоит отметить, что, несмотря на высокий уровень контроля за событиями, построенный в рамках описанной выше модели, мы, тем не менее, на регулярной основе (не реже чем раз в месяц) проводим боевые испытания системы аудита и нашей команды разбора инцидентов. При этом методология такова: заказчик самостоятельно (или с нашей помощью) выполняет набор действий, влекущих выявление инцидента. Мы со своей стороны, во-первых, фиксируем факт получения всей исходной информации в JSOC, а во-вторых, лишний раз подтверждаем корректность работы корреляционных правил, ну и наконец, − проверяем реакцию и уровень анализа инцидента 1-ой линией нашей команды JSOC.


Уровень 3. Быстродействие



Остался последний показатель измерения – быстродействие системы при построении отчетов и расследовании инцидента аналитиком. В нашем случае потенциальные задержки влекут за собой нарушение SLA, поэтому мы, конечно же, не могли оставить это вопрос в стороне.

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

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



Второй − информация по времени выполнения текущих отчетов сотрудниками.

За сим я бы хотел закончить рассказ о том, что по нашему мнению обеспечивает доступность ядра JSOC и как мы решаем задачу по ее контролю. Спасибо за внимание.

Tags:
Hubs:
+4
Comments 2
Comments Comments 2

Articles

Information

Website
jet.su
Registered
Founded
1991
Employees
1,001–5,000 employees
Location
Россия