Как вместить политику по установке обновлений безопасности в 50 слов.

Политика установки обновлений безопасности (патчей) предмет постоянного конфликта между ИТ безопасностью, оперированием и бизнесом. Безопасность традиционно хочет чтоб все обновления были установлены повсеместно, здесь и сейчас, потому что так им подсказывает триада CIA на которую давят всевозможные APT. Оперирование хочет полной гарантии, что патчи ничего не сломают и тогда часть из них они возможно установят в следующем квартале. Бизнес же традиционно хочет чтоб все работало с SLA близким к 99.999 а риски доступности были нулевые. Конфликт этот редко разрешается мирно и еще реже его решение приводит к улучшению ситуации с бизнес-рисками, просто выбирается некоторый компромисс подписывается в виде политики вида “95% серверов должно получить обновления в течении следующего за их выходом месяца”, и потом висит дамокловым мечом над всеми участниками. Бизнес при этом остается там же, в осаде сложнопредсказуемых рисков при полной невозможности принимать систематические управленческие решения для из минимизации. На мой взгляд, у данного конфликта есть достаточно простое решение которое я попытаюсь раскрыть ниже.

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

Добавим деталей. Суть процесса. Для начала нужно вспомнить, для чего мы устанавливаем обновления безопасности и от чего это должно происходить регулярно. Во-первых, нужно помнить, что делаем мы это для предотвращения определенных бизнес-рисков и ни для чего более. Это вот понимание ни в коем случае не должно выходить из поля вашего зрения. Во-вторых, нужно признать, что управлять установкой обновлений в режиме проекта, читай в рамках стандартного процесса управления изменениями, получится только при малоограниченных ресурсах, которые есть далеко не у всех, и процесс нужно существенно оптимизировать. При этом, нужно помнить, что защищаемся мы от реальных угроз, следовательно нужно держать в уме все те меры, что уже приняты для минимизации рисков данного типа, например application firewall, IPS, сегментирование и тому подобное. Это позволит вводить в оценку остаточных рисков актуальные поправки. Отдельно стоит заметить, что ключевым условием успеха является наличие работающих инструментов по оценке уязвимостей - если вы что-то не можете измерить с достаточной точностью, вы не сможете этим управлять.

Детальный разбор. ИТ оперирование. Именно ИТ оперирование является ключевым звеном данного процесса потому как будет нести основную нагрузку по русурсным затратам, поэтому ключ к успеху лежит в правильном вовлечении его управленческого состава. Установка обновлений безопасности по-сути классический элемент управления изменениями и должна быть вписана в данный процесс тем или иным способом. При этом, эффективность как раз и будет зависеть от того, каким способом это будет сделано. Классическая основа любых изменений это их предварительное тестирование и возможность отменить уже сделанные изменения. Как этого достичь в нашем случае? Начните с проведения ревизии инструментария, которым пользуется ИТ оперирование для обновлений безопасности - он должен иметь возможность максимально гладко отзывать сделанные изменения, создавать различные сценарии установки и расписания для разных элементов инфраструктуры и генерировать достаточно непротиворечивые отчеты. Далее следует провести ревизию резервного копирования и восстановления, чтоб понять, с какими сложностями можно столкнуться при выходе из возможных инцидентов. Этот элемент не ключевой, поэтому его можно оставить на этап улучшения. При этом правильно будет убедиться, что ИТ оперирование полностью принимает утверждение, что резервное копирование, управление изменениями и инцидентами это область минимальной зрелости ИТ и по-сути лицензия на оперирование. Чем менее зрелым является ИТ оперирование, тем сильнее в нем живет страх “мы же сейчас тут все сломаем, если поставим это”. В борье с этим помогут две вещи: полная свобода ИТ оперирования в выборе расписания установки обновлений, и прописанная в дополнении к политике методология о том как минимизировать риски при данного типа обновлениях. На самом деле, ничего сложного в этом нет и достаточно следовать простейшим принципам: Иметь доступ к техническим форумам основных бизнес-приложений для отслеживания реакции на установку обновлений другими пользователями. Это позволит вовремя исключать пробемные патчи из цикла установки. Для простых серверов. Устанавливать обновления волнами с недельным интервалом, начиная с наименее критичных серверов. Все тестирование проводить в рабочей среде. При возникновении инцидентов, переводить хрупкие сервера из первых в более отдаленные волны или исключать их из расписания. Для Test-Quality-Production троек. Обновления начитать с тестовых сред, чтоб после тестирования в рабочей среде перейти к разработческим и основным системам. Для кластеров. Устанавливать обновление на неактивный компонент с его последующей активацией и тестированием в реальной среде. Операцию с оставшимися элементами нужно будет повторить через Х дней.

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

Детальный разбор. Безопасность. Чаще всего, самой активной стороной описываемого процесса и наиболее агрессивным его участником является ИТ безопасность и это мне не кажется верным подходом, потому что уводит процесс в область “действия ради действия” оставляя управление рисками за рамками политики. Чаще всего это происходит из-за невозможности актуально определить остаточные риски, что тянет за собой желание поставить все обновления везде и в максимально сжатые сроки. Таким образом, для полноценного функционирования данного процесса безопасности необходим иметь инструмент для сканирования остаточных рисков, например NESSUS. В минимальной конфигурации это может быть один сервер с установленным сканером и находящийся в дата-центре компании. В оптимальной - развертывание нескольких сканеров; один внутри периметра дата-центра для выявления базового уровня риска, другой в пользовательских подсетях, для определения возможностей атакующего инсайдера и третий в DMZ или на внешних ИП, для выявления общедоступных уязвимостей. Все это требуется для создания достоверного индикатора эффективности процесса управления рисками через установку обновлений и создания источника обратной связи по изменению расписания. Стоит заметить, что регулярное сканирование на наличие угроз так же является индикатором зрелости безопасности, поэтому работы в этом направлении принесут массу отдачи в будущем. При этом, нужно постоянно помнить, что безопасность не занимается установкой обновлений или воздействием на оперирование. Основная задача безопасности - управлением бизнес-рисками, информированием о них, и рекомендациями по их минимизации. Наличие у безопасности непротиворечивой и корректной картины по узявимостям и соответствующим рискам позволит вести диалог и арбитраж между оперированием и бизнесом. На начальном этапе в отчетах правильнее всего будет сконцентрироваться на выделении особо рисковых объектов, например бизнес-критичных серверов с высокими профилями риска, на которые обновления не устанавливаются по причине их stand-alone конфигурации, устаревшей ОС или отсутствия стратегии по восстановлению. Так же будет полезным описать из зафиксировать наличие и общий риск серого ИТ.

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

Чтобы просмотреть или добавить комментарий, выполните вход Чтобы просмотреть или добавить комментарий, выполните вход