Сделать это сейчас или отложить? Риск-ориентированный подход к управлению исправлениями
Большинство ИТ-администраторов согласятся с тем, что установка исправлений для таких систем, как клиенты Windows и особенно серверы Windows, сопряжена с определенным риском. Если вы не уверены в этом, взгляните на мою предыдущую статью под названием «Достигли ли исправления Microsoft критической точки?» здесь, на нашем сайте TechGenix. В той статье. Я поделился несколькими историями, которые продемонстрировали, что для многих администраторов стало невыносимо терпеть огромное количество исправлений Microsoft, и я пришел к выводу, что что-то должно измениться, и в ближайшее время. Затем в следующей статье под названием я описал ряд смягчающих мер, которые мы все как администраторы управления исправлениями можем предпринять, чтобы предотвратить надвигающуюся гибель. Эти шаги были в основном практическими советами, такими как ожидание недели перед применением каких-либо обновлений программного обеспечения и использование нескольких надежных источников для просмотра всех известных проблем, связанных с обновлениями, которые вы собираетесь развернуть.
Хотя шаги, которые я описал, могут оказать практическую помощь администраторам управления исправлениями, они не имеют прямого отношения к основной проблеме риска. Я имею в виду, что каждый раз, когда вы применяете недавно выпущенное обновление к операционной системе или приложению для решения какой-либо проблемы с безопасностью или надежностью программного обеспечения, вы рискуете столкнуться с чем-то непредвиденным. Например, сломать приложение, которое вы пытаетесь исправить. Или нарушить сетевые возможности вашей платформы. Или разрыв рабочего процесса между несколькими приложениями и сервисами. Или взломать устаревший код или сценарий, на который опирается ваш бизнес. Или, возможно, даже в конечном итоге с ужасной ошибкой остановки синего экрана на одной или нескольких ваших пропатченных системах.
Список рисков, которым вы можете подвергнуться, когда дело доходит до управления исправлениями, бесконечен. И я не говорю это праздно, поскольку у всех нас, как у администраторов, в прошлом случались серьезные неприятности, когда что-то шло не так из-за применения патча, выпущенного поставщиком для некоторого приложения или операционной системы. Это, конечно же, означает, что основой всего процесса управления исправлениями является концепция управления рисками. Но, учитывая широкий спектр возможных негативных последствий, которые могут возникнуть каждый раз, когда вы применяете патч, выпущенный поставщиком — и особенно патчи, выпущенные Microsoft для своих операционных систем Windows, если все ваши приложения и службы работают и зависят от клиентских и серверных систем Windows — с чего следует начать, когда дело доходит до управления рисками, связанными с управлением исправлениями?
Классификация рисков, связанных с различными уязвимостями
Недавно я обсуждал это с Эмином Атаком, сертифицированным специалистом в области цифровой криминалистики и реагирования на инциденты (DFIR), а также обладателем награды Microsoft Most Valuable Professional (MVP) в области управления облачными вычислениями и центрами обработки данных (CDM). Эмин ведет блог о своих путешествиях по информационной безопасности (InfoSec) и автоматизации на своем сайте WordPress и делится своими проектами на своей странице GitHub. В двух словах подход Эмина к этому вопросу прост и ясен: «Моей стратегией всегда был подход, основанный на риске. Если есть уязвимость, нужно что-то делать с риском. Но сначала необходимо выявить и оценить риск». Другими словами, ключевым первым шагом в управлении рисками для исправлений систем является определение того, для устранения каких уязвимостей предназначено исправление. Затем, основываясь на степени серьезности выявленной уязвимости, вы можете решить, какой уровень риска связан с применением (или неприменением) исправления, а также как и когда следует применять исправление.
По оценке Эмина, это сводится к тому, что существует четыре основных способа устранения уязвимости, обнаруженной в операционной системе или приложении. Во-первых, вы можете принять риск как незначительный в настоящее время и просто сохранить информацию на будущее, когда уязвимость станет эксплойтом нулевого дня, если это когда-либо произойдет. Я попросил Эмина привести пример уязвимости такого типа, и он упомянул блог Мэтта Нельсона, в котором он описал уязвимость удаленного выполнения кода, обнаруженную им еще в феврале 2018 года, из-за которой оболочка Windows неправильно проверяла пути к файлам. Это означало, что злоумышленник, которому удалось успешно воспользоваться уязвимостью, мог запустить произвольный код в контексте текущего пользователя. Мэтт сообщил об уязвимости в Microsoft Security Response Center (MSRC), и конечным результатом стало то, что в августе MSRC выпустила исправление для проблемы, которая к тому времени была обозначена MITRE как уязвимость CVE-2018-8414. Хотя Мэтт предложил несколько способов мониторинга подверженности уязвимости, а также предложил (непроверенный) обходной путь для снижения возможной подверженности уязвимости, большинство администраторов, вероятно, справились с этим вопросом, приняв на себя риск ничего не предпринимать до тех пор, пока не будет выпущено исправление. быть достаточно малым, чтобы оправдать такое решение.
Второй способ обработки недавно обнаруженной уязвимости включает в себя то, что вы можете сделать, когда для ее устранения выпущены исправление, и обходной путь. Эмин называет это «упрощенным/смягченным» подходом, при котором вы «применяете обходной путь вместо того, чтобы сначала устанавливать исправление, так как это дает вам больше времени, и вы можете исправить это позже». В качестве примера Эмин упоминает, что «всякий раз, когда во Flash происходит нулевой день, вы можете применить обходной путь и установить бит аннулирования в реестре». «Бит аннулирования», на который он ссылается, — это параметр реестра, который запрещает попытки создания экземпляра Adobe Flash Player в Internet Explorer и других приложениях, поддерживающих функцию бита аннулирования. Дополнительную информацию об этом можно найти в рекомендации по безопасности MSCR ADV180014. Эмин также рассказывает, что другим недавним примером этого было обновление безопасности IE11 от 14 августа 2018 года, которое сломало ADFS, SSO и перенаправления. У администраторов, столкнувшихся с такими проблемами после установки обновления, было несколько вариантов дальнейших действий. «Вы можете удалить обновление безопасности, — говорит Эмин, — или, к счастью, вы можете применить обходной путь (добавить веб-сайт в зону доверенных сайтов) и дождаться исправления, выпущенного 30 августа 2018 года, которое впоследствии было включено в следующее CU. сентября 2018 года».
«Совместно/переносимый» подход к управлению исправлениями
Третий подход к управлению рисками, связанными с уязвимостью, — это то, что Эмин называет «совместно/переносимым» подходом. Или, как выразился Эмин, «увеличьте бюджет и купите более дорогую страховку», которая может перенести риск, связанный с вашей организацией, на страховую компанию. На самом деле это довольно распространенный подход к управлению рисками, которого придерживаются крупные предприятия в отношении определенных типов новых и разрушительных уязвимостей. Эмин говорит, например, что «многие компании из списка Fortune 500 купили биткойны до того, как их атаковала программа-вымогатель, чтобы они могли следовать уведомлению ФБР и платить выкуп в случае инцидента».
Четвертый и последний подход к исправлению уязвимостей, который определяет Эмин, заключается в том, чтобы просто избежать риска, связанного с уязвимостью, либо немедленно исправив ее, либо — в крайнем случае — удалив нарушающее программное обеспечение или компонент Windows из уязвимых систем. Например, если в Adobe Acrobat была обнаружена серьезная уязвимость нулевого дня, для которой Adobe еще не выпустила исправление, вы можете просто удалить Acrobat со всех клиентских систем и вместо него установить другую программу для чтения PDF-файлов. В качестве примера, связанного с компонентом Windows, Эмин упоминает, что он «удалил SMB v1 за шесть месяцев до появления Wannacry (см. здесь, как это сделать) и сразу же применил MS17-010 для исправления уязвимости Ethernalblue CVE-2017-0144».
Управление исправлениями: 4 разных подхода
Напомним, что есть четыре различных подхода, которые вы можете выбрать для устранения риска, связанного с недавно обнаруженной уязвимостью в Windows или приложении:
- Примите риск на данный момент и подождите, пока Microsoft выпустит для него исправление.
- Уменьшите/уменьшите риск, применив обходной путь (если таковой имеется), который рекомендует Microsoft, пока у вас не будет времени полностью оценить риск, связанный с применением самого исправления.
- Разделите/перенесите риск, вытащив кошелек и позвонив в свою страховую компанию.
- Просто примените патч, чтобы не попасться на эксплойт, указанный в бюллетене MSRC.
Естественно, каждую уязвимость, обходной путь и исправление следует рассматривать отдельно, чтобы определить, какой подход лучше всего подходит с точки зрения риска для вашей среды.