Руслан Рахметов, Security Vision
Внедрение ITSM-практик в кибербезопасность позволяет применить жесткую, предсказуемую процессную логику к хаотичному потоку событий ИБ. Поэтому в данной статье мы расскажем про разницу классических подходов к управлению задачами в ИТ и ИБ, особенности интеграции и о том, как выстроить общую платформу для эффективного мониторинга и контроля.
Оглавление
б) Управление инцидентами, проблемами, изменениями и запросами на обслуживание
Отличия ISSM (Information Security Service Management) и ITSM (Information Technology Service Management)
Исторически ИТ-подразделения и команды информационной безопасности функционировали в условиях изоляции, преследуя различные, а зачастую и конфликтующие цели: если ИТ работал для максимальной доступности и непрерывности предоставления услуг бизнесу, то ИБ концентрировался на минимизации рисков, защите конфиденциальности и целостности данных, что нередко приводило к замедлению бизнес-процессов.
Глобальные стандарты и практики, такие как ISO/IEC 27001 и ITIL, говорят, что информационная безопасность не должна существовать в вакууме. Напротив, она должна быть неразрывно связана с ИТ-процессами организации. В последних итерациях методологии ITIL 4 концепция процессов была расширена до «практик», что подчеркивает необходимость целостного подхода, учитывающего организационную культуру, потоки создания ценности, партнеров и технологии. В этом контексте служба поддержки (Service Desk) перестает быть просто центром обработки заявок на ремонт оргтехники. Она трансформируется в единую точку контакта для всех ИТ- и бизнес-услуг, включая реагирование на инциденты безопасности, управление доступом и координацию устранения уязвимостей.
Для обеспечения бесшовного взаимодействия между ИТ-персоналом и аналитиками безопасности необходимо четко разграничивать зоны ответственности, опираясь на единую процессную модель. Несмотря на использование общей платформы Service Desk, природа операционных и безопасных инцидентов различается:
Управление инцидентами (Incident Management) направлено на максимально быстрое восстановление нормальной работы ИТ-услуги после непредвиденного сбоя или кибератаки, минимизируя ущерб для бизнес-операций. Это означает быструю изоляцию скомпрометированного узла, удаление вредоносного программного обеспечения и восстановление данных из резервных копий.
Технологическими элементами этой архитектуры являются системы Security Information and Event Management (SIEM), Security Orchestration, Automation, and Response (SOAR), которые работают в симбиозе с ITSM, образуя единый конвейер обработки угроз. Мы уже рассказывали про особенности этого процесса, жизненный цикл инцидента и фреймворки для специалистов, поэтому не будем повторяться.
Управление проблемами (Problem Management), напротив, фокусируется на проактивном или ретроспективном поиске корневых причин: если инцидент – это заражение рабочей станции вирусом-вымогателем, то проблема – это системное отсутствие сегментации сети и устаревшие базы сигнатур, позволяющие атаке повторяться.
В архитектуре интегрированного ISSM/SD подход риск-ориентированного управления (например, уязвимостями – Risk-Based Vulnerability Management, RBVM) реализуется путем программного слияния данных сканера VS с архитектурным контекстом из модели активов CMDB (о чем мы также писали недавно). Современные продукты также реализуют сложные механизмы идентификации и согласования (Identification and Reconciliation Engine, IRE).
Управление изменениями (Change Management) является критическим шлюзом, который гарантирует, что действия по реагированию на инциденты (например, экстренное обновление операционных систем или блокировка сетевых портов) не приведут к незапланированным простоям критичных бизнес-услуг.
Взаимодействие ИТ и ИБ достигает максимального уровня сложности и конфликтности на этапе внесения изменений в производственную среду: любое вмешательство, будь то изменение правил фильтрации трафика для блокировки угрозы или установка критического патча безопасности, потенциально несет риски деградации или полного прерывания бизнес-процессов. В этом контексте ITSM-практика Change Management выступает незаменимым балансиром, примиряющим потребность безопасности в скорости реакции с потребностью бизнеса в стабильности ИТ-услуг.
Управление запросами на обслуживание (Service Request Management) автоматизирует рутинные, предварительно одобренные операции ИБ, такие как выдача, изменение или отзыв прав доступа. Это снижает нагрузку на первую линию поддержки и минимизирует риск человеческой ошибки при предоставлении привилегий.
А теперь наша задача объединить эти процессы и управлять ими вместе. Интеграция систем мониторинга и реагирования (таких как SIEM, SOAR, EDR) с платформами управления ИТ-услугами (Service Desk) устраняет концептуальный и технологический разрыв. В такой архитектуре технологические предупреждения (алерты) от средств защиты информации преобразуются в бизнес-ориентированные задачи с четкими параметрами соглашений об уровне услуг (SLA), назначенными исполнителями из числа ИТ-администраторов и контролируемыми жизненными циклами.
SLA и OLA
Для корректного функционирования SecOps необходимо четко разделять внешние обязательства перед бизнесом и внутренние технические договоренности:
1) SLA (Service Level Agreement) – это высокоуровневое, формализованное соглашение между провайдером ИТ-услуг (включая безопасность) и заказчиком (представителями бизнеса), регламентирующее качество, доступность и конечные сроки предоставления сервисов и решения проблем. Например, бизнес-требование SLA может гласить, что в случае масштабной кибератаки высокой степени критичности доступность клиентских транзакционных сервисов должна быть восстановлена не позднее чем через 2 часа с момента обнаружения сбоя. Для бизнеса не имеет значения, кто именно устраняет проблему – важен конечный результат и соблюдение оговоренных сроков.
2) OLA (Operational Level Agreement) в отличие от SLA, это внутренние операционные договоренности между различными техническими командами внутри организации (например, между первой линией SOC, сетевыми инженерами и администраторами баз данных), которые в своей совокупности обеспечивают выполнение глобального SLA. OLA разбивает общую задачу на конкретные этапы с жесткими временными рамками для каждого подразделения. Отсутствие прозрачных OLA является главной причиной «зависания» инцидентов на стыке зон ответственности различных департаментов.
Представьте себе обещание циццерии на районе «Мы доставим вам горячую пиццу ровно за 45 минут, иначе заказ за наш счет». Это финальный результат, который важен для потребителя услуги, и определяется он SLA. А вот OLA опишет внутренние договоренности между отделами самой пиццерии, невидимые для вас. Чтобы уложиться в обещанные 45 минут (SLA), сотрудники договариваются между собой: раскатать тесто и испечь пиццу (повар) за 15 минут после получения чека, нарезать ее, добавить салфетки и упаковать в термосумку (упаковщик) за 5 минут, доехать от кухни (курьер) до вашей двери за 25 минут и т.д. И если кто-то нарушит OLA, а остальные участники сделают все идеально, то SLA все ещё может быть нарушен, и голодный заказчик получит пиццерию позднее, чем ожидает.
Различные метрики KPI
Управление процессами информационной безопасности через призму ITSM требует внедрения четкой, математически выверенной системы показателей и поддержки философии непрерывного совершенствования, заложенной в ITIL. Описанные выше соглашения об уровне услуг и внешние поддерживающие контракты (Underpinning Contracts, UC) задают измеримые параметры взаимодействия между SOC, ИТ-подразделениями, сторонними вендорами и конечным бизнесом:
- MTTD (Mean Time to Detect, Среднее время обнаружения) определяет время от фактического возникновения вредоносного события до его квалификации как инцидента ИБ в SIEM/SOAR. Характеризует качество правил корреляции и работы аналитиков мониторинга.
- MTTA (Mean Time to Acknowledge, Среднее время реакции/назначения) – от создания тикета в Service Desk до назначения ответственного ИТ-инженера или группы. Демонстрирует реактивность процесса диспетчеризации и качество работы интеграции.
- MTTR (Mean Time to Respond, Среднее время устранения) – среднее время полного устранения инцидента, очистки систем и восстановления штатного функционирования ИТ-услуги. Снижение MTTR является главным экономическим обоснованием интеграции SIEM/SOAR и ITSM.
Это основные метрики, по которым оценивается эффективность управления процессами, но есть и более специфические, например:
- Соблюдение SLA по устранению уязвимостей (процент выявленных уязвимостей, устраненных в заданные сроки в зависимости от их приоритизированной критичности), отражает реальную способность ИТ-отдела управлять техническим долгом.
- Процент решений на первой линии, который определяет долю инцидентов ИБ и запросов на обслуживание, решенных на первой линии поддержки (L1 SOC или L1 Service Desk) без необходимости функциональной эскалации на дорогостоящих экспертов.
- Время пребывания (обычно в днях), в течение которого злоумышленник незаметно оперирует внутри корпоративной сети до момента его обнаружения и изгнания. Интеграция ITSM и управление уязвимостями направлены на минимизацию площади атаки, что снижает вероятность успешного закрепления атакующего и сокращает метрику.
- Покрытие обнаружения, процент внедренных и протестированных детектов в соотношении с известными моделями поведения нарушителей (например, согласно матрице MITRE ATT&CK). Интеграция процессов управления проблемами с данными Threat Intelligence позволяет SecOps командам системно выявлять пробелы в Detection Coverage и инициировать архитектурные ИТ-изменения для закрытия слепых зон.
Сквозной мониторинг дает руководителям ИТ и ИБ инструмент для выявления «бутылочных горлышек» в межведомственном взаимодействии. Например, если метрика MTTA стабильно низкая, а MTTR выходит за пределы SLA, это может свидетельствовать о недостаточной квалификации ИТ-инженеров второй линии при работе с инструментами форензики, либо о некачественно составленных инструкциях (плейбуках), передаваемых из SOC в ИТ-отдел. В свою очередь, это служит триггером для пересмотра процессов обучения и оптимизации внутренних OLA.
Заключение
Переход от разрозненных процессов системного администрирования и изолированного мониторинга угроз к парадигме единой системы ITSM практик работает отлично вместе с интеграцией систем информационной безопасности (SOC, SIEM, SOAR, VM и др.), систем управления ИТ-услугами (Service Desk) и активами (ITAM, CMDB). Это создает прозрачную, измеримую и управляемую технологическую среду. В этой интегрированной экосистеме каждый компонент мультиплицирует эффективность другого:
1) CMDB обеспечивает жизненно важный бизнес-контекст, позволяя приоритизировать киберугрозы и уязвимости не по оторванным от реальности техническим метрикам, а по степени их реального влияния на критические бизнес-процессы и финансовые потоки компании.
2) SOAR-системы выступают высокоскоростными интеллектуальными драйверами, которые переводят язык сухих технических алертов и телеметрии в язык четких, регламентированных ИТ-задач, автоматически обогащая их необходимой для расследования информацией.
3) VM трансформируется из бесконечной генерации отчетов в строго управляемый цикл работ с четко прописанными и аудируемыми механизмами принятия риска на уровне высшего руководства.
4) SD предоставляет надежные механизмы контроля исполнения через систему SLA, обеспечивает корректную маршрутизацию, эскалацию и поддерживает непрерывную связь с конечными пользователями и владельцами бизнеса.
5) Процессы управления изменениями и проблемами гарантируют, что внедрение срочных защитных мер происходит максимально безопасно для непрерывности предоставления ИТ-услуг, а первопричины повторяющихся инцидентов выявляются и устраняются на архитектурном уровне.
Стратегические инвестиции в интеграцию ITSM-практик и технологических стеков ИБ – это, скорее, инвестиции в предсказуемость ИТ-операций, контролируемость инфраструктуры и, в конечном итоге, в фундаментальную устойчивость всей организации перед лицом стремительно эволюционирующих цифровых угроз.
