СИСТЕМА И СПОСОБ ЗАЩИТЫ ОТ НЕЛЕГАЛЬНОГО ИСПОЛЬЗОВАНИЯ ОБЛАЧНЫХ ИНФРАСТРУКТУР
SYSTEM AND METHOD OF PROTECTING CLOUD INFRASTRUCTURE FROM ILLEGAL USE

Область техники
Изобретение относится к компьютерным системам и более конкретно к системам и способам обнаружения подложной информации, передаваемой злоумышленниками в облачные сервисы сбора данных от пользователей.
Уровень техники
В современном обществе компьютерные информационные системы играют важную роль. Вместе с тем в настоящее время наблюдается резкое увеличение количества компьютерных угроз, к числу которых могут относиться различные вредоносные приложения (например, сетевые черви, компьютерные вирусы, троянские программы), а также атаки со стороны злоумышленников.
Традиционный сигнатурный метод обнаружения вредоносного программного обеспечения (ПО) основан на создании уникальных сигнатур кода или шаблонов поведений с последующим сравнением с ними подозрительного ПО. Однако информация о новой вредоносной программе обычно поступает в антивирусную компанию с задержкой. Обновления, содержащие сигнатуры новых угроз, отправляются на компьютеры пользователей антивирусных продуктов также спустя большой интервал времени. В итоге с момента появления нового вредоносного ПО до получения пользователями обновления баз сигнатур вредоносных программ проходит значительное время, за которое может быть заражено большое количество ПК.
К традиционным методам обнаружения вредоносного ПО также относятся эвристические методы, основанные на анализе кода программы и эмуляции ее исполняемых команд. Такие методы, в отличие от сигнатурных, подходят для обнаружения нового вредоносного ПО. Вместе с тем эвристические методы имеют недостаточный уровень обнаружения и допускают большое количество ложных срабатываний, иногда принимая легальное ПО за вредоносное.
По этим причинам широкое распространение получили средства защиты компьютерных систем, использующие облачные репутационные сервисы, например Kaspersky Security Network (KSN), которые превосходят традиционные подходы по скорости реакции и уровню обнаружения новых вредоносных программ. Обычно используется несколько репутационных сервисов, которые находятся на одном и более удаленных серверах антивирусной компании (далее для ясности удаленный сервер будет упоминаться как облачная инфраструктура). Такие сервисы основаны на автоматическом сборе и обработке поступающей от пользователей информации обо всех попытках заражения, а также о неизвестных подозрительных файлах, которые загружаются и исполняются на компьютерах пользователей. Использование облачных репутационных сервисов позволяет антивирусной компании быстро реагировать на новые угрозы, уменьшать количество ложных срабатываний. После получения собранная от пользователей информация агрегируется и анализируется в репутационном сервисе антивирусной компании. Решение о безопасности или вредоносности ПО выносится на основе множества факторов, как это описано, например, в патенте US 7640589. Такими факторами могут быть: наличие цифровой подписи; время создания и время первого обнаружения программы; репутация программы, основанная на количестве пользователей репутационного сервиса, которые ее используют; география использования. Программа может быть дополнительно исследована традиционными методами обнаружения, используя мощности антивирусной компании, а также может быть предоставлена для анализа вирусным аналитикам. Полученное решение о вредоносности или безопасности программы в дальнейшем предоставляется всем пользователям репутационного сервиса, которые запускают эту программу на своих компьютерах или загружают ее из сети.
Несмотря на высокий уровень обнаружения репутационных сервисов, существуют возможности их дискредитации вредоносными программами и злоумышленниками. Злоумышленник, зная протокол передачи информации в репутационный сервис, может предоставлять туда ложную информацию. Например, перед размещением в сети новой вредоносной программы он может с большого количества компьютеров отправить в репутационный сервис данные, на основании которых будет вынесено решение о безопасности программы. В итоге, когда вредоносная программа будет выложена в сеть, антивирусные продукты пользователей признают ее безопасной.
Для решения этой проблемы применяются различные технологии. Например, в заявках US 20090328209, US 20090282476 описывается репутационный сервис, осуществляющий сбор данных только от доверенных пользователей. Степень доверия пользователю рассчитывается на основании различной информации о пользователе, например о файлах, находящихся в системе, а также о скачиваемых, устанавливаемых и исполняемых пользователем файлах, посещенных веб-сайтах и обнаруженных вредоносных программах на персональном компьютере (ПК) пользователя. Информация о новых вредоносных файлах, полученная от пользователей со слабой степенью доверия, тоже принимается во внимание, однако с меньшим доверием.
В патенте US 8060577 описывается система защиты, которая собирает мнения пользователей о степени вредоносности новых, еще неизвестных или неклассифицированных объектов. На основании мнения некоторого количества пользователей выносится вердикт о степени опасности этих объектов. Для большей достоверности результата для каждого пользователя рассчитывается показатель надежности, основанный на точности предоставляемых пользователем данных. Мнение пользователей с низкими показателями надежности также учитываются, однако противоположным образом. Если такой пользователь считает какое-либо новое ПО вредоносным, то система защиты учтет мнение пользователя как если бы он ответил, что это ПО является безопасным, и наоборот.
В заявке US 20110067086 описывается способ обнаружения ложных запросов и подложной информации, поступающей в репутационные центры от пользователей репутационных сервисов. При регистрации на репутационном сервисе на ПК клиента отправляется подписанный цифровой подписью токен, содержащий метаданные, такие как IP-адрес, используемое устройство клиента и т.п. При каждом последующем обращении клиента в репутационный сервис помимо информации о новой угрозе пользователь отправляет текущие метаданные и полученный при регистрации токен. В случае если токен поврежден, подделан или если текущие метаданные существенно отличаются от метаданных, полученных из токена, то запросы от этого клиента могут полностью или частично игнорироваться, так как токен, скорее всего, был украден или потерян пользователем и используется нелегально. Недостатком данного способа является большая нагрузка на репутационный сервис, вызванная вычислительной сложностью проверки цифровой подписи токена при каждом обращении клиентов.
Однако существующие решения имеют ряд недостатков. Например, технологии, рассчитывающие рейтинг пользователей, можно обойти. Если злоумышленник будет предварительно предоставлять в репутационные сервисы корректную информацию об угрозах, он в итоге станет доверенным пользователем. После этого злоумышленник может запустить в сеть новую угрозу под видом легальной программы, которую репутационный сервис посчитает безопасной. Несмотря на то, что через некоторое время это событие обнаружится, и злоумышленник станет недоверенным пользователем, угроза успеет распространиться, а злоумышленник заведет себе новый аккаунт пользователя репутационного сервиса. Технология, предоставляющая пользователю токен, содержащий метаданные о пользовательском устройстве, также имеет недостатки. Так, информация, предоставляемая пользователем в репутационный сервис для получения токена, может быть подделана. Более того, токен может быть украден с компьютера легитимного пользователя и использоваться злоумышленниками.
Анализ предшествующего уровня техники позволяет сделать вывод о неэффективности и в некоторых случаях о невозможности применения предшествующих технологий, недостатки которых решаются настоящим изобретением, а именно системой и способом обнаружения подложной информации, передаваемой злоумышленниками в облачные сервисы сбора статистических данных от пользователей.
Раскрытие изобретения
Настоящее изобретение относится к системам и способам обнаружения подложной информации, передаваемой злоумышленниками в облачные сервисы сбора данных от пользователей.
Технический результат настоящего изобретения заключается в уменьшении количества запросов, поступающих с компьютерного устройства на удаленный сервер, что достигается за счет обработки этих запросов в зависимости от уровня доверия пользователей.
Согласно одному из вариантов реализации используется система обработки запросов, поступающих с компьютерного устройства на удаленный сервер, в зависимости от уровня доверия пользователей, содержащая: по крайней мере одно компьютерное устройство пользователя, содержащее средство защиты, которое, в свою очередь, служит для защиты упомянутого компьютерного устройства пользователя от вредоносных программ, путем отправки запросов на проверку объектов упомянутого компьютерного устройства к средству обработки запросов; удаленный сервер, служащий для обработки поступающих от упомянутого средства защиты запросов и предоставления ответов на запросы упомянутому средству защиты, в свою очередь содержащий: упомянутое средство обработки запросов, связанное со средством принятия решений и со средством проверки системы, служащее для предоставления ответов по крайней мере одному средству защиты в зависимости от решения об обработке запросов, полученного от упомянутого средства принятия решений; средство проверки системы, связанное со средством обработки запросов, предназначенное для определения уровня доверия средства защиты, а также обновления уровня доверия в зависимости от обработанных запросов от средства защиты; упомянутое средство принятия решений, связанное со средством проверки системы компьютерного устройства легитимного пользователя, служащее для: принятия решения об обработке запросов от средства защиты на основании уровня доверия упомянутого средства защиты; предоставления средству обработки запросов принятого решения об обработке запросов от по крайней мере одного средства защиты.
Согласно одному из частных вариантов реализации система обработки запросов, поступающих с компьютерного устройства на удаленный сервер, в зависимости от уровня доверия пользователей дополнительно содержит антивирусную базу данных, связанную со средством обработки запросов, предназначенную для формирования ответов по крайней мере одному средству защиты в зависимости от принятого решения об обработке запросов на объекты, а также для хранения по крайней мере одного из: файловой репутации, содержащей по крайней мере один из следующих параметров об объектах, являющихся файлами: время/дата первого появления объекта в упомянутой антивирусной базе; количество пользователей, которые доверяют упомянутому объекту; распространение объекта по странам/регионам; списков легитимных приложений, содержащий по крайней мере список доверенных объектов, являющихся приложениями; настройки анти-спам фильтров для фильтрации объектов, являющихся электронными письмами.
Согласно другому частному варианту реализации средство обработки запросов дополнительно служит для фильтрации запросов от по крайней мере одного средства защиты в зависимости от упомянутого решения об обработке запросов;
Согласно еще одному частному варианту реализации средство проверки системы определяет уровень доверия средства защиты на основании по крайней мере одного критерия: исполнение процессов и служб на компьютерном устройстве, характерных для установленной и настроенной пользователями операционной системы; периодические перезагрузки операционной системы; установка/удаление приложений; исполнение приложений; переход по интернет-адресам в веб-браузере; периодические обновления операционной системы, установленных приложений, средства защиты; нажатие пользователем кнопок на клавиатуре и мыши; передвижение мыши; отслеживание с помощью веб-камеры передвижения пользователя.
Согласно одному из частных вариантов реализации система обработки запросов, поступающих с компьютерного устройства на удаленный сервер, в зависимости от уровня доверия пользователей дополнительно содержит средство хранения уникального идентификатора, связанное со средством обработки запросов, а также со средством проверки системы, предназначенное для создания уникального идентификатора для упомянутого средства защиты пользователя, при этом упомянутый уникальный идентификатор служит идентификации средства защиты для предотвращения нелегального использования копий упомянутого средства защиты.
Согласно другому частному варианту реализации удаленный сервер дополнительно включает средство проверки порядка следования запросов, служащее для проверки правильности порядка следования запросов к средству обработки запросов от по крайней мере одного средства защиты.
Согласно еще одному частному варианту реализации средство проверки порядка следования запросов предоставляет запросы одному или более сервису, который является по крайней мере одним из: сервис файловой репутации, содержащий по крайней мере один из следующих параметров об объектах, являющихся файлами: время/дата первого появления объекта в упомянутой антивирусной базе; количество пользователей, которые доверяют упомянутому объекту; распространение объекта по странам/регионам; сервис списков легитимных приложений, содержащий, по крайней мере, список доверенных объектов, являющихся приложениями; сервис анти-спам фильтров для фильтрации объектов, являющихся электронными письмами.
Согласно одному из частных вариантов реализации удаленный сервер дополнительно включает средство проверки изменения конфигурации системы, связанное со средством проверки системы, а также со средством принятия решений, служащее для проверки изменения конфигурации упомянутого компьютерного устройства пользователя.
Согласно другому частному варианту реализации удаленный сервер дополнительно включает средство проверки изменения местонахождения системы, связанное со средством проверки системы, а также со средством принятия решений, служащее для проверки изменения и частоты изменения местонахождения упомянутого компьютерного устройства пользователя.
Согласно варианту реализации используется способ обработки запросов, поступающих с компьютерного устройства на удаленный сервер, в зависимости от уровня доверия пользователей, в котором: отправляют запросы от средства защиты к средству обработки запросов; анализируют запросы, поступающие к средству обработки запросов с помощью средства проверки системы в зависимости от текущего уровня доверия упомянутого средства защиты; обновляют уровень доверия в зависимости от анализа упомянутых запросов; принимают решение об обработке запросов в зависимости от обновленного уровня доверия; предоставляют ответы по крайней мере одному средству защиты в зависимости от принятого решения об обработке запросов.
Согласно одному из частных вариантов реализации дополнительно фильтруют последующие запросы от по крайней мере одного средства защиты в зависимости от упомянутого решения об обработке запросов.
Согласно другому частному варианту реализации текущий уровень доверия определяют при поступлении первого запроса от упомянутого средства защиты к средству обработки запросов.
Согласно еще одному частному варианту реализации создают уникальный идентификатор средства защиты при поступлении первого запроса от упомянутого средства защиты к средству обработки запросов.
Согласно одному из частных вариантов реализации в зависимости от уровня доверия дополнительно совершают или отменяют по крайней мере одно из следующих действий: обрабатывают данные, содержащиеся в запросах; предоставляют обновления средства защиты на компьютерное устройство; предоставляют ответ средству защиты, содержащий информацию об объекте на основе файловой репутации; предоставляют ответ средству защиты, содержащий информацию об объекте на основе списков легитимных приложений; предоставляют ответ средству защиты, содержащий информацию об объекте на основе анти-спам фильтров.
Согласно другому частному варианту реализации анализ запросов включает по крайней мере одно из следующих событий: исполнение процессов на компьютерном устройстве; обновления программного обеспечения, установленного на компьютерном устройстве; нажатие кнопок на клавиатуре и мыши; передвижение мыши; передвижение пользователя, отслеживаемое с помощью веб-камеры; количество правильно обнаруженных компьютеров злоумышленников; количество ложных срабатываний.
Согласно еще одному частному варианту реализации анализ запросов осуществляют с помощью проверки порядка следования запросов к одному или более сервисам, который является: сервисом файловой репутации, содержащим по крайней мере один из следующих параметров об объектах, являющихся файлами: время/дата первого появления объекта в упомянутой антивирусной базе; количество пользователей, которые доверяют упомянутому объекту; распространение объекта по странам/регионам; сервисом списков легитимных приложений, содержащим, по крайней мере, список доверенных объектов, являющихся приложениями; сервисом анти-спам фильтров для фильтрации объектов, являющихся электронными письмами.
Согласно одному из частных вариантов реализации при несоблюдении средством защиты заранее определенных удаленным сервером правил порядка следования запросов текущий уровень доверия обновляют на более низкий уровень доверия.
Согласно другому частному варианту реализации порядок следования запросов определяют с помощью разности в инкриминирующем индексе запроса средства защиты, при этом упомянутый инкриминирующий индекс увеличивают для каждого последующего запроса от упомянутого средства защиты.
Согласно еще одному частному варианту реализации порядок следования запросов определяют с помощью таблицы запросов средства защиты, содержащей, по крайней мере: уникальный идентификатор компьютерного устройства, упомянутое средство защиты которого отправило запрос средству обработки запросов; время получения запроса упомянутым средством обработки запросов; идентификатор сервиса, которому был предназначен запрос.
Согласно одному из частных вариантов реализации анализ запросов осуществляют с помощью проверки изменения конфигурации оборудования компьютерного устройства, в которой обновляют уровень доверия, если конфигурация оборудования изменилась некоторое количество раз в течение некоторого периода времени.
Согласно другому частному варианту реализации анализ запросов осуществляют с помощью проверки изменения местонахождения системы, в которой обновляют уровень доверия, если в течение определенного периода времени, IP-адрес компьютерного устройства изменялся больше, чем некоторое заданное количество раз.
Согласно еще одному частному варианту реализации для по крайней мере одного уникального идентификатора создают таблицу, содержащую по крайней мере одно из следующих полей: количество различных IP-адресов, с которых приходили запросы с упомянутым уникальным идентификатором; адрес подсети/доменной зоны/номер автономной системы/регион.
Согласно одному из частных вариантов реализации обновляют уровень доверия, если за некоторый период времени запросы для упомянутого уникального идентификатора приходили с разных подсетей/доменных зон/государств/автономных систем.
Согласно другому частному варианту реализации обновляют уровень доверия, если запросы для упомянутого уникального идентификатора приходили с IP-адресов, не входящих в заранее определенный диапазон IP-адресов для упомянутого уникального идентификатора.
Согласно еще одному частному варианту реализации анализ запросов осуществляют с помощью проверки тиражирования уникальных идентификаторов, в котором: в запросы от средств защиты помещают зашифрованный уникальный идентификатор, а также помещают хэш-сумму от тела запроса; в удаленном сервере расшифровывают уникальный идентификатор, от тела запроса рассчитывают хэш-сумму и сравнивают с хэш-суммой, полученной вместе с запросом, и, если упомянутые хэш-сумма от тела запроса и рассчитанная хэш-сумма не совпадают, обновляют уровень доверия.
Краткое описание чертежей
Дополнительные цели, признаки и преимущества настоящего изобретения будут очевидными из прочтения последующего описания реализации изобретения со ссылкой на прилагаемые чертежи, на которых:
На Фиг.1 приведена упрощенная схема построения настоящей системы.
На Фиг.1А приведен частный вариант схемы построения системы.
На Фиг.2 приведена высокоуровневая блок-схема, включающая этапы работы настоящего изобретения.
На Фиг.3 приведена схема выполнения этапа «А», присутствующего на Фиг.2.
Фиг.4 представляет пример компьютерной системы общего назначения, персональный компьютер или сервер.
Описание вариантов реализации изобретения
Объекты и признаки настоящего изобретения, способы для достижения этих объектов и признаков станут очевидными посредством отсылки к примерным вариантам реализации. Однако настоящее изобретение не ограничивается примерными вариантами реализации, раскрытыми ниже, оно может воплощаться в различных видах. Сущность, приведенная в описании, является ничем иным, как конкретными деталями, необходимыми для помощи специалисту в области техники в исчерпывающем понимании изобретения, и настоящее изобретение определяется в объеме приложенной формулы.
На Фиг.1 приведена упрощенная схема построения системы, которая реализует настоящее изобретение. Система включает облачную инфраструктуру антивирусной компании (удаленный сервер) 130, которая состоит из облачных репутационных сервисов 140-150; множество устройств легальных пользователей антивирусного ПО 120 (например, таких устройств, как ПК, ноутбук, смартфон, планшетный ПК, почтовый сервер). В систему могут входить один или несколько компьютеров злоумышленников ПО. Примером облачной инфраструктуры 130 может служить Kaspersky Security Network (KSN). Система позволяет осуществлять автоматизированный сбор и отправку в KSN информации обо всех попытках заражений, а также обо всех неизвестных подозрительных объектах (например, о файлах и приложениях), исполняемых на устройствах пользователей 120 и загружаемых с веб-сайтов или в пиринговых сетях, получаемых во вложениях электронных писем и т.д., как это, например, описано в заявке US 20110083180.
Облачными сервисами 140-150 могут быть: сервис файловой репутации, сервис статистики, сервис репутации интернет-адресов, сервис белых списков, сервис активации, сервис анти-спама. Сервис файловой репутации предоставляет пользователю информацию об объектах, являющихся файлами, такую как, например: содержится ли файл в базе вредоносных файлов сервиса; время первого появления файла у пользователей антивирусного ПО; количество пользователей, которые доверяют данному файлу; распространение файла по странам/регионам. Сервис белых списков содержит список объектов (например, файлы, интернет-адреса), не являющихся вредоносными, и по запросу антивирусного ПО проверяет запрашиваемый объект по этим спискам. Сервис статистики содержит метаинформацию об исполняемых/скачиваемых пользователями файлах, которая может использоваться для вынесения вердикта по файлу, коррекции белых списков, уменьшения числа ложных срабатываний. Сервис репутации предоставляет пользователю информацию об объектах, являющихся интернет-адресами, такую как, например: наличие вредоносного содержимого на интернет-странице, такого как ссылки на вредоносные файлы; популярность посещения пользователями. Сервис активации служит для активации лицензии антивирусного ПО пользователя, а также для продления ее срока действия. Сервис анти-спама служит для улучшения качества проверки писем на предмет содержания спама, например, проверяя по своей базе отправителей и в анти-спам фильтрах письма, адресованные пользователю антивирусного ПО. Сервисы 140-150 могут находиться как на одном сервере, так и на разных серверах. В одном примере реализации данные сервисов 140-150 могут храниться в антивирусной базе данных 138, которая будет описана ниже.
На Фиг.1А приведен частный вариант схемы построения системы. Устройство пользователя 120 включает средство защиты 121 (например, антивирусное программное обеспечение, аппаратный антивирус. Далее для простоты используется термин антивирусное ПО), необходимое для защиты устройства пользователя от вредоносных программ путем отправки запросов к средству обработки запросов 131 облачной инфраструктуры (удаленным сервером) 130. Средство обработки запросов 131 предназначено для предоставления ответов средству защиты 121 в зависимости от решения об обработке запросов, полученного от средства принятия решений 137. В одном примере реализации облачная инфраструктура 130 может включать средство хранения уникального идентификатора (для ясности далее будет упоминаться как средство активации) 132, служащее для создания и хранения уникального идентификатора для средства защиты 121 устройства пользователя 120 (как для легитимных пользователей, так и для злоумышленников).
Облачная инфраструктура включает средство проверки системы 133 в зависимости от критериев, предъявляемых к устройству легитимного пользователя антивирусного ПО 120 и предназначенное для определения уровня доверия средства защиты 121, а также обновления уровня доверия в зависимости от обработанных от него запросов. Облачная инфраструктура также включает средство принятия решений 137, которое служит для принятия решения об обработке запросов от средства защиты 121 на основании определенного уровня доверия, а также для предоставления средству обработки запросов 131 принятого решения.
В одном примере реализации облачная инфраструктура 130 может дополнительно включать средство проверки порядка следования запросов 134 (для ясности далее будет упоминаться как средство проверки порядка обращения к сервисам), средство проверки изменения конфигурации системы 135 и средство проверки изменения местоположения системы 136. Упомянутые выше средства проверки служат для определения легитимности пользователей и будут подробно описаны ниже.
В другом примере реализации облачная инфраструктура 130 дополнительно содержит антивирусную базу данных 138, предназначенную для: формирования ответов средству защиты 121 в зависимости от уровня доверия, определенного средством принятия решений 137; хранения данных облачных сервисов 140-150. Стоит отметить, что облачная инфраструктура 130 состоит из облачных сервисов 140-150, которые могут располагаться на одном или нескольких серверах.
На Фиг.2 приведена высокоуровневая блок-схема, включающая этапы работы настоящего изобретения. В одном примере реализации регистрация/активация антивирусного ПО, установленного на устройстве пользователя 120, происходит на этапе 200 с помощью средства активации 132. В частном примере реализации средство активации 132 может находиться в составе сервиса активации, который является одним из облачных сервисов 140-150.
При активации в одном примере реализации для антивирусного ПО пользователя устройства 120 (в том числе и для злоумышленников) средство активации 132 присваивает уникальный идентификатор (ID); для действительного кода активации антивирусного ПО (уникальный набор символов, служащий для активации лицензии антивирусного ПО) создается ключ активации (файл, содержащий данные, необходимые для работы антивирусного ПО, и информацию о периоде действия ключа (например, 30 дней)).
В другом примере реализации уникальный идентификатор для антивирусного ПО 121 пользователя устройства 120 создается при первом обращении антивирусного ПО в один из облачных сервисов 140-150. В одном примере реализации ID может совпадать с кодом активации. В другом примере реализации ID может быть подписан электронно-цифровой подписью облачной инфраструктуры 130. Ключ активации отправляется на устройство пользователя 120 с помощью средства обработки запросов 131, и по истечении срока действия средство активации 132 создает новый ключ активации, если у пользователя устройства 120 не закончилась подписка на антивирусное ПО.
В одном примере реализации на шаге 210 созданному ID средство принятия решений 137 присваивает текущий уровень доверия «недоверенный». Запросы, поступающие в облачную инфраструктуру 130 с устройств 120, имеющих уникальный идентификатор ID, будут анализироваться и фильтроваться в зависимости от уровня доверия средством обработки запросов 131. В одном примере реализации на запросы, приходящие с недоверенного ID, средство обработки запросов 131 может не предоставлять ответы от одного или нескольких репутационных сервисов 140-150. В другом примере реализации на запросы, приходящие с недоверенного ID, могут предоставляться ответы от одного или нескольких репутационных сервисов 140-150, а данные, полученные с этого ID (например, вердикты об объектах, статистика запуска объекта), могут не анализироваться и не обрабатываться облачной инфраструктурой при принятии решений о вредоносности проверяемых объектов и изменении статистики и репутации объектов.
В одном примере реализации уникальный идентификатор ID создается с использованием серийного номера жесткого диска (например, CRC-суммы от серийного номера жесткого диска), МАС-адреса или прочих уникальных идентификаторов составных частей устройства 120. В другом примере реализации ID создается на основании кода или ключа активации антивирусного ПО. В другом примере реализации в ID содержится информация о типе устройства (например, ПК, смартфон). На шаге 220 антивирусное ПО производит проверку устройства 120 на соответствие критериям, предъявляемым к устройству легитимного пользователя антивирусного ПО 120. Результаты данной проверки далее используются средством проверки системы 133 для определения уровня доверия антивирусного ПО 120.
В одном примере реализации, когда устройство 120 является компьютером, ноутбуком, смартфоном или планшетным ПК, за которым работает пользователь, такими критериями могут быть: выполнение на ПК 120 процессов и служб, характерных для установленной и настроенной пользователями операционной системы (ОС); периодические перезагрузки ОС; установка/удаление новых программ на ПК; исполнение программ; переход по интернет-адресам в веб-браузере; периодическое обновление ОС, установленных приложений и антивирусного ПО; нажатие пользователем кнопок на клавиатуре и мыши, а также передвижение мыши; отслеживание с помощью веб-камеры передвижения пользователя; а также прочие действия, являющиеся характерными для пользователей, работающих за ПК. Например, на ОС семейства Windows легитимные пользователи обычно устанавливают стандартный набор программ (например, Google Chrome, Adobe Reader), вследствие чего в ОС работают соответствующие службы (например, Google Updater Service, Adobe Acrobat Update Service соответственно). Однако работа таких служб не характерна для сред, искусственно создаваемых злоумышленниками. А для ОС семейства UNIX характерны работы так называемых «демонов», то есть служб, работающих в фоновом режиме, например сервера сетевых протоколов, процесса «init». Большинство пользователей устанавливают популярные приложения, например браузер, игры, IM-клиенты. Если таких действий в течение некоторого периода времени (например, 5 дней. Далее, такой период будет упоминаться как период времени недоверия) совершено не было, есть основания полагать, что на ПК работает не «реальный» пользователь, а вредоносная программа, которая шлет заведомо ложные запросы в облачную инфраструктуру 130, или что запросы в облачную инфраструктуру приходят с вредоносных программ, установленных на виртуальных машинах.
Следует отметить, что вредоносная программа может быть установлена на ПК легитимного пользователя и модифицировать запросы, отправляемые антивирусным ПО в облачные сервисы 140-150, либо самостоятельно отправлять подложные запросы. Обычно заражение вредоносной программой происходит из-за неверных действий пользователя (например, перехода по вредоносной ссылке, открытия вложения в письме, содержащем спам). В этом случае на шаге 210 пользователю может быть обновлен текущий уровень доверия на «доверенный», так как за ПК работает легитимный пользователь. Поэтому возникает необходимость в комплексной проверке уровня доверия к отправителю запросов, чтобы установить факт отправки подложных данных с ПК легитимного пользователя.
В другом примере реализации устройство 120 является сервером, который работает автономно, без непосредственного участия пользователя. В этом примере реализации критерии, необходимые для подтверждения легитимности сервера 120, могут быть следующими: выполнение обновления ОС, установленных программ и антивирусного ПО; период между выпуском обновления и установкой этого обновления на сервере 120.
В одном примере реализации заданный период времени недоверия может динамически изменяться. Основаниями для таких изменений могут служить статистические данные, получаемые от недоверенных ID. Например, если при анализе 10000 недоверенных ID было выявлено, что в 95% случаев облачная инфраструктура принимала решение о занесении ID в список недоверенных идентификаторов за 3 дня, период времени недоверия может быть изменен на 3 дня вместо 5. В другом примере реализации период времени недоверия может отличаться для различных типов устройств (например, для ПК - 5 дней, для почтового сервера - 2 дня).
В еще одном примере реализации период времени недоверия может динамически изменяться в зависимости от времени года и мировой/региональной преступной активности. Например, в период празднования Нового года обычно увеличивается активность спам-рассылки и, соответственно, количество заражений устройств пользователей вредоносными программами. Поэтому может увеличиться количество запросов, «обеляющих» вредоносные объекты или «очерняющих» легитимные объекты.
Стоит отметить, что проверка обновлений антивирусного ПО может быть осуществлена в облачной инфраструктуре 130, таким образом не давая злоумышленникам возможности предоставлять ложную информацию об обновлениях. После выполнения проверки системы на соответствие критериям антивирусное ПО устройства 120 отправляет запрос в облачную инфраструктуру 130, содержащий результаты проверки и ID.
В одном примере реализации запрос дополнительно содержит информацию о типе устройства. На шаге 230 в облачной инфраструктуре 130 на основании критериев к устройству принимается решение о доверии к антивирусному ПО устройства 120. В Таблице 1 приведен один из возможных вариантов набора критериев для проверки легитимности устройства 120, когда устройство является ПК.
Таблица 1
Список критериев
№
Критерий
А1
Последнее обновление ОС было установлено на устройстве не позднее чем через 4 дня после выпуска этого обновления.
А2
На ПК пользователя установлено хотя бы одно ПО из списка [браузер, IM-клиент, игра].
A3
В течение 5 дней с момента активации антивирусного ПО пользователь открывал по крайней мере одну интернет-страницу в браузере.
А4
Журнал ОС содержит информацию о включении/отключении питания, переходы в/из режима гибернации/сна в течение 5 дней с момента активации антивирусного ПО.
А5
В течение 5 дней с момента активации антивирусного ПО были зафиксированы нажатия клавиш на клавиатуре и движения мыши.
А6
Согласно расписанию обновлений антивирусного ПО пользователя обновления должны быть загружены в течение 5 дней с момента активации ПО
В1
С ID соответствующего ПО пользователя был получен запрос,
содержащий результаты проверки критериев А1-А6.
В2
В течение 5 дней с момента активации антивирусного ПО обновления устанавливались на устройстве.
ВЗ
С ID соответствующего ПО пользователя были получены запросы на проверку файлов/статистика/вердикт пользователя.
В Таблице 1 критерии А1-А6 проверяются антивирусным ПО на ПК, а критерии В1-В3 проверяются в облачной инфраструктуре 130. В таблице 2 приведен пример списка правил проверки критериев А1-А6 и В1-В3.
Таблица 2
Список правил
№
Условие
Доверенный?
1
В3, и А6, и не В2
нет
2
Не В1 и В2
нет
3
А1, и А2, и A3, и А4, и А5
да
Первое правило в таблице означает, что если в течение 5 дней с момента активации антивирусного ПО с ПК 120 приходили запросы в облачную инфраструктуру 130 (критерий В3), и согласно расписанию обновлений обновления должны были загружаться на ПК 120 (критерий А6), но со стороны антивирусного ПО не было зарегистрировано обращений к серверу обновлений (отрицание критерия В2), то логика работы антивирусного ПО на ПК 120 расходится с заложенной производителем антивирусного ПО. В этом случае облачная инфраструктура 130 будет считать запросы, поступающие с ID, соответствующего этому ПК, «недоверенными», а рассматриваемый ПК - компьютером злоумышленника 110.
Второе правило в таблице означает, что ID соответствующего ПК 120 будет считаться «недоверенным», если обновления антивирусного продукта были загружены ПК 120, но по истечении 5 дней с момента активации ПО с ПК 120 не были получены критерии проверки А1-А6.
Согласно третьему правилу ID, соответствующий ПК 120, будет считаться «доверенным», когда одновременно выполняются критерии А1-А5. Если же хотя бы одно из правил таблицы выполнено не было, можно считать, что ID, соответствующий ПК 120, будет считаться «недоверенным». Таким образом, если проверка, которая была произведена на шаге 220, не пройдена, на шаге 210 делается вывод о том, что рассматриваемому ID соответствует ПК злоумышленника ПО, для которого сохраняется текущий уровень доверия «недоверенный».
В одном примере реализации для данного ID через некоторый промежуток времени (например, месяц) может быть заново произведена проверка на соответствие критериям, производимая на шаге 220. Если же проверка, выполненная на шаге 230, пройдена, на шаге 240 устройству пользователя 120 обновляют текущий уровень доверия на «доверенный». В этом случае на все запросы, приходящие с устройства пользователя 120, ограничения накладываться не будут. Тем не менее, после получения уровня доверия «доверенный» злоумышленник ПО может получить доступ к устройству пользователя 120, например, заразив его устройство вредоносным ПО, и отправлять ложные запросы в облачную инфраструктуру 130. Более того, злоумышленник может использовать один и тот же ключ активации на нескольких устройствах после прохождения проверки системы на соответствие критериям. Таким образом, возникает необходимость постоянной проверки устройства на легитимность (является ли это устройством легитимного пользователя, или запросы отправляет злоумышленник).
В одном примере реализации шаги 210-230 могут быть опущены, при этом после активации антивирусного ПО пользователя на шаге 240 ему будет присвоен текущий уровень доверия «доверенный». В другом примере реализации после активации антивирусного ПО пользователя ему может быть присвоен уровень доверия «доверенный», после чего может быть осуществлена проверка, производимая на этапах 220-230.
После шага 240, на этапе «А», применяется комплексное решение, необходимое для осуществления постоянной проверки на легитимность пользователя. Этап «А» будет подробно рассмотрен ниже, при описании Фиг.3. В случае возникновения аномалий в поведении легитимного пользователя устройства 120 на шаге 250, рассматриваемый пользователь будет иметь текущий уровень доверия «недоверенный», и следующим будет шаг 210. В одном примере реализации этап «А» может выполняться параллельно с проверкой системы на соответствие критериям, производимой на шаге 220. В этом примере реализации, если на шаге 250 аномалии будут обнаружены раньше, чем будет закончена проверка системы на соответствие критериям, проверка системы может быть принудительно завершена, а для рассматриваемого ID будет сохранен уровень доверия «недоверенный».
На Фиг.3 приведена схема примера выполнения этапа «А», присутствующего на Фиг.2. На шаге 310 проводится проверка порядка обращения антивирусного ПО устройства 120, имеющего идентификатор ID, к облачным сервисам 140-150 с помощью средства проверки порядка обращения к сервисам 134. В одном примере реализации облачная инфраструктура 130 может содержать сервис файловой репутации, сервис белых списков и сервис статистики, которые отображены в виде сервисов 140-150.
В одном примере реализации в антивирусное ПО могут быть заложены правила, определяющие порядок его обращения к сервисам 140-150. Например, если после антивирусной проверки файла на устройстве пользователя 120 антивирусное ПО не подтвердило вредоносность файла, оно обращается к сервису белых списков. Сразу же после этого следует запрос в сервис файловой репутации. После этого, имея полную информацию о проверяемом файле, антивирусное ПО устройства 120 выносит окончательный вердикт о файле и отправляет статистическую метаинформацию о файле, а также вердикт в сервис статистики. Однако, не зная логику работы антивирусного ПО, злоумышленник может обращаться к сервисам в неверной последовательности или вовсе не обращаться к некоторым из них. Например, злоумышленник может отправлять только подложную статистику о файлах в сервис статистики, содержащую вердикты, согласно которым легитимные файлы являются вредоносными или, наоборот, вредоносные файлы являются чистыми.
Поэтому если не был соблюден порядок обращения к сервисам на этапе 340 (например, был осуществлен запрос в сервис белых списков, после которого не последовало запроса в сервис файловой репутации), на следующем этапе 370 средство принятия решений 137 определит, достаточно ли оснований полагать, что устройство с определенным идентификатором ID является устройством злоумышленника, или потребуются дополнительные проверки. В последнем случае дополнительными будут проверка изменения конфигурации системы средством проверки изменения конфигурации системы 134, выполняющаяся на шаге 320, и проверка изменения местоположения системы, выполняющаяся на шаге 330 с помощью средства проверки изменения местоположения системы 136.
Если же дополнительных проверок не требуется, тогда средство принятия решений 137 признает аномальными запросы, поступающие с устройств, имеющих идентификатор ID. Таким образом, следующим будет шаг 210, на котором устройство с идентификатором ID будет признано «недоверенным». В случае когда порядок обращения к сервисам был соблюден, на шаге 340 принимается решение, что аномалий нет, и проверки, проводимые на этапе «А», будут продолжены.
В одном варианте реализации порядка обращения к сервисам пользователь может, например, помещать в каждый запрос инкриминирующийся индекс, который будет увеличиваться на единицу для каждого последующего запроса от пользователя. Если в двух последовательных запросах с данного ID содержатся индексы с неправильной разницей, возникает аномалия. В другом варианте реализации проверка порядка обращения к сервисам может быть осуществлена в облачной инфраструктуре 130, например, с помощью общей для сервисов 140-150 таблицы, содержащей идентификатор ID, идентификатор сервиса, к которому обращалось антивирусное ПО с данным ID, и моменты времени, в которые происходили обращения к этому сервису. Таким образом, при получении запроса от устройства с идентификатором ID в сервисе статистики, последний может проверить по таблице, было ли ранее обращение к сервису файловой репутации и к сервису белых списков.
В одном примере реализации сервис статистики может дополнительно проверить разницу во времени между обращениями к сервисам, и если это время меньше заранее заданного (например, 5 секунд), будет считаться, что обращение к сервисам с идентификатора ID происходило не последовательно, возникла аномалия, а идентификатор ID будет считаться «недоверенным». В другом примере реализации, когда был соблюден порядок обращения к сервисам, дополнительно может быть рассчитана частота обращения к сервисам (количество запросов в единицу времени). Если частота запросов выше или ниже заданных значений, возникает аномалия.
Стоит отметить, что правила обращения антивирусного ПО к облачным сервисам 140-150 могут периодически меняться. Новые правила могут отправляться на антивирусное ПО вместе с обновлениями антивирусных записей. Таким образом, даже если злоумышленник узнал правильный порядок обращения к сервисам, после обновления он не сможет пройти проверку на шаге 310, а в промежуток времени до обновления параллельно этой проверке на шаге 320 может осуществляться проверка изменения конфигурации оборудования, а на шаге 330 - проверка изменения местонахождения системы. Каждая из проверок 310, 320 и 330 может осуществляться с некоторым заданным для этой проверки периодом времени (например, один день, одна неделя) или при выполнении определенных условий (например, при каждом запуске антивирусного ПО).
На шаге 320 проверяется, изменялась ли конфигурация оборудования устройства с ID, и как быстро. Например, если у устройства с рассматриваемым ID несколько раз за неделю изменялся идентификатор жесткого диска, материнской платы, есть основания полагать, что запросы в облачную инфраструктуру 130 отправлялись с различных устройств, имеющих одинаковые ID. Частая смена оборудования не свойственна пользователям ПК, особенно не свойственна серверам и мобильным телефонам, в которых смена оборудования происходит крайне редко. Поэтому на шаге 350 будет принято решение о наличии аномалии в данных, поступающих от устройства с идентификатором ID, и следующим будет шаг 370.
На шаге 330 проводится проверка изменения местонахождения пользователя. В одном примере реализации, когда устройство 120 является сервером, в облачной инфраструктуре 130 имеется информация об организации, которой принадлежит сервер с идентификатором ID, и, соответственно, диапазон возможных значений IP-адресов сервера 120. Таким образом, если запросы в облачную инфраструктуру 130 будут приходить с того же ID, но с IP-адресов других диапазонов, то на шаге 360 будет принято решение о возникновении аномалии, и следующим будет шаг 370.
В другом примере реализации, когда устройство 120 является ПК, на шаге 330 будет проводиться проверка частоты изменения местонахождения ПК 120. В одном примере реализации в облачной инфраструктуре 130 для рассматриваемого ID создается таблица, которая может содержать количество уникальных IP-адресов, с которых приходила статистика с ID, а также соответствующую IP-адресу подсеть/доменную зону/номер автономной системы/государство. И если за некоторый определенный период времени (например, неделю) для одного ID запросы приходили с разных подсетей/доменных зон/автономных систем/государств, то при достижении определенного граничного значения (например, с двух разных стран, с пяти разных подсетей) такое поведение на шаге 360 будет определено как аномальное для легитимных пользователей ПК 120, и следующим будет шаг 370.
В другом примере реализации устройством 120 является мобильный телефон/смартфон/планшетный ПК/ноутбук, для которого характерно частое изменение подсетей, однако не характерно частое изменение стран/доменной зоны. В итоге на шаге 370 средство принятия решений 137 определит, достаточно ли оснований полагать, что устройство с ID является устройством злоумышленника, или потребуются дополнительные проверки. Если достаточно, то следующим будет этап 210, ID будет признан «недоверенным», а на все запросы, приходящие с данного ID, будут накладываться ограничения. В одном примере реализации уровень доверия к пользователю устройства 120 с идентификатором ID может принимать более двух значений, как, например, показано в Таблице 3.
Таблица 3
Уровень доверия
Ограничения для ID
1
Занесение ID в черный список, непредоставление ответов для ID, а также полное игнорирование запросов, содержащих данный ID.
2
Отправка ответов ID. Игнорирование вердиктов, содержащихся в запросах с ID.
3
Нет ограничений.
В этом примере реализации на этапах 210 и 240 для идентификатора ID может присваиваться одно из возможных значений уровня доверия.
Например, непосредственно после активации антивирусного ПО невозможно точно сказать, соответствует рассматриваемый ID пользователя легитимному пользователю или злоумышленнику. Поэтому на шаге 210 средство принятия решений 137 присваивает данному ID уровень доверия 2 из Таблицы 3, означающий слабые ограничения для запросов, приходящих с устройств, имеющих уникальный идентификатор ID. Таким образом, легитимные пользователи будут получать полноценные ответы со стороны репутационных сервисов 140-150, в то время как вердикты, предоставляемые злоумышленниками в облачную инфраструктуру 130, будут игнорироваться. Однако если на этапе 370 есть достаточно оснований полагать, что рассматриваемый ID используется злоумышленниками, на шаге 210 ему будет присвоен уровень доверия 1, означающий полное игнорирование запросов, приходящих с устройств с данным ID. В то же время, легитимным пользователям на шаге 240 будет обновлен текущий уровень доверия до 3. В другом примере реализации этап «А» может включать дополнительные проверки устройства 120 на соответствие критериям, предъявляемым к устройству легитимного пользователя антивирусного ПО 120. Например, такой дополнительной проверкой может быть проверка N, выполняющаяся на шаге 380, после которой, в случае возникновения аномалии, следующим будет шаг 370.
В одном примере реализации одной из дополнительных проверок может быть проверка тиражирования ID. В этом примере в запрос пользователя устройства 120 может быть помещен идентификатор антивирусного ПО пользователя ID, зашифрованный открытым ключом облачной инфраструктуры 130, а также хэш-сумма от тела запроса. Далее в одном из сервисов 140-150, которому был адресован данный запрос, производится расшифровка ID с помощью закрытого ключа облачной инфраструктуры 130, от тела запроса рассчитывается хэш-сумма и сравнивается с хэш-суммой, присланной пользователем. Если хэш-суммы не совпадают, возникает аномалия. Такая проверка исключает возможность злоумышленникам отправлять в облачную инфраструктуру 130 запросы с украденного ID.
В одном примере реализации на шаге 370 для проверок 310, 320, 330, 380 может быть назначен различный приоритет. Таблица 4 является примером назначения весовых коэффициентов для различных проверок. В зависимости от итогового веса выполненных проверок (пример соответствия приведен в Таблице 5), на шаге 370 средством принятия решений 137 принимается решение о дальнейших действиях.
Таблица 4
Проверка
Вес
Порядок обращения к сервисам 310
4
Изменение конфигурации оборудования 320
1
Проверка изменения местонахождения системы 330
2
…
Проверка N
1
Так, например, при частом изменении конфигурации проверяемой системы, если после данной проверки возникла аномалия, ей будет назначен приоритет с весом 1. Проверка порядка обращения к сервисам 310 более точно может определить легитимность пользователя, поэтому ей может быть назначен приоритет с весом 4. Если одновременно было выполнено несколько проверок с разными весами, то суммарный вес является функцией от выполненных проверок (например, равен сумме весов или максимальному весу среди всех проверок).
В Таблице 5 приведен пример принимаемых на шаге 370 решений в зависимости от суммарного веса. Так, например, если суммарный вес равен 3, для определения аномалии потребуется дополнительно провести хотя бы одну проверку с весом 1, и если после такой проверки суммарный вес остался прежним, делается вывод об отсутствии аномалии. Если же суммарный вес равен 4, делается вывод о возникновении аномалии, и на шаге 210 рассматриваемый ID становится «недоверенным».
Таблица 5
Вес
Решение, принимаемое на шаге 370
1
Провести две дополнительные проверки, имеющие вес не менее 1.
2
Провести одну проверку с весом 3.
3
Провести проверку с весом 1.
4
Аномалия
В одном примере реализации для каждого типа проверок 310-330, 380 может быть введен рейтинг качества обнаружения подложной информации. Качество обнаружения может зависеть от количества правильно обнаруженных ID злоумышленников, а также от количества ложных срабатываний, то есть когда ID легитимного пользователя устройства становится «недоверенным». В данном примере реализации вес каждой проверки может зависеть от рейтинга качества обнаружения проверок, а также может изменяться при изменении рейтинга качества обнаружения проверок. Например, после прохождения всех необходимых проверок на этапе 250 не было обнаружено аномалий, и ID пользователя считается «доверенным». Однако проверка на изменение конфигурации системы 320 выявило аномалию, что говорит о ложном срабатывании. Если количество ложных срабатываний по отношению к правильному обнаружению аномалий превысило 10% для проверки на изменение конфигурации системы 320, рейтинг качества обнаружения может быть понижен.
Фиг.4 представляет пример компьютерной системы общего назначения, персональный компьютер или сервер 20, содержащий центральный процессор 21, системную память 22 и системную шину 23, которая содержит разные системные компоненты, в том числе память, связанную с центральным процессором 21. Системная шина 23 реализована, как любая известная из уровня техники шинная структура, содержащая в свою очередь память шины или контроллер памяти шины, периферийную шину и локальную шину, которая способна взаимодействовать с любой другой шинной архитектурой. Системная память содержит постоянное запоминающее устройство (ПЗУ) 24, память с произвольным доступом (ОЗУ) 25. Основная система ввода/вывода (BIOS) 26 содержит основные процедуры, которые обеспечивают передачу информации между элементами персонального компьютера 20, например, в момент загрузки операционной системы с использованием ПЗУ 24.
Персональный компьютер 20 в свою очередь содержит жесткий диск 27 для чтения и записи данных, привод магнитных дисков 28 для чтения и записи на сменные магнитные диски 29 и оптический привод 30 для чтения и записи на сменные оптические диски 31, такие как CD-ROM, DVD-ROM и иные оптические носители информации. Жесткий диск 27, привод магнитных дисков 28, оптический привод 30 соединены с системной шиной 23 через интерфейс жесткого диска 32, интерфейс магнитных дисков 33 и интерфейс оптического привода 34 соответственно. Приводы и соответствующие компьютерные носители информации представляют собой энергонезависимые средства хранения компьютерных инструкций, структур данных, программных модулей и прочих данных персонального компьютера 20.
Настоящее описание раскрывает реализацию системы, которая использует жесткий диск 27, сменный магнитный диск 29 и сменный оптический диск 31, но следует понимать, что возможно применение иных типов компьютерных носителей информации 56, которые способны хранить данные в доступной для чтения компьютером форме (твердотельные накопители, флеш-карты памяти, цифровые диски, память с произвольным доступом (ОЗУ) и т.п.), которые подключены к системной шине 23 через контроллер 55.
Компьютер 20 имеет файловую систему 36, где хранится записанная операционная система 35, а также дополнительные программные приложения 37, другие программные модули 38 и данные программ 39. Пользователь имеет возможность вводить команды и информацию в персональный компьютер 20 посредством устройств ввода (клавиатуры 40, манипулятора «мышь» 42). Могут использоваться другие устройства ввода (не отображены): микрофон, джойстик, игровая консоль, сканнер и т.п.Подобные устройства ввода по своему обычаю подключают к компьютерной системе 20 через последовательный порт 46, который в свою очередь подсоединен к системной шине, но могут быть подключены иным способом, например, при помощи параллельного порта, игрового порта или универсальной последовательной шины (USB). Монитор 47 или иной тип устройства отображения также подсоединен к системной шине 23 через интерфейс, такой как видеоадаптер 48. В дополнение к монитору 47, персональный компьютер может быть оснащен другими периферийными устройствами вывода (не отображены), например, колонками, принтером и т.п.
Персональный компьютер 20 способен работать в сетевом окружении, при этом используется сетевое соединение с другим или несколькими удаленными компьютерами 49. Удаленный компьютер (или компьютеры) 49 являются такими же персональными компьютерами или серверами, которые имеют большинство или все упомянутые элементы, отмеченные ранее при описании существа персонального компьютера 20, представленного на Фиг.4. В вычислительной сети могут присутствовать также и другие устройства, например, маршрутизаторы, сетевые станции, пиринговые устройства или иные сетевые узлы.
Сетевые соединения могут образовывать локальную вычислительную сеть (LAN) 50 и глобальную вычислительную сеть (WAN). Такие сети применяются в корпоративных компьютерных сетях, внутренних сетях компаний и, как правило, имеют доступ к сети Интернет. В LAN- или WAN-сетях персональный компьютер 20 подключен к локальной сети 50 через сетевой адаптер или сетевой интерфейс 51. При использовании сетей персональный компьютер 20 может использовать модем 54 или иные средства обеспечения связи с глобальной вычислительной сетью, такой как Интернет. Модем 54, который является внутренним или внешним устройством, подключен к системной шине 23 посредством последовательного порта 46. Следует уточнить, что сетевые соединения являются лишь примерными и не обязаны отображать точную конфигурацию сети, т.е. в действительности существуют иные способы установления соединения техническими средствами связи одного компьютера с другим.
В соответствии с описанием, компоненты, этапы исполнения, структура данных, описанные выше, могут быть выполнены, используя различные типы операционных систем, компьютерных платформ, программ.
В заключение следует отметить, что приведенные в описании сведения являются только примерами, которые не ограничивают объем настоящего изобретения, определенного формулой.