Система и способ для оптимизации выполнения антивирусных задач в локальной сети - RU2453917C1

Чертежи

Показать все 12 чертежа(ей)

Описание

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

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

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

В настоящее время в корпоративных сетях все более остро встает вопрос обеспечения компьютерной безопасности. Этому способствует не только постоянный рост количества таких сетей и компьютеров в них, но и увеличивающееся количество компьютерных угроз. Компьютерные угрозы уже давно включают не только классические компьютерные вирусы, но и более продвинутые вредоносные программы, такие как трояны, черви, руткиты (rootkit), эксплойты (exploit). Например, руткиты умеют скрывать свое присутствие в операционной системе, что затрудняет их нахождение, в то время как эксплойты используют уязвимости в программном обеспечении для проведения атаки или получения несанкционированного доступа. Современные антивирусные решения, такие как Symantec Endpoint Protection, McAfee Total Protection, Trend Micro Worry-Free Business Security, позволяют успешно бороться с большинством известных угроз. Однако существует ряд проблем.

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

Помимо этого, современные антивирусные приложения или системы безопасности содержат большое количество модулей, решающих различные задачи. На Фиг.1 изображена примерная схема состава модулей системы безопасности. Некоторые из модулей являются жизненно необходимыми для работы приложения - это такие модули, как модуль обновления или файловый антивирус. В зависимости от использования различных возможностей, вроде электронной почты или сети Интернет, другие модули требуются для установки, такие как почтовый антивирус, веб-антивирус, IM-антивирус (предназначен для проверки данных, передаваемых через средства мгновенного обмена сообщениями), сетевой экран. Другие являются вспомогательными инструментами: анти-спам модуль, модуль резервного копирования, менеджер личных данных, виртуальная клавиатура. Некоторые модули, вроде анти-баннера, применимы при использовании веб-браузера при просмотре информации в сети Интернет. Иные модули требуют большого количества времени и ресурсов для проверки, однако способны справляться с еще неизвестными вредоносными программами и атаками. Такими модулями являются модуль HIPS (Host Intrusion Prevention System), который ограничивает доступ к ресурсам компьютера для неизвестных программ, модуль проактивной защиты (Proactive Defense Module), способный определить уже активную фазу заражения, эмулятор и виртуальная машина, необходимые для безопасного запуска неизвестных исполняемых файлов. Помимо этого, все модули имеют различный уровень потребления системных ресурсов (процессорное время, объем используемой памяти и т.д.).

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

Одним из примеров решения может быть установка модулей приложения, в том числе и антивирусного, на каждый компьютер в зависимости от его параметров, что позволяет уменьшить использование системных ресурсов. Заявка US 20100138479 A1 широко описывает механизм экономии графика при загрузке модулей ПО клиенту. Для каждого клиента существует возможность выбрать необходимые модули из списка (package definition file) для их дальнейшей загрузки. Предлагаемая в заявке US 20100042991 А1 система позволяет гибко настраивать список предлагаемого ПО в зависимости от аппаратной части компьютера (учитывая изменение аппаратных возможностей). В заявке WО 2010016833 A1 описывается система, раскрывающая возможность установки ПО в виде набора, который зависит от определенных флагов. Флаги могут зависеть от типа аппаратной части компьютера или иметь отношение к тем пользователям, которые будут использовать компьютер. Заявка US 20030200149 A1 направлена на создание списка ПО, совместимого с исходным оборудованием. Для определения совместимости используются данные по тестированию ПО на различных конфигурациях оборудования. Выбрав требуемое оборудование, заказчик (клиент) автоматически получает список рекомендованного ПО.

Другим решением является делегирование задач с конечных рабочих станций на центральный сервер. Однако существующий уровень техники рассматривает лишь вопросы оптимизации нагрузки, не затрагивая проблемы определения уровня риска. Например, в патенте US 6920632 B2 приведен алгоритм кругового обслуживания задач. Патент рассматривает вопросы установки приоритетов задач и выделения им соответствующих ресурсов. Помимо этого, решается задача выделения ресурсов на выполнение задач в случаях конфликтов приоритетов и нехватки ресурсов. Другой патент US 6377975 B1 рассматривает делегирование задачи на наименее загруженный сервер. С этой целью опрашиваются доступные серверы, а также определяется возможность распределения задачи. Заявка KR 2007032441 A рассматривает вопрос снижения нагрузки на серверы путем выбора наименее загруженного. Для выбора используется нечеткая логика.

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

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

