Как минимизировать риски обновления ПО

Инцидент с синим экраном, вызванный обновлением защитного решения CrowdStrike, по подсчетам Microsoft, затронул более 8,5 миллионов компьютеров по всему миру. Эта история дорого обошлась многим компаниям и вызвала много споров о том, как не допустить повторения подобной ситуации.

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

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

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

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

Многоуровневое тестирование

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

Проверка на отсутствие ложных срабатываний

При создании и выпуске правил детектирования (как автоматически генерируемых, так и написанных человеком), они тестируются на обширной базе легитимных (или «чистых») объектов — на файлах, веб-страницах, шаблонах поведения и так далее. Таким образом выявляются и отфильтровываются ложные срабатывания. У нас имеется обширная и постоянно обновляемая коллекция легитимных объектов, как программного обеспечения, так и чистых веб-ресурсов, на которой тестируются все созданные правила.

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

Другие способы получения файлов и метаданных — обмен информацией с партнерами по индустрии, наш Threat Intelligence Portal и так далее. Всего в нашей базе легитимных объектов содержатся сведения о 7,2 миллиардах объектов.

Тестирование на виртуальных машинах

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

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

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

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

Контроль качества

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

Поэтапный выпуск обновлений защитных технологий

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

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

Автоматический мониторинг аномалий

Что происходит в том случае, если обновление все-таки вызывает проблемы? Мы отслеживаем поведение обновленных решений при помощи добровольно передаваемых анонимизированных данных, получаемых через Kaspersky Security Network (KSN), и оперативно останавливаем его распространение, если что-то пошло не так.

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

Тестирование обновлений на стороне клиента

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

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

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

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