Вы только что получили сообщение от своего поставщика о недавно обнаруженной уязвимости в системе безопасности. Также доступен патч. Применять сейчас или подождать? Вам, конечно, следует подождать. Давайте выясним, почему. В сообществе ИТ-безопасности, когда дело доходит до управления патчами, общая мантра звучит так: «Патч рано, патч часто». На первый взгляд, это выглядит как здравый смысл. В конце концов, в наши дни промежуток времени между обнаружением критической уязвимости и появлением эксплойта для нее сокращается и часто почти равен нулю. Итак, если у вас была возможность протестировать только что выпущенный патч, кажется логичным сразу же применить его в производственной среде.
Управление патчами/неправильное управление патчами: исправления могут сломать вещи
Вот где все идет не так. Потому что патчи часто что-то ломают. Я не могу сосчитать, как часто Microsoft выпускала патч для решения той или иной проблемы, а сам патч вызывал дополнительные проблемы. Это похоже на то, как если бы механик ремонтировал рулевое управление вашей машины, а в итоге у него возникли проблемы с тормозами. В качестве недавнего примера такой ситуации рассмотрим, что произошло с уязвимостью CVE-2020-17049 Kerberos KDC Security Feature Bypass. Эта уязвимость связана с обходом функции безопасности, существовавшей в способе, которым служба центра распространения ключей (KDC) для Active Directory определяет, можно ли использовать билет службы для делегирования через ограниченное делегирование Kerberos (KCD). Чтобы злоумышленник воспользовался этой уязвимостью, скомпрометированная служба, настроенная для использования KCD, может подделать билет службы, который недействителен для делегирования, чтобы заставить KDC принять его. В рекомендациях по безопасности, опубликованных Microsoft Security Resource Center (MSRC), эта уязвимость была устранена с помощью рекомендаций по изменению того, как KDC проверяет билеты службы с исправлением, используя следующее значение реестра:
HKLM\System\CurrentControlSet\Services\Kdc\PerformTicketSignature
Звучит довольно просто, не правда ли? Уязвимость обнаружена, уязвимость устранена.
Затем, однако, они обнаруживают, что их исправление может вызвать проблемы для определенных сред, таких как наличие служебных билетов Kerberos и билетов предоставления билетов (TGT), которые не могут быть продлены для клиентов Kerberos, отличных от Windows, а также некоторые другие неприятные проблемы, которые трудно устранить. Поэтому они выпускают еще один патч для этого и публикуют статью в службу поддержки по этому поводу. Так оно и есть. Возможно, было бы лучше подождать, пока Microsoft исправит патч (или исправит исправление или что-то еще), прежде чем применять/выполнять его в производственной среде.
Руководство по установке исправлений может измениться
Есть еще одна причина, почему обычно лучше подождать, чем исправлять или исправлять сразу после объявления об уязвимости. Это связано с тем, что рекомендации поставщика по патчу или исправлению могут измениться. Еще раз возьмем CVE-2020-17049 в качестве примера. 10 ноября прошлого года, когда Microsoft впервые выпустила свои рекомендации по безопасности для этой уязвимости, они включали следующие рекомендации:
FAQ
Есть ли какие-то дополнительные шаги, которые мне нужно предпринять во время развертывания этого обновления?
Да, для сложных доменных сред был предоставлен раздел реестра, позволяющий развертывать в разных доменах до полного включения исправления. В сложном лесу, где билеты Kerberos могут перемещаться по нескольким доменам, мы рекомендуем следующие шаги:
Установите для ключа реестра значение 0 (отключено).
Завершите развертывание на всех контроллерах домена (и контроллерах домена только для чтения) в вашем лесу.
По завершении развертывания установите для параметра реестра значение 1. Более поздняя версия удалит этот раздел реестра и сделает подписи билетов обязательными.
Затем в первоначальном руководстве MSRC подробно описаны шаги, которые необходимо выполнить с помощью значения реестра PerformTicketSignature.
Однако через два дня, если вы снова посмотрите на рекомендации, вы увидите, что приведенное выше руководство было изменено и теперь читается так:
FAQ
Есть ли какие-то дополнительные шаги, которые мне нужно предпринять во время развертывания этого обновления?
В простой среде с одним доменом никаких дополнительных действий не требуется.
В средах с несколькими доменами предоставлен раздел реестра, позволяющий развернуть исправление на всех контроллерах домена (DC) перед включением нового поведения. В таких сложных средах мы рекомендуем следующие шаги…
Что, если бы у вас был только один домен и вы сразу применили исправление? Имело бы это негативное влияние? Нужно ли как-то отменить ваши действия? От Microsoft нет ничего, что могло бы ответить на этот вопрос, но это поднимает вопрос о том, не лучше ли подождать надлежащего руководства, прежде чем внедрять патч или исправление.
Перенесемся в сегодняшний день. Теперь, если вы посмотрите рекомендации Microsoft по этому поводу, вы обнаружите нечто совершенно иное:
FAQ
Нужно ли мне предпринимать дальнейшие шаги для защиты от этой уязвимости?
Да. Клиентам, которые уже установили обновления безопасности от 10 ноября 2020 г., необходимо установить обновления от 8 декабря 2020 г. Обновления безопасности от 8 декабря 2020 г. включают исправления для всех известных проблем, первоначально представленных в выпуске CVE-2020-17049 от 10 ноября 2020 г. Это обновление также добавляет поддержку Windows Server 2008 SP2 и Windows Server 2008 R2.
Дополнительные сведения и дальнейшие действия по включению полной защиты на серверах контроллеров домена см. в разделе Управление развертыванием изменений Kerberos S4U для CVE-2020-17049.
Что делать, если вы не установили обновления от 8 декабря по какой-либо другой причине, например, из-за проблемы совместимости приложений? Или, возможно, вы даже не установили обновления от 10 ноября.
Что еще хуже, на мой взгляд, то, что в рекомендациях теперь используется «новая и улучшенная» структура и представление, которые почти все мои коллеги, работающие в области ИТ-администрирования в средах Windows Server, ненавидят. Главным образом потому, что из этих рекомендаций был удален раздел «Краткое содержание», что усложняет читателям его правильное усвоение.
Я предполагаю, что Microsoft удалила это резюме, потому что они сами изо всех сил пытаются понять, как правильно устранить некоторые уязвимости. Следовательно, они не хотят кратко излагать суть дела, если впоследствии обнаружат, что ошибаются. Другими словами, они исправляют вещи на ходу.
Итак, что касается управления исправлениями: исправлять или ждать?
Подождите.