что такое патч менеджмент
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: «Пожар легче предотвратить, чем потушить», которая как нельзя лучше отражает здравый подход к патч-менеджменту.
Как поставить обновления на поток
В первую очередь необходимо выстроить процесс управления обновлениями в инфраструктуре для оперативного закрытия старых и противодействия новым уязвимостям в ОС, компонентах прикладного и системного ПО, а именно:
Управление обновлениями (Patch Management)
В начале века, после нескольких ошибок, совершенных компанией Майкрософт в ходе первых попыток наладить систему обновлений ОС Windows, в умах миллионов ИТ-специалистов закрепился один очень опасный стереотип. Дело было примерно так: молодой и неотесанный Майкрософт выдал на гора несколько патчей, которые предварительно, чего уж греха таить, не очень усердно протестировал. В результате, сотни тысяч серверов и ПК по всему миру получили обновления, которые, при взаимодействии с существующими до их установки программами и настройками, привели операционные системы к полному краху. Из этого неприятного эпизода ИТ-специалисты сделали совершенно неправильный вывод. Вместо того, чтобы в дальнейшем тщательно тестировать обновления перед их установкой в продуктивной среде, они решили (где там наш easy button. ) отказаться от установки обновлений вообще. Этот глубокомысленное умозаключение ярко проиллюстрировано в старом анекдоте про Билла Гейтса, его сына и ежедневное путешествие солнца с востока на запад: «Пока все работает, ничего не трогай.» Оно настолько широко присуще ИТ-специалистам старой закалки, что я даже не постесняюсь добавить его в категорию « ctrl+shift «.
Проблема заключается в том, что злоумышленнику, интернет-червю, вирусу и прочей нечисти именно это и нужно: по-больше уязвимостей в операционных системах и программном обеспечении. Я не удивился бы, если бы стало известно, что киберпреступники в какой-то мере поучаствовали в распространении и закреплении этого ущербного стереотипа. Уж слишком глубоко он засел в умах непосвященных айтишников.
Собственно, процесс можно организовать следующим образом. Майкрософт выпускает обновления периодически, во второй вторник каждого месяца. Исключения составляют экстренные обновления для очень серьезных критичных уязвимостей. Отталкиваясь от этого графика, компания может сформировать свое собственное расписание применения обновлений безопасности. Скажем,
Разумеется, все изложенное выше применимо к любому вендору, а не только к компании Майкрософт. И помните: правильно налаженный процесс применения обновлений безопасности значительно сокращает количество уязвимостей и переводит систему информационной безопасности компании на следующий уровень зрелости.
Что такое патч менеджмент
Администратор 
Группа: Главные администраторы
Сообщений: 14349
Регистрация: 12.10.2007
Из: Twilight Zone
Пользователь №: 1
Patch Management – это процесс управления обновлениями программного обеспечения (ПО), без которого вряд ли обходится хоть одна современная компания, думающая о безопасности своей ИТ-инфраструктуры.
Обновления или патчи — это дополнительное программное средство, которое применяется для исправления обнаруженных дефектов в программном обеспечении или изменения его функционала.
Существуют 2 типа обновлений:
Помимо прочего очевидна важность обновлений и их своевременной установки для поддержания надлежащего уровня информационной безопасности. Однако в истории были печально известные случаи, когда «заплатки» уязвимостей одного приложения вызывали критические неисправности в других приложениях. Вот несколько таких примеров:
Подобные неприятные последствия применения обновлений приводили к простоям бизнеса и потере денег, и этот риск никуда не делся. Однако неприятностей можно было бы избежать при помощи тщательного тестирования обновлений компанией-разработчиком перед их развёртыванием.
Компания Microsoft не раз сталкивалась с критикой в свой адрес по поводу недостаточного тестирования ежемесячных обновлений безопасности. В ответ на это представители корпорации дали понять, что в их планах переход на новую схему тестирования путем передачи услуги по тестированию обновлений «внешним» пользователям, то есть не сотрудникам Microsoft.
И, действительно, если взглянуть на данную проблему глазами компании-разработчика, то становится понятно, что тестирование обновлений на стороне разработчика довольно емкий по времени процесс. Каждое обновление должно быть протестировано в условиях максимально приближенных к тем, которые эксплуатируются на рабочих станциях и серверах потребителей продукта. Так, к примеру, компания Adobe тратит на тестирование обновлений (updates) до 6000 человеко-часов в месяц.
Но как показывает жизнь, тестирования компанией разработчиком никогда не будет достаточно для 100% пользователей в мире. Соответственно, риск того, что очередное обновление ПО остановит бизнес-процессы компании, остаётся. С другой стороны, не обновляться также нельзя, так как можно оказаться уязвимыми перед хакерами, которые могут нанести вред компании.
В качестве способа существенного снижения этих рисков крупные компании выбирают регулярную установку обновлений пакетами (релизами) с обязательным тестированием обновлений перед их развёртыванием в масштабе всей компании.
Методы управления обновлениями
Метод управления обновлениями является комбинацией подхода к тестированию обновлений и подхода к развёртыванию релизов с обновлениями. О них мы и расскажем далее.
Два самых распространенных подхода к тестированию обновлений — это:
Современные технологии позволяют без задействования лишних единиц техники проводить тестирование обновлений, используя виртуализацию. Наиболее часто используемые и доступные продукты для создания виртуальных машин и сетей: VMware либо Oracle VirtualBox. Преимущества виртуализации в том, что:
Как правило, технология виртуализации используется для небольших сетей с количеством рабочих станций не более 45-70.
Также процесс управления изменениями можно упростить, используя всего пару корпоративных компьютеров или, так называемых, тестовых клиентов. Установив необходимые обновления на такие клиенты и протестировав систему после установки, можно увидеть последствия изменений и убедиться в результате применения обновления, оказывая при этом минимальное влияние на ИТ-инфраструктуру. Тестирование с использованием полноценной тестовой среды применимо для больших промышленных сетей и гарантирует высокую чистоту тестирования. При тестировании в полноценной тестовой среде используются те же подходы к установке обновлений и инструменты для управления обновлениями, что и в промышленной среде. И сейчас мы перейдём к ним и заодно рассмотрим подходы к развёртыванию релизов с обновлениями.
Инструменты для управления обновлениями
Как правило, все широко используемые программные решения для удаленного управления ИТ-инфраструктурой предоставляют возможность управления обновлениями, например:
Лидером по востребованности и использованию в условиях крупных промышленных сетей является SCCM. Поэтому приведём подробности реализации управления обновлениями на его примере.
Принцип управления обновлениями с помощью Configuration Manager достаточно прост. Все управляемые системы SCCM объединяются в сайты. Сайты содержат в себе:
Каждый из серверов сайта должен иметь доступ к базе данных Microsoft SQL Server.
В качестве сервера обновлений используется Windows Server Update Services (WSUS).Он синхронизируется с сайтом Microsoft, скачивая обновления, которые могут быть распространены внутри корпоративной локальной сети. Это экономит внешний трафик компании и позволяет быстрее устанавливать исправления ошибок и уязвимостей в операционных системах Windows на рабочих местах, а также централизованно управлять обновлениями серверов и рабочих станций.
Здесь следует особо отметить, что сервер WSUS предназначен только для обновлений, выпущенных компанией Microsoft.
Однако существует еще один сервер обновлений – System Center Updates Publisher (SCUP) от Microsoft, который позволяет управлять обновлениями стороннего ПО и затем импортировать его на сервер WSUS, с последующим развертыванием на клиентах с помощью SCCM.
Стадии процесса Patch Management
Процесс управления обновлениями состоит из нескольких стадий:
После того как тестовая среда подготовлена к установке новых обновлений, начинается создание листов обновлений, или, как это называется в SCCM, патч-листов.
Патч-лист включает обновления, вышедшие в этом месяце и подходящие под определение «требуемые». Необходимость в обновлении для клиента определяет сам SCCM. Логика проста: если на клиенте установлено приложение Visio и в этом месяце вышло обновление для Visio, то подобный патч будет «требуемым» для данного клиента.
Что же касается обновлений для операционных систем и серверов, то здесь необходимость определяется в зависимости от их разрядности и пакета Windows Service Pack.
При добавлении пакета к коллекции SCCM получает информацию о том, что для клиентов данной коллекции назначено новое задание, синхронизируется с SCCM-клиентом на тестовой машине и начинается развертывание (deployment). Процедура занимает всего несколько минут, по истечении которых, в области уведомлений панели задач появляется соответствующий значок. После двойного нажатия на значок, открывается Configuration Manager, где после выбора обновлений, начинается установка. Как правило, установка заканчивается запросом на перезагрузку системы. После нее начинается тестирование с задачей: найти патч, ломающий систему/компоненты системы, либо убедиться в отсутствии такового.
На этапе PRE Deployment готовится список протестированнных обновлений, который отправляется с помощью SCCM на клиенты пилотных пользователей. Принцип тот же: пакет с обновлениями добавляется к коллекции, включающей в себя только пилотных клиентов, SCCM получает информацию о том, что для клиентов данной коллекции назначено новое задание и начинается развертывание.
Как правило, в качестве пилотных клиентов, выбираются те пользователи, которые
хорошо разбираются в ПО, за которое отвечают, и проверяют нормально ли работает приложение после установки обновлений. Количество пользователей, которые участвуют в пилоте, обычно варьируется в зависимости от числа рабочих станций сети.
Происходит на стадии PRO Deployment, с помощью SCCM, по тому же принципу, что и на тестовые и пилотные клиенты. В данном случае устанавливается время начала развертывания и дата завершения.
Как уже упоминалось ранее, тестирование происходит на основании тест-матрицы. Ниже мы представим описание базовых проверок, которые обычно включаются в такие матрицы.
Тестирование установки. Установка обновлений на тестовый клиент инициируется SCCM. Как правило, после установки обновлений система требует перезагрузки. Соответственно, первая проверка: перезагрузить систему, войти в систему после перезагрузки под тестовой учетной записью, убедиться в отсутствии сообщений об ошибках/предупреждений системы.
Следующий шаг – проверка системной переменной PATH. Убеждаемся в том, что PATH не содержит символов и знаков, которые могут привести к проблемам.
Третий шаг – проверка журнала системных событий (Event Viewer). Информация об установке обновлений пишется в журнал под ID 19. Проверка позволяет убедиться в успешности установки всех обновлений и отсутствии ошибок.
Далее на очереди проверка офисных приложений. Проверкой Office, как правило, пересекаются все тест-матрицы процесса Patch Management.
Простые примеры проверок Office:
Данный пример проверки Office является базовым и общим. Матрица может включать в себя и более сложные детальные проверки. Например, кроме открытия MS Word и сохранения документа нужно проверить, что во вкладке «Орфография и грамматика» проставлена галочка «Проверка Орфографии и Грамматики» и т.д.
Одной из наиболее распространенных проверок так же является проверка приложений Adobe, которые подвергаются обновлению. Минимальная проверка для Adobe Flash Player заключается в проверке версии данного ПО на сайте. Если же обновление для Adobe Reader, то проверяется версия и производится проверка работоспособности приложения.
Проверка работоспособности браузера также в ходит в список базовых. Патчи не должны вносить изменения в настройки прокси и ActiveX, и это также проверяется при тестировании.
Кроме того стоит обратить внимание на общее влияние обновлений на систему. На этапе подготовки тестового клиента, который уже содержит ранее протестированные обновления, проводятся тесты, описанные выше, и результаты такого тестирования принимаются за эталон.
Любое отклонение системы от состояния, предшествующего вновь установленным патчам, анализируется и, в некоторых случаях, может быть принято решение об исключении патчей, ведущих к нежелательным изменениям в системе.
Стоит заметить, что для экономии полезного времени, некоторые проверки могут быть автоматизированы с помощью VBScript, например:
Подводя итоги, хотим ещё раз подчеркнуть, что налаженный процесс управления обновлениями позволит заблаговременно убедиться в успехе применения обновлений и сохранить надежность и работоспособность инфраструктуры при постоянной установке обновлений, обеспечивающих необходимый уровень информационной безопасности.
Проводите ли вы тестирование регулярного обновления ПО?
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, например: