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

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

Иллюстрации

Показать все

Реферат

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

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

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

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

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

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

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

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

Так, в патенте US 7523308 B2 описывается способ защиты компьютерной системы от использования уязвимостей приложений. Способ включает в себя наличие правил безопасности, содержащих условия, характеризующие соответствующие уязвимости и определяющие уровень безопасности. В случае выявления какого-либо действия в системе, на которое сработало правило, выполняются соответствующие действия по защите системы, например, блокирование приложения или ограничение доступа приложения к различным ресурсам, например, к Интернету.

В заявке US 20090038015 A1 описан способ защиты компьютерной системы от известной уязвимости во время отсутствия обновления для устранения выявленной уязвимости. На первом этапе защиты системы создается «датчик обнаружения» для конкретной уязвимости, содержащейся в приложении. «Датчик обнаружения» создается на основе информации, содержащейся в бюллетени безопасности, раскрывающей сведения об уязвимости в приложении. Далее производится выявление атак на систему через данную уязвимость приложения с последующим блокированием выявленной атаки или информированием администратора.

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

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

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

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

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

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

В одном из вариантов исполнения способа анализ указанного приложения на этапе б) проводится, по крайней мере, с помощью одного из способов:

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

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

- анализа приложения во время эмуляции указанного приложения,

- анализа приложения различными системами контроля и наблюдения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Краткое описание прилагаемых чертежей

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

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

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

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

Фиг.3 иллюстрирует алгоритм контроля приложений, содержащих уязвимости.

Фиг.4 иллюстрирует схему настройки правил ограничения.

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

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

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

На Фиг.1 представлена система контроля приложений, содержащих уязвимости. Система контроля приложений 100 в одном из вариантов реализации относится к так называемым системам «application control». Системы «application control» предназначены для контроля приложений 70 с помощью перечня правил контроля приложений, который позволяет контролировать, по крайней мере, одно из приложений 70 или целые группы приложений 70 за счет ограничения действий (активностей), совершаемых в процессе исполнения данных приложений. Стоит отметить, что причины контроля приложений могут быть различны. Одной из причин является защита компьютерных систем от атак через приложения, содержащие уязвимости. Поэтому с этой целью система контроля приложений 100 (далее - система 100) проверяет приложения 70 на содержание, по крайней мере, одной уязвимости и формирует правила контроля приложений в случае выявления, по крайней мере, одной уязвимости у приложения. Стоит отметить, что система контроля приложений 100 позволяет контролировать приложения, содержащие как известные уязвимости, так и неизвестные уязвимости. В представленном варианте реализации система контроля приложений 100 содержит средство контроля приложений 110, базу правил ограничения 120, средство проверки приложения на наличие уязвимости 130, базу знаний 140 (содержащую, по крайней мере, информацию о приложениях и их уязвимостях), средство анализа приложений 150 и средство формирования правил ограничения 160.

Средство контроля приложений 110 предназначено для контроля приложений, содержащих, по крайней мере, одну уязвимость, с помощью правил ограничения, хранящихся в базе правил ограничения 120, и передачи каждого запускаемого приложения, которое не контролируется соответствующими правилами ограничения из базы правил ограничения 120, средству проверки приложения на наличие уязвимости 130. Правила ограничения позволяют блокировать действия, не соответствующие типичным действиям контролируемого приложения. Под типичными действиями приложения в настоящей заявке понимаются такие действия, которые совершаются приложением при выполнении команд и инструкций, заложенных при создании производителем данного приложения, и которые направлены на выполнение задачи, соответствующей данному приложению. Например, для приложения «Adobe Acrobat» типичными действиями являются следующие действия: действие «открыть файл» и действие «сохранить файл», но в тоже время действие «сохранить исполняемый файл на диске» или действия, направленные на «запуск процесса из исполняемого файла», являются нетипичными действиями для указанного приложения. В частном случае реализации в случае выявления нетипичного действия для контролируемого приложения средство контроля приложений 110 может блокировать всю работу контролируемого приложения 70 или частично ограничивать выполнение контролируемого приложения 70, например, блокировать только доступ к корпоративной сети или сети Интернет (более конкретно будет описано на Фиг.2).