Сущность изобретения

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

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

В частном варианте реализации нахождение клиентов в сети реализовано на основании механизма ARP-spoofing.

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

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

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

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

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

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

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

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

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

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

В частном варианте реализации нахождение клиентов в сети реализовано на основании механизма ARP-spoofmg.

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

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

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

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

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

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

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

Фиг.1 иллюстрирует примерную схему состава модулей антивирусного приложения;

Фиг.2 показывает вариант выбора модулей антивирусного приложения для конкретного клиента;

Фиг.3 показывает алгоритм установки модулей антивирусного приложения на клиент;

Фиг.3а отражает пример базы данных модулей;

Фиг.4 показывает пример делегирования задач с клиента на сервер;

Фиг.5 иллюстрирует алгоритм делегирования задач с клиента на сервер;

Фиг.6 иллюстрирует алгоритм запроса информации с сервера по делегированной задаче;

Фиг.7 показывает алгоритм переконфигурации набора модулей на клиенте;

Фиг.7а иллюстрирует частный вариант алгоритма переконфигурации набора модулей на клиенте в случае отключения сервера;

Фиг.8 показывает алгоритм переконфигурации набора модулей на клиентах;

Фиг.9 отражает способ работы настоящего изобретения;

Фиг.10 показывает работу средств системы настоящего изобретения;

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

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

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

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

Фиг.2 показывает вариант выбора модулей антивирусного приложения для конкретного клиента. Клиент 200 представляет определенный компьютер с заданной аппаратно-программной конфигурацией. Сервер 210 является компьютером, который способен предоставлять услуги, связанные с компьютерной безопасностью и администрированием. Эти функции могут быть реализованы с помощью таких корпоративных продуктов, как Kaspersky Security for Microsoft Exchange Server, Kaspersky Anti-Virus for Windows Servers, Kaspersky Anti-Virus for Windows Workstations и других, которыми можно управлять с помощью приложения Kaspersky Administration Kit. Помимо того что сервер 210 выполняет различные антивирусные функции, он также используется для хранения сборок антивирусных продуктов, которые требуется установить на локальные компьютеры, такие как клиент 200. Подобная защита называется защитой конечного узла локальной сети (endpoint protection). Сервер располагает набором 230 различных модулей, которые аналогичны по своим функциям тем, которые приведены на Фиг.1. Для каждого клиента 200 определяется собственный набор 220 модулей, который подходит под его аппаратно-программную конфигурацию.

Фиг.3 показывает алгоритм установки модулей антивирусного приложения на клиент. На этапе 300 происходит обнаружение клиента в сети. Подобный шаг может быть выполнен с использованием различных вариантов реализации. Например, это может быть периодическая проверка всех узлов (широковещательный запрос) с последующим обнаружением новых компьютеров. Другой вариант реализации подразумевает использование технологии ARP-spoofing, которая заключается в перехвате графика между узлами сети, основываясь на использовании ARP протокола. Используя особенности реализации протокола ARP, можно, перехватив на неизвестном компьютере (хосте) внутри сети широковещательный ARP-запрос, послать ложный ARP-ответ, в котором объявить себя искомым хостом (например, маршрутизатором), и в дальнейшем контролировать сетевой трафик неизвестного компьютера (хоста). Различные патенты, такие как US 7512980 B2, US 7475426 B2, US 7418733 B2, US 7379993 B2, US 7290283 B2, направлены на решение задач безопасности в сети, используя особенности реализации сетевых протоколов.

На этапе 310 происходит передача модуля сбора информации на обнаруженный клиент с последующим сбором информации на этапе 320. Модуль сбора информации выполняет функции сбора информации об аппаратных возможностях клиента 200 (используемый процессор, объем памяти, пропускная способность соединения и т.д.), используемой операционной системе (ОС) и переменных окружения, установленном ПО. Эти функции могут быть реализованы как в одном модуле, так и в виде нескольких независимых приложений, таких как LOGINventory, ServiceDesk Plus, и других. Также подобная информация может быть собрана с помощью средств ОС, таких как Windows Management Instrumentation (WMI).

