Обзор BI.ZONE TDR, сервиса мониторинга и реагирования на инциденты в кибербезопасности

1. Введение
2. Функциональные возможности BI.ZONE TDR
3. Архитектура BI.ZONE TDR
4. Системные требования BI.ZONE TDR
5. Взаимодействие с клиентами BI.ZONE TDR
6. Сценарии использования BI.ZONE TDR через BI.ZONE SOC Portal
   1. 6.1. Расследование инцидентов
   2. 6.2. Управление системами
   3. 6.3. Управление источниками событий
   4. 6.4. Конструктор и выгрузка отчётов
   5. 6.5. Документация
7. Выводы

Введение

В 2018 году на российском рынке появился BI.ZONE Security Operations Center (SOC), предоставляющий сервис по выявлению киберинцидентов по классическому сценарию «SOC-as-a-Service» (SOCaaS). SOCaaS позволяет организации передать часть задач по обеспечению безопасности стороннему сервис-провайдеру, получая от него мониторинг ИБ-событий, выявление инцидентов с последующим уведомлением и рекомендациями по реагированию и повышению защищённости, а также — в некоторых случаях — активное реагирование с использованием имеющихся у организации средств защиты. 

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

Среди достоинств модели SOCaaS можно выделить широкий охват ИТ-инфраструктуры организации, пассивный сбор событий из области безопасности за счёт штатных функций по аудиту компонентов инфраструктуры и средств защиты, а также выявление любых типов инцидентов, в том числе по сценариям, разработанным под нужды конкретной организации с учётом специфики её отрасли, инфраструктуры и других особенностей.

Рисунок 1. Концепция SOCaaS

В то же время модель SOCaaS имеет свои недостатки: например, выявление угроз не выходит за пределы возможностей штатного аудита элементов ИТ-инфраструктуры и имеющихся средств защиты, для подключения к услуге заказчик должен выполнить настройку большого количества различных источников событий для отправки последних в SIEM-систему, а возможности по реагированию ограничены. Кроме того, подобная модель малоэффективна при низком уровне зрелости ИТ и ИБ в компании, т. к. реагирование на выявляемые SOC инциденты требует экспертизы, опыта и выстроенных процессов взаимодействия служб ИТ и ИБ.

Параллельно развивался сервис класса «управляемое детектирование и реагирование» — BI.ZONE MDR. В отличие от SOCaaS, в модели MDR выявление инцидентов в ИБ происходит не за счёт анализа штатных журналов аудита, а на базе расширенной телеметрии от агентов класса EDR, устанавливаемых на конечные точки. Кроме того, этот подход позволяет выявлять неизвестные угрозы благодаря проактивному поиску (Threat Hunting), а использование агентов обеспечивает активное реагирование на обнаруженные угрозы. Из недостатков подхода необходимо отметить частичный охват ИТ-инфраструктуры мониторингом: он распространяется лишь на те хосты, куда возможно установить агенты EDR, а те функционируют только на ОС Windows, Linux, macOS актуальных версий и выполняют активный сбор событий, который не всегда возможен в высоконагруженных системах.

Рисунок 2. Концепция MDR

В 2021 г. разработчик принял решение объединить эти два подхода в новый сервис BI.ZONE Threat Detection and Response (TDR). Он нивелирует недостатки SOCaaS-модели и MDR, используя их достоинства.

С одной стороны, BI.ZONE TDR поддерживает обнаружение на основе агентов, опирающееся на EDR-решение вендора BI.ZONE Sensors; установленные на конечных точках агенты позволяют аналитикам SOC предпринимать согласовываемые с заказчиками действия по активному реагированию на инциденты, используя данные, которые были получены путём сбора и анализа телеметрии с хостов. С другой стороны, часть инфраструктуры подключается на мониторинг классическим способом на базе сбора событий штатного аудита и средств защиты. Таким образом, объединённый подход позволяет не только обеспечить максимальный охват ИТ-инфраструктуры и глубину видимости происходящего в ней, но и оперативно выполнять активное реагирование на инциденты по согласованию с заказчиком.

Рисунок 3. Концепция TDR

