Новости

Слепые зоны ИТ: как ISO 27001 помогает закрыть пробелы в ITSM

Почему отлаженные процессы управления ИТ-сервисами не гарантируют киберустойчивость компании и как интеграция со стандартами ИБ превращает формальные требования в работающие процессные контроли.
ОГЛАВЛЕНИЕ

Введение: почему ваш CAB одобряет изменения вслепую

Комитет по управлению изменениями (CAB)* утверждает десятки изменений в месяц. SLA не нарушаются, инциденты фиксируются, отчёты строятся по всем канонам ITIL. Но спросите любого специалиста по ИБ: «Что произойдёт, если это изменение откроет новый вектор атаки, нарушит требования регулятора или передаст избыточные права вендору?» — и вы услышите молчание. Или, что ещё опаснее, вежливое: «Это не зона нашей ответственности в процессе».
* Комитет по управлению изменениями (Change Advisory Board, CAB) — группа специалистов, которая рассматривает и утверждает изменения в ИТ-среде, оценивая их влияние на стабильность и доступность сервисов.
Звучит как парадокс, но это норма для большинства компаний. ITSM-фреймворки (ITIL, COBIT, ISO/IEC 20000) блестяще выстроены вокруг ценности сервиса, скорости доставки и финансовой эффективности. Они учат управлять конфигурациями, реактивно и проактивно работать с инцидентами, оптимизировать бюджет. Но они изначально не про защиту, не про оценку угроз, не про конфиденциальность данных и не про устойчивость к кибератакам.

Здесь вступает в игру другая логика — стандартов по обеспечению ИБ (ISO/IEC 27001 и других). Если ITSM спрашивает «Как сделать сервис быстрее, дешевле и стабильнее?», то стандарты ИБ задают вопрос «Что сломается, если сервис упадёт, данные утекут или доступ окажется в чужих руках?». Без этого вопроса даже самый зрелый ITSM* остаётся слепым к половине операционных рисков.
* ITSM (IT Service Management) — подход к управлению ИТ-услугами и связанными процессами, направленный на обеспечение стабильности, доступности и качества сервисов.
Интеграция со стандартами ИБ не означает дублирование процессов или рост бюрократии. Это точечное встраивание риск-ориентированных контролей в существующие ITSM-циклы. В этой статье мы покажем, где именно ITSM «слепнет», как ISO 27001 закрывает эти пробелы без потери скорости, и на реальных обезличенных примерах разберём, почему компании, объединившие сервисную и security-логику, получают не просто «галочку для аудита», а измеримый рост устойчивости и ROI.
На бумаге процессы выглядят зрело: тикеты закрываются вовремя, CAB собирается по расписанию, CMDB (единый реестр ИТ-активов и связей между ними) синхронизирована с Discovery-инструментами. Но «зрелость процесса» не равно «защищенность бизнеса». В определенных зонах типовые ITSM-фреймворки оставляют критические пробелы, которые аудиторы ИБ и регуляторы фиксируют в первую очередь. Ниже наиболее яркие примеры.

Управление изменениями: CAB одобряет, но не оценивает угрозы

ITIL и ISO/IEC 20000 выстраивают Change Management вокруг стабильности сервиса: оценка влияния на доступность, план отката, окно обслуживания. Но в стандартных чек-листах по изменениям часто отсутствует обязательный блок по ИБ. Изменение проходит, потому что не «уронит» прод, а не потому, что не создаст вектор атаки.

Симптом: Патч, обновление инфраструктуры или интеграция с новым SaaS утверждаются за 4–6 часов. В документации есть план отката, но нет проверки на соответствие принципу наименьших привилегий, анализа сторонних зависимостей (SCA/SBOM) и пост-валидации конфигураций.

Регуляторный след: Прямое нарушение требований ISO/IEC 27001:2022 (A.8.32, A.8.33). Для компаний под 187-ФЗ (КИИ) или PCI DSS это автоматически означает несоответствие требованиям к управлению изменениями в защищённых контурах.

Управление поставщиками и доступами: онбординг работает, пересмотр — формален

ITSM позволяет автоматизировать выдачу доступов при приёме/переводе сотрудников и подключение подрядчиков. Но процесс быстро «застаивается»: права накапливаются, роль вендора размывается, а периодический пересмотр превращается в массовую рассылку типа «подтвердите, если ещё нужно».

