Как агрегировать киберриски дочерних компаний, не потеряв реальную картину

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

Проблема возникает не потому, что дочерние компании плохо оценивают риски. Чаще они делают это по-разному.

Одна компания считает вероятность по статистике инцидентов. Другая — на основании экспертного мнения. Третья оценивает зрелость контролей. Четвёртая фактически измеряет количество открытых уязвимостей.

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

Единый цвет ещё не означает единого понимания риска.

Представим группу из десяти компаний.

Девять дочерних организаций оценивают риск компрометации привилегированных учётных записей как низкий. Одна крупная компания, управляющая общей identity-платформой, оценивает его как критический.

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

У киберриска нет свойства взаимной компенсации.

Низкий риск одного юридического лица не нейтрализует критичную экспозицию другого. Более того, локально умеренные риски могут образовать системную угрозу, если компании зависят от одного облачного провайдера, SOC, центра обработки данных, канала связи, поставщика ПО или механизма восстановления.

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

На уровне группы важны не только величина каждой оценки, но и:

Пять баллов у банка и пять баллов у сервисной компании могут означать совершенно разные вещи.

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

Различаться могут не только последствия, но и исходные предположения:

Если эти различия не отражены в корпоративной модели, стандартизация создаёт не сопоставимость, а иллюзию сопоставимости.

NIST IR 8286 Rev. 1, опубликованный в декабре 2025 года, подчёркивает необходимость передавать информацию о киберрисках с системного и организационного уровней в процессы enterprise risk management. При этом смысл такой передачи состоит не только в roll-up показателей, но и в понимании риска в контексте целей бизнеса. (NIST Computer Security Resource Center)щий документ NIST IR 8286C Rev. 1 описывает интеграцию информации из cybersecurity risk registers в целостный enterprise risk portfolio и enterprise risk profile. Иными словами, задача корпоративного центра — не собрать максимальное количество локальных оценок, а превратить их в материал для групповых решений. (NIST Computer Security Resource Center)цировать нужно не всё

Распространённая реакция корпоративного центра — обязать все дочерние компании использовать одну методику.

Это может помочь, но не всегда решает проблему.

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

Попытка полностью унифицировать анализ часто приводит к двум последствиям:

Более практичный подход — установить единый минимальный контракт данных, сохранив разумную локальную автономию.

Корпоративному центру не обязательно заставлять всех одинаково рассчитывать вероятность. Но он должен потребовать, чтобы каждая компания одинаково понятно описывала:

NIST CSF 2.0 также связывает зрелое управление с установлением стандартного метода документирования, категоризации и приоритизации рисков, а также с использованием согласованных категорий, позволяющих интегрировать и сравнивать киберриски. Это не означает, что все компании должны применять идентичную математическую модель. Это означает, что результаты должны быть понятны и пригодны для совместного управления. (NIST Computer Security Resource Center)менно следует агрегировать

Я предлагаю рассматривать групповую агрегацию через восемь измерений.

Запись должна описывать не абстрактный «риск утечки» или «риск кибератаки», а причинно-следственную цепочку:

источник угрозы → событие → затронутый актив или процесс → бизнес-последствие.

Например:

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

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

На уровне группы нужны общие диапазоны последствий:

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

Две компании с одинаковым локальным риском могут иметь разную значимость для группы.

Следует учитывать:

В каждом значимом сценарии необходимо фиксировать используемые групповые сервисы и внешние зависимости:

Без этого корпоративный центр видит отдельные риски, но не видит их общий корень.

Некоторые события не являются независимыми.

Крупная уязвимость в общем продукте, компрометация поставщика, ошибка централизованной конфигурации или атака на единую identity-инфраструктуру могут одновременно повысить риск сразу в нескольких компаниях.

Коррелированные сценарии нельзя анализировать как отдельные строки реестра.

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

Например:

Концентрация может быть приемлемой архитектурной стратегией. Но она должна быть осознанной, защищённой и поддержанной проверенной recovery capability.

Не каждый риск должен уходить в корпоративный центр.

Нужно разделить:

Если уровень решения не определён, риск может годами перемещаться между комитетами без реального владельца.

Два одинаковых остаточных риска могут иметь разное качество оценки.

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

Поэтому рядом с величиной риска должна отображаться степень уверенности:

Неопределённость — это не повод скрывать риск. Это отдельный фактор управленческого решения.

Холдингу недостаточно общей heatmap.

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

Outliers. Какие компании или сценарии резко отличаются от остальных?

Concentration. Где группа слишком сильно зависит от одного сервиса, поставщика или центра компетенций?

Correlation. Какие риски способны реализоваться одновременно?

Propagation. Через какие технологические и организационные связи инцидент может перейти из одной компании в другую?

Decision backlog. Какие существенные риски уже выявлены, но решение по ним просрочено, не профинансировано или не имеет владельца?

Именно эти представления позволяют совету директоров и руководству увидеть не среднюю температуру, а потенциальный blast radius.

Требования к содержательному oversight усиливаются и регуляторно. SEC требует от публичных компаний раскрывать процессы управления существенными киберрисками, роль менеджмента и надзор со стороны совета директоров. (SEC)овом секторе ЕС DORA закрепляет ответственность management body за определение, утверждение, надзор и реализацию ICT risk management framework. Регламент также исходит из того, что высокая взаимосвязанность организаций и их ICT-систем способна превратить локальный инцидент в системное событие. (EUR-Lex)ический план для Group CISO

Для запуска модели необязательно сначала внедрять сложную GRC-платформу.

Зафиксировать обязательные поля группового risk record:

Согласовать категории сценариев, последствий, критичных сервисов и зависимостей.

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

Взять 20–30 наиболее значимых рисков из нескольких разных дочерних компаний и проверить:

Начать не со всей инфраструктуры, а с критичных групповых сервисов:

Установить критерии эскалации:

Доклад должен отвечать не на вопрос «сколько у нас красных рисков», а на вопросы:

Я против механического сложения и усреднения risk scores.

Средний уровень риска может быть полезен как вспомогательная метрика качества портфеля. Но он не должен становиться главным основанием для управленческого решения.

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

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

Зрелая модель киберрисков холдинга начинается не с единой цифры и не с общей heatmap.

Она начинается с общего языка сценариев, бизнес-последствий и решений.

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

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

Подписывайтесь на мой ТГ канал: @ib_decisions