Одинаковый security baseline для всех подразделений — справедливость или ошибка

Корпоративному центру удобно иметь один стандарт безопасности.

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

На уровне governance такая модель выглядит логично. На уровне реального риска — далеко не всегда.

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

Поэтому одинаковый baseline часто создаёт одинаковый отчёт, но не одинаковую защищённость.

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

Единый baseline даёт корпоративному центру несколько очевидных преимуществ:

Ошибка начинается тогда, когда стандартизацию принимают за достаточную модель управления риском.

Одинаковое требование не обязательно приводит к одинаковому результату.

Например, обязательное резервное копирование может быть адекватной мерой для офисной системы. Для критичной цифровой услуги этого недостаточно: потребуется определить RTO и RPO, обеспечить изоляцию копий, проверить восстановление зависимостей, отработать переключение и подтвердить способность бизнеса работать в деградированном режиме.

Формально контроль один — резервное копирование. Фактический security outcome принципиально разный.

У единого baseline обычно возникают две противоположные проблемы.

Небольшая дочерняя компания может не иметь собственного SOC, IAM-команды, архитекторов безопасности и специалистов по реагированию.

Если потребовать от неё самостоятельно внедрить весь корпоративный стек, она, скорее всего:

В результате деньги будут потрачены, но риск снизится незначительно.

Зрелое решение здесь — не отменить базовую гигиену, а предоставить её через shared security services: централизованные IAM, EDR, управление уязвимостями, мониторинг, резервное копирование, incident response и security awareness.

Если критичная услуга выполнила корпоративный минимум, это ещё не означает, что её риск находится в допустимых пределах.

Системе, от которой зависит непрерывность основного бизнеса, могут потребоваться:

Корпоративный baseline в таком случае должен быть не финишем, а отправной точкой.

Во многих компаниях baseline описывает конкретные способы реализации:

Такой подход удобен для контроля, но плохо работает в неоднородной архитектуре.

Один и тот же security outcome можно получить разными способами. Централизованная инфраструктура, облачная платформа, промышленная сеть и SaaS-сервис требуют разных механизмов.

Поэтому универсальный минимум должен в первую очередь определять результат.

Не «установить конкретное средство многофакторной аутентификации», а «исключить возможность удалённого и привилегированного доступа только по паролю».

Не «передавать все события в определённый SIEM», а «обеспечить обнаружение и расследование значимых событий в установленное время».

Не «делать резервные копии ежедневно», а «подтвердить восстановление критичной услуги в пределах согласованных RTO и RPO».

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

Я не считаю одинаковые требования признаком зрелого governance.

Риск не распределяется поровну. Следовательно, одинаковый объём мер не создаёт ни одинаковой защищённости, ни одинакового остаточного риска.

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

Зрелая модель находится между этими крайностями:

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

Практически такую модель можно построить на трёх уровнях.

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

Например:

Здесь важно не перегрузить baseline сотнями пунктов. Enterprise Minimum должен описывать действительно недопустимые состояния, а не весь каталог возможных контролей.

Следующий уровень определяется классом риска.

Критерии должны быть прозрачными:

На этой основе можно сформировать несколько профилей: Tier-0 и критичные услуги, регулируемые данные, внешние цифровые продукты, стандартная корпоративная инфраструктура, малые подразделения, временные проекты.

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

Даже два объекта одного класса могут иметь разные архитектуры и угрозы.

Поэтому третий уровень должен учитывать:

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

Каждое существенное отклонение должно быть подтверждено:

NIST предлагает сравнивать Current и Target Profiles, чтобы выявлять и анализировать разрывы, а Community Profiles — использовать как основу для групп организаций с общими интересами или контекстом. CSF Tiers при этом помогают характеризовать строгость процессов управления и governance, но не заменяют саму оценку риска. (NIST)

Security exception часто воспринимают как проблему дисциплины подразделения.

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

Повторяющиеся исключения обычно означают одно из четырёх:

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

Полезно измерять:

Если исключение стало типовым, это уже не исключение. Это непризнанная часть архитектуры.

Процент выполнения baseline — слабый показатель, если он используется изолированно.

Подразделение может выполнить 95% требований и при этом сохранить один критический разрыв. Другое может выполнить 75%, но закрыть наиболее значимые сценарии риска.

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

Compliance coverage — какие обязательные outcomes подтверждены.

Control effectiveness — работают ли меры в реальных сценариях.

Target gap — насколько Current Profile отличается от целевого профиля конкретного сегмента.

Residual risk — какой риск остаётся и кто его принял.

Именно эта модель позволяет уйти от управления процентами к управлению решениями.

Для построения дифференцированного baseline я бы предложил семь шагов.

Единый security baseline нужен распределённой организации. Но его задача — создать общий фундамент, а не сделать вид, что все подразделения одинаковы.

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

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

Зрелая функция ИБ стандартизирует outcomes и evidence, но допускает разные способы реализации. Она усиливает требования там, где последствия действительно существенны, и предоставляет централизованные сервисы там, где локальные ресурсы ограничены.

Одинаковый checklist создаёт видимость порядка. Risk-informed Target Profile создаёт управляемое решение.

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