Инцидент с синим экраном, вызванный обновлением защитного решения CrowdStrike, по подсчетам Microsoft, затронул более 8,5 миллионов компьютеров по всему миру. Эта история дорого обошлась многим компаниям и вызвала много споров о том, как не допустить повторения подобной ситуации.
Понятно, что от ошибки не застрахован никто, в сложных программных системах просто невозможно гарантировать абсолютное отсутствие багов. Но правильно выстроенный процесс разработки, тестирования и доставки продуктов и их обновлений позволяет изрядно минимизировать риск серьезного сбоя.
И у нас бывали инциденты, напрямую связанные с обновлениями наших продуктов. Но последний раз заметная проблема с обновлениями случилась у нас в далеком 2013 году.
После этого неприятного эпизода мы провели тщательный анализ причин и полностью пересмотрели свой подход к подготовке и тестированию обновлений как в продуктах для бизнеса, так и в наших разработках для домашних пользователей. Выстроенная в итоге система отлично себя зарекомендовала — за 11 лет у нас не случилось ни одного сбоя подобного уровня.
Мы не делаем секрета из построенного нами механизма выпуска обновлений и готовы делиться этой информацией с индустрией. Ведь без свободного обмена лучшими практиками и решениями, разработанными разными компаниями, прогресс отрасли кибербезопасности будет попросту невозможен. Одними из главных составляющих этого механизма системы являются: многоуровневое тестирование, постепенная раскатка обновлений и автоматический мониторинг аномалий. Расскажем о них по порядку.
Оглавление
Многоуровневое тестирование
Обновления наших продуктов бывают двух типов: добавление детектирующей логики и изменение функциональности продукта. Добавление новых функций потенциально добавляет больше рисков, но проблемы могут возникнуть и с детектирующей логикой. Поэтому мы тщательно тестируем и те и другие апдейты на разных этапах.
Проверка на отсутствие ложных срабатываний
При создании и выпуске правил детектирования (как автоматически генерируемых, так и написанных человеком), они тестируются на обширной базе легитимных (или «чистых») объектов — на файлах, веб-страницах, шаблонах поведения и так далее. Таким образом выявляются и отфильтровываются ложные срабатывания. У нас имеется обширная и постоянно обновляемая коллекция легитимных объектов, как программного обеспечения, так и чистых веб-ресурсов, на которой тестируются все созданные правила.
Один из способов пополнения этой коллекции — программа Allowlist, позволяющая разработчикам ПО (как клиентам, создающим и эксплуатирующим собственные разработки, так и независимым вендорам) предоставлять нам свой софт. Это позволяет уменьшить количество потенциальных ложных срабатываний и снизить риск некорректной классификации ПО.
Другие способы получения файлов и метаданных — обмен информацией с партнерами по индустрии, наш Threat Intelligence Portal и так далее. Всего в нашей базе легитимных объектов содержатся сведения о 7,2 миллиардах объектов.
Тестирование на виртуальных машинах
Но проверка обновлений, разумеется, не сводится только лишь к их тестированию на коллекциях файлов. Если на первом этапе проблем не выявляется, все обновляемые компоненты проходят многоступенчатое автоматическое тестирование на виртуальных машинах с различными конфигурациями защитных продуктов, софта и операционных систем. На них выполняются различные сценарии работы как связанные с нашими продуктами и работой защитных механизмов, так и с имитацией типичных действий пользователя.
Если говорить о продуктовых сценариях, то, например, проводится сканирование файловой системы, обновление продукта, перезагрузка после обновления и так далее. Это позволяет убедиться, что продукт после обновления функционирует нормально, не падает сам и не роняет систему. Через эту проверку проходит каждый апдейт.
В качестве пользовательских сценариев имитируется типичное поведение человека за компьютером — открывается браузер, посещаются веб-страницы, скачивается файл, запускается программа. Данная проверка позволяет убедиться, что продукт не оказывает негативного влияния ни на скорость работы, ни на стабильность.
Отдельно обновления автоматически тестируются на совместимость с индустриальным ПО (например, на SCADA-системы). Любое негативное влияние на софт из этой сферы чревато остановкой производственных процессов и потенциальным ущербом.
Контроль качества
В дополнение к предыдущим проверкам у нас также есть отдельная команда, занимающаяся контролем качества. Ни один продуктовый релиз обновлений не выходит без подтверждения его готовности экспертами этой команды. Также она, при необходимости, корректирует и постоянно совершенствует процессы проверки и отслеживает появление возможных операционных рисков.
Поэтапный выпуск обновлений защитных технологий
Разумеется, мы реалисты и допускаем, что всей этой многоуровневой системы проверок может оказаться недостаточно. Например, какое-то стороннее ПО обновится одновременно с нашим и это вызовет непредвиденный конфликт. Да и вообще, все сочетания конфигураций разных программ и систем предугадать невозможно. Поэтому, после того как обновление, затрагивающее функциональность защитных решений, готово и одобрено, оно не оказывается сразу на всех компьютерах наших заказчиков. Вместо этого происходит постепенный выпуск обновлений.
Обновления проходят предварительное тестирование на части машин в нашей собственной сети до начала публикации на публичные серверы обновлений. Если проблем не выявляется, то сначала обновление получает очень небольшое количество случайным образом выбранных пользователей. Если проблем и сбоев не фиксируется, то количество компьютеров, получивших обновление, постепенно увеличивается с некоторыми интервалами. И так, пока обновление не будет доступно всем пользователям.
Автоматический мониторинг аномалий
Что происходит в том случае, если обновление все-таки вызывает проблемы? Мы отслеживаем поведение обновленных решений при помощи добровольно передаваемых анонимизированных данных, получаемых через Kaspersky Security Network (KSN), и оперативно останавливаем его распространение, если что-то пошло не так.
Но главное, благодаря сочетанию автоматического мониторинга аномалий и таргетированного выпуска обновлений, ошибка может затронуть только очень небольшое количество компьютеров — сотни, а не тысячи и не миллионы.
Тестирование обновлений на стороне клиента
В нашей компании предусмотрена возможность еще одной проверки полученных обновлений, на этот раз уже на стороне клиента, через консоль управления Kaspersky Security Center.
По сути, системные администраторы клиента могут завести в собственной инфраструктуре отдельную тестовую группу компьютеров (или виртуальных машин) с наиболее распространенной в сети организации конфигурацией и набором ПО. А потом создать задачу на проверку обновлений, указав эту группу в качестве цели. Тогда поступающие обновления сначала будут устанавливаться только на тестовых машинах, проверяться в деле и только после завершения проверки устанавливаться во всей сети компании. Подробнее о том, как настроить такую проверку, можно узнать на сайте нашей технической поддержки.
Каждую проблему с обновлениями, в том числе и выявленную в предварительных тестах, мы тщательно анализируем и разбираемся в причинах ее возникновения. И принимаем меры к тому, чтобы она больше не повторилась. Кроме того, у нас внедрена практика проактивного выявления и оценки рисков возможных проблем, по которым проводится системная работа. В результате такой работы мы за все время развития нашей компании выстроили многоуровневую систему, позволяющую значительно снижать риск возникновения проблем.
Конечно, в рамках одного блогпоста невозможно рассказать обо всех нюансах выстроенной у нас многоуровневой системы проверки обновления продуктов. Однако, если тема вызовет интерес в индустрии, мы готовы и дальше делиться подробностями. Только свободная кооперация всех игроков сферы инфобезопасности может создать эффективный заслон действиям киберпреступников.
Блог Касперского
Вот да, вот. Теперь мы за Касперского спокойны. Американцы уже обожглась со своим CrowdStrike и ещё раз обожгуться. Не надо было Касперского запрещать.