Сформированная информация затем передается на сервер на этапе 330. Далее на этапе 340 происходит подготовка набора модулей для клиента 200 в соответствии с собранной информацией с дальнейшей передачей и установкой на этапе 350. Установка может быть выполнена с помощью отдельного инсталлятора (например, установочный пакет MSI), как правило, автоматически и удаленно. Для подготовки набора модулей для клиента 200 используется база данных модулей 400, которая содержит необходимую информацию о каждом модуле и выполняемых им функциях.

Фиг.3а отражает пример базы данных модулей. База данных содержит следующую информацию о модуле: его название и версия, известные несовместимости с ОС или ПО, требования к аппаратным возможностям клиента 200 (т.е. аппаратные требования модуля), тип и объем хранимой информации (например, файловый антивирус может использовать достаточно емкую базу данных сигнатур известных вредоносных программ), типы взаимодействия с другими модулями (например, модуль обновления взаимодействует почти со всеми остальными модулями), типы используемых в работе данных (например, эмулятор работает с файлами, имеющими РЕ-структуру), важность в различных режимах работы (например, файловый антивирус является критически важным модулем, который опирается на базы сигнатур известных вредоносных программ, в то время как виртуальная клавиатура является вспомогательным средством при работе в сети Интернет). Следует понимать, что приведенный набор информации не является исчерпывающим и служит только в качестве примера.

Для выбора типа модуля, который требуется установить на клиент 200, сравнивается полученная на этапе 330 от клиента 200 информация с информацией в базе данных модулей 400, которая отражена на Фиг.3а. Соответствие может быть реализовано в рамках продукционных правил в одном из вариантов реализации. Продукционное правило реализовано в виде "ЕСЛИ …, ТО …", где в графе ЕСЛИ проверяется выполнение соответствующего условия. Например, если на клиенте 200 установлен веб-браузер (и один или несколько), то при отсутствии несовместимостей и наличии достаточного количества ресурсов на клиенте 200 в набор модулей для установки будет включен веб-антивирус. Если при сборе информации с клиента 200 было установлено, что большое количество ПО требует авторизации у пользователя, то в набор модулей для установки могут быть включены модуль шифрования данных и менеджер личных данных. При наличии на клиенте 200 более одного пользователя, также может быть добавлен родительский контроль. Приведенные варианты выбора набора модулей для установки на клиент 200 являются примерными и могут варьироваться при различных вариантах реализации.

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

Фиг.4 показывает пример делегирования задач с клиента на сервер. Клиент 200 имеет определенный список задач безопасности 410, которые он не в состоянии выполнить самостоятельно. С этой целью он делегирует эти задачи на сервер 210, который ведет общий список задач 420. Каждая задача на стороне сервера имеет ряд параметров, таких как приоритет, тип задачи, прикрепленные данные. При делегировании приоритет (т.е. ее важность) задачи может быть как вручную задан пользователем, так и определен с помощью алгоритма определения важности задачи, который использует данные об объектах для исследования (файл, ссылка, письмо и т.д.). Организация передачи данных может быть выполнена в виде поэтапного обмена информацией "запрос-ответ", что отражено на Фиг.5. Задачами безопасности могут быть: антивирусная проверка файлов и веб-страниц, эмуляция исполняемых файлов, проверка выполнения исполняемых файлов в виртуальной среде, проверка почтовых сообщений на наличие спама, шифрование данных, управление личными данными, безопасный ввод данных (через виртуальную клавиатуру), создание резервных копий, обновление баз данных модулей, обеспечение родительского контроля, ограничение доступа к системным ресурсам для программ, контроль сетевых соединений, блокировка нежелательного контента и т.д.

Фиг.5 иллюстрирует алгоритм делегирования задач с клиента на сервер. На этапе 500 определяется, хватает ли клиенту ресурсов для выполнения задачи. Под ресурсами подразумевается наличие соответствующих модулей, которые выполняют задачи безопасности (например, файловый антивирус проверяет файлы на жестком диске). В случае наличия необходимых ресурсов, алгоритм заканчивается на этапе 505. В противном случае на этапе 510 проверяется, доступен ли сервер 210, который занимается выполнением делегированных задач. При недоступности сервера алгоритм завершается на этапе 515 оповещением пользователя. Если сервер 210 доступен, то на этапе 520 задача помещается в общий список задач 420. Список регулярно обновляется на стороне сервера 210 на этапе 530, выстраивая задачи в соответствии с их приоритетом. Каждая задача находится в процессе ожидания ее выбора на выполнение на этапе 540 с проверкой на этапе 550 о начале выполнения задачи. Если сервер 210 начал выполнение задачи на этапе 555, то алгоритм заканчивается. При определении превышения лимита ожидания задачи в очереди на этапе 560 приоритет задачи может быть повышен на этапе 570. Данные этапы будут повторяться, пока задача не уйдет на выполнение на этапе 555. Таким образом, гарантируется выполнение задач безопасности от каждого из клиентов 200.

