> «Карта процессов, это база, с которой вся ИБ либо работает, либо нет. Обычно её составление занимает месяцы, но можно сократить до трёх дней. Секрет не в скорости, а в отсеве лишнего. BPMN даёт инженерам язык, а Miro — стену для быстрых решений. Главное — на старте договориться, что мы картируем не «как есть», а «что должно происходить при риске». Иначе завязнем в деталях настоящих рабочих процессов.»
Три дня на полную карту процессов информационной безопасности звучит как фантастика. В реальных проектах на это уходят месяцы, иногда годы. Но срок в 72 часа реален, если понимать ключевое отличие: карта строится не для документирования текущей операционной деятельности компании, а как модель реакций и решений в условиях киберугроз. Это инструмент для инженеров и руководства, а не отчёт для проверяющих.
Зачем нужна такая карта и почему BPMN 2.0
Распространённая ошибка — начинать с описания всех существующих регламентов. Результат — громоздкая диаграмма, которая устаревает через неделю и не отвечает на главный вопрос: кто и что делает, когда происходит инцидент или выявляется уязвимость?
Карта процессов ИБ, построенная по BPMN 2.0, решает другие задачи:
- Даёт однозначное визуальное представление ролей, решений и последовательности действий.
- Служит живым прототипом для автоматизации (SOAR, тикет-системы).
- Позволяет выявить и устранить разрывы в ответственности ещё до реального инцидента.
- Становится основой для обучения новых сотрудников и моделирования сценариев (tabletop exercises).
BPMN 2.0, это стандарт, понятный как бизнес-аналитикам, так и разработчикам. Его элементы (пулы, дорожки, события, шлюзы) интуитивны и исключают разночтения в сложных сценариях с ветвлениями.
«За 3 дня»: что это значит на практике
Сжатый срок — не самоцель, а жёсткое ограничение, отсекающее перфекционизм и избыточную детализацию. Работа идёт в формате интенсивного воркшопа с ключевыми участниками. Эти три дня распределяются не на рисование, а на сессии принятия решений.
День 1: Фреймворк и границы. Определяется, какие классы инцидентов и процессов мы картируем. Не «всё подряд», а критичные с точки зрения регуляторных требований (152-ФЗ, ФСТЭК) и основных бизнес-рисков. Формируется глоссарий: кто такие «Оператор ИБ», «Владелец ресурса», «Группа реагирования». Создаётся скелет карты в Miro — основные пулы (Компания, Внешние стороны) и дорожки для ключевых ролей.
День 2: Прорисовка ключевых сценариев. Проходим 3-5 основных сценариев от начала до конца. Например: «Получение оповещения об уязвимости от поставщика» или «Обнаружение подозрительной активности с рабочей станции». В режиме реального времени на доске Miro участники выстраивают цепочки событий, действий и решений, используя элементы BPMN. На этом этапе выявляются первые спорные моменты и «белые пятна» в ответственности.
День 3: Валидация и связывание. Проработанные сценарии связываются между собой через общие события или точки принятия решений. Например, выходом из процесса обработки инцидента может быть запуск процесса пересмотра политик. Карта проверяется на целостность и непротиворечивость. Формируется итоговый артефакт и список выявленных action items для доработки регламентов.
Инструмент: почему Miro, а не специализированные BPMN -редакторы
Популярные BPMN-редакторы вроде Camunda Modeler или dedicated плагинов для draw.io хороши для финальной, чистовой документации. Но для трёхдневного спринта они проигрывают Miro по нескольким причинам:
- Нулевой порог входа: Все участники с любого устройства мгновенно попадают на доску. Не нужна установка ПО, обучения работе с интерфейсом редактора.
- Совместная работа в реальном времени: Видно, как двигаются мышки других участников, кто и что рисует или комментирует. Это ускоряет обсуждение и создаёт эффект общего дела.
- Гибкость помимо BPMN: На той же доске можно прикрепить скриншот политики, набросать схему архитектуры, создать карточку с вопросом или оставить стикер для будущей доработки. Miro не ограничивает рамками только нотации.
- Библиотеки шаблонов: Существуют готовые наборы BPMN-элементов (stencils) для Miro, которые можно импортировать и сразу начать работу. Ключевой принцип: сначала наращиваем концептуальную массу и находим общее понимание на быстрой, гибкой платформе. Детализацию и приведение к строгому стандарту можно сделать позже, экспортировав наработки.
Ключевые BPMN-элементы для процессов ИБ
Не нужно использовать всю мощь нотации. Для построения понятной карты достаточно небольшого, но точного набора элементов.
| Элемент BPMN | Использование в контексте ИБ | Пример |
|---|---|---|
| Пулы и Дорожки | Пул, это Организация. Дорожки внутри пула — роли (отделы, должностные лица). Внешний пул — Внешний поставщик или Регулятор. | Пул «Наша компания» с дорожками: «Служба ИБ», «Отдел инцидентов», «Администратор». |
| События (Старт, Промежут., Конец) | Стартовое событие — триггер процесса (письмо, алерт, запрос). Промежуточное — получение информации, эскалация. Конечное — закрытие инцидента, отправка отчёта. | Старт: «Поступило письмо от ФСТЭК». Конец: «Отправлен отчёт об исполнении предписания». |
| Задачи | Атомарное действие, которое выполняет роль. | «Проанализировать лог», «Заблокировать учётную запись», «Уведомить руководство». |
| Шлюзы (Ворота) | Точки принятия решения, ветвления или слияния потоков. Ключевой элемент для моделирования развилок. | Эксклюзивный шлюз (XOR): «Уровень критичности уязвимости высокий?» — Да/Нет. Параллельный шлюз (AND): Запустить одновременно задачи «Заблокировать аккаунт» и «Начать сбор артефактов». |
| Потоки управления | Сплошные стрелки, показывают последовательность задач и событий. | |
| Потоки сообщений | Пунктирные стрелки между пулами. Показывают внешнее взаимодействие. | Отправка запроса поставщику, получение уведомления от CERT. |
Чего не должно быть на карте
Чтобы уложиться в срок и сохранить полезность, необходимо жёстко отсекать:
- Слишком глубокую техническую детализацию. Не «настроить правило корреляции в Splunk», а «проанализировать алерт SIEM». Карта описывает управленческие и контрольные действия, а не инструкцию для инженера.
- Одновременное описание процессов «как есть» и «как должно быть». Выбирается одна опорная точка — целевое состояние («как должно быть в соответствии с политиками»). Разрывы между этим состоянием и реальностью фиксируются отдельным списком несоответствий.
- Дублирование положений внутренних регламентов. Карта ссылается на них (например, задача «Действовать по регламенту Р-ИБ-01»), но не копирует их текст.
Что делать с результатами трёх дней
Итогом спринта становится не просто картинка, а набор конкретных артефактов:
- Визуальная карта процессов в Miro (и, опционально, экспорт в
.pngили.pdfдля презентаций). - Протокол разрывов и неопределённостей — список вопросов, на которые не было найдено ответа в ходе сессий (например, «Кто утверждает решение о публикации информации об инциденте?»).
- План действий по согласованию и уточнению — кому, что и к какому сроку нужно доработать в регламентах.
- Уточнённый глоссарий ролей и терминов.
Эта карта становится отправной точкой для дальнейшей работы: автоматизации в SOAR, разработки сценариев учений, актуализации политик. Важно назначить ответственного за её поддержание в актуальном состоянии и проводить ревизию не реже раза в полгода или после значимых изменений в инфраструктуре или регламентах.
Три дня, это не магия, а сфокусированная работа по переводу часто разрозненных и текстовых требований в единую, живую модель. Это инвестиция, которая экономит десятки часов в моменте реального кризиса, когда на кону — время на реакцию.