Клиентам предлагается три варианта поставки BI.ZONE TDR: «Horizon», «Focus» и «Panorama». 

«Horizon» представляет собой классический SOCaaS, основанный на анализе штатных журналов аудита компонентов ИТ-инфраструктуры и логов средств защиты. Тариф «Focus» (классический MDR) — это мониторинг и активное реагирование с помощью BI.ZONE Sensors, выявление инцидентов (в том числе передовых атак) по телеметрии, собираемой с конечных точек с помощью EDR. Наконец, «Panorama» — это максимальный уровень сервиса BI.ZONE TDR (объединение тарифов «Horizon» и «Focus»), включающий в себя мониторинг и выявление инцидентов как на базе штатных журналов ИТ-систем, так и с опорой на расширенную телеметрию и инвентаризацию конечных устройств посредством BI.ZONE Sensors (EDR), а также активное реагирование на выявляемые инциденты. 

Следует отметить, что компания BI.ZONE имеет статус корпоративного центра ГосСОПКА класса «А», благодаря чему может брать на себя функцию взаимодействия с НКЦКИ и по согласованию с заказчиком передавать информацию об инцидентах в рамках выполнения требований законодательства.

Производитель применяет собственную экспертизу и интегрированные между собой компоненты технологической платформы, на 90 % состоящей из собственных разработок. Составные части BI.ZONE TDR (личный кабинет клиента BI.ZONE SOC Portal, система управления инцидентами BI.ZONE IRP, сервер управления BI.ZONE Sensors, EDR-агент для Windows, macOS и Linux, платформа управления данными киберразведки BI.ZONE ThreatVision) внесены в реестр российского ПО.

Функциональные возможности BI.ZONE TDR

Синергия двух направлений в области обнаружения и предотвращения угроз позволила увеличить не только заметность событий в инфраструктуре, но и скорость реагирования на инциденты в ИБ. Согласно экспертным оценкам BI.ZONE, в классическом SOCaaS с момента выявления инцидента до реагирования в среднем проходит около двух часов, в то время как при использовании MDR — чуть более получаса. Реализация возможностей TDR достигается на протяжении ряда этапов, составляющих жизненный цикл инцидента.

Рисунок 4. Этапы процесса управления инцидентами в BI.ZONE TDR

В соответствии с методологией BI.ZONE, инфраструктура организации находится в одном из трёх состояний: до взлома, когда необходимо минимизировать вероятность возникновения инцидента; взлом, когда необходимо выявить предпринимаемые атаки и отреагировать на них; после взлома, когда необходимо найти признаки уже совершённых вредоносных действий.

Первым этапом жизненного цикла инцидента в BI.ZONE TDR является прогнозирование угроз (Threat Prediction), в рамках которого происходят анализ инфраструктуры, в т. ч.  версий ОС и установленных обновлений безопасности, выявление уязвимостей и недостатков конфигураций. Сбор информации производится с помощью агентов BI.ZONE Sensors (EDR) на хостах.

Автоматическое предотвращение угроз (Threat Prevention) производится за счёт имеющихся в EDR правил с низким уровнем ложных срабатываний. Делается это с помощью автоматического превентивного реагирования и недопущения ИБ-инцидентов в принципе. Другой сценарий использования Threat Prevention — разработка аналитиками BI.ZONE SOC правил автоматического предотвращения угроз в рамках реагирования на инциденты (например, блокировка попыток открыть вредоносный документ из фишингового письма, выявленного в рамках расследования инцидента).

Этап обнаружения угроз (Threat Detection) отвечает за выявление активных в настоящий момент атак. Для этого используются богатая база правил корреляции и данные Threat Intelligence, YARA-правила, ручной проактивный поиск инцидентов (Threat Hunting) и круглосуточный мониторинг срабатываний правил корреляции экспертами BI.ZONE. Используемые BI.ZONE подходы и правила обнаружения угроз позволяют охватить большую часть известных тактик и техник атакующих, представленных в матрице MITRE ATT&CK. На момент подготовки обзора собственная библиотека правил насчитывала около 1500 единиц. Стоит отметить, что в рамках сервиса предусмотрена как подстройка имеющихся в библиотеке правил под нужды конкретного заказчика, так и разработка полностью индивидуальных сценариев для решения специфичных задач.

