Обновлять или не обновлять?

С тех пор, как я начал работать там, где я сейчас работаю, я бесконечно боролся с моим боссом и коллегами за обновление систем.

Я, конечно, полностью согласен с тем, что любое обновление (будь то прошивка, ОС или приложение) не следует применять небрежно, как только оно выйдет, но я также твердо верю, что должна быть хотя бы какая-то причина, если поставщик выпустил его; и наиболее распространенная причина - это исправление некоторой ошибки ... которую, возможно, вы не испытываете сейчас, но вы можете столкнуться с ней вскоре, если не поспеваете за ней.

Это особенно верно для исправлений безопасности; Например, если бы кто-нибудь просто применил патч, который уже был доступен в течение нескольких месяцев , печально известный SQL Slammerчервь был бы безопасен.

Я за тестирование и оценку обновлений перед их развертыванием; но я категорически не согласен с подходом к управлению системами «если он не сломан, то не трогай его», и мне действительно больно , когда я нахожу производственные системы Windows 2003 SP1 или ESX 3.5 Update 2, и единственный ответ, который я могу получить, это «это работает, мы не хотим его сломать».

Что Вы думаете об этом?
Какова ваша политика?
А какова политика вашей компании , если она не соответствует вашей?

А как насчет обновлений прошивки (BIOS, хранилище и т. Д.)?
А как насчет основных обновлений ОС (пакетов обновления)?
Как насчет небольших обновлений ОС?
А как насчет обновлений приложений?

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

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

Против долгосрочного менталитета «не сломал, не обновляй», вы должны дать понять, что:

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

Надеюсь, что это даст вам некоторые рычаги и удачу в том, чтобы убедить вышесказанное воспринимать вещи всерьез Как всегда, установите бумажный след, который доказывает, что вы оценили управление рисками, которые они принимают.

Это бесконечные дебаты, и разумные люди не согласятся. Если вы говорите о пользовательских ПК, я согласен, что они должны быть обновлены. Если вы говорите о серверах, рассмотрите отдельную политику для серверов, выходящих в Интернет, и серверов, которые не подключены. Я не знаю о ваших серверах, но в моей среде, возможно, 10% наших серверов имеют порты, открытые для интернета. Эти интернет-серверы имеют наивысший приоритет, когда речь идет о исправлениях безопасности. Серверы, не подключенные к Интернету, имеют более низкий приоритет.

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

Если вы полагаетесь только на Windows Update для исправлений (вы не упомянули, какую ОС вы используете, но я, в основном, парень из Windows, так что это моя справка), взгляните на актуальные исправления, которые выпускаются каждый месяц. , У меня есть несколько серверов, на которых я запустил Центр обновления Windows, и мне скажут, что мне нужно более 50 исправлений, но если я прокрою эти исправления и изучу каждый из них, я обнаружу, что 90% элементов, являющихся исправлениями, не являются безопасными связанные, но исправляют ошибки, которые влияют на сервисы, которые я не запускаю в этом окне. В более крупных средах, где вы используете систему управления исправлениями, обычно проверяют все, что выходит, и беспокоятся только о том, что абсолютно необходимо, и это обычно составляет около 10% от того, что выпускает Microsoft.

Мой аргумент состоит в том, что эта дискуссия о том, «исправлять или не исправлять», предполагает, что вы должны быть одной или другой стороной, когда на самом деле это огромная серая зона.

Я могу говорить только о серверах, но у нас есть режим «Ежеквартальное обновление», по четырем заранее определенным и объявленным датам в год, мы собираем запросы на обновление, применяем их к нашей справочной среде, запускаем их в течение месяца, чтобы проверить стабильность и, если это хорошо, развернуть в течение следующих n дней / недель. Вдобавок к этому мы применяем политику срочных обновлений, где у нас есть возможность развернуть справочные, протестировать и развернуть срочные обновления в течение дня или двух, если серьезность такова - хотя это использовалось только 2/3 раза в последние 4 года или около того.

Этот двойной подход гарантирует, что наши серверы разумно, но не глупо, обновляются, что обновления производятся экспертами в данной области (например, микропрограммой, драйверами, ОС, персоналом приложений), а не поставщиками, но также позволяет быстро исправлять ошибки, если требуется. О, конечно же, нам повезло, что у нас было очень мало разных аппаратных моделей по всему бизнесу (<10 вариантов сервера), а также значительных и современных эталонных платформ для тестирования.

Я работал в разных фирмах, у которых были политики по всему континууму от «применять исправления как можно скорее», нам все равно, если они сломают что-то, что у нас работает - тогда мы поддержим их, «чтобы» ничего не применялось без двух недель тестирования ". Обе крайности (и точки между ними) хороши, если Компания понимает компромиссы .

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

Я считаю, что лучший курс в значительной степени попахивает в середине ваших двух крайностей. Например, почему вы так отчаянно хотите обновить ESX, если для этого нет очевидной причины, возможно, сломать работающие системы в процессе? Конечно, он может быть уязвимым, если он общедоступный, но не должно быть способа прямого доступа к нему извне вашей сети, так в чем же риск? Есть ли какие-либо ошибки или нехватка функций, которые на самом деле представляют вам причину для обновления?

Обновление ради этого, и это действительно то, что вы предлагаете («но вы могли бы скоро испытать»), даже если вы утверждаете, что это не так, - абсурдный и опасный путь для путешествий. Если вы не можете представить реальную причину, в отличие от какой-то теоретически возможной причины, вы никогда не будете убеждать других, если они против обновления.

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

редактировать

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

Обновления безопасности отправляются на промежуточный сервер, а затем производятся после того, как они показали, что они не взрываются. Если нет реального бип ИНГ чрезвычайной ситуации (что я ударил несколько раз :(), в этом случае PRODUCTION сейчас. Другие обновления только по мере необходимости, после того, как проводить время в постановке.

Я думаю, что первое, что нужно сделать, - это «классифицировать» обновления по серьезности и составить расписание исправлений на основе классификации. Нет сомнений, что исправления безопасности нулевого дня должны быть применены сразу же; тогда как Service Pack может подождать после тщательной оценки.