Средство проверки приложения на наличие уязвимости 130 (далее - средство проверки 130) проводит проверку полученного приложения 70 на наличие уязвимостей. Проверка основана на определении принадлежности проверяемого приложения 70 к категории приложений, содержащих уязвимости, с помощью базы знаний 140. База знаний 140 хранит информацию обо всех приложениях, содержащих, по крайней мере, одну уязвимость, и предоставляет ее средству проверки 130 по требованию. Стоит отметить, что база знаний 140 производит обновления информации с помощью получения новой информации из внешних источников информации 80, например, из базы данных антивирусной компании (антивирусного сервера), из баз данных компаний, специализирующихся на выявлении новых уязвимостей приложений, или из баз данных поставщиков приложений (программного обеспечения). Кроме того, в частном случае реализации база знаний 140 может размещаться отдельно от остальных средств системы 100, например, на удаленном антивирусном сервере. Итак, во время проверки средство проверки 130 определяет, относится ли проверяемое приложение к категории уязвимых приложений или нет. В том случае, если приложение не соответствует указанной категории, т.е. не было выявлено ни одной уязвимости у проверяемого приложения в базе знаний 140, то проверка данного приложения закончится. После чего приложение продолжит работу. В противном случае, если определено, что проверяемое приложение относится к категории уязвимых приложений (т.е. была выявлена, по крайней мере, одна уязвимость у приложения), то данное приложение передается средству анализа приложений 150 для последующего анализа.

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

В еще одном частном случае реализации после выявления у приложения, по крайней мере, одной уязвимости средство проверки 130 проводит поиск выпущенного обновления, устраняющего соответствующую уязвимость в приложении. Поиск будет проводиться с помощью базы знаний 140, в которую передается соответствующая информация из внешних источников информации 80 на периодической основе. После выявления соответствующих обновлений для приложений, содержащих уязвимости, система 100 установит автоматически или предложит установить пользователю данные обновления с последующим ослаблением или полным удалением соответствующих правил ограничения приложения, если обновления будут применены для приложения. Стоит отметить, что удаление правил ограничения приложения будет произведено только в случае отсутствия еще каких-либо известных уязвимостей в приложении. Ослабление правил ограничения приложений возможно, в случае если оставшиеся уязвимости в приложении не соответствуют критическому уровню опасности (определение уровня опасности уязвимости рассмотрено при описании Фиг.2).

Средство анализа приложений 150 проводит анализ предоставленного приложения таким образом, чтобы создать список типичных действий для данного приложения. Способы создания списка типичных действий будут рассмотрены при описании Фиг.2. Как было описано выше, под типичными действиями приложения понимаются такие действия, которые совершаются приложением при выполнении команд и инструкций, заложенных при создании производителем данного приложения, и которые направлены на выполнение задачи, соответствующей данному приложению. После создания списка типичных действий для предоставленного приложения средство анализа приложений 150 передает данный список типичных действий средству формирования правил ограничения 160.

Средство формирования правил ограничения 160 создает, по крайней мере, одно правило ограничения приложения на основе полученного списка типичных действий от средства анализа приложений 150. Правила ограничения создаются таким образом, чтобы во время исполнения соответствующего приложения, данные правила ограничения разрешали совершать только действия из списка типичных действий для данного приложения, а все остальные действия блокировали (так как все остальные действия являются нетипичными действиями для данного приложения). Так, например, для приложения «MS Word» были созданы правила ограничения, блокирующие все действия, не попавшие в ранее созданный список типичных действий. Далее во время исполнения указанного приложения было выявлено, что приложение пытается сохранить исполняемый файл (например, РЕ - формата), а так как данное действие не соответствует списку типичных действий, то, следовательно, такое действие будет заблокировано средством контроля приложений 110. Далее средство формирования правил ограничения 160 направляет все созданные правила ограничения в базу правил ограничения 120 для последующего использования средством контроля приложений 110.

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

Одним из вариантов формирования рейтинга популярности может являться сбор и анализ информации о запуске приложений. Таким образом, один из внешних источников информации 80, например антивирусный сервер, собирает информацию с ПК пользователей сети о запусках всех приложений. Затем антивирусный сервер 80 разделяет полученную информацию по приложениям и подсчитывает количество запусков каждого приложения. После чего антивирусный сервер 80 формирует рейтинг популярности того или иного приложения и направляет данный рейтинг в базу знаний 140.

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

На Фиг.2 представлен пример схемы работы средства анализа приложений 150 во время создания списка типичных действий. В одном из вариантов реализации средство анализа приложений 150 состоит из модуля сбора информации о приложении 220 (далее - модуль сбора 220), модуля анализа уязвимости 240, модуля контроля и наблюдения за действиями приложения 260 (далее - модуль 260) и модуля создания списка типичных действий на основе анализа предоставленных данных 280 (далее - модуль 280).