Реагирование на угрозы (Threat Response) происходит после их выявления и заключается в отправке автоматизированных уведомлений и подготовке рекомендаций по выявленным инцидентам аналитиками SOC, а также в последующем активном реагировании на выявляемые инциденты с помощью BI.ZONE Sensors силами экспертов BI.ZONE по согласованию с заказчиком.

Не менее важным этапом является выявление прошлых атак, неактивных в настоящий момент (Threat Archeology). Используя исторические данные (история запуска процессов, входов пользователей, ретроспективные логи из журналов аудита и ряд других источников), сервис даёт заключение о возможной компрометации системы ранее.

Уведомление заказчика о выявляемых инцидентах возможно тремя способами: через BI.ZONE SOC Portal, путём отправки карточки инцидента по почте и посредством прямой коммуникации со специалистами заказчика (по телефону, через мессенджеры).

Рисунок 5. Выявление активных атак в рамках BI.ZONE TDR

Обработка получаемого потока событий состоит из нескольких этапов:

1. На первом этапе события по безопасности из инфраструктуры заказчика нормализовываются для приведения к унифицированной модели данных BI.ZONE, а далее обогащаются данными киберразведки (Threat Intelligence), получаемыми от собственной TI-платформы BI.ZONE ThreatVision.
2. Нормализованный и обогащённый поток событий поступает на корреляционный слой, используемый для автоматического выявления угроз и известных тактик, техник и процедур атакующих на базе правил корреляции и моделей машинного обучения.
3. Нормализованный, обогащённый и скоррелированный поток событий индексируется в хранилище, где изучается аналитиками BI.ZONE SOC. При обнаружении подозрительной активности проводится валидация; в случае подозрения на ИБ-инцидент инициируются расследование и реагирование.

Архитектура BI.ZONE TDR

Для реализации BI.ZONE TDR есть несколько вариантов взаимодействия архитектур заказчика и поставщика сервиса. Ключевые компоненты технологической платформы BI.ZONE TDR не изменяются, разница заключается только в контуре, где находятся её составляющие. Перед знакомством с вариантами реализации архитектуры рассмотрим основные компоненты.

• Реализация подхода MDR в BI.ZONE TDR достигается за счёт установки агентов BI.ZONE Sensors, осуществляющих мониторинг активности на конечных точках, обнаружение угроз на базе правил (YARA, поведенческих и т. п.), сбор телеметрии и её передачу на сервер управления.
• За постановку агентам задач по активному реагированию и получение результатов их выполнения, а также за общее администрирование отвечает сервер управления BI.ZONE Sensors.
• Брокер событий является сервером предварительной обработки событий, располагающимся перед компонентами SIEM. Основная его задача — производить операции над поступающими событиями для снижения нагрузки на SIEM и канал передачи данных, включая фильтрацию, оптимизацию, агрегирование и дедупликацию.
• SIEM отвечает за корреляцию полученных событий по ИБ из инфраструктурных источников заказчика и выявление инцидентов в информационной безопасности.
• Аналитическая платформа BI.ZONE Threat Hunting Platform предназначена для нормализации, обогащения и анализа телеметрии от агентов EDR и сетевых сенсоров.
• Обработка инцидентов, выявленных командой BI.ZONE SOC, ведётся на платформе реагирования (Incident Response Platform, IRP). Она нужна для управления жизненным циклом инцидента от его обнаружения до устранения причин его возникновения (и до автоматизации ответных действий).
• BI.ZONE SOC Portal необходим для взаимодействия между заказчиком сервиса и аналитиками SOC.
• BI.ZONE ThreatVision является платформой управления данными киберразведки (TI), поступающими во внутренние подразделения разработчика по исследованию угроз. Используется для обогащения событий из области безопасности, а также для предоставления специалистам, занимающимся разработкой правил выявления инцидентов, актуальной информации о новейших угрозах.
• Система управления контентом BI.ZONE Use Case Portal является единым репозиторием правил обнаружения угроз (правила корреляции SIEM, YARA, правила EDR, сигнатуры Suricata и др.), разрабатываемых специалистами вендора. В системе хранятся реализации правил, их описания, отображения в различные таксономии (например, MITRE ATT&CK), а также связанные с правилами инструкции по реагированию для аналитиков (плейбуки). Кроме того, система позволяет выполнять автоматизированную доставку контента до множественных систем его применения (SIEM, EDR).