Для каждой задачи создается собственный набор прикрепленных данных. Например, для задачи проверки файлов это может быть информация о файле (хеш-сумма, наличие цифровой подписи, данные о размере, местоположении, атрибуты командной строки, указание авторства (если есть), атрибуты файла (скрытый, архив), откуда был получен (из сети, с носителей вроде CD), когда был изменен и т.д.), для задачи проверки веб-страницы это может быть адрес (ссылка) этой страницы, настройки проверки для работы эмулятора сценариев (какие типы сценариев проверять и на каком уровне глубины, какие объекты следует подвергать проверке) и т.д. Чтобы сократить размер пересылаемых на сервер данных, предусмотрен алгоритм пошагового запроса более подробной информации со стороны сервера.

Все данные по объекту проверки можно разбить на несколько типов:

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

- важные. Например, это атрибуты файла вроде подписи или атрибутов командной строки. Они могут быть использованы для более точного вынесения заключения по проверке;

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

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

Фиг.6 иллюстрирует алгоритм запроса информации с сервера по делегированной задаче. На этапе 600 сервер 210 запрашивает базовую информацию об исследуемых объектах в рамках задачи. Например, для файла это может быть хеш-сумма. На этапе 610 проверяется, достаточно ли информации для вынесения вердикта по задаче. Если информации достаточно (например, хеш-сумма была найдена в базе данных известных вредоносных программ), то алгоритм завершается на этапе 615 выдачей результата на клиент 200. Если информации недостаточно, то на этапе 620 сервер запрашивает дополнительную информацию об исследуемых объектах. Например, расширенной информацией о файле могут быть данные о цифровой подписи, атрибутах файла (расширение, наличие упаковки, местоположение, размер) и т.д. На этапе 630 проверяется, достаточно ли информации для вынесения вердикта по задаче. Если информации достаточно, то алгоритм завершается на этапе 635 выдачей результата на клиент 200. Если информации недостаточно, то на уровне клиента 200 проверяется, есть ли дополнительная информация об исследуемых объектах и может ли клиент ее предоставить. Например, при наличии эмулятора клиент 200 может предоставить соответствующий журнал эмуляции на сервер 210. Также эмуляция может быть выполнена с разными настройками (например, на клиенте стоят наиболее легкие настройки - для ограничения времени работы и потребления ресурсов), поэтому на сервере можно заново прогнать эмуляцию с более строгими настройками (многие вредоносные программы имеют противоэмуляционные действия, вроде большого количества ненужных инструкций). Если на этапе 650 будет обнаружено, что сервер не может вынести вердикт по данной задаче, а клиент не располагает более детальной информацией, то задача будет заблокирована в целях безопасности.

Фиг.7 показывает алгоритм переконфигурации набора модулей на клиенте. При выполнении задач безопасности сервер 210 ведет статистику запросов от клиентов 200 и проводит анализ соответствия отсылаемых запросов и установленных наборов модулей на каждом из клиентов 200, что выполняется на этапе 700. На этапе 710 определяется, превышает ли количество запросов одного типа заданный порог. Запросы одного типа могут быть запросами на выполнение проверки файла или спам анализа входящих писем, а также проверки веб-страниц, проверки получаемых по сети файлов, запросами на создание резервных копий, запросами на шифрование. Задание порога может быть выполнено как эмпирическим путем (например, задан вручную администратором сети), так и автоматически вычислено исходя из ряда параметров, влияющих на эту величину: оценки программно-аппаратных возможностей клиента и сервера, количества клиентов в сети, средней ресурсоемкости задач данного типа.

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

