Система тестирования и исправления тестовых баз данных антивирусного приложения

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

Область техники

Полезная модель относится к системам снижения риска ложных срабатываний антивирусных баз данных.

Уровень техники

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

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

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

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

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

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

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

Еще один вариант системы тестирования обновлений программного обеспечения предлагается в патенте US 7334005. Сначала обновления рассылаются узкому списку подписчиков, затем, если проблем не было найдено, список подписчиков расширяется. Таким образом решается задача предварительного тестирования. В качестве выборки выступает случайно сгенерированное число, которое может быть сгенерировано по времени в зависимости от настроек пользователя (в том числе от настроек по рискам безопасности). Также на стороне сервера можно принять решение о загрузке пользователю (подписчику) только части обновлений (в рамках снижения риска).

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

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

Сущность полезной модели

Настоящая полезная модель предназначена для тестирования и исправления баз данных средств антивирусной системы.

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

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

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

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

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

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

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

Краткое описание чертежей

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

Фиг.1 иллюстрирует упрощенное представление РЕ-формата файла.

Фиг.2 иллюстрирует схему обнаружения ложных срабатываний для сигнатур файлов.

Фиг.3 иллюстрирует схему отключения сигнатуры файла у пользователей при наличии ложного срабатывания.

Фиг.4 иллюстрирует схему обнаружения ложных срабатываний для эвристик.

Фиг.5 иллюстрирует схему работы с неизвестными файлами.

Фиг.6 иллюстрирует схему обнаружения ложных срабатываний для родительского контроля.

Фиг.7 иллюстрирует схему системы в соответствии с одним из вариантов реализации настоящей полезной модели.

Описание вариантов осуществления полезной модели

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

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

Все исследуемые неизвестные исполняемые файлы являются так называемыми РЕ-файлами (Portable Executable) и имеют РЕ-формат (для семейства операционных систем Windows, под которые пишется большая часть вредоносного программного обеспечения). На фиг.1 представлено упрощенное представление данного формата, благодаря чему мы видим, что РЕ-файл представлен в виде заголовка 105, некоторого количества секций 110 (которые составляют образ исполняемой программы) и оверлея 115 (т.е. сегмент программы, подгружаемый при необходимости во время ее выполнения). Здесь мы намерено опускаем многие детали представления, включая упоминание про MZ-заголовок и более подробное описание секций.

В настоящий момент для того, чтобы создать сигнатуру файла вычисляют его хеш (например, используя алгоритм MD5). Так как вычисление хеша от больших по размеру файлов занимает продолжительное время, то для ускорения его вычисления можно не использовать весь файл целиком в алгоритме хеширования, а только его части, например, заголовок 105, некоторые из секций 110, а также оверлей (если он есть) 115.

Соответственно, чем меньше частей файла используется для алгоритма хеширования, тем больше вероятность того, что при работе антивирусной системы хеш, взятый от приложения из белого списка (например, редактор Notepad), может совпасть с хешем вредоносного приложения, который находится в базе данных антивирусной системы.

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

Один из вариантов реализации настоящей полезной модели описан на фиг.7. Антивирусная компания располагает средствами пополнения баз данных 770 (сигнатур, эвристик, средства родительского контроля и др.), которые она может выпускать в виде двух типов баз - как уже проверенные обновления 725а, так и тестовые записи 725б, которые можно проверить на компьютерах пользователей в тестовом режиме. Эти записи передаются на средство обновления 720, которое присутствует в каждой антивирусной системе у пользователя. Антивирусная система имеет соответственно собственные базы 715 - как текущую 715а, так и базу с тестовыми записями 715б. Эти базы может использовать одно из средств антивирусной системы 710 - это может быть средство сигнатурной проверки, эмулятор, средство эвристической проверки и др. В том случае, если средство 710 сработало, то перед тем как предпринять действия и оповестить пользователя, на этапе 730 уточняется, являются ли сработавшие на средстве 710 записи (или настройки средства антивирусной системы) тестовыми. Если записи были текущими записями 715б, то в таком случае средство сработает (например, сигнатурная проверка предупредит, что обнаружена вредоносная программа) и произойдет оповещение пользователя 740. Если же записи были тестовыми, то в этом случае пользователь не будет оповещен, а средство обработки ложных срабатываний 750 проверит событие на предмет ложных срабатываний (например, приложение из белого списка было ошибочно обнаружено как вредоносная программа). В таком случае средство обработки ложных срабатываний 750 зарегистрирует ложное срабатывание и отошлет на средство исправления ложных срабатываний 760 все нужную информацию, которая необходима для исправления базы 725б. Также эта информация попадет и в средство пополнения баз данных 770, к которому могут иметь доступ люди-эксперты для исправления неточностей и ошибок, которые возникли при создании тестовых записей 725б.

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