Сервис предполагает облачную и гибридную схемы подключения в нескольких вариациях. Необходимо отметить, что облачная схема является приоритетной при подключении новых заказчиков. Таким образом подключены порядка 90 % потребителей сервиса.

Рисунок 6. Облачная схема подключения BI.ZONE TDR

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

Далее по безопасному тоннелю (Remote Access VPN), построенному на основе BI.ZONE Secure SD-WAN, данные попадают в SIEM-систему исполнителя, где происходят их обогащение и корреляция для выявления инцидентов в ИБ.

Для мониторинга хостов заказчику предоставляется агент EDR для ОС Microsoft Windows, Linux или macOS, устанавливаемый на конечные точки (рабочая станция, сервер и т. п.) внутри инфраструктуры. Установленные на хостах агенты взаимодействуют с сервером управления в инфраструктуре BI.ZONE через TLS, выполняя передачу собираемой телеметрии и получая задачи на реагирование. Таким образом можно выполнять мониторинг:

• активности процессов;
• файловых операций;
• операций с реестром;
• инъекций исполняемого кода в процессы;
• загрузки драйверов / модулей ядра;
• загрузки модулей в память процессов;
• сетевых соединений;
• открытия сетевых портов;
• именованных каналов;
• изменения привилегий процессов;
• операций с памятью и аномалий в памяти;
• выполнения PowerShell-скриптов;
• вводимых в консолях команд;
• автозагрузки;
• DNS-запросов;
• WMI-запросов;
• использования .NET-сборок;
• LDAP-запросов;
• входящих / исходящих SMB-подключений;
• создания WMI-подписок;
• учётных записей, групп и входов в систему;
• контейнеров;
• событий из Windows Event Log.

Телеметрия от EDR-агентов обогащается данными киберразведки, получаемыми из платформы BI.ZONE ThreatVision, и анализируется по базе правил корреляции, оперирующих тактиками и техниками атакующих. В рамках мониторинга также выполняется обнаружение аномалий с помощью YARA-правил, собирается инвентаризационная и ретроспективная информация (установленное ПО, обновления, настройки операционной системы, история запусков процессов, входов пользователей и т. п.), на базе которой выявляются уязвимости и недостатки конфигурации (Threat Prediction) и ведётся обнаружение прошлых атак (Threat Archeology).

Также в состав EDR входит модуль «Deception», автоматизирующий создание ловушек на конечных точках. На текущий момент модуль поддерживает следующие типы ловушек:

• внедрение в память процесса LSASS подложных учётных данных;
• добавление в реестр подложной учётной записи для автоматического входа;
• создание в Windows Credentials Manager записи с подложными данными;
• сохранение в браузере подложной учётной записи;
• создание файла Group Policy Preferences подложной учётной записью в локальном кеше групповой политики;
• создание в Active Directory подложной учётной записи, помещённой в привилегированную группу;
• создание в Active Directory подложной сервисной учётной записи с установленным значением имени Service Principal;
• cоздание в Active Directory подложной учётной записи c отключённой предварительной аутентификацией Kerberos.

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

Гибкие возможности по настройке модуля «Deception» позволяют индивидуализировать создаваемые ловушки под особенности клиента — скажем, использовать специфичный шаблон именования для подложных учётных записей, соответствующий корпоративному стандарту. Контроль доступа к ловушкам и мониторинг использования подложных учётных записей осуществляются на базе EDR-телеметрии; если атакующий попытается авторизоваться или запросить Kerberos-билет под подложной учётной записью, тут же сработают соответствующие правила корреляции.