Если порог не превышен, то сбор статистики продолжается на этапе 715. Статистика набирается за определенный промежуток времени, например за час. Так как нельзя сразу говорить, что если в один час за сутки количество запросов превышает определенный предел и необходимо сразу ставить необходимые модули на клиенты, то с этой целью происходит усреднение запросов за некоторое время, например за 8-9 часов рабочего времени в будни. На этапе 720 определяется наличие достаточных ресурсов для установки соответствующего модуля, который решал бы задачи данного типа. Установка такого модуля позволяет разгрузить сервер 210. В случае наличия достаточного количества ресурсов, на клиент 200 устанавливается соответствующий модуль на этапе 730. В противном случае, задачи продолжают выполняться на сервере на этапе 725. На последнем этапе 740 на сервере будет активирован (или установлен) соответствующий модуль системы безопасности, если такой модуль отсутствует или не активен в целях экономии ресурсов. Модули могут быть также заблаговременно установлены на сервере для выполнения соответствующих задач, которые могут быть делегированы от клиентов.

Фиг.7а иллюстрирует частный вариант алгоритма переконфигурации набора модулей на клиенте в случае отключения сервера. Данный вариант предусматривает непредвиденные ситуации, когда сервер 210 оказывается неспособен принимать запросы от клиентов 200. Это может быть связано с целым рядом факторов: обрыв каналов связи (как проводных, так и беспроводных), большая нагрузка на каналы связи, что может быть связано с DDoS-атаками, которые приводят к нестабильности передачи данных и их возможной потере, внеплановое отключение сервера и т.д.

На этапе 740 клиент 200 отправляет запрос на сервер 210 на выполнение задачи. Если сервер отвечает на запрос на этапе 750 (это выражается в виде обратного сообщения о том, что задача была принята на выполнение), то клиент 200 продолжает работать в обычном режиме. В противном случае клиент 200 ведет подсчет времени по неактивности сервера (т.е. времени, которое проходит от запроса клиента) на этапе 760. Как правило, ожидание ответа от сервера не занимает много времени и может длиться от нескольких десятков миллисекунд для небольшой локальной сети до считанных минут для большой распределенной сети, состоящей из нескольких десятков тысяч компьютеров. В зависимости от размера сети выбирается допустимое время неактивности сервера, в течение которого сервер должен гарантированно ответить клиенту. Подобное время выбирается автоматически на основании эмпирических исследований, но может быть изменено администратором. На этапе 770 проверяется, превышен ли порог ожидания ответа от сервера (время его неактивности). Если порог не превышен, то клиент может отослать запрос снова, особенно если запрос основан на использовании протоколов передачи данных, которые не гарантируют доставки (например, UDP). Если порог был превышен, то на клиенте повышаются настройки безопасности для используемых модулей на этапе 780. Повышение настроек может заключаться в усилении политик для HIPS модуля, увеличении времени на эмуляцию и использование виртуальной машины и т.д. Другой вариант этапа 780 может предусматривать создание дополнительного сетевого соединения с серверами антивирусных компаний, таких как ЗАО "Лаборатория Касперского" или Symantec, для передачи им необходимой информации по задачам безопасности. Еще один вариант предусматривает использование отложенных задач, когда клиенты не отправляют все задачи по безопасности сразу же на сервер 210, а делают это через определенные промежутки времени.

Фиг.8 показывает алгоритм переконфигурации набора модулей на клиентах. При выполнении задач безопасности сервер 210 ведет статистику запросов от клиентов 200 и проводит анализ соответствия отсылаемых запросов и установленных наборов модулей на всех известных клиентах 200, что выполняется на этапе 800. На этапе 810 определяется, превышает ли количество запросов одного типа заданный порог. Запросы одного типа могут быть запросами на выполнение проверки файла или спам анализа входящих писем. Если порог не превышен, то сбор статистики продолжается на этапе 815. На этапе 820 определяется эффективность выполнения запросов на сервере. Например, можно определить более эффективный анализ спама на стороне сервера, где для почтового релея будет использован соответствующий модуль.

Эффективность может быть рассчитана исходя из множества параметров, таких как скорость обмена информацией между клиентами и сервером (полоса пропускания), средняя ресурсоемкость задач данного типа, оценка программно-аппаратных возможностей клиента и сервера. В частном варианте реализации эффективность представлена в виде отношения общей условной скорости работы выполнения задач данного типа на сервере и на клиентах за определенный промежуток времени (дни, недели, месяцы). Условная скорость работы выполнения задач данного типа на сервере может быть рассчитана заранее исходя из известных данных по работе модулей системы безопасности на шлюзах (можно привести в качестве примера такие приложения, как Антивирус Касперского для Check Point Firewall или Kaspersky Security для Microsoft Exchange Server). Таким образом, при соотношении больше единицы эффективность выполнения задач безопасности на сервере будет выше.

