А как вообще тестируются антивирусные обновления?
По вполне понятной причине в антивирусной индустрии технологические подробности тестирования обычно держатся за семью печатями. Попробуйте поискать в Интернете — сколько-нибудь полезной информации по этому поводу нет.
С другой стороны, тестирование обновлений — очень интересная тема, достойная внимания читателя. И нам здесь есть чем поделиться.
В конце 90-х «Лаборатория Касперского» была одной из первых в индустрии, кто автоматизировал процесс и уже около 15 лет постоянно развивает его.
Сначала несколько интересных цифр:
- Мы выпускаем более 120 типов обновлений для более 90 различных версий/сборок продуктов;
- 79 публичных наборов: антивирусные базы под разные платформы, антиспам базы, базы анти-руткитов, анти-фишинга, родительского контроля, BSS-базы и др.
- 43 специальных наборов баз для наших технологических партнёров.
Публичные антивирусные базы выпускаются в среднем каждые 2 часа, антиспам-базы – вплоть до 5 минут. Всё тестируется на ложные срабатывания («фалсы»), лост-детекты (пропуск вредоносных программ), «падения», загружаемость системы, работоспособность в каждом продукте и по ряду других критериев.
Одно из главных – «фалсы» и лост-детекты. От них зависит качество защиты и к этому процессу мы подходим особенно основательно. Базы тестируются автоматически на большой коллекции (софт, кривые, битые файлы и пр.), на обычном компьютере это заняло бы сутки. Разумеется, позволить себе такую роскошь мы не можем, поэтому тесты проводятся на специальном вычислительном кластере под управлением нашей собственной распределённой системы DDPS (Distributed Data Processing System), которая способна просканировать 80-терабайтную коллекцию за 6 часов.
Работоспособность баз в конкретном продукте под конкретной ОС тоже весьма критична (потому как кому нужны хорошие базы с неработающим продуктом?). Они тестируются специальным роботом на виртуальных машинах, где установлены все комбинации поддерживаемых версий и ОС (Windows, разные Юниксы-Линуксы, MacOS). В этом кластере больше 1300 виртуальных машин, т.е. потенциально мы можем одновременно проверить 1300 (sic!) комбинаций.
Отдельно тестируются обновляемые модули (антивирусный движок, анти-руткит, Script Emulator, IDS и т.п., это более 20 модулей). Это работа выделенной команды тестеров, расположенных в Москве, Петербурге и Пекине (всего 10 человек). Процесс полуавтоматический, т.е. над задачей работают и роботы и специалисты.
После тестирования создаётся «набор для выкладки», который загружается на публичные серверы всего количеством более 60 штук на всех континентах за исключением Антарктиды. С этих серверов как раз и получает обновления антивирус, установленный на вашем компьютере. Загрузка происходит с помощью опять же нашей собственной разработки DRS (Distributed Replication System). Благодаря DRS процесс идёт очень быстро, во много потоков, с высокой степенью надёжности. Для примера вот такой показатель: репликация обновления на все эти серверы занимает всего несколько минут, в час мы делаем порядка 20 «выкладок».
Контролируемые обновления
Что важно во всём этом механизме производства, тестирования и доставки обновлений?
Результаты обновления контролируются другим нашим инструментом, а именно облачной системой KSN. В случае «багов», KSN сигнализирует о наличии проблемы за час (а то и несколько часов или даже дней, в зависимости от характера «баги») до поступления первых сигналов от пользователей в техподдержку. Эта технологическая особенность позволяет нам быстрее реагировать и даже решать некоторые инциденты ДО их разрастания.
Общая стоимость нашей инфраструктуры для тестирования обновлений составляет около $3 млн в год. Недёшево, но это очень важные затраты — от них зависит качество защиты, стабильность работы продуктов и, главное, мнение и комфорт пользователя. За прошлый год система тестирования выявила и предотвратила 4 крупных инцидента, а также приличное количество «фалсов». В общем, инфраструктуру будем и дальше развивать, это не повод для экономии.
За последнее время у нас было 2 серьезных инцидента с обновлениями (в декабре и в феврале). Мы их тщательно проанализировали, сделали выводы и уже внесли несколько важных изменений как в организационном, так и в техническом плане.
Во-первых, ужесточили регламент для выпуска «опасных» обновлений, которые потенциально могут вызвать проблемы на стороне клиента: повысили уровень контроля — теперь каждая манипуляция с каждым файлом регистрируется и можно мгновенно понять что, как и кем выпускается, а любые, даже самые незначительные отклонения в инфраструктуре от нормального состояния или расследуемые инциденты могут остановить обновление (соответственно, предотвратить новый инцидент).
Во-вторых, в процедуру проверки обновлений введены новые тесты на «падучесть». В одном из них используется специальная коллекция файлов, при сканировании которой продукт задействует максимальное количество кода в антивирусных базах, при этом у некачественного кода появляется больше возможностей проявиться. При этом, доработали систему сбора, учёта, атрибутирования и агрегирования сведений о «падениях» на стороне клиента (дампов) – теперь ни одно «падение» в базах не растворяется, всё расследуем. Первые испытания показали, что процедура очень эффективная. Уже выловили один очень неприятный баг.
В-третьих, сформировали требования к будущим продуктам для повышения устойчивости к разного рода проблемам с обновлениями. Здесь пока без деталей, чтобы не выболтать описания будущих патентов :-).
Наконец, запускаем новую корпоративную процедуру кризис-менеджмента, которая охватывает все вовлечённые подразделения и обеспечивает максимальную скорость и прозрачность прохождения информации по цепочке от разработчика до клиента.
Важно: перечисленное выше — лишь небольшая часть из улучшений, над которыми идёт работа в этом году.
Несмотря на мощную систему тестирования, ошибки случаются, и от этого никто не застрахован. Мы тоже люди, хоть и управляем роботами и автоматами. Errare humanum est. Но важно, чтобы humanum делал выводы из каждой errare и постоянно совершенствовался, ведь совершенству, увы (или к счастью?), предела нет.
Автор поста — Николай Гребенников, CTO «Лаборатории Касперского»
ссылка на оригинал статьи http://habrahabr.ru/company/kaspersky/blog/173753/
Добавить комментарий