Кроме того, агент BI.ZONE Sensors может выполнять различные активные действия по предотвращению угроз на основании задач от сервера управления, формируемых аналитиками в рамках реагирования на инциденты. Перечислим возможные действия по реагированию.

• Операции с файловой системой: удаление файла / каталога, поиск файла, листинг файлов в заданных директориях, скачивание файла с хоста, загрузка файла на хост.
• Операции с процессами в системе: завершение процесса, приостановка процесса (suspend), создание дампа памяти процесса.
• Операции с реестром Windows: создание, удаление, изменение ключей / значений реестра.
• Операции с автозагрузкой: удаление / изменение сервисов, драйверов, задач планировщика, WMI-подписок, задач BITS.
• Сбор данных для проведения расследования: получение метафайлов NTFS, списка активных процессов, сетевых подключений пользовательских сессий, инвентаризация автозагрузки, извлечение криминалистических артефактов.
• Запуск YARA-проверки.
• Сетевая изоляция хоста.
• Запуск произвольных исполняемых файлов и скриптов на хосте, интерактивная консоль связи с заданным хостом, позволяющая выполнять команды оболочки и немедленно получать ответы.

Рисунок 7. Гибридное подключение BI.ZONE TDR (схема 1)

В гибридном варианте сервер управления BI.ZONE Sensors, с которого администрируются агенты, размещается в инфраструктуре заказчика.

Рисунок 8. Гибридное подключение BI.ZONE TDR (схема 2)

В рамках третьего варианта на стороне заказчика устанавливаются брокер и обработчик событий. Последний выполняет корреляцию, а также обеспечивает хранение всего собранного, кроме событий от EDR-агентов. Обработка и хранение событий EDR во всех схемах осуществляются на платформе Threat Hunting, располагающейся в инфраструктуре BI.ZONE.

Стоит отметить, что инфраструктура BI.ZONE SOC сертифицирована на соответствие требованиям международного стандарта по защите информации и безопасности данных в индустрии платёжных карт PCI DSS v3, а также стандарта менеджмента информационной безопасности ISO/IEC 27001.

Системные требования BI.ZONE TDR

На компоненты, которые устанавливаются на стороне заказчика, распространяются следующие системные требования.

Таблица 1. Системные требования компонентов BI.ZONE TDR

Взаимодействие с клиентами BI.ZONE TDR

Команда аналитиков BI.ZONE TDR взаимодействует с заказчиками тремя способами.

Первый способ заключается в использовании BI.ZONE SOC Portal, позволяющего непрерывно отслеживать работу команды BI.ZONE SOС, просматривать статистику по произошедшим инцидентам, распределять инциденты по типам атак в соответствии с матрицей MITRE, а также просматривать сценарии обнаружения угроз, которые имеются в базе знаний BI.ZONE SOС.

Второй способ — отправка карточки инцидента на адреса электронной почты тех сотрудников, которых выбрал для этого заказчик.

Третий способ — взаимодействие с клиентом в соответствии с составленной матрицей коммуникации по телефону или мессенджерам, в зависимости от типа и критической значимости выявленного инцидента.

Кроме того, компания BI.ZONE является аккредитованным центром ГосСОПКА класса «А» и вправе отправлять уведомления об инцидентах в НКЦКИ. Инцидент может отправлять как сам заказчик (путём нажатия на соответствующую кнопку в интерфейсе BI.ZONE SOC Portal), так и сервис-провайдер в соответствии с заранее определёнными правилами — например, только для инцидентов с высоким уровнем критической значимости или затрагивающих определённые активы.

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

Сценарии использования BI.ZONE TDR через BI.ZONE SOC Portal

BI.ZONE SOC Portal предоставляет пользователю графический веб-интерфейс для ознакомления со статистикой на панелях мониторинга (дашбордах), получения сведений об инцидентах и взаимодействия со специалистами BI.ZONE. Всего на платформе доступно восемь разделов, характеризующих как процесс работы с инцидентами в ИБ, так и сами инциденты: статистика по приоритету и статусу, отнесение признаков инцидентов к тактикам, техникам и процедурам из матрицы MITRE ATT&CK.