Установка модуля, который решает соответствующие задачи, позволяет разгрузить клиенты 200 и оптимизировать общую нагрузку в локальной сети. В случае определения более высокой эффективности выполнения задач на сервере, на клиентах 200 удаляется соответствующий модуль на этапе 830, а также включается (активируется) соответствующий модуль на сервере на этапе 840. В противном случае, задачи продолжают выполняться на клиентах на этапе 825.

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

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

Фиг.9 отражает способ работы настоящего изобретения. На этапе 910 находят клиентов в сети. Далее на этапе 920 устанавливают модули системы безопасности на каждый из клиентов в соответствии с их конфигурацией. Затем, на этапе 930 собирают статистику выполнения задач безопасности на клиентах и передают статистику на сервер. На этапе 940 анализируют выполнение задач безопасности на клиентах исходя из собранной статистики. После этого, на этапе 950 переконфигурируют модули на стороне клиентов в соответствии с собранной статистикой, а на этапе 960 переконфигурируют сервер в соответствии с поступающими от клиентов запросами на выполнение задач.

Фиг.10 показывает работу средств системы настоящего изобретения. Средство определения клиентов 1010 находит клиентов в сети. Как уже было сказано ранее, для этой цели могут использоваться различные особенности реализации сетевых протоколов, в том числе и ARP. После обнаружения клиентов в сети средство оценки ресурсов клиента 1020 оценивает программно-аппаратные возможности клиента, что более подробно описано на Фиг.3. Далее средство оценки ресурсов клиента 1020 передает полученную информацию на средство выбора состава и установки модулей системы безопасности 1030, которое использует уже описанную ранее базу данных модулей 400 для определения конкретного набора модулей системы безопасности для последующей установки их на каждый из клиентов. Таким образом, средство выбора состава и установки модулей системы безопасности 1030 определяет набор модулей системы безопасности на стороне клиента 1040 и на стороне сервера 1050. В последнем случае возможны различные варианты подхода: модули системы безопасности на стороне сервера 1050 могут быть установлены по мере необходимости или же установлены заранее, но не активированы с целью экономии ресурсов сервера. Модули системы безопасности на стороне клиента 1040 и на стороне сервера 1050 передают статистику по выполнению задач безопасности на средство сбора статистики выполнения задач безопасности 1060, которое агрегирует полученную информацию для средства переконфигурации 1070. Данное средство, в свою очередь, передает команды на средство выбора состава и установки модулей системы безопасности 1030 с целью наилучшего набора модулей системы безопасности на стороне клиента 1040 и на стороне сервера 1050, что позволит оптимизировать выполнение задач безопасности в рамках данной сети.

Фиг.11 представляет пример компьютерной системы общего назначения, персональный компьютер или сервер 20, содержащий центральный процессор 21, системную память 22 и системную шину 23, которая содержит разные системные компоненты, в том числе память, связанную с центральным процессором 21. Системная шина 23 реализована, как любая известная из уровня техники шинная структура, содержащая в свою очередь память шины или контроллер памяти шины, периферийную шину и локальную шину, которая способна взаимодействовать с любой другой шинной архитектурой. Системная память содержит постоянное запоминающее устройство (ПЗУ) 24, память с произвольным доступом (ОЗУ) 25. Основную систему ввода/вывода (BIOS), содержащую основные процедуры, которые обеспечивают передачу информации между элементами персонального компьютера 20, например, в момент загрузки с использованием ПЗУ 24.

