Средняя стоимость утечки данных в 2023 году $4.45 млн (IBM Cost of a Data Breach Report, цифру приводит Kiteworks в обзоре governance-практик). Число впечатляющее, но бесполезное без контекста. Когда разбираешь post-mortem конкретного инцидента, выясняется: дорогим его сделала не уязвимость и не отсутствие EDR. Организационный хаос. Кто принимает решение об изоляции скомпрометированного сегмента? Кто уведомляет регулятора в установленный срок? На ком accountability за финансовые и репутационные последствия? В организациях без формализованного governance информационной безопасности ответ на каждый из этих вопросов - тишина и импровизация под давлением.
Ниже - практический разбор того, как выстроить модель управления ИБ, которая работает не в папке на файловом сервере, а в реальном кризисе.
Управление информационной безопасностью: governance - не тактическая защита
Организации регулярно путают governance с compliance, а compliance - с закупкой средств защиты. Это три разных уровня, и смешение убивает эффективность каждого.Governance информационной безопасности работает на стратегическом уровне: это система руководства, организационных структур и процессов, которые обеспечивают защиту информационных активов и привязывают её к бизнес-целям. Kiteworks формулирует разграничение прямо: тактическая кибербезопасность отвечает на вопрос "как?" - как настроить SIEM, как закрыть уязвимость, как реагировать на инцидент. Governance отвечает на вопросы кто?, что? и зачем?: кто принимает решение о допустимом уровне риска, что входит в scope ИБ-программы, зачем организация инвестирует в конкретные контроли.
Фреймворк NIST CSF 2.0 ввёл функцию GOVERN (GV) как фундаментальную - в предыдущей версии её не было. Субкатегория GV.OC-01 требует, чтобы миссия организации была понята и информировала управление киберрисками. На практике это значит одно: стратегия управления ИБ привязана к бизнес-целям, а не живёт в вакууме технического департамента.
Почему это не бумажное упражнение? Посмотрите на матрицу MITRE ATT&CK. Техники Valid Accounts (T1078, Initial Access / Persistence / Privilege Escalation), Account Manipulation (T1098, Persistence), Create Account (T1136, Persistence), Domain or Tenant Policy Modification (T1484, Defense Evasion / Privilege Escalation) - все они эксплуатируют слабости в управлении доступом и политиками. Если в организации нет формализованного процесса рецертификации привилегий, нет ответственного за мониторинг изменений в групповых политиках домена, нет регулярного пересмотра учётных записей - атакующий получает идеальные условия для закрепления. Техника Impair Defenses (T1562, Defense Evasion) напрямую эксплуатирует отсутствие governance над конфигурацией защитных средств: если никто не accountable за целостность настроек антивируса или SIEM, злоумышленник отключает телеметрию. И никто не замечает.
Governance не заменяет технические контроли. Governance определяет, кто их настраивает, кто проверяет корректность и кто отвечает за пробелы.
Оргструктура ИБ: три модели и критерий выбора
Выбор оргструктуры ИБ-функции в компании - управленческое решение, от которого зависит эффективность всей программы. IANS Research называет его "пороговым вопросом" (threshold question), который решается на уровне руководства, а не ИТ-отдела.
Перед проектированием структуры нужно зафиксировать scope ИБ-функции. IANS Research перечисляет более пятнадцати зон ответственности: разработка политик и стандартов, security architecture, training and awareness, risk management, IAM, SDLC, BC/DR, DLP, anti-malware, IDS/IPS, криптографическое управление ключами, SIEM, security infrastructure management, патчинг, метрики и reporting. Какие из этих зон лежат на ИБ-команде, какие на ИТ, какие на бизнесе - решается совместно руководством ИБ и топ-менеджментом. Этот scope напрямую определяет численность команды и операционную модель ИБ.
Модели организации ИБ-функции сводятся к трём вариантам:
Централизованная. Все ИБ-функции под единым CISO. Подходит для компаний с единой ИТ-инфраструктурой и централизованным управлением. Единые стандарты, консистентность контролей, понятная accountability. Минус: bottleneck при масштабировании - все решения проходят через одну точку, и при географическом распределении бизнеса реакция замедляется.
Распределённая. ИБ-ответственности делегированы бизнес-подразделениям или регионам. Для холдинговых структур и мультигеографических компаний. Быстрая реакция на локальные угрозы, учёт специфики подразделений. Минус серьёзный: дублирование усилий, несогласованность стандартов, потеря целостной картины рисков. Когда три подразделения используют три разных подхода к классификации инцидентов, агрегированный reporting становится невозможным.
Гибридная. Центральный CISO задаёт стратегию, политики и стандарты. Бизнес-подразделения имеют security-координаторов, которые адаптируют требования к локальному контексту. Доминирует в организациях от 500+ сотрудников, где нужен баланс управляемости и гибкости.
Выбор определяется не числом сотрудников, а тремя факторами: уровень регуляторного давления (чем выше - тем сильнее аргумент за централизацию), географическая и юридическая распределённость (несколько юрисдикций - потребность в гибридной модели), зрелость ИТ-процессов (незрелая ИТ-функция не потянет распределённую ИБ - нет базы для координации).
Подчинение CISO: линия reporting определяет всё
Вопрос "кому подчиняется CISO?" - не административная формальность. Это архитектурное решение, от которого зависит работоспособность всей CISO оргструктуры.CISO подчиняется CIO / ИТ-директору. Самая распространённая схема в российских компаниях. И самая проблемная. Структурный конфликт интересов: CIO отвечает за uptime, скорость развёртывания и ИТ-бюджет. CISO - за безопасность, которая замедляет деплой, требует дополнительного тестирования и ограничивает доступы. Когда CISO подчинён CIO, безопасность систематически проигрывает при приоритизации ресурсов. На практике это выглядит так: запрос на сегментацию сети откладывается на квартал, потому что "ИТ сейчас занят миграцией". Злого умысла нет - есть следствие оргструктуры.
CISO подчиняется CEO. Прямой доступ к стратегическим решениям. Риск: CEO перегружен операционкой, и ИБ-повестка вытесняется из расписания. Работает в компаниях, где CEO технически грамотен или где ИБ - ключевой бизнес-дифференциатор (финтех, healthtech).
CISO подчиняется совету директоров / комитету по рискам. Наиболее зрелая модель. Обеспечивает независимость ИБ-функции от ИТ и прямой канал эскалации. ISF Standard of Good Practice рекомендует именно комбинацию индивидуального лидера (CISO) и управляющего органа (governing body), как описывает InformIT.
Ключевое требование вне зависимости от модели: CISO должен иметь возможность эскалировать критические вопросы безопасности, минуя оперативное руководство ИТ. Без этого governance информационной безопасности превращается в процедуру без полномочий - документ, который не может предотвратить ни одного инцидента.
Роли и ответственности в ИБ: от CISO до бизнес-владельца
Governance начинает работать, когда каждый участник знает свою роль и полномочия. COBIT 5, как описывает ISACA Journal, определяет пять ключевых ролей в управлении информационной безопасностью:CISO (Chief Information Security Officer) - несёт overall responsibility за ИБ-программу. Связующее звено между руководством и операционной безопасностью. Зоны: создание и поддержание ISMS, определение плана обработки рисков ИБ, мониторинг и пересмотр ISMS. Как указывает ISACA, отсутствие в организации человека, accountable за информационную безопасность, увеличивает вероятность крупного инцидента.
ISM (Information Security Manager) - операционное управление: application security, infrastructure security, IAM, threat and incident management, awareness-программы, метрики, vendor-оценки. COBIT 5 разделяет CISO и ISM: CISO - C-level стратег, ISM - операционный руководитель. В организациях до 1000 сотрудников роли обычно совмещены. При масштабировании разделение становится критичным - один человек физически не может и защищать бюджет перед CFO, и разбирать алерты SIEM.
Владелец бизнес-процесса (Information custodian / Business owner) - связующее звено между бизнесом и ИБ. Определяет ценность информации, устанавливает требования к защите, утверждает роли доступа. Без активного вовлечения бизнес-владельцев governance ИБ оторван от реальности: ИБ-команда не может самостоятельно определить, какие данные критичны для бизнеса.
ИТ-менеджер - реализует технические решения по защите и отчитывается о статусе ИТ-инициатив в области ИБ.
Представители специализированных функций - внутренний аудит, HR, юридический отдел - на постоянной основе или по необходимости.
Здесь критически важен подход IANS Research: при определении ИБ-рисков начинайте не с технического анализа угроз, а с фиксации "worries" - опасений руководителей относительно конфиденциальности, целостности и доступности данных. Не требуйте от CEO формулировать риски в терминах CVE или MITRE ATT&CK - спрашивайте, что его беспокоит. Аналогия IANS: врач не ждёт от пациента диагноза, а спрашивает, где болит и насколько сильно. Затем ИБ-команда трансформирует "worries" в формализованные риски с трассировкой: каждый риск в реестре привязан к конкретному опасению конкретного руководителя. Когда обсуждаете риски с executive-уровнем, вы можете связать их с тем, что они сами говорили. Это принципиально меняет уровень вовлечённости и снимает барьер "мы не понимаем, зачем вам бюджет".
Комитет по информационной безопасности: состав и полномочия
Зрелая модель управления ИБ предполагает управляющий комитет. COBIT 5, как описывает InformIT, рекомендует для крупных организаций разделение на два комитета:ISS - Information Security Steering Committee. Обеспечивает последовательное применение ИБ-практик по всей организации. Принимает решения по ИБ в поддержку стратегических решений комитета по рискам.
Состав ISS по COBIT 5:
- CISO (председатель, связь с ERM-комитетом)
- ISM (отчёты о реализации и мониторинге практик)
- Владельцы бизнес-процессов (коммуникация бизнес-инициатив, влияющих на ИБ)
- ИТ-менеджер (статус ИТ-инициатив по ИБ)
- Представители аудита, HR, юридического отдела (постоянно или по запросу)
Состав ERM по COBIT 5:
- CISO (консультирует по информационным рискам)
- CEO, COO, CFO (представители высшего руководства)
- Владельцы бизнес-процессов
- Представитель аудита/compliance
- Юридический представитель
- CRO (стратегические, финансовые, операционные, репутационные риски)
RACI информационной безопасности: практическая матрица
Accountability за IAM - на бизнес-владельце, не на CISO. Контринтуитивно, но логично: именно владелец процесса определяет, кому нужен доступ и какого уровня. ИТ реализует технически (R), CISO устанавливает стандарты и контролирует, но accountability за то, что конкретный сотрудник имеет конкретные привилегии, - на бизнесе. Почему это критично: техники Account Discovery (T1087, Discovery) и Permission Groups Discovery (T1069, Discovery) эксплуатируют именно избыточные привилегии, которые бизнес-владелец не пересмотрел при очередной рецертификации. Если accountability за IAM лежит на ИТ - бизнес снимает с себя ответственность, и рецертификация превращается в формальное нажатие кнопки "подтвердить всё".
Совет директоров - Accountable за стратегию, не за операции. Совет не должен выбирать SIEM-платформу. Совет определяет риск-аппетит организации и утверждает стратегию ИБ, которую CISO готовит (R). Путаница в этих ролях - одна из главных причин разочарования: "мы одобрили бюджет, а утечки происходят". Accountability без Responsibility означает принятие стратегического направления, а не ответственность за каждый инцидент.
Аудит ИБ: независимость через совмещение A/R. Внутренний аудит - и Accountable, и Responsible за проведение аудита ИБ. CISO и ИТ-директор - только Consulted. Это обеспечивает объективность оценки и исключает ситуацию, когда ИБ-функция проверяет сама себя.
RACI-матрица для информационной безопасности пересматривается минимум ежегодно или при существенных изменениях: реструктуризация, слияние, смена CIO или CISO. При каждом инциденте RACI используется для мгновенной идентификации ответственных - если в момент кризиса приходится гадать, кто Accountable, матрица существует только на бумаге.
Reporting по информационной безопасности: метрики для принятия решений
Оргструктура ИБ и RACI работают только при замкнутой системе reporting. IANS Research включает метрики в обязательный scope ИБ-функции: разработка, управление и reporting метрик, релевантных ИБ-программе и руководству компании.
Reporting по информационной безопасности работает на трёх уровнях:
Операционный (еженедельно, ISM -> CISO). Технические метрики: открытые уязвимости по severity, статус патчинга критических систем, результаты сканирований, инциденты по категориям, нагрузка на SOC.
Управленческий (ежемесячно, CISO -> CEO / CIO). Бизнес-ориентированные метрики: прогресс по закрытию рисков из реестра, статус compliance-программы, бюджетное исполнение, значимые инциденты и принятые меры, ресурсные запросы.
Стратегический (ежеквартально, CISO -> совет директоров / комитет по рискам). Динамика risk posture организации, ключевые risk indicators в контексте бизнес-целей, ROI ИБ-инвестиций, бенчмарк относительно отрасли.
KRI и KPI: что измерять и как представлять
KPI показывает, насколько хорошо работает ИБ-функция. KRI показывает, насколько высок риск для бизнеса. Совет директоров интересуют KRI. Это принципиальное различие.KRI для совета директоров (не более 7 индикаторов):
- Mean Time to Detect (MTTD) - среднее время обнаружения инцидента
- Mean Time to Respond (MTTR) - среднее время реагирования
- Доля критических активов с просроченным патчингом (% от общего числа)
- Количество high/critical уязвимостей старше 30 дней
- Compliance gap по основному фреймворку (ISO 27001, NIST CSF, отраслевые требования)
- Количество ключевых поставщиков без проведённого risk assessment
- Инциденты с подтверждённым бизнес-импактом за квартал
- Процент сотрудников, прошедших awareness-тренинг в срок
- Соблюдение SLA по устранению уязвимостей (по каждому severity)
- Процент завершённых рецертификаций доступа
- Частота и результаты тестирования плана реагирования на инциденты
- Покрытие критических активов средствами мониторинга
Зрелость ИБ-программы: от реактивной к управляемой модели
Governance информационной безопасности не появляется одномоментно. Понимание текущего уровня зрелости - отправная точка для дорожной карты.Уровень 1: Ad hoc. ИБ-функции как отдельной структуры нет. Реагирование на инциденты - по ситуации. Нет формальных политик. Безопасность - побочная обязанность ИТ-отдела.
Уровень 2: Повторяемый. Назначен ответственный за ИБ (не обязательно CISO). Есть базовые политики. Реагирование на инциденты частично формализовано. RACI отсутствует или формальна. Reporting - по запросу руководства.
Уровень 3: Определённый. Формализованная оргструктура с CISO. Действует комитет по информационной безопасности. RACI-матрицы определены и утверждены. Политики покрывают основные домены. Reporting регулярный, но не всегда risk-centric.
Уровень 4: Управляемый. Решения принимаются на основе метрик (KRI/KPI). RACI используется при реальных инцидентах, а не только для аудитора. Reporting на всех трёх уровнях. Стратегия управления ИБ привязана к бизнес-целям. Проводятся table-top exercises.
Уровень 5: Оптимизирующий. Непрерывное совершенствование governance на основе уроков из инцидентов и результатов аудитов. ИБ-риски полностью интегрированы в enterprise risk management. CISO - полноценный участник стратегического планирования бизнеса.
Экспресс-диагностика - пять вопросов:
- Есть ли в организации человек с explicit accountability за ИБ, не совмещённой с руководством ИТ?
- Существует ли утверждённая RACI-матрица, и применялась ли она при последнем инциденте?
- Получает ли совет директоров регулярные (не реже раза в квартал) отчёты по ИБ-рискам?
- Привязана ли ИБ-стратегия к бизнес-целям с измеримыми KRI?
- Проводились ли за последний год учения (table-top) для проверки governance-процессов?
По опыту формирования ИБ-комитетов и RACI-матриц в компаниях от 500 до нескольких тысяч сотрудников - большинство организаций в российском корпоративном сегменте находятся между уровнями 2 и 3. CISO назначен, политики написаны, но RACI - формальность для аудитора, reporting - набор технических слайдов без бизнес-контекста, комитет по информационной безопасности собирается дважды в год для галочки. Разрыв между уровнями 3 и 4 - самый болезненный: он требует не новых документов, а изменения управленческой культуры. Руководство должно начать принимать решения на основе ИБ-метрик, а не интуиции.
Kiteworks отмечает: "Effective governance requires continuous evolution." Согласен - но эволюция начинается не с покупки GRC-платформы. Она начинается с ответа на один вопрос: кто в организации accountable за информационную безопасность, и имеет ли этот человек прямой доступ к совету директоров?
Сколько компаний могут честно ответить "да"? По опыту работы с организациями этого масштаба - меньше трети. И именно эта треть показывает меньший MTTR при инцидентах и меньше проблем с регуляторами. Не потому что у них лучший SIEM или больший бюджет - а потому что человек, принимающий решения о безопасности, сидит за столом, где принимаются решения о бизнесе.
Governance информационной безопасности - в конечном счёте - не про RACI-таблицы и дашборды. Это про то, считает ли бизнес безопасность своей ответственностью или проблемой ИТ-отдела. Пока CxO-уровень относится к ИБ как к ИТ-задаче, никакие фреймворки ситуацию не изменят. А когда бизнес принимает accountability - фреймворки становятся рабочим инструментом, а не декорацией для аудитора.
Последнее редактирование модератором:
