Что такое патч менеджмент
Patch Management. Тестирование ежемесячных обновлений ПО
Материал данной статьи основан на опыте установки более 5 000 обновлений для продуктов Microsoft и Adobe.
Компания Microsoft не раз сталкивалась с критикой в свой адрес по поводу недостаточного тестирования ежемесячных обновлений безопасности. В ответ на это представители корпорации дали понять, что в их планах переход на новую схему тестирования путем передачи услуги по тестированию обновлений «внешним» пользователям, то есть не сотрудникам Microsoft.
И, действительно, если взглянуть на данную проблему глазами компании-разработчика, то становится понятно, что тестирование обновлений на стороне разработчика довольно емкий по времени процесс. Каждое обновление должно быть протестировано в условиях максимально приближенных к тем, которые эксплуатируются на рабочих станциях и серверах потребителей продукта. Так, к примеру, компания Adobe тратит на тестирование обновлений (updates) до 6000 человеко-часов в месяц.
Но как показывает жизнь, тестирования компанией разработчиком никогда не будет достаточно для 100% пользователей в мире. Соответственно, риск того, что очередное обновление ПО остановит бизнес-процессы компании, остаётся. С другой стороны, не обновляться также нельзя, так как можно оказаться уязвимыми перед хакерами, которые могут нанести вред компании.
В качестве способа существенного снижения этих рисков крупные компании выбирают регулярную установку обновлений пакетами (релизами) с обязательным тестированием обновлений перед их развёртыванием в масштабе всей компании.
Методы управления обновлениями
Метод управления обновлениями является комбинацией подхода к тестированию обновлений и подхода к развёртыванию релизов с обновлениями. О них мы и расскажем далее.
Инструменты для управления обновлениями
Здесь следует особо отметить, что сервер WSUS предназначен только для обновлений, выпущенных компанией Microsoft.
Однако существует еще один сервер обновлений – System Center Updates Publisher (SCUP) от Microsoft, который позволяет управлять обновлениями стороннего ПО и затем импортировать его на сервер WSUS, с последующим развертыванием на клиентах с помощью SCCM.
Стадии процесса Patch Management
Процесс управления обновлениями состоит из нескольких стадий:
Как уже упоминалось ранее, тестирование происходит на основании тест-матрицы. Ниже мы представим описание базовых проверок, которые обычно включаются в такие матрицы.
Тестирование установки. Установка обновлений на тестовый клиент инициируется SCCM. Как правило, после установки обновлений система требует перезагрузки. Соответственно, первая проверка: перезагрузить систему, войти в систему после перезагрузки под тестовой учетной записью, убедиться в отсутствии сообщений об ошибках/предупреждений системы.
Следующий шаг – проверка системной переменной PATH. Убеждаемся в том, что PATH не содержит символов и знаков, которые могут привести к проблемам.
Третий шаг – проверка журнала системных событий (Event Viewer). Информация об установке обновлений пишется в журнал под ID 19. Проверка позволяет убедиться в успешности установки всех обновлений и отсутствии ошибок.
Далее на очереди проверка офисных приложений. Проверкой Office, как правило, пересекаются все тест-матрицы процесса Patch Management.
Одной из наиболее распространенных проверок так же является проверка приложений Adobe, которые подвергаются обновлению. Минимальная проверка для Adobe Flash Player заключается в проверке версии данного ПО на сайте. Если же обновление для Adobe Reader, то проверяется версия и производится проверка работоспособности приложения.
Проверка работоспособности браузера также в ходит в список базовых. Патчи не должны вносить изменения в настройки прокси и ActiveX, и это также проверяется при тестировании.
Кроме того стоит обратить внимание на общее влияние обновлений на систему. На этапе подготовки тестового клиента, который уже содержит ранее протестированные обновления, проводятся тесты, описанные выше, и результаты такого тестирования принимаются за эталон.
Любое отклонение системы от состояния, предшествующего вновь установленным патчам, анализируется и, в некоторых случаях, может быть принято решение об исключении патчей, ведущих к нежелательным изменениям в системе.
Стоит заметить, что для экономии полезного времени, некоторые проверки могут быть автоматизированы с помощью VBScript, например:
Управление обновлениями (Patch Management)
В начале века, после нескольких ошибок, совершенных компанией Майкрософт в ходе первых попыток наладить систему обновлений ОС Windows, в умах миллионов ИТ-специалистов закрепился один очень опасный стереотип. Дело было примерно так: молодой и неотесанный Майкрософт выдал на гора несколько патчей, которые предварительно, чего уж греха таить, не очень усердно протестировал. В результате, сотни тысяч серверов и ПК по всему миру получили обновления, которые, при взаимодействии с существующими до их установки программами и настройками, привели операционные системы к полному краху. Из этого неприятного эпизода ИТ-специалисты сделали совершенно неправильный вывод. Вместо того, чтобы в дальнейшем тщательно тестировать обновления перед их установкой в продуктивной среде, они решили (где там наш easy button. ) отказаться от установки обновлений вообще. Этот глубокомысленное умозаключение ярко проиллюстрировано в старом анекдоте про Билла Гейтса, его сына и ежедневное путешествие солнца с востока на запад: «Пока все работает, ничего не трогай.» Оно настолько широко присуще ИТ-специалистам старой закалки, что я даже не постесняюсь добавить его в категорию « ctrl+shift «.
Проблема заключается в том, что злоумышленнику, интернет-червю, вирусу и прочей нечисти именно это и нужно: по-больше уязвимостей в операционных системах и программном обеспечении. Я не удивился бы, если бы стало известно, что киберпреступники в какой-то мере поучаствовали в распространении и закреплении этого ущербного стереотипа. Уж слишком глубоко он засел в умах непосвященных айтишников.
Собственно, процесс можно организовать следующим образом. Майкрософт выпускает обновления периодически, во второй вторник каждого месяца. Исключения составляют экстренные обновления для очень серьезных критичных уязвимостей. Отталкиваясь от этого графика, компания может сформировать свое собственное расписание применения обновлений безопасности. Скажем,
Разумеется, все изложенное выше применимо к любому вендору, а не только к компании Майкрософт. И помните: правильно налаженный процесс применения обновлений безопасности значительно сокращает количество уязвимостей и переводит систему информационной безопасности компании на следующий уровень зрелости.
Patch’ти — не считается: сказ о патч-менеджменте в лицах и красках
Наверно, все SOC-аналитики спят и видят, как их детектирующие правила отлавливают модные техники проправительственных APT-группировок, а расследования приводят к обнаружению эксплойтов для zero-day уязвимостей. К сожалению (или к счастью), большая часть инцидентов, с которыми приходиться сталкиваться среднему специалисту по реагированию, намного менее романтичны: использование непереименованных PsExec’ов для распространения, классических методов обхода UAC для повышения привилегий и огромное количество уязвимостей, для которых давно выпущены заплатки. 
Вспоминая прошлые инциденты, невольно приходишь к выводу, что почти каждый из них можно было относительно легко предотвратить, если… Если все делать так как уже много раз описано в разных руководствах и лучших ИБ-практиках. Поэтому сегодня хочется не только рассказать об одном нашем недавним кейсе по реагированию на инцидент, но и напомнить о необходимости ставить патчи даже на «системах, разработанных под ключ».
До сих пор достаточно часто встречается заблуждение о том, что информационная безопасность должна быть функцией, но никак не процессом. Как правило, это выглядит следующим образом: «Сделайте нам безопасно, а мы потом сами будем все поддерживать». Особенности бизнеса в области ИБ таковы, что сервисная компания-интегратор, которая «делает безопасно», не станет спорить с заказчиком. Сделает и пойдет дальше — нести ИБ в массы. А заказчик после подписания актов сдачи работ и выплаты денег по контракту останется в наивной уверенности, что у него все отлично, ИБ построена на века. Сюрприз, как говорится, будет потом. Потому что информационная безопасность — это активный, постоянно меняющийся процесс, который нельзя зафиксировать раз и навсегда. И вот об этой «маленькой особенности» потребители зачастую забывают. ИБ, как и любой бизнес-процесс, состоит из множества элементов, без которых он не работает. Один из них — патч-менеджмент.
Как можно понять из названия, патч-менеджмент представляет собой процесс управления обновлениями программного обеспечения, предназначенного для устранения дыр в безопасности или поддержания адекватного уровня безопасности (характерно для серверного ПО или ОС), а также для решения проблем с прикладным ПО.
Из кейса
Территориально распределенная закрытая сеть на решениях Microsoft, состоящая из примерно 200 хостов. Два из них несут на борту по второй сетевой карте и имеют выход в Интернет. По всем параметрам инфраструктура должна попадать под требования №187-ФЗ «О безопасности критической информационной инфраструктуры». В силу специфики основного ПО обслуживанием инфраструктуры занимаются две сервисные компании. На момент подключения «пожарной команды» Solar JSOC инфраструктура не функционировала уже более 2 суток.
Из кейса
По информации, предоставленной сервисными компаниями: на протяжении последних 48 часов почти все хосты сети испытывают нагрузки CPU в районе 100% и вызывают BSOD. Многочисленные попытки использования сертифицированного антивирусного ПО результатов не принесли: фиксируются множественные повторные заражения ВПО Trojan.Equation. Более того, обнаружен откат антивирусных баз на декабрь 2017 года. Отсутствует доступ по RDP. И в качестве вишенки на торте: данные по количеству АРМ, полученные как от интеграторов, так и от пострадавшей стороны, расходятся. Последняя инвентаризация проводилась за несколько лет до инцидента уже уволившимся сисадмином. Какое-либо подобие планов обеспечения непрерывности отсутствует.
Однако добытая разрозненная информация позволяет сделать предварительные выводы о способе распространения вируса по сети и дать первые рекомендации по противодействию.
Одна из основных — отключить протоколы SMBv.1 и SMBv.2, чтобы остановить распространение ВПО по сети.
С момента поступления запроса о помощи до выдачи рекомендаций прошло около 3 часов.
Наиболее известные широким массам вирусные атаки — WannaCry и NotPetya. Оба вируса используют уязвимость протокола SMB в Windows-системах и были опубликованы группировкой ShadowBrokers в апреле 2017 года. При этом месяцем ранее компания Microsoft выпустила патч, закрывающий уязвимость EternalBlue, в своем бюллетене безопасности MS17-010. А «бахнуло» в мае–июне 2017 года. Последствия этих вирусных атак были бы не такими критичными, если б пострадавшие не проигнорировали критичное обновление и вовремя установили «заплатку». К сожалению, известны также случаи, когда критичные патчи вызывали сбои в работе стороннего программного обеспечения, но последствия не были настолько глобальными, как в случаях с массовыми вирусными атаками.
На волне хайпа вокруг майнинга криптовалют уязвимости в сетях компаний становятся по-особенному привлекательными: можно использовать чужие ресурсы для необходимых вычислений, доводя хосты до физического уничтожения.
Из кейса
«Пожарная команда» Solar JSOC выявила множественные попытки заражения обследуемой инфраструктуры вирусами-криптомайнерами, один из которых использовал для своего распространения уязвимость EternalBlue.
Анализ логов и сэмплов из карантина антивирусной защиты также показал наличие в пострадавшей инфраструктуре ВПО WannaMine, которое предназначено для майнинга криптовалюты Manero. Одной из особенностей обнаруженного вируса является механизм распространения, аналогичный ранее появившемуся WannaCry. Также в директориях SpeechsTracing обнаружены файлы, полностью идентичные архиву, который был опубликован ShadowBrokers за полтора года до этого.
При проведении работ по нейтрализации вирусной атаки в зараженной инфраструктуре были установлены множественные обновления, выпущенные Microsoft с 2016 года по сегодняшний день.
С момента подключения к работе специалистов JSOC до вывода инфраструктуры в «боевой» режим прошло порядка 50 часов. Причем бОльшая часть времени ушла на согласование действий между пострадавшей стороной, сервисными компаниями и нашей командой.
Практика показывает, что многих проблем можно было избежать, если не стараться доходить до всего своим умом. Не стоит уповать на то, что «у нас свой, особенный, путь». В цифровую эпоху эта парадигма не работает. Сейчас написано огромное количество рекомендаций и мануалов по предотвращению катастроф различного генезиса. Тем более, что при современных технологиях сделать это относительно несложно. Я еще с детства помню отличную фразу Службы 01: «Пожар легче предотвратить, чем потушить», которая как нельзя лучше отражает здравый подход к патч-менеджменту.
Как поставить обновления на поток
В первую очередь необходимо выстроить процесс управления обновлениями в инфраструктуре для оперативного закрытия старых и противодействия новым уязвимостям в ОС, компонентах прикладного и системного ПО, а именно:
• разработать и ввести в действие регламент управления обновлениями ОС, компонентов прикладного и системного ПО;
• провести работы по разворачиванию и настройке в серверном сегменте Windows Server Updates Services (WSUS) — сервиса обновлений операционных систем и продуктов Microsoft;
• осуществлять непрерывный контроль актуальности установленных в инфраструктуре пострадавшей стороны обновлений и оперативно устанавливать новые критические обновления безопасности.
Patch’ти — не считается: сказ о патч-менеджменте в лицах и красках
Наверно, все SOC-аналитики спят и видят, как их детектирующие правила отлавливают модные техники проправительственных APT-группировок, а расследования приводят к обнаружению эксплойтов для zero-day уязвимостей. К сожалению (или к счастью), большая часть инцидентов, с которыми приходиться сталкиваться среднему специалисту по реагированию, намного менее романтичны: использование непереименованных PsExec’ов для распространения, классических методов обхода UAC для повышения привилегий и огромное количество уязвимостей, для которых давно выпущены заплатки.
Вспоминая прошлые инциденты, невольно приходишь к выводу, что почти каждый из них можно было относительно легко предотвратить, если… Если все делать так как уже много раз описано в разных руководствах и лучших ИБ-практиках. Поэтому сегодня хочется не только рассказать об одном нашем недавним кейсе по реагированию на инцидент, но и напомнить о необходимости ставить патчи даже на «системах, разработанных под ключ».
До сих пор достаточно часто встречается заблуждение о том, что информационная безопасность должна быть функцией, но никак не процессом. Как правило, это выглядит следующим образом: «Сделайте нам безопасно, а мы потом сами будем все поддерживать». Особенности бизнеса в области ИБ таковы, что сервисная компания-интегратор, которая «делает безопасно», не станет спорить с заказчиком. Сделает и пойдет дальше — нести ИБ в массы. А заказчик после подписания актов сдачи работ и выплаты денег по контракту останется в наивной уверенности, что у него все отлично, ИБ построена на века. Сюрприз, как говорится, будет потом. Потому что информационная безопасность — это активный, постоянно меняющийся процесс, который нельзя зафиксировать раз и навсегда. И вот об этой «маленькой особенности» потребители зачастую забывают. ИБ, как и любой бизнес-процесс, состоит из множества элементов, без которых он не работает. Один из них — патч-менеджмент.
Как можно понять из названия, патч-менеджмент представляет собой процесс управления обновлениями программного обеспечения, предназначенного для устранения дыр в безопасности или поддержания адекватного уровня безопасности (характерно для серверного ПО или ОС), а также для решения проблем с прикладным ПО.
Территориально распределенная закрытая сеть на решениях Microsoft, состоящая из примерно 200 хостов. Два из них несут на борту по второй сетевой карте и имеют выход в Интернет. По всем параметрам инфраструктура должна попадать под требования №187-ФЗ «О безопасности критической информационной инфраструктуры». В силу специфики основного ПО обслуживанием инфраструктуры занимаются две сервисные компании. На момент подключения «пожарной команды» Solar JSOC инфраструктура не функционировала уже более 2 суток.
Из кейса
По информации, предоставленной сервисными компаниями: на протяжении последних 48 часов почти все хосты сети испытывают нагрузки CPU в районе 100% и вызывают BSOD. Многочисленные попытки использования сертифицированного антивирусного ПО результатов не принесли: фиксируются множественные повторные заражения ВПО Trojan.Equation. Более того, обнаружен откат антивирусных баз на декабрь 2017 года. Отсутствует доступ по RDP. И в качестве вишенки на торте: данные по количеству АРМ, полученные как от интеграторов, так и от пострадавшей стороны, расходятся. Последняя инвентаризация проводилась за несколько лет до инцидента уже уволившимся сисадмином. Какое-либо подобие планов обеспечения непрерывности отсутствует.
Однако добытая разрозненная информация позволяет сделать предварительные выводы о способе распространения вируса по сети и дать первые рекомендации по противодействию.
Одна из основных — отключить протоколы SMBv.1 и SMBv.2, чтобы остановить распространение ВПО по сети.
С момента поступления запроса о помощи до выдачи рекомендаций прошло около 3 часов.
Наиболее известные широким массам вирусные атаки — WannaCry и NotPetya. Оба вируса используют уязвимость протокола SMB в Windows-системах и были опубликованы группировкой ShadowBrokers в апреле 2017 года. При этом месяцем ранее компания Microsoft выпустила патч, закрывающий уязвимость EternalBlue, в своем бюллетене безопасности MS17-010. А «бахнуло» в мае–июне 2017 года. Последствия этих вирусных атак были бы не такими критичными, если б пострадавшие не проигнорировали критичное обновление и вовремя установили «заплатку». К сожалению, известны также случаи, когда критичные патчи вызывали сбои в работе стороннего программного обеспечения, но последствия не были настолько глобальными, как в случаях с массовыми вирусными атаками.
На волне хайпа вокруг майнинга криптовалют уязвимости в сетях компаний становятся по-особенному привлекательными: можно использовать чужие ресурсы для необходимых вычислений, доводя хосты до физического уничтожения.
«Пожарная команда» Solar JSOC выявила множественные попытки заражения обследуемой инфраструктуры вирусами-криптомайнерами, один из которых использовал для своего распространения уязвимость EternalBlue.
Анализ логов и сэмплов из карантина антивирусной защиты также показал наличие в пострадавшей инфраструктуре ВПО WannaMine, которое предназначено для майнинга криптовалюты Monero. Одной из особенностей обнаруженного вируса является механизм распространения, аналогичный ранее появившемуся WannaCry. Также в директориях SpeechsTracing обнаружены файлы, полностью идентичные архиву, который был опубликован ShadowBrokers за полтора года до этого.
При проведении работ по нейтрализации вирусной атаки в зараженной инфраструктуре были установлены множественные обновления, выпущенные Microsoft с 2016 года по сегодняшний день.
С момента подключения к работе специалистов JSOC до вывода инфраструктуры в «боевой» режим прошло порядка 50 часов. Причем бОльшая часть времени ушла на согласование действий между пострадавшей стороной, сервисными компаниями и нашей командой.
Практика показывает, что многих проблем можно было избежать, если не стараться доходить до всего своим умом. Не стоит уповать на то, что «у нас свой, особенный, путь». В цифровую эпоху эта парадигма не работает. Сейчас написано огромное количество рекомендаций и мануалов по предотвращению катастроф различного генезиса. Тем более, что при современных технологиях сделать это относительно несложно. Я еще с детства помню отличную фразу Службы 01: «Пожар легче предотвратить, чем потушить», которая как нельзя лучше отражает здравый подход к патч-менеджменту.
Как поставить обновления на поток
В первую очередь необходимо выстроить процесс управления обновлениями в инфраструктуре для оперативного закрытия старых и противодействия новым уязвимостям в ОС, компонентах прикладного и системного ПО, а именно:
Как удаленно и централизованно управлять патчами и обновлениями ПО в компании
Своевременное обновление установленного в компании программного обеспечения и установка требуемых патчей – это одна из важных задач, выполнение которой позволяет избежать различных сбоев в работе программ, а также обеспечивать должный уровень безопасности. Как можно централизованно и удаленно управлять обновлениями и патчами ПО в компании? Рассмотрим на примере облачного RMM-решения Panda Systems Management.
Задача: своевременное обновление ПО
Производители программного обеспечения регулярно выпускают обновления и патчи, которые, по большому счету, преследует две цели: с одной стороны, они позволяют исправить имеющиеся ошибки в программе, с другой стороны, закрывают обнаруженные уязвимости или дыры безопасности. Поэтому неудивительно, что своевременное обновление ПО является одной из приоритетных задач.
Соответственно, для решения этой задачи требуется своевременно знать о том, доступны ли обновления/патчи, а также оперативно контролировать, какие устройства уже были обновлены, а какие – еще нет. Очевидно, что при росте парка ИТ-устройств в компании (особенно при наличии удаленных офисов) требуются инструменты централизованного и удаленного управления и контроля.
Для автоматизированного решения данной задачи предлагаем Вам обратить внимание на RMM-решения, предназначенные для удаленного и централизованного мониторинга, обслуживания и поддержки корпоративных сетей.
Предлагаем рассмотреть решение задачи по управлению патчами на примере одного из таких решений — облачного сервиса Panda Systems Management.
В своих предыдущих статьях мы подробно рассказывали о том, как можно быстро внедрить данный сервис, как осуществлять мониторинг работы сети, управлять мобильными устройствами, удаленно и централизованно устанавливать ПО и осуществлять инвентаризацию всех ИТ-активов компании. Сегодня мы остановимся именно на управлении патчами.
Кстати, Вы можете бесплатно зарегистрировать лицензии Panda Systems Management на сайте и вместе с нами настроить управление патчами непосредственно в Вашей сети.
Итак, поехали.
Что такое управление патчами
В данном случае управление патчами – это набор инструментов для централизованного контроля, внедрения и установки патчей и обновлений ПО. Функции управления патчами в Panda Systems Management не только облегчают решение вопросов, связанных с регулярным обновлением ПО, но также позволяют выполнять аудиты, благодаря которым быстро и легко можно получить список устройств, которые не обновлены или имеют известные уязвимости.
Как мы уже говорили, благодаря управлению патчами можно избежать конфликтов в работе ПО, а также повысить уровень безопасности корпоративной сети.
Функции управления патчами в Panda Systems Management в настоящий момент поддерживают Windows-системы и используют Windows Update API, который присутствует на всех устройствах с Microsoft Windows, где установлен агент данного решения.
Какие патчи можно внедрять/применять?
Panda Systems Management позволяет Вам централизованно управлять всеми патчами и обновлениями, опубликованными корпорацией Microsoft в своем Windows Update. Microsoft публикует обновления для всех операционных систем Windows, поддерживаемых в настоящий момент, а также разрабатываемых корпорацией программных продуктов:
• Microsoft Office
• Microsoft Exchange
• SQL Server
• Windows Live
• Windows Defender
• Visual Studio
• Zune Software
• Virtual PC
• Virtual Server
• CAPICOM
• Microsoft Lync
• SilverLight
• Windows Media Player
• …и другие
Внедрение и установка патчей
Panda Systems Management предлагает три взаимодополняющих метода управления патчами. Каждый из них имеет различные функции для адаптации всех возможных потребностей и/или сценариев.
• Ручное управление патчами
• Политика Windows Updates
• Политика Patch Management
Управление патчами с помощью политик Windows Update и Patch Management являются взаимоисключающими. Рекомендуется отключать Windows Updates при использовании политик Patch Management для обновления операционных систем Windows, иначе это может привести к непредсказуемым последствиям.
Процедуры, описанные ниже, могут конфликтовать с другими процедурами, которые определены производителями стороннего ПО, например, как политики Windows Update, определенные в GPO. Поэтому рекомендуется отключать политики сторонних производителей, которые могут препятствовать политикам, определенным в Panda Systems Management.
Сравнительная таблица методов
Метод 1: Ручное управление патчами
Ручное управление патчами позволяет Вам отдельно выбрать патчи, которые требуется установить, в соответствии с критерием, применяемым администратором. Этот метод позволяет достичь максимальной гибкости, т.к. все время отображаются все патчи, установленные на каждом устройстве, а также патчи, ожидающие установки.
Этот метод может быть применим на любом уровне: Account, Site или Device. Таким образом, Вы можете выбрать патчи для определенного устройства (уровень Device), для определенной группы устройств или проекта (Site) или же для всех устройств, которые управляются Вами в рамках Вашего аккаунта в Panda Systems Management (Account).
Доступ к ручному управлению патчами
Вне зависимости от выбранного уровня, ручной метод доступен при открытии закладки Manage.
Выбор доступных действий осуществляется с помощью иконок, размещенных в панели действий.
Разрешить патч (Approve Patch)
Выберите патч и нажмите зеленую иконку. В результате этого патч будет ожидать установки. Разрешенные вручную патчи устанавливаются в тот момент времени, как настроено на закладке Manage на уровне Account.
Обратите внимание, что время для установки патчей, настроенных вручную, Вы можете настроить только на уровне всего аккаунта. Таким образом, все вручную управляемые патчи для всех устройств в рамках аккаунта будут устанавливаться в одно и то же время.
Скрыть патч (Hide patch)
Выберите патч и нажмите синюю иконку, чтобы скрыть патч из списка доступных патчей.
Быстрая установка патчей (Quick patch)
Выберите патч и нажмите зеленую иконку со стрелочкой, чтобы сразу же установить патч, не дожидаясь времени, настроенного для установки всех вручную разрешенных патчей (на уровне Account на закладке Manage).
Сбросить выбор патчей (Reset patch)
Нажмите белую иконку, чтобы сбросить выбор патчей.
Просмотр патчей
Все опубликованные патчи сгруппированы в три раскрывающихся списка в зависимости от их статуса по отношению к управляемому устройству.
• Missing Patches: Патчи, которые еще не были установлены на устройствах, принадлежащих данному уровню. На уровнях выше уровня Device также показывается количество устройств, на которых каждый конкретный патч еще не был установлен.
• Installed Patches: Патчи, которые уже были установлены на выбранном уровне. На уровнях выше уровня Device также показывается количество устройств, на которых каждый конкретный патч уже был установлен.
• Hidden Patches: Патчи, которые администратор решил скрыть в связи с тем, что их не требуется применять и по ним не требуется получать напоминания.
Чтобы упростить поиски, при раскрытии каждого списка доступна дополнительная информация по патчам, а также доступна дополнительная панель управления для фильтрации списка патчей.
Эта дополнительная панель управления позволяет Вам легко выбрать в списке те патчи, которые соответствуют следующим критериям:
• Severity: позволяет выбрать степень критичности патча, установленный корпорацией Microsoft: Critical (Критический), Important (Важный), Moderate (Умеренный), Low (Низкий) и Unspecified (Не определенный). Кстати, надо отметить, что Microsoft, как правило, устанавливает степень критичности только для патчей безопасности, а потому остальные патчи обычно имеют степень Unspecified.
• Reboot required: если устройство должно быть перезагружено после применения патча.
• User input required: если для применения патча требуется участие пользователя.
• Category: позволяет выбрать патчи, которые применяются к определенной программе.
Panda Systems Management по каждой записи предоставляет следующую информацию:
• Check: чекбокс для выбора патча.
• Action icon: отображается иконка, соответствующая статусу патча. У тех патчей, которые ожидают установку, данная иконка будет зеленым цветом, у скрытых пачтей – синяя и т.д.
• Title: полное название патча в соответствии с информацией от Windows Update.
• Severity: степень критичности патча по информации от Windows Update.
• Reboot: в том случае, если после установки патча требуется перезагрузка устройства, в данном столбце будет показываться галочка.
• User input: показатель того, требуется ли вмешательства пользователя для установки патча (диалоговые окошки для разрешения установки, EULA и пр).
Когда применяется данный метод
Можно использовать данный метод в том случае, если администратору требуется очень точный контроль над применением патчей на управляемых устройствах.
Метод 2: Политика Windows Update
Политика Windows Update разрешают централизованную конфигурацию функций Windows Update на устройствах Windows в корпоративной сети. Данная политика доступна на уровнях Account и Site.
Доступ к методу Политика Windows Update
Чтобы воспользоваться данным методом, необходимо создать политику Windows Update на уровне Account или Site. Для этого на соответствующем уровне на закладке Policies нажмите кнопку для добавления политики (на приведенном ниже рисунке представлен пример добавления новой политики на уровне Site, нажатием кнопки New Site Policy…).
После этого в выпадающем окне необходимо указать название политики и выбрать тип политики Windows Update.
В результате этого откроется окно, в котором Вы можете централизованно настроить поведение Windows Update на всех устройствах, к которым будет применена данная политика. Политики Windows Update настраиваются аналогичным образом, как и ресурсы Windows Update на каждом индивидуальном устройстве Windows.
Windows Update классифицирует патчи по трем категориям:
• Important (Важные)
• Recommended (Рекомендуемые)
• Optional (Не обязательные)
Только важные и рекомендуемые патчи могут быть установлены автоматически. Остальные патчи будут установлены вручную с устройства пользователя или через Panda Systems Management при использовании других методов управления патчами.
Все настройки данной политики являются транспозицией функций Windows Update на устройствах Windows. Таким образом, все указанные действия относятся к устройствам, а не к Агенту или Консоли управления.
Несмотря на то, что настройки политики одинаковы для всех устройств, поведение Windows Update на каждом устройстве может незначительно варьироваться в зависимости от версии операционной системы Windows.
Итак, окно с настройками политики:
Ниже приводим описание некоторых опций политики:
• Add target: позволяет Вам добавить фильтры или группы, которые ограничивают область применения политики
• Patch Policy: позволяет Вам указать основное поведение Windows Update на каждом устройстве в отношении к патчам, которые классифицированы корпорацией Microsoft как “Important” (Важные): автоматически скачивать и устанавливать, ручное скачивание и выбор пользователем, уведомлять без скачивания, отключить Windows Update. При этом, чтобы предотвратить пересечение политик в том случае, если Вы уже используете другой метод обновления патчей с помощью Panda Systems Management или сторонних продуктов, рекомендуется создать политику Windows Update со значением данного параметра “Disable Windows Update”
• Install new updates: укажите периодичность установки патчей
• Give me recommended updates the same way I receive important updates: применяет параметр политики, указанный в опции Patch Policy, как для важных патчей, так и для рекомендованных
• Allow all users to install updates on the computer: разрешает пользователям вручную устанавливать патчи
• Give me updates for Microsoft products and check for new optional Microsoft software when updating Windows: проверяет необязательные патчи, основные патчи для других продуктов Microsoft
• Show me detailed notifications when new Microsoft software is available: показывает пользователю подробные уведомления в том случае, когда доступно новое ПО Microsoft
• No auto-restart with logged on users for scheduled automatic updates installations: если выбрана эта опция, то после установки патчей пользователь уведомляется о том, что необходимо перезагрузить ПК. Если опция не включена, то в этом случае после установки патчей пользователь будет уведомлен о том, что его ПК будет перезагружен через 5 минут
• Re-prompt for restart with scheduled installations: предлагает указать, за какое количество минут Windows Update предложит пользователю перезагрузить ПК в том случае, если были установлены патчи, требующие перезагрузки устройства
• Delay restart for scheduled installations: определяет количество минут, в течение которых после установки патчей система будет ожидать перезагрузки. Если ничего не указано, то используемое по умолчанию время – 15 минут
• WSUS: разрешает использовать альтернативный локальный или удаленный сервер Windows Server Update Services для того чтобы минимизировать загрузку индивидуальных патчей на каждое устройство в сети
• Enable Client-Side Targeting: если используется WSUS-сервер с включенной опцией Client-Side Targeting, то группы и устройства, которые они содержат, будут вручную определены на WSUS-сервере. Этот параметр позволяет Вам указать группы, к которым принадлежат устройства, где будет применена данная политика (для разделения используйте запятую). При этом если некоторые или все устройства, на которых должна быть применена политика Windows Update, не совпадают с теми устройствами, что настроены в группах WSUS, то к таким устройствам политика применяться не будет.
Когда применяется данный метод
• Если администратору необходимо гарантировать, что все важные патчи автоматически устанавливаются на всех устройствах в сети, при этом пользователи не могут помешать этому
• Если администратору не требуется контролировать каждый установленный патч и он может делегировать решение об установке патча корпорации Microsoft в соответствии с их классификацией патчей в качестве важных или рекомендуемых
• Если не требуется автоматически устанавливать патчи, классифицированные как необязательные.
Метод 3. Политика Patch Management
Политики Patch Management разрешают автоматическую установку патчей аналогично тому, как это реализовано для политик Windows Update. Основное различие заключается в том, как сгруппированы патчи, которые необходимо устанавливать. В то время как ручной способ позволяет Вам выбрать применение каждого отдельно взятого патча, а политика Windows Update позволяет Вам применять патчи по уровню (важные, рекомендованные или необязательные), то политика Patch Management позволяет Вам выбрать патчи, которые необходимо применить, группируя их более гибким способом: по названию, описанию, размеру, типу и пр.
Данный метод поддерживается на уровнях Account и Site.
Доступ к методу Политика Patch Management
Чтобы воспользоваться данным методом, Вам необходимо на уровне Account или Site создать новую политику с типом Patch Management.
В результате этого появится окно, в котором Вы сможете централизованно настроить поведение политики управления патчами для всех устройств, к которым будет применена данная политика.
• Add target: позволяет Вам добавить фильтры или группы, которые ограничивают область применения политики
• Shedule Options: позволяет Вам указать время применения патчей. Нажмите Click to change в блоке Shedule для отображения формы, где Вы сможете выбрать интервал установки патчей и периодичность
В появившейся форме слева выберите периодичность, в зависимости от которой будет изменяться правая часть формы, позволяя Вам указывать точные дату и время, когда патчи должны быть установлены.
• Install criteria: позволяет Вам выбрать патчи для установки на устройство. Здесь предусмотрено три опции:
— Install all patches: устанавливает все выпускаемые патчи
— Filter patches by: позволяет Вам настроить фильтр с одним или несколькими критериями: категория, условие (в зависимости от выбранной категории) и объект поиска (также зависит от выбранной категории).
Вы можете создать сложные критерии выборки, настроив несколько категорий с логикой применения И/ИЛИ (соответствует положению переключателя AND/OR). Вы также можете настроить различные значения для каждой категории с помощью логических операторов AND/OR.
Когда применяется данный метод
• Если администратору необходима более высокая гибкость по сравнению с методом Политика Windows Update
• Если администратору необходимо автоматически и централизованно устанавливать все патчи без исключения.
Аудиты
На закладке Manage на уровне сайта или аккаунта Вы можете одним взглядом оценить статус всей сети в плане обновления приложений.
Критерии выбора позволяют показывать информацию по всем устройствам, только серверам или только рабочим станциям на сайте или в рамках всего аккаунта.
В зависимости от критериев выбора в круговой диаграмме ниже будет показываться соответствующая статистика. При этом синим цветом показывается количество устройств с неустановленными некритическими обновлениями, оранжевым цветом показывается количество устройств с неустановленными критическими обновлениями, а зеленым цветом показывается количество устройств, которые являются полностью обновленными.
Справа от круговой диаграммы показывается список 10 наиболее уязвимых устройств в зависимости от критериев выбора. Если Вы нажмете на интересующий Вас сегмент на круговой диаграмме, то данный список обновится, и он будет показывать информацию только по данному сегменту.
Если в данном списке нажать на название в столбце Hostname, то Вы перейдете в детальную информацию по данному устройству для того, чтобы посмотреть, какие конкретно патчи на данном устройстве не были установлены, и разрешить требуемые патчи.
Если в данном списке нажать на зеленую иконку со стрелкой в столбце Quick patch, то в этом случае на данном устройстве незамедлительно будут применены патчи в соответствии с выбранными критериями (критические или некритические) в зависимости от того, кликнули ли Вы на синем или оранжевом сегменте круговой диаграммы.
Заключение
Современные комплексные RMM-решения позволяют централизованно решать одну из важных задач любого ИТ-департамента: обеспечение своевременного обновления установленного в корпоративной сети ПО во избежание проблем в его работе и устранению известных брешей безопасности и уязвимостей. Не трудно понять, что эффективное решение поставленной задачи позволяет повысить эффективность работы сотрудников компании, а значит, и ее конкурентоспособность.
Кстати, во второй половине февраля станет доступна новая версия Panda Systems Management, в которой будут внесены определенные изменения в управление патчами, что позволит сделать этот процесс еще более управляемым, простым и эффективным.
Добивайтесь большего, делая меньше!