Симптом: Учётные записи подрядчиков и сервисные аккаунты живут годами. Квартальные ревью доступов проходят по шаблону «руководитель согласовал», без автоматического сопоставления с текущими задачами, анализа аномальной активности или проверки соответствия договору (NDA).

Регуляторный след: Конфликт с ISO/IEC 27001 (A.5.37, A.8.2). При проверках по 152-ФЗ, GDPR или требованиям ЦБ РФ это классическая находка: «отсутствует механизм регулярного пересмотра и отзыва избыточных прав третьих лиц».

CMDB и управление конфигурациями: учёт есть, классификации по рискам нет

COBIT и ITIL позиционируют CMDB как источник истины для зависимостей сервисов. Но в большинстве зрелых ИТ-ландшафтов конфигурационные единицы классифицируются по IT-параметрам (тип, вендор, зона поддержки), а не по безопасности: какие данные обрабатывает сервис, какова его критичность для бизнеса, какова его поверхность атаки.

Симптом: В CMDB тысячи активов, но лишь небольшая часть имеет теги критичности с точки зрения ИБ. Обновление и мониторинг проводятся по расписанию вендора, а не по фактической уязвимости сервиса. При инциденте построение карты влияния занимает очень длительное время.

Регуляторный след: Не выполняется базовое требование ISO/IEC 27001 (A.8.1.2, A.8.9). Без привязки активов к данным и бизнес-процессам невозможно корректно провести Business Impact Analysis (BIA) и, как следствие, подтвердить адекватности мер защиты.

Эти пробелы не означают, что ITSM «плохой». Они означают, что процесс спроектирован без security-контекста. Далее покажем, как ISO 27001 встраивается в эти же циклы, не замедляя их, а делая управляемыми.

Закрытие пробелов: как ISO 27001 встраивается в ITSM

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

Интеграция ITSM и стандартов ИБ работает только тогда, когда превращается из набора разовых проверок в непрерывный управленческий процесс. Именно поэтому за основу берётся цикл PDCA (Plan-Do-Check-Act), являющийся фундаментом ISO 27001 и практики Continual Improvement в ITIL. Он позволяет системно связывать риски с операционной деятельностью, а не фиксировать их постфактум. Спроецируем PDCA на рабочие потоки через три процедурных уровня:

  • Слой 1 (Plan): Риск-контекст и классификация. Определяет, какие активы критичны и какие угрозы релевантны.
  • Слой 2 (Do): Процессные контроли. Встраивает ИБ-проверки в регламенты изменений, управления доступом и конфигурациями.
  • Слой 3 (Check & Act): Мониторинг и адаптация. Превращает данные аудитов и инцидентов в корректирующие решения.

Эта структура гарантирует, что ИБ-требования не остаются в регламентах, а постоянно обновляются на основе фактов. Вместо разрозненных блоков интеграция работает как единый регламентный поток. Каждый слой передаёт результаты следующему, замыкая PDCA-цикл на уровне документов, согласований и управленческих сессий. Ниже представлена визуальная схема цикла и его пошаговое операционное описание.

Рисунок 1 . Визуальная схема цикла интеграции

*BIA (Business Impact Analysis) — анализ влияния на бизнес.
**RA (Risk Assessment) — оценка рисков.
***Change Enablement — процесс управления и согласования изменений.
****Access Mgmt (Access Management) — управление доступом.

Слой 1: Риск-контекст задаёт правила для действий (Plan → Do)

Фундамент цикла — это утверждённая матрица классификации. Владельцы бизнес-процессов совместно с ИБ-специалистами проводят Business Impact Analysis (BIA) и Risk Assessment (RA), присваивая каждому активу в CMDB уровень конфиденциальности и критичности. Эти данные становятся обязательным входом для операционных процессов. Без них Change Enablement и Access Management работают вслепую, опираясь только на технические параметры и вендорные рекомендации по обновлениям.

Слой 2: Контроли выполняются в рамках регламентных процедур (Do)

