Почему «патчинг» по SLA должен быть минимумом, а не стратегией безопасности

Я занимал должность CISO в двух разных компаниях, лично знаком с несколькими CISO и общаюсь со многими другими на различных форумах по кибербезопасности. У нас у всех есть нечто общее. Мы можем с ходу назвать наши показатели SLA по установке исправлений. Девяносто пять процентов критических уязвимостей закрываются за 14 дней. Восемьдесят с лишним процентов — по высоким. Слайд для совета директоров зеленый. Аудиторы удовлетворены. Опросники клиентов приходят чистыми.

Затем я задаю другой вопрос: что еще предстоит сделать? И тон меняется с уверенного «Мы все контролируем» на «Нууу… у нас есть технический долг устаревших систем, который нас сдерживает».

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

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

Ловушка соответствия требованиям

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

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

Что не закрывается: модуль устаревшей ERP, который нельзя пропатчить, не нарушив три последующие интеграции. Встраиваемая система на складе, работающая под управлением операционной системы, поставщик которой прекратил свое существование в 2019 году. Сервер Windows 2000 под столом системного администратора, который работает в компании с 1995 года. Неправильная конфигурация в основном поставщике удостоверений, изменение которой заблокирует бизнес-подразделение на день, пока кто-то перестраивает свой поток SSO. Архитектурный недостаток в уровне аутентификации, который технически является CVSS 7, но практически представляет собой экзистенциальную угрозу, поскольку находится перед главными активами.

Они не двигаются. Их переводят на Остров Неподходящих Рисков — очереди исключений, трекеры принятых рисков или бэклог той команды, которая владеет системой или функцией с 2017 года. И отчет SLA остается зеленым, потому что знаменатель заполнен легкими вещами, а бизнес «принял риск».

Я был тем человеком, которому приходилось объяснять совету директоров, что наше соответствие SLA составляет девяносто четыре процента, а наша самая большая единая точка отказа находится в этих шести процентах. Это не приятный разговор. Однако он правильный. И причина, по которой он почти никогда не происходит, заключается в том, что весь аппарат отчетности устроен так, чтобы сделать это невидимым.

SLA измеряют дисциплину, а не риск

Вот ментальная модель, которую я продвигаю среди своих коллег. Думайте об SLA по установке исправлений так же, как вы думаете об учебных пожарных тревогах. Пожарные тревоги необходимы. Они доказывают, что с предсказуемой периодичностью ваша организация может выполнить известную процедуру. Никто, отвечающий за здание, полное людей, не станет утверждать, что успешная пожарная тревога означает, что здание безопасно. Они скажут, что здание безопасно, когда спринклеры, конструктивное исполнение, выходы и материалы выдержат сценарий, который вы не прописывали.

SLA по установке исправлений — это пожарные тревоги. Они доказывают, что ваша программа может выполнять известную процедуру с предсказуемой периодичностью. Они не говорят вам, защищены ли вы от сценария, который вы не прописывали — цепочки эксплойтов, неправильно настроенной границы доверия, контроля, который выглядит присутствующим в GRC-инструменте, но молчаливо не работает в течение восьми месяцев, или моего любимого: «этот контроль работает везде, кроме бизнес-подразделения XYZ».

Когда я спрашиваю CISO, сколько у них киберрисков, им трудно это сформулировать. Они говорят о поверхности атаки, количестве уязвимостей, оценке аудита. Редко я слышу, чтобы они сказали что-то вроде: «У нас киберриск в размере 252 миллионов долларов». Что, если бы мы, как CISO, могли сформулировать, сколько у нас риска в долларовом выражении, и наконец смогли бы обосновать необходимость устранения этих сложных уязвимостей, неправильных конфигураций и сбоев контроля, вместо того чтобы пытаться продавать страх, неуверенность и сомнения?

На этот вопрос есть ответ, и его уже много лет формализует FAIR Institute: квантификация киберрисков, или CRQ. Я здесь не для того, чтобы проповедовать методологию. Их существует несколько — некоторые более обоснованные, чем другие — и конкретный выбор имеет меньшее значение, чем дисциплина принуждения уязвимостей, неправильных конфигураций и пробелов в контроле к терминам потерь, а не к меткам серьезности. Когда я говорю финансовому директору, что на сервере существует неисправленная уязвимость CVSS 9.8, у него затуманивается взгляд. Когда я говорю ему, что у нас есть оценочная подверженность годовым потерям в двенадцать миллионов долларов, сконцентрированная в одном неустраненном архитектурном недостатке, у нас совершенно другой разговор — и, по моему опыту, совершенно другой бюджет на устранение.

Три сдвига, которые действительно меняют ситуацию

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

1. Относитесь к SLA как к нижнему пределу требуемого, а не к верхнему пределу отчетности. Продолжайте выполнять свои контрактные и нормативные обязательства по SLA — они существуют не просто так, и клиенты о них спрашивают. Но перестаньте представлять соответствие SLA в качестве основного показателя вашей программы управления уязвимостями. Это мера гигиены. Поместите ее на слайд о гигиене. Основным показателем должна быть тенденция вашего квантифицированного остаточного риска, разбитая по бизнес-сервисам, которым он угрожает.
2. Сделайте так, чтобы ваш процесс исключений приводил к лучшим решениям, а не просто к документированным. В большинстве программ, которые я просматривал, процесс принятия риска — это упражнение по архивированию, когда риски живут в реестре годами. Кто-то подписывает форму, заявка закрывается как «риск принят», и подверженность исчезает из отчета SLA до тех пор, пока исключение не истечет в GRC-инструменте в следующем году. Это не управление рисками. Это бумажная работа. Функциональный процесс исключений требует, чтобы владелец бизнеса видел квантифицированную потерю, которую он принимает, соглашался пересматривать ее с определенной периодичностью и — для самых больших угроз — брал на себя обязательство по плану устранения с выделенным финансированием. Исследование Verizon в рамках DBIR 2025 года показало, что среди уязвимостей периферийных устройств, упомянутых в отчете, среднее время установки исправления составляло 209 дней, в то время как медианное время эксплуатации злоумышленниками составляло пять дней — разрыв, который существует потому, что исправления находятся там, где изменения наиболее затруднены. Та же закономерность проявляется в Каталоге известных эксплуатируемых уязвимостей CISA, который в основном заполнен CVE, для которых исправления были доступны задолго до того, как их начали использовать в реальных условиях. Это не проблема установки исправлений. Это проблема гигиены исключений.
3. Финансируйте устранение так же, как вы финансируете другие капитальные и операционные проекты. Сложные уязвимости — те, которые требуют реархитектуры сервиса, замены устаревшей платформы или перестройки потока идентификации — не будут решены за счет квартального операционного бюджета. Они требуют капитальных и операционных инвестиций и конкурируют с любыми другими бизнес-инвестициями. Квантифицированный риск позволяет вам конкурировать на равных условиях. «Нам нужно перестроить уровень аутентификации, потому что он старый и неподдерживаемый» проиграет в этой борьбе в восьми случаях из десяти. «Нам нужно перестроить уровень аутентификации, потому что он представляет собой киберриск в размере 10 миллионов долларов, а инвестиции в 1 миллион долларов на его устранение снизят наш киберриск на чистые 9 миллионов долларов» выигрывает достаточно часто, чтобы это имело значение.

Одно последнее замечание, поскольку я слышу этот вопрос каждый раз, когда говорю о CRQ скептически настроенной аудитории. Ваши оценки подверженности потерям будут неточными. Входные данные неопределенны, диапазоны широки, и любое честное упражнение по квантификации дает результаты, которые могут быть раскритикованы настойчивым оппонентом. И это нормально. Финансовый директор или актуарий могут спорить, что число составляет 8 миллионов долларов, а не 10 миллионов долларов — это все равно нормально. По крайней мере, у вас есть число, на которое люди могут ориентироваться, в отличие от старой системы оценки установки исправлений, которая говорила, что все идет как по маслу.

Зеленый дашборд SLA говорит руководителю, что его команда безопасности дисциплинирована. Картина квантифицированного риска говорит ему, где находится его реальная подверженность и сколько будет стоить ее снижение. Один из этих разговоров приводит к устранению сложных проблем. Другой — к их документированию и забвению.

SLA — это пол. Если это все, на чем вы стоите, вы ближе к земле, чем думаете.

Эта статья опубликована в рамках Сети экспертных авторов Foundry.
Хотите присоединиться?