Рисунок 9. Веб-интерфейс пользователя BI.ZONE SOC Portal. Дашборды

Рисунок 10. Соотнесение инцидентов с MITRE ATT&CK в BI.ZONE SOC Portal

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

Расследование инцидентов

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

Рисунок 11. Веб-интерфейс пользователя BI.ZONE SOC Portal. Список инцидентов

Карточка инцидента содержит подробное описание, составленное аналитиками BI.ZONE, и восстановленную хронологию событий с указанием места происшествия (хост), объектов (файлы, скрипты и т. д.), выявленных индикаторов компрометации и используемых тактик и техник атакующего. Также обязательно выдаются рекомендации для заказчика: что необходимо предпринять в рамках реагирования или сделать для расследования инцидента и повышения защищённости инфраструктуры.

Рисунок 12. Веб-интерфейс пользователя BI.ZONE SOC Portal. Карточка инцидента

К каждой карточке добавляется чат с аналитиками BI.ZONE, занимающимися разбором конкретного случая («Комментарии к инциденту»), для оперативной коммуникации при расследовании.

На вкладке «Связанные активы» отображаются вовлечённые в инцидент объекты.

Рисунок 13. Веб-интерфейс пользователя BI.ZONE SOC Portal. Активы из карточки инцидента

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

Рисунок 14. Веб-интерфейс пользователя BI.ZONE SOC Portal. Уведомления из карточки инцидента

Последняя вкладка содержит индикаторы компрометации, связанные с инцидентом.

Рисунок 15. Веб-интерфейс пользователя BI.ZONE SOC Portal. Выявленные индикаторы компрометации

При необходимости пользователь может сам создать карточку инцидента для дальнейшего расследования специалистами BI.ZONE.

Рисунок 16. Создание карточки инцидента в системе BI.ZONE SOC Portal

Управление системами

Раздел «Системы» используется в тех случаях, когда к BI.ZONE TDR подключено несколько инфраструктур предприятия: например, головной офис и филиалы в разных регионах либо корпоративная и промышленная инфраструктуры. Также деление на системы позволяет разграничить доступ к инцидентам со стороны специалистов из филиалов организации.

Рисунок 17. Веб-интерфейс пользователя BI.ZONE SOC Portal. Раздел «Системы»

Рисунок 18. Веб-интерфейс пользователя BI.ZONE SOC Portal. Подробная карточка системы

Управление источниками событий

Раздел «Источники событий» содержит перечень источников, подключённых к SOC и используемых для выявления инцидентов. Каждый источник имеет название и тип, отображаются статистика по событиям в секунду (EPS), дата последнего события и наименование коллектора, через который осуществлено подключение источника.

Рисунок 19. Веб-интерфейс пользователя BI.ZONE SOC Portal. Раздел «Источники событий»

Можно выгрузить данные в формате CSV для более удобной работы, применить фильтрацию и полнотекстовый поиск.

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

Конструктор и выгрузка отчётов

Отчёты формируются двумя способами: за выбранный период и по расписанию. В отчёт попадают данные из разделов «Дашборд» и «Инциденты».

Рисунок 20. Веб-интерфейс пользователя BI.ZONE SOC Portal. Раздел «Отчёты»

Отчёт предоставляется в формате PDF и содержит данные об инцидентах, выявленных в рамках оказания услуг по информационной безопасности на базе BI.ZONE SOC, а также об обращениях заказчика.

Рисунок 21. Отчёт BI.ZONE SOC Portal. Зарегистрированные инциденты и обращения

По каждому инциденту, так же как и в веб-интерфейсе, предоставляются подробное описание и рекомендации специалистов.

Пользователь может сам создавать отчёты по необходимой ему системе и с заданной периодичностью. Конструктора отчётов с возможностью выбора необходимых разделов и блоков в BI.ZONE SOC Portal нет, но соответствующая доработка зафиксирована в планах развития.

Рисунок 22. Создание нового отчёта в BI.ZONE SOC Portal

Документация

Для удобства пользователя в веб-интерфейсе BI.ZONE SOC Portal предусмотрен раздел «Документация», содержащий инструкции по настройке источников событий и реагированию на инциденты.