Персональный компьютер 20 в свою очередь содержит жесткий диск 27 для чтения и записи, привод магнитных дисков 28 для чтения и записи на сменные магнитные диски 29 и оптический привод 30 для чтения и записи на сменные оптические диски 31, такие как CD-ROM, DVD-ROM и иные оптические носители информации. Жесткий диск 27, привод магнитных дисков 28, оптический привод 30 соединены с системной шиной 23 через интерфейс жесткого диска 32, интерфейс привода магнитных дисков 33 и интерфейс оптического привода 34 соответственно. Приводы и соответствующие компьютерные носители информации представляют собой энергонезависимые средства хранения компьютерных инструкций, структур данных, программных модулей и прочих данных персонального компьютера 20. Настоящее описание раскрывает реализацию системы, которая использует жесткий диск, сменный магнитный диск 29 и сменный оптический диск 31, но следует понимать, что возможно применение иных типов компьютерных носителей информации, которые способны хранить данные в доступной для чтения компьютером форме (кассеты с магнитной лентой, карты памяти flash, цифровые диски, картриджи Бернулли, память с произвольным доступом (ОЗУ), постоянные запоминающие устройства (ПЗУ) и т.п.).

Некоторые из программных модулей, в том числе операционная система 35, хранятся на жестком диске, магнитном диске 29, оптическом диске 31, ПЗУ 24 или ОЗУ 25. Компьютер 20 имеет файловую систему 36, где хранится записанная операционная система 35 и дополнительные программные приложения 37, другие программные модули 38 и программные данные 39. Пользователь имеет возможность вводить команды и информацию в персональный компьютер 20 посредством устройств ввода (клавиатура 40, манипулятор «мышь» 42). Другие устройства ввода (не отображены): микрофон, джойстик, игровая консоль, спутниковая тарелка, сканнер и т.п. Подобные устройства ввода по своему обычаю подключаются к центральному процессору 21 через последовательный порт 46, который в свою очередь подсоединен в системной шине, но могут быть подключены иным способом, например через параллельный порт, игровой порт или универсальную последовательную шину (USB). Монитор 47 или иной тип устройства отображения также подсоединен к системной шине 23 через интерфейс, такой как видеоадаптер 48. В дополнение к монитору 47, персональный компьютер может быть оснащен иными периферийными устройствами вывода (не отображены), например колонками, принтером и т.п.

Персональный компьютер 20 способен работать в сетевом окружении, при этом используется логическое соединение с другим или несколькими удаленными компьютерами 49. Удаленный компьютер (или компьютеры) 49 являются такими же персональными компьютерами, серверами, роутерами, сетевыми станциями, пиринговыми устройствами или иным сетевым узлом и по обыкновению имеют большинство или все из упомянутых элементов, описанных ранее при объяснении существа персонального компьютера 20, представленного на Фиг.11 лишь только как устройство хранения 50, в котором хранятся приложения 37'. Логические соединения подразумевают локальную вычислительную сеть (LAN) 51 и глобальную вычислительную сеть (WAN) 52. Такие сети являются обычным офисным оборудованием, а также применяются в корпоративных компьютерных сетях, внутренних сетях компаний и Интернете.

При использовании LAN сетей персональный компьютер 20 подсоединен к локальной сети 51 через сетевой адаптер или интерфейс 53. При использовании WAN сетей персональный компьютер 20 имеет модем 54 или иные средства установления связи с глобальной вычислительной сетью 52, такой как Интернет. Модем 54, который является внутренним или внешним, подключен к системной шине 23 посредством последовательного порта 46. В сетевом окружении программные модули раскрытых персональных компьютеров 20 или части таких программ хранят в удаленных устройствах хранения данных. Следует уточнить, что сетевые соединения являются лишь примерными и не обязаны отображать точную сетевую конфигурацию сети, т.е. в действительности существуют иные способы установления логического соединения другими техническими средствами связи одного компьютера с другим.

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

Реферат

Изобретение относится к методам антивирусной защиты. Технический результат заключается в оптимизации выполнения задач безопасности путем конфигурации модулей системы безопасности в локальной сети. Настоящее изобретение предусматривает сбор данных о конфигурации найденных клиентов в сети, установку модуля системы безопасности на каждый из клиентов в соответствии с их конфигурацией, отслеживание выполнения задач безопасности на клиентах и сервере. Задача безопасности выполняется на клиенте при наличии на нем соответствующего модуля системы безопасности. Задача безопасности выполняется на сервере при отсутствии соответствующего модуля системы безопасности на клиенте. Далее происходит сбор статистики выполнения задач безопасности на клиентах и сервере и анализ выполнения задач безопасности на клиентах и сервере исходя из собранной статистики. Далее происходит изменение конфигураций модулей системы безопасности на стороне клиентов и сервера в соответствии с собранной статистикой. 3 н. и 15 з.п. ф-лы, 13 ил.

Формула