Рабочее пространство кейса и War Room
Маршрут: /cases/:caseId (создание — /cases/new) · Права:
cases.view (открыть), cases.edit, cases.close, cases.reopen,
cases.create, cases.delete, war_room.view (живая лента и командная
строка), плюс права на виджеты (evidence.view/evidence.manage,
comments.view/comments.manage, tasks.view/tasks.manage,
playbooks.view/playbooks.decide) · Модуль: cases
Почему это важно. Страница детали кейса — это где инцидент фактически разбирают. Всё, что нужно аналитику — поля инцидента, его индикаторы и активы, прогоны плейбуков, доказательства, обсуждение и след аудита — собрано на одном экране и держится живым по WebSockets, так что целая смена может расследовать один инцидент одновременно, не наступая друг другу на ноги. War Room — это совместное сердце этого экрана: хронологический журнал в реальном времени всего, что случилось с кейсом, плюс командная строка, позволяющая рулить платформой из одной строки ввода.
Страница детали кейса управляется layout-ом: какие поля, виджеты и секции появляются, решает layout, привязанный к типу инцидента (собранный в конструкторе Layout — см. главу 7). Два кейса разных типов поэтому могут выглядеть довольно по-разному. Эта глава документирует каждый элемент управления, который может появиться; на любом конкретном кейсе вы увидите подмножество, которое включает layout.
10.1. Открытие кейса и режимы рабочего пространства
Вы попадаете на кейс, кликнув его заголовок в списке кейсов
или пройдя по ссылке из виджета, уведомления или ленты War Room. URL —
/cases/:caseId. За этим URL сидит небольшой резолвер: если id принадлежит этому
узлу, он открывает локальное рабочее пространство; если он принадлежит
удалённому федеративному тенанту, он открывает спиннер «Resolving case…», а
затем перенаправляет вас, в новой вкладке, к владеющему тенанту с токеном single-
sign-on (федерация покрыта в руководстве администратора). Неизвестный id
показывает чистую страницу Case not found.
Локальное рабочее пространство работает в одном из нескольких режимов,
выбираемых query-параметром ?view=. Режим меняет тело страницы, а не кейс:
Режим (?view=) |
Что показывает | Право |
|---|---|---|
| summary (по умолчанию) | Полное рабочее пространство: поля инцидента, виджеты, вкладки Work Plan и War Room. | cases.view |
| quick | Сжатый layout quick view (quickView layout-а), с теми же вкладками Work Plan и War Room. |
cases.view |
| edit | Форма редактирования полей, с Save Changes / Cancel. | cases.edit |
| close | Форма закрытия, с Close Incident / Cancel. | cases.close |
| new | Форма создания инцидента (достигается через /cases/new). |
cases.create |
В режимах summary и quick рабочее пространство отрисовывается как компактная
доска-«холст»: тонкая строка заголовка с номером кейса, заголовком и тегами статуса,
за которой следуют секции layout-а и дополнительные вкладки. В режимах edit и
close страница вместо этого показывает озаглавленную карточку, содержащую форму.
Текущий режим — часть URL, так что ссылка, оканчивающаяся на ?view=close,
открывается прямо в форме закрытия.
10.2. Верхняя панель кейса — все действия
В заголовке холста (summary/quick) левая сторона показывает #<номер> <заголовок>,
за которым следуют теги severity (цветокодированный), status, бренд
source и по одному фиолетовому тегу на каждую сопоставленную технику MITRE
ATT&CK (наведите на тег техники ради её тактик). Правая сторона держит панель
действий. Та же панель действий появляется в карточке над формой в режимах
edit/close.
| Элемент | Когда появляется | Действие |
|---|---|---|
| Back to Summary | любой режим кроме summary | Вернуться к ?view=summary. |
| Edit Incident | открытый кейс, summary, cases.edit |
Переключиться на форму редактирования. |
| Close Incident | открытый кейс, summary, cases.close |
Переключиться на форму закрытия (показана как красная/danger кнопка). |
| Reopen Incident | закрытый кейс, cases.reopen |
Переоткрыть кейс. Для кейса, закрытого как duplicate, подтверждение спрашивает, отвязать ли его также от первичного инцидента. |
| ⋯ (More) | всегда | Меню overflow — см. ниже. |
Меню ⋯ More содержит, по порядку, только записи, которые разрешают ваши права:
| Пункт меню | Право | Действие |
|---|---|---|
| Context Data | cases.view |
Открывает выдвижную панель Context Data (см. §10.12). |
| Raise as GRC risk | grc_risks.manage |
Продвигает кейс в новый GRC-риск и прыгает в Risk Register. |
| Edit Incident Type Layout | layouts.manage |
Открывает конструктор Layout для этого типа инцидента. Если кейс на виртуальном (несохранённом) дефолтном layout-е, сначала материализует редактируемую копию. |
| New Incident | cases.create |
Открывает форму создания инцидента. |
| Delete Incident | cases.delete |
Удаляет кейс (показан красным). |
Справа от панели действий (в режимах edit/close) небольшая подпись показывает
Layout: <name> и тег с source layout-а. Если вы можете управлять layout-ами
и кейс на виртуальном дефолте, подсказка напоминает, что виртуальный layout нужно
материализовать, прежде чем его можно редактировать.
Заметка. Кнопки export или print на кейс нет. Формальные документы инцидента производятся из раздела Reports. Собственная запись кейса захватывается непрерывно в ленте War Room и таймлайне.
10.3. Редактирование, закрытие и переоткрытие
Edit (?view=edit, cases.edit) отрисовывает edit-представление layout-а
как форму. Поля — те, что layout экспонирует для редактирования; встроенные поля
(title, description, severity, status, owner/assignee, source, tags) сидят рядом с
любыми кастомными полями, и видимость полей может реагировать вживую на то, что вы
набираете (правила оцениваются на сервере). Save Changes персистит и возвращает
в summary; Cancel отбрасывает. Редактирование заблокировано на закрытом кейсе с
inline-уведомлением, указывающим сначала переоткрыть.
Close (?view=close, cases.close) отрисовывает close-представление
layout-а. Типичные поля — close reason / classification (взятая из настроенных
причин закрытия инцидента, напр. true positive / false positive / duplicate)
и closure summary. Свободнотекстовый close comment, который вы вводите здесь,
постится как комментарий кейса до того, как кейс закрывается. Close Incident
(красная) финализирует; Cancel возвращает в summary.
Reopen (cases.reopen) предлагается на закрытом кейсе. Для обычного кейса он
переключает статус прямо обратно на open. Для кейса, который был закрыт как
duplicate of #N, модальное окно сначала спрашивает, убрать ли маппинг дубликата
и отвязать его от первичного инцидента.
10.4. Виджеты Summary и привязанный layout
В режиме summary/quick секции layout-а отрисовываются как сетка, и рабочее пространство затем добавляет две фиксированные вкладки — Work Plan и War Room — после собственного содержимого layout-а. (Если сам layout определяет вкладки, вкладки layout-а идут первыми, а Work Plan / War Room дописываются; иначе секции layout-а сворачиваются во вкладку Incident Info, а две дополнительные вкладки следуют.)
Layout может разместить любой из этих типов виджетов; каждый задокументирован в указанном разделе:
| Виджет | Что отрисовывает | Разобран в |
|---|---|---|
| Incident Info (fields) | Поля инцидента согласно layout-у | гл. 7 |
| Notes | Композер заметок аналитика + список заметок newest-first | §10.7 |
| Comments | Threaded-обсуждение | §10.7 |
| Tasks | Чек-лист задач кейса | §10.8 |
| Evidence | Файлы-доказательства | §10.10 |
| Approvals (quick actions) | Ожидающие согласования | §10.9 |
| Playbook Console | Компактная строка прогона + недавние прогоны | §10.11 |
| Timeline | Цветокодированный таймлайн событий | §10.14 |
| Team Members | Владелец, назначенец, живые зрители, коллабораторы | §10.14 |
| Canvas | Локальные карточки-стикеры | §10.14 |
| Related Incidents | Связанные / дубликаты / дочерние / родительские кейсы | §10.14 |
| IOC / indicators | Таблица индикаторов кейса | гл. 5 (Threat Intel) |
| Linked Assets | Активы, привязанные к кейсу | гайд GRC |
| Business Impact | Радиус поражения + рекомендация по приоритету | §10.15 |
| Investigation Workbook | Доска фаз и трекер шагов | §10.13 |
| SLA Status, Raw Data, Enrichment, Email Headers/Preview, Markdown, Dynamic Section | Read/утилитарные виджеты | гл. 7 |
Пустая или ограниченная ролью секция не отрисовывает ничего, так что summary всегда показывает только то, что применимо к этому кейсу и вашей роли.
10.5. Лента War Room
Открытие: вкладка War Room в рабочем пространстве кейса (URL
/cases/:caseId/war-room перенаправляет на /cases/:caseId?tab=war-room) ·
Право: war_room.view
Почему это важно. Лента War Room — единственная хронологическая запись инцидента: каждая заметка, комментарий, команда, шаг плейбука, согласование, действие с доказательствами, смена статуса и обогащение попадают сюда по порядку, так что любой, присоединяющийся к кейсу, может читать сверху вниз и точно знать, что было сделано.
Лента показывает до 120 самых недавних записей, старейшие сверху и новейшие
снизу, и авто-прокручивается к новейшей записи по мере прихода активности. Новые
записи появляются вживую — лента освежает себя, когда бэкенд проталкивает
событие timeline:new для этого кейса — а кнопка Refresh в заголовке карточки
форсирует ручную перезагрузку.
Сегментированный фильтр наверху сужает поток:
| Фильтр | Показывает |
|---|---|
| All | Всё (по умолчанию). |
| Notes | Ручные заметки / записи аналитика. |
| Comments | Комментарии и plain-text чат-сообщения. |
| Playbooks | Выполнения плейбуков и вывод шагов автоматизации. |
| Approvals | Запросы согласований и ответы. |
| Evidence | Доказательства загружены / удалены. |
| Tasks | Задача создана / обновлена. |
| Status | Смены статуса и команды /system. |
| Enrichment | Результаты обогащения, вывод команд !integration, слияния контекста. |
Каждая запись взята из записи таймлайна кейса, так что лента — это append-only
журнал: содержимое записи никогда не редактируется и не удаляется из ленты —
это след аудита. Однако аналитик с cases.edit может закрепить запись или
отметить её как доказательство, не изменяя её (см. Закрепление и
доказательства ниже). Каждая запись отрисовывается в карточке, соответствующей
её виду:
| Вид записи (как появляется) | Отрисован как |
|---|---|
| comment / чат-сообщение | Чат-пузырь или карточка комментария с инициалом автора, именем и временем. Markdown в теле отрисовывается (заголовки, списки, таблицы, жирный, inline-код, fenced-код). |
! команда интеграции |
Карточка команды интеграции: командная строка, актор, коннектор, который она дёрнула, длительность, markdown-результат, опциональный бокс ошибки, сворачиваемый блок Raw JSON и футер Success/Failed. |
/ системная команда |
Компактная карточка команды: команда и однострочный результат. |
| шаг плейбука (command / error / engine output) | Карточка узла плейбука с иконкой статуса (success / skipped / failed), заголовком шага, временем и markdown-выводом (таблицы поддерживаются). Упавшие шаги тонированы красным. |
| запрос/ответ согласования, доказательство загружено/удалено, задача создана/обновлена, смена статуса, обогащение, слияние/обновление контекста | Обобщённая карточка события: чип категории с иконкой, тип записи, сервис-источник, timestamp, заголовок, актор («by …» или «System event»), любое содержимое тела и до шести тегов деталей (phase, workflow, file, type, status, assignee, action, decision или переход from → to). |
Если ничего ещё не случилось, лента показывает No investigation activity yet.
Закрепление и доказательства. При наведении на карточку записи появляются
два действия (показываются при cases.edit на открытом кейсе): Закрепить
удерживает запись в полосе закреплённых вверху ленты для быстрого доступа, а
Отметить как доказательство помечает запись как доказательство. У
закреплённой записи есть значок-пин, а после отметки появляется чип
Доказательство (отметка идемпотентна). Записи, отмеченные как доказательства,
также выводятся в разделе только для чтения Доказательства из боевой комнаты
на панели Evidence кейса (§10.10) — это теги на записях ленты, а не
загруженные файлы. Свободного редактора тегов в этом релизе нет; теги
проявляются через отметку доказательством.
Вид Board (панель)
Вверху вкладки War Room сегментированный переключатель Feed | Board (по умолчанию — Feed) переключает между хронологической лентой и Board — раскладкой панелей, заданной для типа инцидента в Settings → War Room Panels (см. руководство администратора). Board отрисовывает настроенные секции и виджеты этого типа инцидента:
- Секции или виджеты, помеченные hidden, либо ограниченные ролями, которых у
вас нет, опускаются. Это косметический слой — реальной границей доступа
является
war_room.view, проверяемое на сервере. - grid-раскладка секции размещает виджеты рядом по их ширине столбца; stack-раскладка складывает их на всю ширину. Ограничение высоты виджета прокручивает его тело.
- Встроенные виджеты переиспользуют те же панели, что вы видите в других местах кейса (контекст-данные, IOC, обогащение, таймлайн, комментарии, задачи, доказательства, заметки, быстрые действия, консоль плейбука, сырые данные, ручной таймлайн). Неизвестный встроенный тип отрисовывает нейтральную карточку «unsupported widget», а не ломает Board.
- Скриптовые виджеты запускают свой backend-скрипт при открытии Board и отрисовывают результат (markdown, одно число, таблицу или список); у каждого виджета своё обновление, а кнопка Refresh board перезапускает их все. Скрипт без результата (или не найденный в реестре автоматизаций) показывает предупреждение внутри своей карточки.
Редактирование Board остаётся в Settings; вкладка кейса только отрисовывает его.
10.6. Командная строка (War Room CLI)
Где: фиксированная строка, приколотая к низу рабочего пространства кейса (скрыта
на закрытом кейсе) · Право: cases.edit
Почему это важно. Командная строка превращает War Room в консоль: можно запостить сообщение, выполнить системное действие или вызвать threat-intel коннектор, не покидая кейс и не открывая другой экран — и всё, что вы делаете, записывается как запись ленты.
Набирайте в единую строку ввода и жмите Enter, чтобы отправить (Shift+Enter для переноса строки). Набранное маршрутизируется по первому символу, а живой тег справа от ввода говорит, в каком режиме вы, до отправки:
| Вы набираете | Режим | Результат |
|---|---|---|
| обычный текст | Chat Message (зелёный) | Постит чат/заметку в ленту. |
/… |
System Command (синий) | Гоняет платформенное действие на этом кейсе. |
!… |
Integration Command (фиолетовый) | Гоняет команду коннектора (threat-intel обогащение и т. д.). |
Кнопка отправки читается Send для чат-сообщения и Execute для команды /
или !.
Системные команды. Начните набирать /, чтобы получить автодополнение.
Доступные команды:
| Команда | Эффект |
|---|---|
/help |
Перечислить системные команды. |
/assign <email-or-userId> |
Задать владельца/назначенца кейса. |
/severity <critical|high|medium|low|informational> |
Сменить severity. |
/status <new|open|in_progress|pending_approval|resolved|closed> |
Сменить статус. |
/tag <tag1> [tag2 …] |
Добавить теги на кейс. |
/link-incident <caseId> [--type <linked|duplicate|child>] |
Связать другой кейс. |
/run-playbook <playbookId> [--input <json>] |
Запустить плейбук на этом кейсе. |
/playground-create |
Создать сессию investigation playground (песочницу, чтобы пробовать команды) и ответить её именем и ID плюс подсказкой /playground-run <id>. |
/close-investigation [--reason <text>] [--classification <value>] |
Закрыть кейс. |
/reopen-investigation |
Переоткрыть кейс. |
Команды интеграций. Начните набирать !, чтобы искать команды коннекторов.
Подсказки показывают аргументы каждой команды (обязательные отмечены). SOARForge
резолвит команду против ваших активных, дефолт-включённых коннекторов и гоняет её;
обобщённые глаголы вроде !ip, !domain, !url, !file, !email, !cve и
семейство !enrich-* разветвляются на каждый совпадающий коннектор параллельно,
тогда как команда с вендорским префиксом целит в один коннектор. Результаты постятся
как карточка команды интеграции в ленте, а любые индикаторы или техники MITRE,
которые возвращает коннектор, сливаются в кейс автоматически. Пример: !ip ip=8.8.8.8.
Автодополнение, история и клавиши. Подсказки появляются по мере набора префикса
/ или ! (с дебаунсом). Кнопка history (иконка часов) перечисляет ваши
недавние команды на этом кейсе; при закрытом выпадающем списке ↑ / ↓ шагают по
истории в вводе, а Esc его очищает.
10.7. Заметки и комментарии
Notes и Comments — два представления над одним и тем же хранилищем обсуждения кейса; layout может разместить любое или оба.
Comments (comments.view читать, comments.manage постить) — threaded-
обсуждение. Ответы вкладываются под родителем (с отступом). Композер — текстовая
область — Ctrl/Cmd+Enter или кнопка Send постят. Системно-сгенерированные
комментарии отрисовываются серым курсивом. Тела комментариев хранятся как написаны и
отрисовываются с лёгким markdown, когда появляются в ленте War Room. Редактирование
или удаление чужого комментария требует права comments.moderate; системные
комментарии нельзя редактировать или удалять, а удаление мягкое (комментарий
скрывается, а не вычищается).
Notes (те же права) — более лёгкая поверхность: композер заметок с кнопкой Save и списком newest-first верхнеуровневых, не-системных заметок. Используйте её для гипотез и следующих шагов; используйте Comments для threaded- обсуждения.
10.8. Задачи
Виджет: Tasks · Права: tasks.view (читать), tasks.manage
(добавить/завершить)
Чек-лист задач отслеживает to-do расследования. Каждая строка показывает
чекбокс, заголовок задачи (перечёркнут, когда завершена), тег
назначенца, если задан, и срок (MM/DD, показан красным, когда просрочен и
задача не завершена). Отметьте чекбокс, чтобы пометить задачу completed (или
сбросить обратно в pending). Add task раскрывает inline-поле — наберите заголовок
и нажмите Enter (или Add).
Почему это важно. Задачи также точка передачи между автоматизацией и людьми: шаг human task плейбука создаёт задачу кейса и ждёт; когда вы отмечаете эту задачу завершённой, приостановленный шаг плейбука возобновляется. Так плейбук может встать на паузу ради ручной проверки и подхватить там, где остановился.
10.9. Согласования (Quick Actions)
Виджет: Approvals · Права: playbooks.view (видеть их),
playbooks.decide (действовать)
Когда плейбук достигает шага, требующего человеческого одобрения, здесь появляется карточка согласования. Каждая карточка показывает точку статуса, тип действия, подпись, описывающую, что произойдёт, и когда это было запрошено; у ожидающей карточки пульсирующая янтарная рамка. Approve (основная) или Reject (красная) записывает ваше решение, которое возобновляет или останавливает плейбук и пишет запись approval-response в ленту. Когда ничего не ждёт, виджет показывает No pending approvals.
10.10. Доказательства и вложения
Виджет: Evidence · Права: evidence.view (список/скачивание),
evidence.manage (загрузка/удаление)
Почему это важно. Доказательства — это файловое хранилище кейса — захваты пакетов,
.eml-файлы писем, скриншоты, экспортированные логи. Держать их прикреплёнными к кейсу (а не в чате или шаре) сохраняет цепочку хранения и держит доказательство рядом с расследованием.
Заголовок панели показывает счётчик файлов и кнопку Upload. Кликните Upload и выберите один или несколько файлов; каждый хранится и перечисляется со своим именем, размером и относительным временем загрузки. По строке:
- Download (иконка стрелки) — открывает файл по короткоживущей подписанной ссылке
(ссылка валидна около 15 минут). Доступно любому с
evidence.view. - Delete (красная иконка корзины) — показана только с
evidence.manage. Удаление — мягкое удаление: файл выпадает из списка, а запись evidence deleted пишется в ленту.
Лимиты и хранение. Одна загрузка может быть до 100 МБ. Байты файла хранятся в объектном хранилище платформы (MinIO); приложение никогда не отдаёт их напрямую — скачивания всегда идут через подписанную ссылку. Загрузки дедуплицируются по хешу содержимого, так что повторная загрузка идентичного файла не создаёт вторую копию. Ограничения по типу файла при загрузке нет.
Доказательства из боевой комнаты. Под списком файлов панель показывает раздел только для чтения Доказательства из боевой комнаты: записи ленты, которые аналитик отметил как доказательства (§10.5). Это теги на записях таймлайна/комментариев, а не файлы — они не хранятся в объектном хранилище и не скачиваются отсюда; откройте вкладку War Room, чтобы прочитать их в контексте. Отметка и снятие отметки выполняются из ленты, а не из этой панели.
Доказательства vs библиотека доказательств GRC. Доказательства кейса (War Room) и библиотека доказательств GRC — это отдельные системы. GRC- доказательства прикрепляются к контролям, оценкам, рискам, исключениям, политикам, находкам аудита и элементам ремедиации — никогда к кейсу — и управляются в гайде GRC. Пометка файла кейса как «evidence» не добавляет его в библиотеку GRC, и наоборот.
10.11. Work Plan — представление выполнения плейбука
Вкладка: Work Plan (в рабочем пространстве summary/quick) · Право:
cases.view; запуск плейбука использует cases.edit
Почему это важно. Work Plan — это где вы запускаете плейбуки реагирования на кейсе и смотрите, как они гоняются, шаг за шагом, на живом графе — том же DAG, что вы увидели бы в редакторе плейбуков (глава 8), но в read-only режиме выполнения со статусом и выводом на шаг.
Вкладка центрируется на execution canvas плейбука. Её элементы управления:
| Элемент | Действие |
|---|---|
| Run selector | Выбрать, какой прогон смотреть — Run #N — <status> · <started>, новейшие первыми. |
| Status tag | Состояние выбранного прогона (Queued / Running / Completed / Failed / Cancelled / Waiting). |
| Refresh | Перезагрузить прогон и его шаги (представление также авто-освежается каждые ~2.5 с, пока прогон активен). |
| Run Playbook | Открывает модальное окно Run Playbook: выбрать активный плейбук и, опционально, JSON-объект входов, затем Run. |
Холст рисует плейбук как граф узлов (пан, зум, мини-карта; узлы здесь не перетаскиваемы). Кликните узел, чтобы открыть его панель детали с тремя вкладками — Input, Output и Context (контекст кейса в этой точке). Когда узел ждёт, панель детали добавляет элемент, который его разблокирует:
| Тип ждущего узла | Элемент |
|---|---|
Approval (wait_approval) |
Approve / Reject (показаны разрешённые роли). |
| Ask | Настроенные кнопки ответа (или Approve / Reject). |
| Human task | Заметка, что связанная task кейса должна быть завершена для возобновления (§10.8). |
| Data collection | Submit Response — открывает форму (text, number, checkbox, date, select / multi-select), построенную из вопросов шага. |
| Polling | Спиннер прогресса и Cancel Polling. |
Футер показывает, сколько шагов отработало, и время старта/финиша прогона. Упавший прогон показывает свою ошибку баннером.
Компактный виджет Playbook Console (виджет layout-а, а не вкладка) — легковесный собрат: строка Select playbook → Run плюс пять самых недавних прогонов с тегами статуса. Используйте Console, чтобы запустить прогон с доски summary, а вкладку Work Plan — чтобы наблюдать за ним детально.
10.12. Context Data
Где: ⋯ More → Context Data (правая выдвижная панель) и вкладка Context
внутри узла Work Plan · Права: cases.view читать; cases.edit редактировать
или удалять значение
Почему это важно. Context Data — это живое хранилище ключ/значение кейса — поля инцидента плюс всё, что написали плейбуки и коннекторы (вывод обогащения, извлечённые индикаторы, результаты интеграций). Это сырьё, которое читают условия плейбуков и динамические поля layout-а, и место, где взять DT-путь для использования в плейбуке или автоматизации.
Панель показывает контекст как сворачиваемое JSON-дерево под единым узлом
root, сгруппированное для читаемости: системные поля первыми, затем каноническое
пространство имён incident (развёрнуто по умолчанию), затем пространства имён
выводов автоматизаций, затем labels. Заголовок показывает общий размер, со
ссылками Collapse / Expand. Поле search фильтрует по ключу или значению.
Взаимодействия:
- Кликните лист (или результат поиска), чтобы скопировать его DT-путь как
${path}в буфер — готовый к вставке в плейбук или трансформер. - Правый клик по узлу для Copy DT path, а — с
cases.edit— Edit value (редактор JSON/текста; объекты и массивы парсятся автоматически) и Delete key (убирает узел и всё вложенное под ним, после подтверждения).
Раздел Executions наверху перечисляет прогоны плейбуков кейса с живым статусом. Дерево обновляется в реальном времени по мере того, как плейбуки пишут контекст. Записи ограничены по размеру и глубине на сервере, а системные поля защищены, так что редактор не может испортить запись кейса.
10.13. Investigation Workbook
Виджет: Investigation Workbook (присутствует, когда тип инцидента отображается на workbook)
Почему это важно. Workbook — это направляемый, пофазовый runbook, прикреплённый к кейсу — triage → enrichment → investigation → containment → eradication → recovery → notification — так что аналитик всегда знает следующий шаг, а ревьюер видит, насколько продвинулось реагирование.
Виджет открывается с cockpit-заголовком: имя workbook, селектор autonomy level (L1 / L2 / L3, который управляет тем, сколько платформа может автоматизировать), счётчик шагов и прогресс-бар. Ниже:
- MITRE ATT&CK techniques — чипы техник для кейса. Кандидатные техники (из
извлечения, AI или ручного добавления) несут пунктирную рамку и действие
Confirm / Dismiss при наведении; подтверждённые техники рулят остальным
workbook. Технику можно добавить по ID (
T####/T####.###) с поиском. - D3FEND recommendations — защитные контрмеры, предложенные из подтверждённых техник.
- Steps — сгруппированы по фазе на рельсе таймлайна. Каждый шаг показывает узел статуса (locked / ready / in progress / completed / skipped / blocked) и его теги MITRE. Динамически внедрённые шаги отмечены глифом искры (ATT&CK) или щита (D3FEND).
Клик по шагу открывает его модальное окно детали: инструкции, поле notes,
плейбуки на шаг, которые можно run, и действия состояния Start, Complete
(с заметками завершения), Skip и — для привилегированных аналитиков — Block
/ Unblock. Пропуск шага может требовать причины; блокировка/разблокировка и
принудительный пропуск требуют права investigation_workbooks.override_skip. Доска
согласуется вживую между аналитиками по мере смены шагов.
10.14. Team Members, Canvas, Related Incidents и Timeline
Team Members. Перечисляет людей на кейсе: Owner (создатель), Assignee, любого сейчас смотрящего (вживую, из presence — см. §10.16) и Collaborators (людей, оставивших комментарий). Каждая строка показывает имя, контакт и тег роли.
Canvas. Свободная доска карточек-стикеров (заголовок, детали и цвет: янтарь / синий / зелёный / роза). Add Card открывает модальное окно; иконка корзины на карточке её убирает. Обратите внимание: Canvas хранится локально в вашем браузере, на кейс — это личный черновик и он не разделяется с другими аналитиками и не переживает на другом устройстве.
Related Incidents. Показывает кейсы, связанные с этим, сгруппированные в Linked / Duplicate / Child / Parent. Можно Add Relation (искать кейс и выбрать тип связи) и убрать связь. Связи также появляются как бейджи в списке кейсов.
Timeline. Цветокодированный вертикальный таймлайн событий кейса — auto (синий), manual (зелёный), enrichment (фиолетовый), approval request (оранжевый), approval response (циан), comment (серый) и status change (золотой) — каждое с относительным временем и актором. Он обновляется вживую на новых событиях. Это компактный, типизированный кузен ленты War Room.
10.15. Бизнес-влияние (GRC)
Виджет: Case Business Impact (с модулем grc и привязанным активом)
Виджет резюмирует, насколько инцидент мог бы навредить: максимальную критичность привязанных активов, число привязанных активов и системный радиус поражения (число затронутых информационных систем). Когда сервер вычисляет, что severity кейса должно измениться, чип priority recommendation предлагает Apply (задать рекомендованное severity) или Dismiss. Он освежается вживую по мере привязки или отвязки активов. Полная глубина GRC — критичность активов, системы и риск — в гайде GRC; сводка уровня аналитика в гайде аналитика §4.5.
10.16. Совместная работа в реальном времени и присутствие
Рабочее пространство кейса держит живое соединение с сервером (Socket.IO) и присоединяется к комнате, ограниченной кейсом, так что следующее обновляется без обновления страницы для всех на кейсе:
- Новые записи ленты и таймлайна по мере их записи.
- Смены полей и статуса кейса — заголовок, поля и виджеты пере-запрашиваются при обновлении кейса.
- Прогресс плейбука — холст Work Plan и списки прогонов продвигаются по мере выполнения и завершения шагов.
- Согласования — карточки появляются и очищаются по мере прихода запросов и решений.
- Задачи — чек-лист отражает создания и завершения.
- Context Data — дерево обновляется по мере того, как плейбуки пишут контекст.
- SLA — SLA-виджеты отражают переходы at-risk / breached / met.
Присутствие. Когда вы открываете кейс, вы присоединяетесь к его комнате; строка «N viewing» (с аватарами) показывает, кто ещё на кейсе прямо сейчас, и эти люди также появляются как Viewers в Team Members. Комната кейса держит до 50 одновременных зрителей.
10.17. AI-помощь на кейсе
Отдельного внутрикейсового чат-копилота нет. AI-помощь, доступная на кейсе, — это глобальный AI-ассистент — кнопка 🤖 в заголовке (гайд аналитика §1.5). Он read-only и ограничен вашими собственными правами, так что вы можете попросить его резюмировать открытый кейс или ответить на вопросы о нём, но он никогда не меняет данные кейса. Autonomy levels workbook (§10.13) — это поверхность, которая управляет тем, сколько расследования автоматизирует платформа — отдельная концепция от чат- ассистента.
10.18. Закрытые инциденты только для чтения
Как только кейс закрыт, всё рабочее пространство становится read-only: поля,
заметки, комментарии, доказательства, индикаторы, согласования, прогоны плейбуков,
задачи и командная строка War Room — всё заперто, и баннер об этом сообщает. Лента и
история остаются полностью читаемыми. Чтобы возобновить работу, используйте Reopen
Incident (cases.reopen); если у вас нет этого права, баннер говорит попросить
администратора.
Распространённые ошибки
- Вкладка War Room — не весь War Room. Вкладка — это живая лента (read-only журнал). Интерактивные панели — Comments, Tasks, Evidence, Approvals, Playbook Console — это виджеты layout-а, размещённые на доске summary. Если ожидаемая панель отсутствует, это выбор layout-а для этого типа инцидента (глава 7), а не баг.
- Записи ленты нельзя редактировать или удалять. Лента — след аудита. Чтобы
убрать комментарий, используйте виджет Comments (мягкое удаление,
comments.moderateдля чужих комментариев); запись ленты о действии остаётся. - Карточки Canvas приватны и локальны. Они живут только в вашем браузере. Не используйте Canvas для чего-либо, что должен видеть коллега — используйте Notes, Comments или Tasks.
- Удаление доказательства мягкое. Файл покидает список, но хранимый объект сохраняется; трактуйте «delete» как «скрыть с кейса», а не «стереть».
- Ссылки на скачивание истекают. Ссылка скачивания доказательства валидна лишь ~15 минут — кликайте её, когда файл нужен, не добавляйте в закладки.
- Командам
!нужен коннектор. Команда интеграции гоняется, только если активный, дефолт-включённый коннектор её экспонирует; без настроенных ей не по чему гоняться. - Редактирование требует открытого кейса. Почти каждая запись требует, чтобы кейс был открыт. Если элемент недоступен, проверьте, не закрыт ли кейс, прежде чем предполагать проблему с правами.
- Кросс-тенантный «not found» — это редирект, а не ошибка. Открытие кейса, живущего на другом федеративном тенанте, отправляет вас к этому тенанту в новой вкладке через SSO; это ожидаемое поведение, а не сломанная ссылка.