Управление обновлениями (Patch Management)

В начале века, после нескольких ошибок, совершенных компанией Майкрософт в ходе первых попыток наладить систему обновлений ОС Windows, в умах миллионов ИТ-специалистов закрепился один очень опасный стереотип. Дело было примерно так: молодой и неотесанный Майкрософт выдал на гора несколько патчей, которые предварительно, чего уж греха таить, не очень усердно протестировал. В результате, сотни тысяч серверов и ПК по всему миру получили обновления, которые, при взаимодействии с существующими до их установки программами и настройками, привели операционные системы к полному краху. Из этого неприятного эпизода ИТ-специалисты сделали совершенно неправильный вывод. Вместо того, чтобы в дальнейшем тщательно тестировать обновления перед их установкой в продуктивной среде, они решили (где там наш easy button?..) отказаться от установки обновлений вообще. Этот глубокомысленное умозаключение ярко проиллюстрировано в старом анекдоте про Билла Гейтса, его сына и ежедневное путешествие солнца с востока на запад: "Пока все работает, ничего не трогай." Оно настолько широко присуще ИТ-специалистам старой закалки, что я даже не постесняюсь добавить его в категорию " ctrl+shift ".

Проблема заключается в том, что злоумышленнику, интернет-червю, вирусу и прочей нечисти именно это и нужно: по-больше уязвимостей в операционных системах и программном обеспечении. Я не удивился бы, если бы стало известно, что киберпреступники в какой-то мере поучаствовали в распространении и закреплении этого ущербного стереотипа. Уж слишком глубоко он засел в умах непосвященных айтишников.

К сожалению, самый распространенный путь ИТ-специалиста на светлую сторону лежит через возникновение инцидента. Ярким примером тому служит недавнее триумфальное шествие Conficker 'а. Казалось бы, установите вы везде обновления безопасности (хотите -- протестируйте их предварительно, хоть в лаборатории, а хоть и на фокусной группе компьютеров) и спите себе спокойно. Ан-нет, все же работало, чего его трогать, -- вот и дождались эпидемии. В общем, пока гром не грянет, мужик не перекрестится.

Вот и после последнего "вторника обновлений" ("Patch Tuesday") по рядам сисадминов пронесся недобрый шепот. Видите, мол, что ваш MS10-015 натворил, мы же вас предупреждали... Все же работало! Что случилось на самом деле, и почему многие компьютеры отвечали на установку обновления отчаянным Blue Screen of Death , пока точно не известно. Но по последним данным, Майкрософт не исключает , что такой результат стал следствием несовместимости обновления с якобы установленным в операционной системе руткитом (rootkit). Если это правда, представляете каким ударом для противников обновлений безопасности это может стать?

Итого, каковы позитивные выводы. Не обновляемая система намного более уязвима к атакам. То есть, обновляться нужно. Запятая. Если опасаетесь негативных последствий применения обновлений -- тестируйте их на тестовых ОС перед установкой в продуктивную среду. Точка.

Теперь о том, как организовать процесстестирования и установки обновлений. Для тестирования очень удобно использовать операционные системы, установленные на виртуальных машинах: благо, VMWare Server бесплатен и потрясающе прост в использовании. Также, стоит отметить, что не все обновления ОС являются обновлениями безопасности. В принципе, какие обновления к чему относятся можно посмотреть в коротком описании к каждому патчу, предлагаемом к установке при помощи Microsoft Update . С другой стороны, эти описания малоинформативны и не содержат никакой классификации ("Low", "Medium", "High"). Для установки обновлений в "ручном" режиме, Майкрософт предлагает утилиту Microsoft Baseline Security Analyzer , о которой я уже неоднократно писал в этом блоге . В отличие от Microsoft Update, MBSA ранжирует обновления безопасности в зависимости от критичности той уязвимости, которую это обновление исправляет.

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

• уязвимости "высокой" критичности должны быть исправлены в течение 5 дней,
• "средне"-критичные -- не позднее двух недель, с момента выхода обновления,
• а уязвимости "низкой" критичности могут подождать месяц.