Команды кибербезопасности должны отвечать за надзор за рисками, а не за выполнение каждого корректирующего действия. Возложение на команды безопасности задач по поиску, приоритизации, назначению, внедрению, отслеживанию и проверке каждого исправления не способствует подотчетности. Вместо этого это приводит к созданию организационного хранилища нерешенных проблем.
Более эффективная модель четко разграничивает роли: безопасность выступает в роли надзирателя, а технологические и бизнес-подразделения выполняют исправления. Служба безопасности должна вести авторитетный реестр рисков, определять приоритеты, устанавливать стандарты исправления, эскалировать пропущенные обязательства и проверять закрытие. Владельцы затронутой инфраструктуры, облачной среды, приложения, платформы идентификации или бизнес-процесса несут ответственность за внедрение исправлений. Руководители отвечают за разрешение конфликтов ресурсов и явное принятие рисков, которые организация решает не устранять.
Это различие является существенным, поскольку оно определяет, снижает ли программа управления уязвимостями риск эффективно или просто генерирует тикеты на исправление.
Растущий бэклог свидетельствует о сбое в операционной модели
Команды безопасности часто становятся владельцами по умолчанию любой проблемы, помеченной как угроза безопасности. Например, когда сканер обнаруживает устаревший пакет, ожидается, что служба безопасности установит патч на сервер. Если платформа облачной безопасности обнаруживает открытое хранилище данных, на службу безопасности возлагается задача перепроектировать развертывание. Аналогично, когда аудит выявляет избыточные привилегии в бизнес-приложении, ожидается, что служба безопасности согласует изменения доступа с отделом, ответственным за рабочий процесс.
Такая динамика возникает потому, что обнаружение очень заметно, в то время как исправление часто является неудобным. Когда команда безопасности готовит отчет, организация может предположить, что эта же команда также отвечает за внедрение решений. Со временем владельцы инфраструктуры, инженерных и бизнес-систем начинают ожидать, что служба безопасности будет создавать тикеты, давать инструкции, назначать встречи, отслеживать сроки, запрашивать исключения и сообщать о задержках руководству. В результате фактический владелец системы становится участником процесса, который должен был быть его прямой обязанностью.
Возникающий бэклог часто приписывают команде безопасности, поскольку она ведет панель мониторинга. Однако панель мониторинга лишь выявляет более широкий организационный сбой: владение активом никогда не было назначено, работа по исправлению не была включена в операционные мощности, а руководство не установило четкие полномочия по принятию решений относительно того, когда надежность, поставка продукта, обязательства перед клиентами или технический долг должны быть понижены в приоритете в пользу снижения риска.
NIST’s Cybersecurity Framework 2.0 подчеркивает важность управления, приоритизации и коммуникации киберрисков во всей организации. Он не рекомендует, чтобы функция безопасности лично выполняла каждое исправление. Аналогично, руководство NIST по управлению корпоративными патчами характеризует установку патчей как профилактическое обслуживание и стандартные бизнес-затраты, а не как специализированную задачу, выполняемую исключительно командой безопасности.
Бэклог — это не просто набор технических слабостей; это запись нерешенных организационных решений. Каждый устаревший пункт отражает безответные вопросы, такие как: Кто владеет системой? Кто имеет право вносить изменения? Какие бизнес-последствия необходимо учитывать? Какие ресурсы доступны? Кто уполномочен принять оставшийся риск?
Безопасность отвечает за ведение реестра рисков, а владельцы систем — за выполнение исправлений
Самый эффективный способ сохранить подотчетность — определить обязанности до выявления новых находок.
Служба безопасности должна владеть авторитетным реестром известных рисков. Это включает проверку находок, удаление дубликатов и ложных срабатываний, привязку технических слабостей к затронутым активам и бизнес-сервисам, назначение приоритета на основе риска, определение минимальных доказательств исправления, эскалацию просроченных пунктов и независимую проверку закрытия. Служба безопасности также должна выявлять закономерности. Десять почти идентичных облачных неверных конфигураций — это не десять несвязанных тикетов; это свидетельство сломанного стандарта развертывания, отсутствующей автоматизации или слабого превентивного контроля.
Приоритизация должна выходить за рамки простой оценки серьезности. Агентство по кибербезопасности и безопасности инфраструктуры (CISA) рекомендует использовать свой каталог известных эксплуатируемых уязвимостей в качестве исходных данных для приоритизации управления уязвимостями, поскольку он выделяет уязвимости с доказательствами активной эксплуатации. Например, критическая уязвимость на изолированном тестовом активе может требовать менее срочных действий, чем уязвимость с более низким баллом, которая доступна из интернета, связана с привилегированным доступом или активно эксплуатируется. Команды безопасности находятся в наилучшем положении для проведения таких различий благодаря своему всестороннему пониманию контекста угроз и средств контроля.
Выполнение исправлений должно быть обязанностью команд, владеющих соответствующей технологией или процессом. Инфраструктурные команды отвечают за установку патчей и перенастройку серверов и конечных точек. Команды облачных платформ занимаются контролем идентификации, сети, хранения и журналирования. Команды приложений обновляют зависимости и перепроектируют уязвимый код, в то время как владельцы бизнес-систем утверждают изменения рабочих процессов и доступа. Эти команды обладают необходимым пониманием зависимостей, требований к тестированию, рисков простоев и операционных последствий, а также контролем над инженерными механизмами, необходимыми для долговечных решений.
Руководители принимают решения, которые не могут разрешить ни служба безопасности, ни владельцы систем. Когда обязательство по исправлению вступает в конфликт с запуском продукта, обязательствами перед клиентом, проблемами надежности или бюджетными ограничениями, проблема переходит в разряд управленческих решений. Руководство должно выбрать: предоставить ресурсы, изменить сроки, утвердить компенсирующий контроль или принять риск. Молчание не является принятием риска. Позволять находке устаревать, потому что у каждой команды есть более срочная работа, — это неуправляемый риск без ответственного решения. Эта модель также переопределяет показатели эффективности. Службу безопасности следует оценивать по охвату, скорости проверки, качеству приоритизации, своевременности эскалации и проверке закрытия. Владельцев исправлений следует оценивать по снижению риска, возрасту высокоприоритетных находок, частоте повторения и доле работы, устраненной с помощью автоматизации или постоянных изменений в проекте. Руководители должны отслеживать рост бэклога относительно доступных ресурсов, неразрешенные конфликты ресурсов, просроченные исключения и объем риска, принятого без финансируемого плана лечения.
Ни одна организационная функция не должна нести ответственность за задачи, находящиеся вне ее контроля.
Бэклоги устраняются за счет увеличения ресурсов, а не внедрения дополнительных соглашений об уровне обслуживания
Многие организации решают проблему растущего бэклога путем введения более строгих соглашений об уровне обслуживания (SLA), например, требуя устранения критических находок в течение 15 дней, а высокоприоритетных — в течение 30 дней. Хотя политика может измениться, а панели мониторинга отражают повышенную срочность, лежащая в основе мощность по исправлению часто остается неизменной.
SLA — это обязательство, а не источник рабочей силы. Недавняя статья CSO затронула эту тему: SLA на установку патчей должны быть базовым минимумом, а не стратегией, поскольку «зеленые» показатели соответствия могут скрывать небольшое количество сложных рисков, которые имеют наибольшее значение. Сроки полезны только тогда, когда ответственные команды обладают полномочиями, навыками, окнами обслуживания, средами тестирования и инженерным временем, необходимыми для их соблюдения.
Эта проблема особенно значима, когда организация наследует существенный технический долг. Тысячи устаревших уязвимостей, неподдерживаемых систем, облачных неверных конфигураций, слабостей идентификации и результатов аудита нельзя просто назначить инженерным командам, уже занятым текущими операциями и стратегическими инициативами. Такой подход не является жизнеспособным планом исправления. Перегруженные команды вряд ли создадут дополнительную мощность только на основе важности бэклога.
При определенном масштабе организациям следует выделять ресурсы на временную команду по исправлению, посвященную ликвидации исторического долга по рискам и установлению устойчивого операционного ритма. Эта команда должна быть ограничена по времени, финансироваться отдельно и состоять из персонала с опытом в области инфраструктуры, облачных технологий, приложений, автоматизации и управления программами, что позволит им напрямую вносить изменения, а не просто координировать усилия. Служба безопасности должна сохранять ответственность за приоритизацию и независимую проверку, а не выступать в роли основной рабочей силы по исправлению.
Временная команда по исправлению должна решать категории проблем, а не отдельные тикеты. В ее обязанности входит разработка автоматизированных базовых конфигураций для установки патчей, замена неподдерживаемых компонентов, исправление повторно используемых шаблонов инфраструктуры, удаление заброшенных активов, стандартизация сбора доказательств и выявление систем, требующих решений руководства, а не повторяющихся исключений. Руководство NIST 2026 года, которое связывает киберриски, управление корпоративными рисками и планирование персонала, подкрепляет принцип, согласно которому меры реагирования на риски и кадровые решения должны быть скоординированы.
Активация этой команды не должна основываться на произвольном количестве находок, а скорее на устойчивом дисбалансе между поступающими рисками и мощностями по исправлению. Индикаторы включают постоянно растущий бэклог, высокорисковые находки, превышающие обычные циклы изменений, повторяющиеся слабости или усилия по исправлению, которые потребовали бы нескольких кварталов существующих мощностей. Эти условия предоставляют руководству доказательства того, что стандартные операции недостаточны для восстановления программы.
Критерии выхода должны быть четко определены: ликвидировать исторический высокорисковый бэклог, сократить оставшуюся работу до управляемого уровня для стандартных команд, автоматизировать повторяющиеся исправления, назначить каждый актив ответственному владельцу и установить измеримый ритм, при котором новые высокоприоритетные риски устраняются быстрее, чем они возникают.
Бэклог кибербезопасности не указывает на неудачу команды безопасности. Скорее, он демонстрирует, что организация разделила полномочия по выявлению рисков и возможности и подотчетность, необходимые для их устранения.
Служба безопасности должна отвечать за мониторинг, проверку, приоритизацию, эскалацию и верификацию рисков. Владельцы систем должны выполнять исправления, а руководители — принимать стратегические решения. Если эти обязанности не будут четко определены и должным образом обеспечены ресурсами, бэклог будет сохраняться независимо от количества внедренных сканеров, тикетов, панелей мониторинга или соглашений об уровне обслуживания.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Joshua Copeland