На этом уровне контроли ISO 27001 превращаются в конкретные шаги:

  • Change Enablement (ITIL / BAI06): перед вынесением на CAB инициатор заполняет обязательный раздел «Оценка ИБ-последствий» по утверждённому чек-листу (ISO 27001 A.8.32). Оцениваются изменения прав, сторонние компоненты и влияние на защищённый контур. Для критичных изменений требуется отдельное согласование владельца риска — в рамках того же тикета, но как явная процедура.
  • Access Management (ITIL / DSS05): пересмотр прав проводится по расписанию. Владельцы ресурсов получают списки доступов подрядчиков и сервисных аккаунтов, подтверждают их необходимость или инициируют отзыв по процедуре. При отсутствии ответа в срок действует регламентная эскалация и временная приостановка прав (A.5.19).
  • Configuration Management (ITIL / APO13): атрибуты безопасности вносятся в реестр активов через процедуру классификации. Конфигурационные единицы CMDB обогащаются тегами безопасности, а не только техническими атрибутами. Это закрывает пробел A.8.9.
  • Incident Management (ITIL / DSS02): при регистрации инцидента выполняется сверка с матрицей критичности, чтобы определить, затронуты ли конфиденциальные данные. Инциденты приоритизируются не только по времени SLA, но и по потенциальному влиянию на ИБ. Процедура включает классификацию события как ИБ-инцидента, регламентную эскалацию и фиксацию уроков для обновления риск-модели (A.5.24–A.5.27).

Слой 3: Проверка, улучшение и замыкание цикла (Check → Act → Plan)

Выполненные процедуры генерируют документальные свидетельства: журналы согласований изменений, отчёты о пересмотре прав, карточки инцидентов с классификацией. Эти артефакты становятся основой для Слой 3.

  • Регламентные обзоры и аудиты: на регулярной основе ответственные сводят данные в единый отчёт. На совместной сессии CAB и CISO этот отчёт анализируется: какие чек-листы сработали, где были отклонения, какие риски реализовались.
  • Адаптация и обновление: выводы формализуются в виде рекомендаций, которые попадают в бэклог для последующей реализации улучшений. На основе фактических инцидентов и результатов проверок пересматривается реестр рисков, корректируются матрицы классификации и обновляются регламенты.

Как оценить эффективность интеграции ИБ и ITSM

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

  • % изменений с обязательной ИБ-оценкой до утверждения CAB (цель: 100% для mid/high-risk). Показатель закрывает пробел «слепых» изменений.

  • Среднее время отзыва/корректировки прав подрядчиков после окончания контракта (цель: <24 ч). Маркер зрелости Access Management и соответствия A.5.19.

  • % критичных КЕ с актуальной классификацией данных и привязкой к владельцу риска (цель: >95%). Базовая метрика для BIA, RA и отчётности перед регулятором.

  • Среднее время решения инцидентов ИБ (цель: снижение на 20–30% за 2 квартала). Показывает, насколько наличие критериев критичности в CMDB/SIEM ускоряет реакцию без нарушения процессных SLA.

Такая архитектура не ухудшает качество сервисов. Она убирает «сюрпризы» на поздних стадиях, когда стоимость исправления экспоненциально выше, а регуляторные последствия уже неизбежны.

Практические шаги по выстраиванию ИБ-контролей в ITSM

ITSM без фокуса на информационную безопасность — это отлаженный конвейер без системы предупреждения. Изменения идут, SLA соблюдаются, но каждое обновление может стать точкой входа для угрозы или причиной регуляторного штрафа. Интеграция ITSM со стандартами ИБ делает риски видимыми до того, как они перерастут в инциденты, и превращает compliance из формального требования в измеримый элемент устойчивости бизнеса.

Начать можно без остановки текущих операций. Достаточно двигаться поэтапно и избегать типичных ошибок:

  • Диагностика и пилот. Сопоставьте текущие процессы с требованиями стандартов, выберите 1–2 критичных сервиса и встройте ИБ-контроли в процессы ITSM. Избегайте попыток «закрыть всё сразу» - это гарантированно создаст трение между ИТ и ИБ.

  • Ответственность и контроль. Закрепите роли, запустите совместные KPI (% изменений с ИБ-оценкой, время отзыва прав, покрытие CMDB классификацией) и переведите аудиты из разовых проверок в регулярную активность.

  • Масштабирование и культура. Распространите модель на остальные сервисы. Помните: классификацию активов должны вести владельцы данных, а не ИТ-инженеры. Иначе CMDB останется техническим справочником, а не инструментом управления рисками.

Мы рекомендуем стартовать с целевого аудита зрелости процессов ITSM и ИБ. За 1-2 месяца наши эксперты помогут выявить реальные пробелы в процессах ИТ и ИБ, спроектировать архитектуру интеграции под ваш ландшафт и подготовить пошаговый план выстраивания процессов с понятными процедурами, KPI и ролевой моделью.

Нужна бесплатная консультация эксперта? Оставьте заявку >>>
2026-07-06 12:19 Экспертиза