ДокументацияАдминистратор3. Настройка объектов — типы инцидентов и конвейеры

Настройка объектов — типы инцидентов и конвейеры

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

Раздел Настройка объектов — центральное место настройки объектов платформы: типы инцидентов и их поля, классификаторы, мапперы, конвейеры обработки, layout-ы, панели War Room, индикаторы и дедупликация.

3.1. Типы инцидентов и конвейеры

Маршрут: /admin/incident-types · Права: incident_types.view, incident_types.manage

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

Экран сгруппирован по стадиям жизненного цикла:

  • Classificationclassifier (правила сопоставления события типу инцидента) и objects (типы инцидентов и их поля, см. §3.4).
  • Enrichmentincoming-mappers и outgoing-mappers (входящие и исходящие мапперы полей).
  • Automationclose-reasons, preprocessing (правила до fetch), postprocessing (правила после создания), mirroring (синхронизация с внешними системами), deduplication (см. §3.5), export-delete (правила экспорта/удаления).

Конструктор классификатора состоит из трёх панелей:

  1. Слева — список событий: выбор коннектора/инстанса; загрузка данных («Pull from live events», «Generate sample events», «Paste JSON events»); навигация по событиям, лимит превью, сортировка.
  2. Центр — JSON-дерево события: поиск полей; перетаскивание поля задаёт его source-путь (цвета по типу значения).
  3. Справа — правила классификации: Fallback type (тип по умолчанию) и вкладки по типам инцидентов с drop-зонами для сопоставления значений полей → типам инцидентов.

Наверху — имя классификатора, ссылка на библиотеку объектов, Save и быстрый тест. Остальные вкладки — таблицы (мапперы: Name / Type / Instances / Description / System, с действиями Edit / Clone / Delete; close reasons; правила pre/postprocessing с переупорядочиванием).

3.2. Layout-ы — конструктор layout кейса

Маршрут: /admin/layouts (список), /admin/layouts/:layoutId/edit и /admin/layouts/incident-types/:incidentTypeId (редактор) · Права: layouts.view, layouts.manage

Почему это важно. Layout определяет, какие поля и виджеты и в каком порядке аналитик видит в карточке кейса. Хороший layout ускоряет работу и снижает ошибки; удобно иметь разные layout-ы для разных типов инцидентов.

Визуальная сборка layout-ов кейсов (режимы summary / edit / close / quickView), с историей версий и откатом.

Список layout-ов — вкладки Defaults (по типу инцидента), Versions (все версии), Personal, List View (отображение списком). Кнопки: + New Detached, ⬆ Import Personal, ⬆ Import Managed, поиск и фильтр по типу инцидента. В строках — Edit/View, Create Personal / Open Personal, ⬇ Export, Delete.

Редактор (Layout Builder) — полноэкранный:

Элемент Назначение
Имя layout-а Редактируемое имя; рядом — пилюли статуса (source, state, virtual/personal/default, тип инцидента).
Incident Type (Select) Тип инцидента, к которому привязан layout.
📋 History История версий (drawer с JSON-превью и кнопкой Roll back).
⚙ Settings Расширенный JSON-редактор конфигурации layout-а.
More (⋯) ⬇ Export, 📋 Duplicate, 🔌 Detach (отвязать от default), Delete.
💾 Save Сохранить (недоступно в read-only).
Canvas Сетка: перетаскивание секций, полей, кнопок и виджетов; превью.
Library (слева) Пикер полей, пресеты секций, библиотека виджетов (timeline, comments, notes, evidence, business-impact и т. д.).
Panel свойств (справа) Свойства выбранного элемента (name, label, тип, правила видимости).

Виджет бизнес-влияния. При модуле grc библиотека виджетов включает виджет Case Business Impact (blast radius + рекомендация по приоритету). Добавьте его в layout типа инцидента, чтобы дать аналитикам контекст активов на кейсе — см. руководство аналитика §4.5 и гайд GRC.

3.3. Конструктор панелей War Room

Маршрут: /admin/war-room[/incident-types/:incidentTypeId] · Право: war_room.panels.manage

Почему это важно. Панели War Room ставят нужные аналитику инструменты и данные рядом с лентой расследования; набор панелей настраивается per тип инцидента.

Настройка вспомогательных панелей рядом с лентой War Room в карточке кейса (сама лента — хронологический журнал — здесь не настраивается).

Где появляется сохранённый борд. Сохранённая конфигурация панелей теперь отрисовывается во вкладке War Room кейса в виде Board (переключатель Feed | Board; по умолчанию — Feed). Секции/виджеты, помеченные hidden или ограниченные ролями, скрываются на клиенте для зрителей, а скриптовые виджеты запускаются при открытии. Редактирование остаётся здесь, в Settings — вкладка кейса лишь отрисовывает борд.

  • Список типов инцидентов с кнопкой Open Builder.
  • Редактор: вкладки Visual Builder (drag-and-drop панелей) и Advanced JSON; кнопка 💾 Save; справа — Widget Catalog (каталог виджетов с режимом script/automation, key, описанием и аргументами).

3.4. Индикаторы — типы и исключения

Маршрут: /admin/incident-types?object=indicators (вкладки types / exclusions) · Права: indicators.manage_types, indicators.manage_exclusions

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

В библиотеке объектов слева выберите Indicators; справа — две вкладки:

  • Indicator Types — типы индикаторов и их regex (валидация + извлечение). Таблица (Type Name / Regex / Data Type / Actions), кнопка + New Indicator Type, действия Edit / Duplicate / Delete.
  • Exclusion Rules — правила исключения индикаторов. Таблица (Pattern / Type / Enabled / Actions), кнопка + New Exclusion Rule, тумблер включения.

3.5. Дедупликация

Маршрут: /admin/deduplication · Право: automations.view

Почему это важно. Дедупликация не даёт одному и тому же событию порождать дублирующие кейсы — снижает шум и нагрузку на аналитика. Это один из объектов Automation конвейера инцидента.

Правила автоматической дедупликации инцидентов. Статистика (всего правил, активных, совпадений, среднее окно). Test Dedup (проверка на JSON-сэмпле), + New Rule. Колонки: Name, Match Type (exact / fuzzy / custom), Match Fields, Time Window, Strategy (merge / keep_first / keep_latest), Matches, Status, Actions. Модалка правила: тип сопоставления, стратегия слияния, поля сравнения, временное окно, приоритет, тип инцидента, Enabled.