Управление исправлениями: важнее, чем когда-либо (часть 1)

Введение

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

Эволюция управления исправлениями

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

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

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

Загадка сложности

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

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

К сожалению, установка исправлений сегодня не только важнее, чем когда-либо; это также более сложно, чем когда-либо. В «старые» времена большинство сетей состояло из нескольких серверов (под управлением Windows Server в «магазине Windows» или некоторых разновидностей Linux/UNIX в «магазине *NIX»), а также нескольких настольных клиентских машин, обычно клиенты Windows. Такое единообразие сделало развертывание исправлений по всей организации относительно простым.

Сегодня единообразие является скорее исключением, чем правилом. В большинстве корпоративных сетей используются различные типы серверов; у вас может быть домен Windows с веб-серверами на базе Linux, на которых работает Apache. На стороне клиента все еще сложнее. Компании открыли свои сети для всех типов личных устройств сотрудников. У удаленных сотрудников дома есть собственные настольные компьютеры, на которых может работать одна из нескольких версий Windows, Mac OS X или один из бесчисленных дистрибутивов Linux. Пользователи, работающие на территории компании, приносят свои ноутбуки. Сотрудники больше не получают доступ к ресурсам компании только с этих компьютеров, но также могут работать со своих планшетов или телефонов, на которых установлена одна из множества версий мобильной операционной системы. Обеспечение того, чтобы все они были правильно исправлены, является серьезной головной болью для ИТ.

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

Дилемма «быстрого решения»

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

Из-за характера программного обеспечения поставщик никогда не может охватить все возможные конфигурации при тестировании. Вот почему лучшие практики уже давно включают внутреннее тестирование систем, предназначенных для эмуляции ваших производственных систем (с точки зрения оборудования, версий и настроек операционной системы, установленных приложений и т. д.). Хитрость заключается в том, чтобы максимально защитить ваши системы от уязвимостей, не подвергая их другому риску из-за непроверенных исправлений.

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

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

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

Делай свою домашнюю работу

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

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

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

В течение нескольких дней после выпуска основного набора исправлений, если с исправлениями связаны широко распространенные проблемы, новости обычно начинают появляться сначала на технических форумах, а затем подхватываются технической прессой. Сканирование форумов в поисках такой информации может заранее предупредить вас о том, что некоторых патчей лучше избегать или, по крайней мере, откладывать до тех пор, пока вы не получите больше информации. Иногда можно избавить себя от многих неприятностей, просто подождав несколько дней. Действительно плохие исправления часто удаляются поставщиком и заменяются «фиксированным исправлением» в течение короткого времени.

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

Резюме

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