Рисунок 23. Веб-интерфейс пользователя BI.ZONE SOC Portal. Инструкции по настройке источников событий

Каждая инструкция содержит подробное описание действий по настройке, снабжённое иллюстрациями там, где это необходимо. Также к некоторым инструкциям могут быть приложены дополнительные файлы, которые требуются в процессе конфигурирования (например, экспортированная в файл политика аудита). При необходимости инструкция может выгружена с портала в формате PDF — например, если возникает необходимость передать её специалистам, у которых нет учётной записи для доступа на портал.

Рисунок 24. Инструкция по настройке аудита MySQL в BI.ZONE TDR

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

Рисунок 25. Веб-интерфейс пользователя BI.ZONE SOC Portal. Статья по обнаруженной уязвимости

База правил расположена на вкладке «Правила». Уже больше года, поставив цель добиться максимальной прозрачности, BI.ZONE предоставляет заказчикам доступ ко всем своим правилам. По каждому правилу приведены название, описание, уровень доверия и ссылки на дополнительную информацию.

Рисунок 26. Веб-интерфейс пользователя BI.ZONE SOC Portal. База правил BI.ZONE SOC

Выводы

Сервис BI.ZONE TDR позволяет повысить устойчивость организации к киберугрозам и решить наиболее насущные проблемы обеспечения кибербезопасности: сократить время обнаружения сложных угроз и реагирования на инциденты, снизить расходы на обеспечение кибербезопасности за счёт привлечения высококвалифицированных специалистов BI.ZONE, обеспечить прозрачность происходящего в инфраструктуре заказчика.

BI.ZONE TDR опирается на объёмную базу самостоятельно разработанных правил корреляции, которых на данный момент уже более 1500, поддерживает коннекторы для большого числа различных источников. EDR и Threat Intelligence, используемые для выявления и анализа угроз, являются собственной разработкой BI.ZONE.

Сервис активно развивается, на 2023 год запланирован ряд доработок. Так, в третьем квартале в SOC Portal появится модуль инвентаризации активов, который позволит собрать сведения об источниках событий и хостах с EDR-агентами в одном месте, а также оценивать уровень охвата EDR-агентами защищаемой инфраструктуры. Кроме того, по каждому активу появится возможность отслеживать обнаруженные уязвимости и недостатки конфигураций по данным инвентаризации от EDR. Это могут быть, например, небезопасно сохранённые учётные данные привилегированных пользователей (в открытом виде или с использованием обратимого шифрования), неразрешённое ПО в продуктивных средах, возможные векторы локального повышения привилегий, нарушение политик использования привилегированных учётных записей и др.

Также в SOC Portal появится возможность согласовывать действия по активному реагированию и просматривать историю всех инициированных / выполненных с помощью EDR-агента ответных действий.

К концу года BI.ZONE планирует расширить перечень систем, которые доступны для активного реагирования, рядом других решений — например, средствами антивирусной защиты (запуск внеплановой антивирусной проверки хоста) или Active Directory (для выполнения операций с учётными записями).

Достоинства:

• Объединение подходов SOCaaS и MDR в одном сервисе.
• Возможность обнаруживать целенаправленные атаки и проактивно реагировать на них без привлечения специалистов заказчика.
• Выявление неизвестных ранее угроз благодаря проактивному поиску (Threat Hunting).
• Широкий охват ИТ-инфраструктуры с возможностью внедрения на низком уровне её зрелости.
• Комбинирование методов сбора событий «с агентами» и «без агентов».
• Использование собственного EDR-решения, поддерживающего все популярные семейства операционных систем (Windows, Linux, macOS), что даёт разработчику возможность оперативно адаптироваться под стремительно меняющийся ландшафт угроз.
• Богатая библиотека правил выявления инцидентов охватывает большую часть известных тактик и техник атакующих, представленных в матрице MITRE ATT&CK.
• Интеграция с ГосСОПКА (возможность автоматизированной передачи инцидентов).

Недостатки:

• Отсутствие возможности добавления собственных дашбордов.
• Отсутствие конструктора отчётов.