Головоломка системного администратора по управлению исправлениями: устанавливать исправления сейчас или подождать?

Опубликовано: 31 Марта, 2023
Головоломка системного администратора по управлению исправлениями: устанавливать исправления сейчас или подождать?

Вы только что получили бюллетень от вашего поставщика о недавно обнаруженной уязвимости в системе безопасности. Также доступен патч. Применять сейчас или подождать? Вы должны подождать, конечно. Давайте выясним, почему. В сообществе ИТ-безопасности общая мантра, когда дело доходит до управления исправлениями, звучит так: «Исправляйте раньше, исправляйте часто». На первый взгляд, это выглядит как здравый смысл. Ведь временное окно в наши дни между обнаружением критической уязвимости и появлением эксплойта для нее сокращается, а зачастую почти до нуля или даже до нуля. Так что, пока у вас есть возможность протестировать недавно выпущенный патч, кажется логичным пойти дальше и быстро применить его в вашей производственной среде.

Управление исправлениями/неправильное управление исправлениями: исправления могут привести к поломке

Вот где что-то идет не так с управлением исправлениями. Потому что . Я не могу сосчитать, как часто Microsoft выпускала патч для решения какой-то проблемы, а сам патч вызывал дополнительные проблемы. Это как если бы механик чинил рулевое управление на вашей машине, и в итоге у вас возникли проблемы с тормозами из-за того, что механик сделал что-то. В качестве недавнего примера этого случая посмотрите, что произошло с уязвимостью обхода функции безопасности Kerberos KDC CVE-2020-17049. Эта уязвимость связана с обходом функции безопасности, которая существовала в способе, которым служба центра распространения ключей (KDC) для Active Directory определяет, можно ли использовать билет службы для делегирования через ограниченное делегирование Kerberos (KCD). Чтобы злоумышленник воспользовался этой уязвимостью, скомпрометированная служба, настроенная на использование KCD, может подделать билет службы, недопустимый для делегирования, чтобы заставить KDC принять его. В бюллетене по безопасности, опубликованном Microsoft Security Resource Center (MSRC), эта уязвимость была устранена с рекомендациями по изменению того, как KDC проверяет билеты службы, с помощью исправления, использующего следующее значение реестра:

Звучит довольно просто, не так ли? Уязвимость обнаружена, уязвимость устранена.

Затем, однако, они обнаруживают, что их исправление может вызвать проблемы в определенных средах, такие как отсутствие возможности продления билетов службы Kerberos и билетов на предоставление билетов (TGT) для клиентов Kerberos, отличных от Windows, а также некоторые другие неприятные трудности. - устранение неполадок. Итак, они выпускают еще один патч для этого и публикуют статью поддержки по этому поводу. Так оно и есть. Возможно, было бы лучше подождать, пока Microsoft исправит патч (или исправит исправление или что-то еще), прежде чем применять/выполнять его в производстве.

Руководство по установке исправлений может измениться

Есть еще одна причина, по которой, как правило, лучше подождать, чем исправлять или исправлять сразу же после объявления об уязвимости. Это связано с тем, что . Еще раз возьмем в качестве примера CVE-2020-17049. 10 ноября прошлого года, когда Microsoft впервые выпустила свои рекомендации по безопасности для этой уязвимости, они включили следующее руководство:

Затем в первоначальном руководстве от MSRC подробно описывались шаги, которые необходимо выполнить с использованием значения реестра PerformTicketSignature.

Однако через два дня, если вы снова взглянете на рекомендации, вы увидите, что приведенное выше руководство было изменено и теперь выглядит следующим образом:

Что, если бы у вас был только один домен и вы немедленно применили исправление? Могло ли это иметь какие-либо негативные последствия? Нужно ли как-то отменить ваши действия? Microsoft не дает ответа на этот вопрос, но возникает вопрос, не лучше ли дождаться надлежащего руководства, прежде чем внедрять патч или исправление.

Перенесемся в сегодняшний день. Теперь, если вы посмотрите рекомендации Microsoft по этому вопросу, вы найдете нечто совершенно другое:

Что делать, если вы не установили обновления от 8 декабря по какой-то другой причине, например, из-за проблемы совместимости приложений? Или, возможно, вы даже не установили обновления от 10 ноября. Что делать сейчас? Я думаю, прочитайте другую статью, связанную здесь. А там есть что переварить.

Что еще хуже, на мой взгляд, так это то, что рекомендации теперь используют «новую и улучшенную» структуру и представление, которые почти все мои коллеги, работающие в области ИТ-администрирования в средах Windows Server, говорят мне, что они ненавидят. Главным образом потому, что из этих советов был удален раздел «Резюме», из-за чего тем, кто читает его, будет труднее его правильно усвоить.

Я предполагаю, что Microsoft удалила это резюме, потому что они изо всех сил пытаются понять, как правильно устранить некоторые уязвимости. Следовательно, они не хотят предлагать краткое изложение вопроса на случай, если впоследствии обнаружат, что были неправы. Другими словами, они чинят вещи на лету. Или, возможно, пролетая мимо их штанов. Вы можете выбрать метафору, которая вам больше всего нравится, чтобы описать это.

Итак, когда дело доходит до управления исправлениями: исправлять или ждать?

Ждать. Ага.