Вы залатаны, но вы застрахованы? Проверьте свой полис киберстрахования

Вы давно проверяли свой полис киберстрахования? Я обращаюсь к тем из вас, кто занимается администрированием клиентских и серверных систем Windows. И я особенно обращаюсь к тем из вас, кто отвечает за то, чтобы системы вашей компании были в курсе всех критических обновлений, обновлений безопасности, накопительных обновлений, необязательных обновлений, исправлений и других обновлений, которые в эти дни поступают из Редмонда. как вода из пожарного шланга.

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

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

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

Проблема киберстрахования № 1: должны быть установлены последние исправления

Здесь у нас возникает простая языковая проблема, а именно, что именно страховщик (поставщик полиса) имеет в виду под фразой «актуальные патчи»? Означает ли формулировка здесь, что застрахованная (ваша компания или организация) обязана в соответствии с политикой устанавливать исправления в день их выпуска? Вероятно, нет, так как в другом утверждении политики говорится, что вы также должны тестировать все исправления перед их применением, и, очевидно, тестирование может занять некоторое время для правильного выполнения, в зависимости от масштаба и сложности вашей инфраструктуры.

Тем не менее, остается вопрос о том, что означает двусмысленный термин «актуальный» в данном контексте. Если вы откладываете применение накопительного обновления (CU) на две недели, значит ли это, что в системе Windows не установлены последние исправления? Или три недели? Месяц? Когда система Windows считается не обновленной с помощью исправлений?

А как насчет автономного ПК с Windows, на котором работает промышленный или медицинский инструмент? Такие системы часто не подключены к Интернету, и если они работают нормально, вам, вероятно, не захочется их исправлять, если патч что-то сломает и вы не сможете использовать свой инструмент. Это, безусловно, исключительный случай, который необходимо обрабатывать, и даже если в настоящее время в вашей среде нет подобной системы, ваша политика должна включать заявление о таких исключениях.

Проблема № 2: должно быть включено автоматическое обновление

Должны быть? Что делать, если у меня есть небольшая часть моей сети, где я вручную исправляю определенные машины? Например, критически важные для бизнеса серверы. Некоторым администраторам нравится следовать этому подходу, чтобы избежать (к сожалению, все более распространенной) ситуации, когда патч вызывает больше проблем, чем он предназначен для исправления. Например, во второй половине 2018 года было несколько случаев, когда обновления программного обеспечения, выпущенные Microsoft, вызывали многочисленные проблемы у тех из нас, кто отвечает за исправление серверных и клиентских систем Windows. Поэтому очевидно, что необходимо включить что-то о возможных исключениях из этого заявления о политике или об изменении формулировки заявления.

Проблема № 3: Необходимо тестировать… в полностью изолированной отдельной тестовой среде

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

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

Для тестирования исправлений на клиентских системах вы можете использовать другой подход, подобный тому, который предложил мне мой коллега, управляющий 300 рабочими местами в компании среднего размера. Ее подход заключается в том, чтобы собрать небольшую группу энтузиастов и несколько технически подкованных пользователей и сделать их «пилотной группой» для установки исправлений на ПК с Windows. Новые обновления программного обеспечения от Microsoft сначала устанавливаются на ПК этих пилотных пользователей, и если что-то пойдет не так, они уведомляют администратора, который откатывает исправления и исследует проблему дальше. Однако если в течение семи дней с этой группой проблем не возникнет, исправления будут установлены на все компьютеры в сети. Я считаю, что это хороший подход для малого и среднего бизнеса, но просто убедитесь, что ваша страховая компания понимает, что вы делаете, и обоснование этого, и что язык вашего полиса киберстрахования подтверждает, что они понимают его и принимают. это для вашей среды.

Проблема № 4: Должны быть задокументированы… в правильном порядке

И здесь видимость снова переходит в действительность. Из-за того, что Microsoft теперь выпускает большинство ежемесячных исправлений в виде накопительных обновлений (CU), при восстановлении системы с нуля вам не нужно применять все исправления, которые вы ранее установили в неисправной системе, все в том же порядке. как прежде. Затем есть вопрос о патчах, которые Microsoft вытаскивает из-за проблем с ними. Позже они могут быть выпущены под тем же обозначением KB или под другим KB. На самом деле, эта идея документирования каждого патча, установленного на каждой системе, — просто пустая трата времени, и когда вы ведете переговоры (или пересматриваете) свою киберстраховку, вы должны стремиться удалить такие формулировки и требования из своей политики.

Проверьте свой полис киберстрахования — прямо сейчас!

Основываясь на нашем обсуждении возможных проблем, которые могут возникнуть из-за несоблюдения — преднамеренного или непреднамеренного — реального или кажущегося — вашей организацией заявленных требований к управлению исправлениями, содержащихся в полисе страхования вашей компании от киберугроз, вероятно, будет хорошей идеей просмотреть что ваша политика говорит об управлении исправлениями. Ищите любые формулировки, которые могут показаться вам двусмысленными, или требования, требующие четко сформулированных исключений. Затем обратитесь в страховую компанию, которая покрывает ваши потребности в кибербезопасности, и попросите их разъяснить — в письменной форме — проблемы с исправлением, которые, по вашему мнению, должны быть определены и выражены более четко. Потому что помните, когда происходит что-то неожиданное и плохое, и вам нужно подать иск в страховую компанию, их удовлетворение или отказ в иске в конечном итоге будет зависеть только от одного: от точной формулировки вашего полиса.