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

    Добрый день. Мы продолжаем серию статей «из-за кулис» 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 и как мы решаем задачу по ее контролю. Спасибо за внимание.

    Инфосистемы Джет
    Системный интегратор

    Похожие публикации

    Комментарии 2

      0
      Хорошая статья, коллеги, спасибо.
      Жаль аудитории для подобного рода статей практически нет в Рунете, в том числе и на Хабре.
        0
        Спасибо за оценку.

        Интерес к теме и глубина погружения специалистов, по нашей оценке, качественно растет последние пару лет. Что не может не радовать :)

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое