СИСТЕМА ДЛЯ АВТОМАТИЧЕСКОГО СОЗДАНИЯ СРЕДСТВ ПРОТИВОДЕЙСТВИЯ ОПРЕДЕЛЕННОМУ ТИПУ ВРЕДОНОСНЫХ ПРИЛОЖЕНИЙ

Область техники
Полезная модель относится к системам защиты от вредоносного программного обеспечения и, в частности, идентификации компонент вредоносного программного обеспечения. Она основана на автоматическом сборе статистических данных и лечении зараженных компьютерных систем.
Уровень техники
В настоящее время распространение вредоносного программного обеспечения (далее ПО) увеличивается, а вследствие этого увеличивается вред, который данное ПО приносит компьютерным системам. Существующие системы защиты персональных компьютеров, а также компьютеров в корпоративной сети основаны на обнаружении уже известных угроз. Однако новые угрозы появляются все чаще, и поэтому появляется необходимость в их методах распознавания. В связи с ростом коммуникационных сетей, таких как Интернет, постоянно увеличивается объем обмена данными, включая использование почтовых сообщений. Заражение компьютеров может происходить с помощью различных программ, таких как компьютерные вирусы или троянские программы.
События, связанные с почтовыми атаками, имеют большие последствия как для поставщиков интернет-услуг (ISP), так и для множества других компаний, что доказывает необходимость улучшения стратегий обнаружения вредоносных атак.
С одной стороны для обнаружения вредоносных программ достаточно давно применяются системы, использующие сигнатуры. Когда шаблоны кода, которые были получены из известных вредоносных программ, и подозреваемые объекты сканируются на наличие в коде данных шаблонов. Одним из недостатков систем обнаружения с использованием сигнатур является то, что таким образом могут быть обнаружены только известные вредоносные программы. Все вредоносные программы, которые не были идентифицированы ранее как вредоносные, а также вредоносные программы, созданные после обновления баз сигнатур, не будут распознаны данной системой.
Антивирусные компании продолжают обновлять базы сигнатур вредоносных программ, помимо этого также создавая и базы программного обеспечения проверенных или надежных программ (или их исполняемых файлов), так называемые "белые списки" (whitelist), которые становятся все более популярными в виду постоянного роста количества вредоносных программ. Подобные списки можно составлять исходя из многих факторов: наличия электронной цифровой подписи или иных данных производителя, данных об источнике (откуда программа была получена), данных о связях программы (отношения родитель-ребенок), данных о версии программы (например, программу можно считать проверенной, исходя из того, что прошлая версия также была в списке проверенных программ), данных о переменных окружения (операционная система, параметры запуска) и т.д.
Для обнаружения вредоносных программ используются системы проверки целостности информации, которые обычно создают длинные списки модифицированных файлов после обновлений операционной системы, когда устанавливается много обновлений программ. Основной недостаток систем проверки целостности заключается в том, что система реагирует на все изменения в программе, хотя эти изменения могут и не быть вредоносными. Также пользователю сложно решить, является ли то или иное изменение атакой на компьютерную систему.
Системы обнаружения с использованием контрольной суммы для поиска вредоносных программ создают значение циклического кода избыточности (CRC) для каждого программного файла. Модификации программного файла будут обнаружены, если изменится значение CRC. Системы наблюдения контрольной суммы вместе с применением систем проверки целостности улучшают устойчивость общей системы. Тем не менее, системы наблюдения контрольной суммы имеют те же недостатки, как и системы проверки целостности, связанные с большим количеством ложных предупреждений при малейших изменениях данных.
В случае заражения компьютера вредоносной программой предусмотрены частные персональные решения для каждого компьютера. Такое персональное решение строится на сервере антивирусной компании на основе служебной информации о зараженной системе, передаваемой компьютером пользователя на сервер. Представленное решение является индивидуальным и предназначено для решения конкретной проблемы, возникшей на компьютере пользователя. Такое создание решения на основе заранее известных шаблонов раскрывается в патенте US 7346928, где описывается система, состоящая из сервера, который получает запросы от множества клиентов на проверку файлов на вирусы. Существуют также системы, которые сначала создают сценарий исследования зараженного компьютера, и на основании исследования создается сценарий лечения. В патенте US 7093239 описывается система анализа компьютера, созданная для обнаружения вредоносного кода. Система создает и последовательно анализирует шаблон поведения для каждой программы, установленной на компьютере. Шаблон поведения создается с помощью виртуальной машины. В патенте US 7631357 описывается система обнаружения и/или удаления руткитов. Для обнаружения создается «снимок» компьютерной системы пользователя с помощью утилиты, установленной на компьютере пользователя. Однако, несмотря на то, что решение создается для определенной проблемы и учитывает все особенности проблемной ситуации, существуют и недостатки. Такие микро-решения могут использоваться пользователем многократно, потому что пользователь не всегда задумывается о том, что данное решение индивидуально и не подходит для решения других проблем, пусть и довольно схожих. Пользователи могут передавать данные решения другим пользователям, у которых появилась похожая, но не абсолютно идентичная, проблема. При написании индивидуальных решений используется роль эксперта службы технической поддержки и, соответственно, существует вероятность допущения ошибки экспертом. Написание таких решений занимает длительное время работы эксперта, т.к. они пишутся индивидуально для каждого компьютера.
Анализ предшествующего уровня техники и возможностей, которые появляются при комбинировании их в одной системе, позволяют получить новый результат, а именно: автоматически создавать средства противодействия определенному типу вредоносных программ.
Раскрытие полезной модели
Настоящая полезная модель предназначена для автоматического создания средства противодействия определенному типу вредоносных программ.
Техническим результатом является удаление компонент вредоносного программного обеспечения с помощью выбранного сценария лечения.
Согласно одному объекту заявленной полезной модели предоставляется система удаления компонент вредоносного программного обеспечения с помощью выбранного сценария лечения, которая содержит:
средство поддержки, предназначенное для получения и анализа журнала событий от компьютера пользователя и создания последовательности инструкций лечения компьютера пользователя, связанное со средством создания универсальных алгоритмов лечения, средством хранения инструкций, средством хранения шаблонов сценариев, средством верификации и средством выполнения сценария лечения;
упомянутое средство создания универсальных алгоритмов лечения, предназначенное для анализа журнала событий и последовательности инструкций, полученных от упомянутого средства поддержки, и создания сценария лечения компьютера пользователя, при этом средство создания универсальных алгоритмов лечения связано со средством верификации, средством хранения шаблонов сценариев и средством хранения инструкций;
упомянутое средство хранения инструкций предназначено для формирования сценариев лечения, а также для хранения набора определенных инструкций, необходимых для описания языка построения сценариев;
упомянутое средство хранения шаблонов сценариев предназначено для хранения универсальных шаблонов, на основе которых создаются сценарии лечения;
упомянутое средство верификации предназначено для проверки сценария лечения на предмет наличия ошибок;
упомянутое средство выполнения сценария лечения предназначено для исполнения сценария лечения для удаления компонент вредоносного программного обеспечения на компьютере пользователя.
В частном варианте реализации средство поддержки также предназначено для получения журнала событий от компьютера пользователя, в котором зафиксирован список событий на компьютере пользователя.
В частном варианте реализации средство создания универсальных алгоритмов лечения также предназначено для создания сценария лечения в виде последовательности инструкций на основе анализа журнала событий и последующего выбора шаблона сценария.
В частном варианте реализации средство выполнения сценария лечения также предназначено для сохранения сценария лечения в исполняемом файле.
В частном варианте реализации средство создания универсальных алгоритмов лечения также предназначено для сохранения созданных сценариев лечения.
В частном варианте реализации средство создания универсальных алгоритмов лечения также предназначено для передачи сценария лечения средству верификации на проверку сценария лечения на предмет наличия ошибок.
В частном варианте реализации средство верификации также предназначено для запрета выполнения сценария, если обнаружены ошибки, представляющие угрозу компьютеру пользователя, и передаче средству поддержки сценария лечения и отчета об исследованных ошибках.
В частном варианте реализации средство верификации также предназначено для разрешения выполнения сценария, если не обнаружены ошибки, представляющие угрозу компьютеру пользователя, и передаче средству поддержки сценария лечения.
В частном варианте реализации средство верификации также предназначено для синтаксической проверки сценария лечения и проверки на предмет опасных для компьютерной системы действий.
В частном варианте реализации средство создания универсальных алгоритмов лечения также предназначено для создания сценария лечения в текстовом формате.
Краткое описание чертежей
Дополнительные цели, признаки и преимущества настоящей полезной модели будут очевидными из прочтения последующего описания осуществления полезной модели со ссылкой на прилагаемые чертежи, на которых:
Фиг.1 показывает примерный вариант реализации системы удаления компонент вредоносного программного обеспечения с помощью выбранного сценария лечения.
Фиг.2 показывает примерный вариант реализации блок-схемы системы удаления компонент вредоносного программного обеспечения с помощью выбранного сценария лечения.
Фиг.3 показывает примерный вариант реализации блок-схемы передачи данных между средствами системы.
Фиг.4 показывает примерный вариант реализации связи в системе удаления компонент вредоносного программного обеспечения с помощью выбранного сценария лечения для реализации корпоративной сети.
Фиг.5 показывает примерный вариант реализации блок-схемы работы средства верификации.
Описание вариантов осуществления полезной модели
Далее будут описаны примерные варианты реализации настоящей полезной модели со ссылкой на сопровождающие чертежи. Объекты и признаки настоящей полезной модели станут очевидными посредством отсылки к примерным вариантам реализации. Настоящая полезная модель не ограничивается примерными вариантами реализации, раскрытыми ниже, она может воплощаться в различных видах. Сущность, определенная в описании, является ничем иным, как конкретными деталями, предоставленными для помощи специалисту в области техники в исчерпывающем понимании полезной модели, и настоящая полезная модель определяется только в объеме приложенной формулы.
Настоящая полезная модель используется в компьютерах общего назначения, например, обычных компьютерах или серверах. Такие компьютеры содержат процессор, системную память и системную шину, которая соединяет разные системные компоненты, включая системную память, с процессором. Системная шина может быть одним из нескольких типов шинной структуры, включая шину памяти или контроллер памяти, периферийной шиной и локальной шиной, использующей любую шинную архитектуру. Системная память включает в себя постоянную память (ROM) и оперативную память (RAM).
Базовая система ввода-вывода (BIOS) содержит основные программы, которые помогают передавать информацию между элементами компьютерной системы, и сохраняется в ROM. Компьютер может дополнительно содержать накопитель на жестком диске для чтения или записи на жесткий диск, накопитель на магнитных дисках для считывания с или записи на сменный магнитный диск, и накопитель на оптических дисках для чтения с или записи на сменный оптический диск, такой как CD-ROM, DVD-ROM или другие оптические носители.
Накопитель на жестком диске, накопитель на магнитных дисках и накопитель на оптических дисках также соединяются с системной шиной посредством интерфейса накопителя на жестком диске, интерфейса накопителя на магнитных дисках и интерфейса накопителя на оптических дисках соответственно. Накопители и связанные с ними машиночитаемые носители обеспечивают энергонезависимое хранение машиночитаемых команд, структур данных, программных модулей и других данных для компьютера.
Компьютер может также содержать магнитные кассеты, карты флэш-памяти, цифровые видеодиски, картриджи Бернулли, оперативную память (RAM), постоянную память (ROM) и другие виды памяти.
Ряд программных модулей может быть сохранен на жестком диске, магнитном диске, оптическом диске, ROM или RAM, включая операционную систему (например, Windows™ 2000). Компьютер включает в себя также файловую систему, связанную с/включенную в операционную систему, такую как Windows NT™ File System (NTFS), одну или более прикладных программ, другие программные модули и данные программ. Пользователь может вводить команды и информацию в компьютер с помощью устройств ввода/вывода, таких как клавиатура и указательное устройство (мышь).
Другие устройства ввода могут включать в себя микрофон, джойстик, игровой планшет, спутниковую антенну, сканер или т.п. Эти и другие устройства ввода/вывода соединены с процессором через интерфейс последовательного порта, который соединен с системной шиной. Следует отметить, что эти устройства могут соединяться с другими интерфейсами, такими как параллельный порт или универсальный последовательный порт (USB). Монитор или другой тип устройства отображения также соединяется с системной шиной через интерфейс, такой как видеоадаптер. Кроме того, компьютер может включать в себя другие периферийные устройства вывода, такие как динамики и принтеры.
Компьютер, в котором используются заявленные системы, работает в сетевой среде, использующей логические соединения с одним или более удаленными компьютерами. Удаленный компьютер (или компьютеры) могут быть другими компьютерами, серверами, маршрутизаторами, сетевыми PC, одноранговым устройством или другим общим сетевым узлом. Этот компьютер может быть подсоединен к локальной сети (LAN) или к глобальной сети (WAN), к сети в офисах, Интернету или Интранету.
Когда компьютер используется в сетевой среде LAN, компьютер соединяется с локальной сетью через сетевой интерфейс или адаптер. При применении в сетевой среде WAN, компьютер обычно включает в себя модем или другие средства для установления связи через глобальную сеть, такую как Интернет. Модем, который может быть внутренним или внешним, соединен с системной шиной через интерфейс последовательного порта.
Настоящая полезная модель описывает систему для автоматического создания средств противодействия определенному типу вредоносных программ.
Одно из направлений полезной модели - это система удаления компонент вредоносного программного обеспечения с помощью выбранного сценария лечения. В соответствии с примером осуществления сценарии лечения автоматически создаются на основе информации, полученной от зараженного вредоносной программой компьютера пользователя.
Для автоматического создания сценариев лечения используется система удаления компонент вредоносного программного обеспечения с помощью выбранного сценария лечения 100, изображенная на фиг.1. Представленная система 100 содержит компьютер пользователя 110, который передает средству поддержки 120 журнал событий, предназначенный для фиксирования списка событий на компьютере пользователя. Затем средство поддержки 120 на основе полученного журнала событий и с помощью средство хранения инструкций для формирования сценария лечения 135 создает последовательность инструкций для лечения компьютера пользователя 110. Методы формирования последовательности инструкций, в том числе и в виде сценариев, рассмотрены в таких патентах и заявках как ЕР0605166, JP 101493 01, JP2000222194, JP2001175481, KR20010076775. Средство хранения инструкций для формирования сценария лечения 135 содержит набор специальных инструкций, необходимых для описания языка построения сценариев. Далее средство поддержки передает средству создания универсальных алгоритмов лечения 130 последовательность инструкций и журнал событий, полученный от компьютера пользователя 110. Универсальность средства 130 заключается в том, что оно составляет решения для разных видов индивидуальных проблем автоматически. Средство создания универсальных алгоритмов лечения 130 на основе полученных данных выбирает шаблон сценария лечения из сценариев в средстве хранения шаблонов сценариев 145 и создает сценарий лечения. Анализ журнала событий может быть реализован в виде одного из способов, описанных в таких патентах и заявках как US5121475, JP3034038, JP7182210, US2003040889. Средство хранения шаблонов сценариев 145 содержит шаблоны, предназначенные для создания сценариев лечения для компьютера и представляющие собой шаблоны для решения типовых проблем. Шаблоны для решения типовых проблем могут быть сохранены в базе данных, такой как MySQL, DB2, PostgreSQL, SQLite. Созданный сценарий отправляется на проверку средству верификации 150. Средство верификации 150 проверяет сценарий лечения на наличие синтаксических ошибок (инструкции) и логических ошибок (последовательность инструкций) для того, чтобы выполнение сценария лечения на компьютере пользователя 110 не нанесло ему вреда. Также средство верификации 150 проверяет, не было ли в сценарии лечения удаления важных файлов. Например, если сценарий лечения удаляет файл «Explorer.exe», то средство верификации с большой вероятностью сочтет сценарий лечения ошибочным. Способы верификации (проверки) описаны в таких заявках и патентах как US2004044992, US2003028830, JP61023250, JP4151743, JP7283847. В случае, если проверка проходит успешно, то средство верификации 150 возвращает сценарий лечения средству создания универсальных алгоритмов лечения 130. Средство поддержки 120 может повлиять на работу средства хранения шаблонов сценариев 145 и на средство верификации 150, например, исправить или дополнить. Если средством 120 исправляется сценарий лечения, то оно отправляет исправленный сценарий лечения средству верификации 150. Если сценарий лечения содержит действия, способные причинить вред компьютерной системе, то средство верификации 150 добавляет этот случай в условия проверки и возвращает сценарий лечения и отчет об ошибке средству создания универсальных алгоритмов лечения 130. Средство создания универсальных алгоритмов лечения 130 исправляет сценарий лечения на основе отчета от средства верификации 130. В частном варианте реализации, а именно при невозможности автоматического исправления, сценарий лечения может быть исправлен экспертом 125. В случае создания успешного сценария лечения средство создания универсальных алгоритмов лечения 130 создает уникальное решение для компьютера в виде единственного исполняемого файла. Затем исполняемый файл передается средству поддержки, а через него средству выполнения сценария лечения на компьютере пользователя. Выполнение сценариев раскрывается в таких патентах как US5715386, JP9167085, JP9305381, US5754760, US6275868, US6332217. Преимущество сохранения сценария лечения в исполняемом файле заключается в том, что пользователь не сможет просмотреть или изменить сценарий лечения. Для защиты от пользователя существует возможность после исполнения непосредственно сценария лечения включить «самоуничтожение файла» или «блокировку». Таким образом, если в сценарий включено самоуничтожение файла, то средство выполнения сценария лечения сработает на компьютере пользователя только один раз. Если же включена блокировка, то средство выполнения сценария лечения будет выполняться только на том компьютере, для которого оно создавалось. Для реализации блокировки средства выполнения сценария лечения компьютеру 110 присваивается уникальный идентификатор, который формируется на основе данных о компьютере: серийного номера его диска, версии операционной системы, и т.д.
Представленная система является решением для лечения компьютера от характерных проблем. Фиг.2 иллюстрирует примерный алгоритм работы настоящей системы. На ней изображено создание и использование сценария лечения, который является одноразовым. При возникновении какой-либо проблемы на компьютере пользователя, связанной с вредоносным ПО, недостаточно выполнить только удаление вируса, т.к. остаются следы вируса, которые антивирусное приложение не в состоянии удалить. Поэтому пользователь отправляет журналы событий зараженной компьютерной системы службе поддержки на шаге 210. В этой ситуации средство поддержки должно создать последовательность инструкций на основе журнала событий на шаге 215, которая затем на шаге 220 передается средству создания универсальных алгоритмов лечения 130. Для формирования сценария лечения используются данные от средства хранения инструкция для формирования сценариев лечения 135. Сценарий лечения зашифровывается на шаге 225. На основе сценария с помощью шаблона сценариев от средства хранения шаблонов сценариев 145 средство создания универсальных алгоритмов лечения 130 создает исполняемый файл для решения этой характерной проблемы на шаге 230. Исполняемый файл строится всегда с разными антивирусными сигнатурами (т.е. у него нет статических сигнатур), что позволяет скрыть от внимания вредоносных программ такую сборку сценариев лечения, и они не могут заблокировать запуск представленного исполняемого файла. На шаге 235 средство создания универсальных алгоритмов лечения 130 отсылает файл пользователю. На шаге 240 пользователь запускает файл на зараженном компьютере. При этом вирус не может определить, что это приложение предназначено для лечения компьютерной системы, т.к. оно не устанавливается в папке антивирусного приложения, не содержит никаких идентификаторов антивирусного приложения (таких как имя антивирусного приложения в названии файла, или информации о создателе файла), не сохраняет дочерние файлы на диске. После завершения работы файла исследования собираются журналы событий и файла, которые затем на шаге 245 отправляются в службу поддержки без участия пользователя. Служба поддержки получает файлы от пользователя на шаге 250 и сохраняет их для дальнейшего исследования. После этого выполнение может продолжиться, начиная с шага 210.
Система удаления компонент вредоносного программного обеспечения с помощью выбранного сценария лечения, изображенная на фиг.3, является также инструментом портативной диагностики, работающим без участия пользователя. Прежде всего, создается пользовательский журнал событий на шаге 310, который затем отправляется службе поддержки на шаге 320. На основе журнала пишется сценарий исследования на шаге 330, который анализирует состояние компьютерной системы, для которой необходимо лечение. Сценарий исследования отправляется на компьютер пользователя на шаге 340. На шаге 350 выдаются данные от исполнения сценария исследования. На основании этих данных делается вывод о состоянии компьютера, на шаге 360, который затем предоставляется пользователю. Сценарий исследования является типовым и может практически не изменяться (изменяется только в случае изменения операционных систем, возникновения новых архитектурных решений, и т.д.). Подобные сценарии исследования могут также создаваться для автоматического карантина и сбора потенциально вредоносных шаблонов программ, очищения компьютерной системы от следов поведения вредоносных программ.
Представленный вариант реализации системы удаления компонент вредоносного программного обеспечения с помощью выбранного сценария лечения может быть использован при создании решения для администрирования корпоративных сетей, изображен на фиг.4. В состав антивирусной программы, установленной на компьютере средства администрирования 420 корпоративной сети 410, включается компонента, позволяющая организовывать и контролировать защиту в корпоративной сети 410. Для централизованной проверки компьютеров сети средство администрирования 420 отправляет запрос заранее предустановленным на компьютерах пользователей сетевым агентам 425 исполняемый файл 430, содержащий сценарий исследования, в виде задания. В свою очередь сетевой агент запускает этот файл и возвращает данные 440 средству администрирования (например, по электронной почте). Данный вариант реализации может применяться для массового обследования компьютеров в корпоративной сети 410. Плюсами такого применения являются работа сценария исследования без предварительной установки, наличие единственного исполняемого файла, и т.д.
Представленная система создает инструмент для всего процесса лечения на пользовательской компьютерной системе. На компьютере пользователя запускается единственный исполняемый файл. При этом исполняемый файл может находиться где угодно, т.е. как непосредственно на компьютере пользователя, так и запускаться с веб-страницы или из почтового сообщения.
Для того, чтобы защитить сценарий лечения от запуска на других компьютерах, существует возможность установления связи исполняемого файла с конкретным компьютером, для лечения которого предназначен исполняемый файл. Данный сценарий лечения после привязки к определенному компьютеру не запустится на других компьютерах и не сможет нанести вред другим компьютерным системам. Также представленный исполняемый файл со сценарием лечения может самоуничтожаться, или не допускать запуск два или более раза.
Система также содержит средство верификации, предназначенное для проверки сценария лечения на предмет синтаксической корректности и на предмет опасных для компьютерной системы логических ошибок. Блок-схема процесса верификации изображена на фиг.5. После того, как средство поддержки создает сценарий лечения, он отправляет его на проверку средству верификации на шаге 510. На шаге 520 средство верификации пропускает сценарий через набор синтаксических проверок. В случае, если на шаге 530 ошибки не обнаружены, то средство верификации проверяет сценарий пошагово на опасность для системы на шаге 540. Если на шаге 550 выявлены опасные операции, то средство верификации шифрует файл исследования на шаге 560. Затем на шаге 570 средство верификации разрешает выполнение сценария. Если на шаге 530 или на шаге 550 обнаружены опасные операции или ошибки, то средство верификации запрещает выполнение сценария лечения на шаге 535. Затем на шаге 545 средство верификации сохраняет условия, при которых возникает ошибка. На шаге 555 средство верификации отправляет сценарий средству создания универсальных алгоритмов лечения с отчетом об исследовании на наличие ошибок. На шаге 580 средство верификации завершает работу.
В заключение следует отметить, что приведенные в описании сведения являются только примерами, которые не ограничивают объем настоящей полезной модели, определенной формулой. Специалисту в данной области становится понятным, что могут существовать и другие варианты осуществления настоящей полезной модели, согласующиеся с сущностью и объемом настоящей полезной модели.