Фиг.2 иллюстрирует схему обнаружения ложных срабатываний для сигнатур файлов. В соответствии с одним из вариантов реализации на этапе 210 происходит выпуск тестовой сигнатуры для файла с помощью средств пополнения баз данных 770. Необходимо отметить, что здесь и далее описывается работа полезной модели с одной тестовой записью в базе, но надо понимать, что антивирусная компания может выпускать их в составе пакетов обновлений, тестируя таким образом множество тестовых сигнатур для различных средств антивирусной системы 710. Далее на этапе 220 идет сбор данных по срабатываниям тестовой сигнатуры. В том случае если сразу накапливается большое количество ложных срабатываний, которые были обнаружены с помощью средства обработки ложных срабатываний 750 (например, происходит обнаружение программ из белого списка вместо вредоносных), и их число превышает определенный порог на этапе 230, то сигнатура отключается у всех пользователей на этапе 240 для того, чтобы исключить подобные ошибки в будущем. Подобные случаи могут иметь место, когда вместо вредоносного файла в антивирусной компании была неверно определена программа из белого списка.

Если же количество ложных срабатываний невелико, то спустя некоторое время происходит анализ полученных от пользователей данных на этапе 250 и определяется количество ложных срабатываний на этапе 260. В том случае если ложных срабатываний не было найдено, то тестовая сигнатура переводится в действующую на этапе 270. Однако, если ложные срабатывания были найдены, то сигнатура отправляется для дальнейшего анализа на этапе 280 с помощью средства исправления ложных срабатываний 760 и антивирусная компания должна будет исправить собственную базу сигнатур (или белые списки) перед тем, как выпустить обновление пользователям.

Фиг.3 иллюстрирует схему отключения сигнатуры файла у пользователей при наличии ложного срабатывания. На данной фигуре изображен другой способ обработки ложных срабатываний для сигнатур файлов при котором тестовая сигнатура отключается сразу же при первом ложном срабатывании. На этапе 310 происходит выпуск тестовой сигнатуры с помощью средств пополнения баз данных 770, после чего ведется статистика ее срабатывания на этапе 320. В том случае, если на этапе 330 было обнаружено ложное срабатывание, которое было обнаружено с помощью средства обработки ложных срабатываний 750, то сигнатура немедленно отключается на этапе 350, а данные, полученные при ложном срабатывании могут быть отосланы антивирусной компании на этапе 360 для дальнейшей правки с помощью средства исправления ложных срабатываний 760. Если же ложного срабатывания так и не произошло за время, отведенное для тестирования тестовой сигнатуры, то тогда она переводится в действующую на этапе 340.

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

Помимо использования тестовых сигнатур, есть возможность использовать так же тестовые эвристики, т.е. методы эвристического сканирования. На фиг.4 изображена схема тестирования новых эвристик, которая начинается с того, что на этапе 410 антивирусная компания выпускает тестовую эвристику, которая была разработана с помощью средств пополнения баз данных 770, с целью проверить ее работу в реальных условиях. На этапе 420 происходит сбор данных по ее срабатываниям. Так как сами методы эвристического сканирования могут вызывать ложные срабатывания при наличии в программе фрагментов кода, выполняющего действия и/или последовательности, в том числе и свойственные некоторым вирусам, то использование тестовой эвристики не будет отображено у пользователя. После сбора данных на этапе 420 можно проверить количество ложных срабатываний на этапе 430, которые могут быть обнаружены с помощью средства обработки ложных срабатываний 750. В том случае, если тестовая эвристика показывает хорошие результаты обнаружения неизвестных вредоносных программ, то ее переводят в действующую на этапе 440. Однако если тестовая эвристика обнаруживает большое количество приложений из белого списка, то тогда требуется ее отключение у пользователей на этапе 450 и дальнейшая доработка на этапе 460 с помощью средства исправления ложных срабатываний 760. После доработки эвристики можно снова передавать ее пользователям на этап 410. Можно также помимо записей и выпускать тестовые настройки для эмулятора программного обеспечения, для того, чтобы подобрать их оптимальное сочетание, например, во время вирусных эпидемий.

Возможны случаи, когда ни сигнатурная проверка, ни эвристический анализ не могут дать точного ответа на вопрос, является ли неизвестное приложение (исполняемый файл) вредоносным программным обеспечением. В таком случае можно использовать различные методы проактивной защиты, например, HIPS (способ ограничения функционала программ на основе анализа их активности). Еще одним фактором будет являться количество запусков неизвестного приложения пользователями, т.е. при большом количестве запусков можно предполагать начало так называемой вирусной эпидемии. В таком случае для антивирусной компании понадобиться получить экземпляр вредоносной программы как можно раньше. На фиг.5 показан алгоритм работы полезной модели при работе с неизвестными файлами. На этапе 510 пользователь пытается запустить неизвестный исполняемый файл и на этапе 520 антивирусная система проверяет этот файл всеми доступными методами. В том случае если файл содержит вредоносный функционал или же наоборот, находится в белом списке, то на этапе 530 антивирусная система может разрешить или запретить запуск файла. Если антивирусная система не может точно определить тип файла (вредоносный он или нет), то тогда используются различные проактивные методы защиты, а также ведется статистика запуска этого файла пользователями на этапе 540. Если количество запусков растет быстро, то это может служить сигналом для антивирусной компании, что появилась новая вредоносная программа или приложение (исполняемый файл) из белого списка, которую следует загрузить на этапе 550, отправить на дальнейший анализ на этапе 560 и внести новые изменения в базы данных антивирусной системы на этапе 570 с помощью средств пополнения баз данных 770.

На фиг.6 изображена схема обнаружения ложных срабатываний для родительского контроля. На этапе 610 происходит срабатывание родительского контроля (политика для которого была изначально разработана с помощью средств пополнения баз данных 770), например, была обнаружена попытка зайти на сайт, где было обнаружены слова винтовка и оружие. Однако это может быть ситуация, когда ребенок попытался зайти на сайт детских игрушек, а там среди товаров могут быть найдены слова пластиковая винтовка, так и "игрушечное оружие". Если этот сайт находится в списке заблокированных (проверка на этапе 620), то в таком случае он будет заблокирован на этапе 630. Если сайта нет в подобном списке не обнаружено, то ребенок будет допущен на сайт на этапе 640, а данные по этому сайту будут отправлены на анализ на этапе 650 (т.е. это было ложное срабатывание, которое было обнаружено с помощью средства обработки ложных срабатываний 750). В результате анализа в политику родительского контроля будут внесены изменения (например, обновлено правило по блокировке слов винтовка и оружие) на этапе 660 с помощью средства исправления ложных срабатываний 760.

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

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

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

3. Система по п.1, в которой средством антивирусной защиты являются эмулятор и модуль проактивной защиты; модуль сигнатурной проверки; модуль контроля приложений; модуль родительского контроля.

4. Система по п.1, в которой средство обработки ложных срабатываний на стороне пользователя дополнительно собирает информацию из журнала событий средства антивирусной защиты на стороне пользователя, которая необходима средству исправления ложных срабатываний на стороне сервера.

5. Система по п.1, в которой средством пополнения текущих и тестовых записей в базе данных средства антивирусной защиты на стороне сервера являются средства обнаружения вредоносных программ в антивирусных лабораториях, а также люди-эксперты.

6. Система по п.1, в которой базы данных с текущими и тестовыми записями на стороне пользователя и сервера переписывают тестовые записи на место текущих, спустя заданный промежуток времени при отсутствии ложных срабатываний от средства обработки ложных срабатываний на стороне пользователя.