Модуль сбора 220 предназначен для сбора информации о работе приложения, а именно о действиях, совершаемых приложением во время работы. Сбор информации осуществляется с помощью запроса к внешним источникам информации 80 и последующего получения соответствующего ответа от внешних источников информации 80. В качестве внешних источников информации 80 могут быть как ранее перечисленные базы данных при описании Фиг.1, так и другие источники информации, например, персональные компьютеры (ПК) пользователей, на которых используется данное приложение. После чего модуль сбора 220 передает собранную информацию модулю 280 для последующего анализа. Стоит отметить, что указанная информация о действиях приложения может быть предварительно собрана и объединена на одном из внешних источников информации 80. Тогда модуль сбора 220 будет обращаться только к нему, например, к удаленному антивирусному серверу. Также стоит отметить, что модуль 220 может проводить периодическую проверку наличия новой информации о действиях приложения.

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

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

1) во время исполнения приложения формировать журнал событий, который содержит все произошедшие события (например, системные вызовы),

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

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

Модуль 280 предназначен для формирования списка типичных действий на основе анализа информации, предоставленной модулями 220, 240 и 260. Стоит отметить, что для создания списка типичных действий модулю достаточно иметь, по крайней мере, информацию от модуля сбора 220 или от модулей 240 и 260. Но для более точного формирования списка типичных действий целесообразно использовать информацию от всех модулей.

Итак, анализ содержит три этапа. На первом этапе модуль 280 проводит анализ информации, предоставленной модулем сбора 220. Анализ заключается в выявлении типичных действий среди всех действий, произошедших во время исполнения приложения у всех источников информации 80. Как ранее отмечалось, в качестве источников информации 80 могут быть как базы данных, содержащие информацию о типичных действиях, например, от компаний - производителей приложений, так и, по меньшей мере, один ПК пользователя, предоставляющий информацию о совершенных действиях во время работы приложения. Примерами выявления типичных действий в данном случае являются:

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

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

Также модуль 280 из информации, предоставленной модулем 220, может выявлять и аномальные действия. Например, если какое-либо действие было выявлено только у 25% или меньше источников информации (т.е. является редким), а при этом еще был выявлен эксплойт, использующий данное действие, то такое действие является аномальным. На втором этапе модуль 280 анализирует информацию, полученную от модуля 240 и модуля 260. Анализ основан на сравнении перечней совершенных действий. Так как модуль 240 предоставил перечень совершенных действий, которые являются аномальными, а модуль 260 предоставил перечень всех совершенных действий при анализе приложения, то модуль 280 из перечня всех совершенных действий (от модуля 260) удалит действия, встретившиеся в перечне аномальных действий (от модуля 240). Таким образом, модуль 280 сформирует список типичных действий приложения. На третьем этапе модуль 280 сравнит сформированные списки типичных действий на этапах один и два. После чего сформирует заключительный список типичных действий из действий, попавших в оба списка. Стоит отметить, что модуль 280 может использовать этапы один (анализ информации, полученной от модуля сбора 220) и два (анализ информации, полученной от модулей 240 и 260) как совместно, так и исключая один из них.

В одном из частных вариантов реализации системы 100, средство анализа приложений 150, кроме списка типичных действий, будет определять уровень опасности каждой известной уязвимости анализируемого приложения 20. В зависимости от уровня опасности уязвимости средство 150 будет передавать средству формирования правил ограничения 160 информацию по созданию дополнительных правил ограничения, направленных на частичное ограничение выполнения действий соответствующего приложения 20. В одном из вариантов реализации, уровень опасности уязвимости будет определяться в соответствии со способом определения уровня опасности компанией Microsoft, описанном по адресу http://technet.microsoft.com/ru-ru/security/dn144685.aspx и представленном в Таблице 1.

Таблица 1
Уровень опасности	Определение
Критический	Уязвимость, использование которой делает возможным распространение Интернет-червя без вмешательства пользователя
Существенный	Уязвимость, использование которой может подвергнуть опасности конфиденциальную информацию, целостность или доступность данных пользователей либо обрабатываемых ресурсов
Средний	Уязвимость, использование которой значительно сдерживается такими факторами, как стандартная конфигурация, аудит или трудность использования
Низкий	Уязвимость, которой крайне сложно воспользоваться или воздействие которой минимально

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