СИСТЕМА И СПОСОБ ВРЕМЕННОЙ ЗАЩИТЫ ОПЕРАЦИОННОЙ СИСТЕМЫ ПРОГРАММНО-АППАРАТНЫХ УСТРОЙСТВ ОТ ПРИЛОЖЕНИЙ, СОДЕРЖАЩИХ УЯЗВИМОСТИ Российский патент 2015 года по МПК G06F21/55 G06F11/00 

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

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

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

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

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

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

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

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

Так, в патенте 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 сформирует дополнительные правила ограничения приложения. Примерами дополнительных правил ограничения могут являться следующе правила: правило ограничения, направленное на блокирование тех действий, которые совершаются во время исполнения уязвимости (например, правило будет запрещать совершать действия, связанные с работой в Интернете или с загрузкой какого-либо файла, т.е. производить частичное ограничение функционала приложения); правило ограничения, блокирующее все действия приложения, в случае отсутствия какой-либо защищенной среды (таким образом, приложение будет работать только в защищенной среде, например, sandbox); скорректированное действующее правило ограничения, которое дополнительно формирует запрос к пользователю, который, в свою очередь, содержит вопрос о разрешении совершения конкретного действия или запуска приложения.

На Фиг.3 представлен алгоритм контроля приложения, содержащего уязвимость. На этапе 310 средство контроля приложений 110 выявляет запуск каждого приложения 20. На этапе 330 средство проверки приложения на наличия уязвимости 130 (далее - средство проверки 130) определяет принадлежность запускаемого приложения 70 к категории уязвимых приложений. Стоит отметить, что к категории уязвимых приложений относятся приложения, содержащие, по крайней мере, одну уязвимость. Принадлежность приложения 70 к категории уязвимых приложений средство проверки 130 будет определять с помощью запроса-ответа к базе знаний 140, содержащей информацию обо всех уязвимых приложениях. В случае если запускаемое приложение 70 не содержит ни одной уязвимости, то средство проверки 130 информирует об этом средство контроля приложений 110, которое, в свою очередь, производит выполнение приложения 70 на этапе 340. В случае если запускаемое приложение содержит, по крайней мере, одну уязвимость, то средство проверки 130 передает данное приложение 70 средству анализа приложений 150. На этапе 350 средство анализа приложений 150 проводит анализ запускаемого приложения 70 с целью выявления типичных действий, совершаемых запускаемым приложением 70. Под типичными действиями приложения в настоящем изобретении понимаются такие действия, которые совершаются при выполнении команд и инструкций, заложенных при создании производителем данного приложения, и которые направлены на выполнение задачи, соответствующей данному приложению. Способы выявления типичных действий аналогичны рассмотренным способам при описании Фиг.2. Далее на этапе 360 средство анализа приложения формирует список типичных действий запускаемого приложения 70 и передает данный список типичных действий средству формирования правил ограничения 160. На этапе 370 средство формирования правил ограничения 160 создает, по крайней мере, одно правило ограничения для контроля запускаемого приложения 70 на основе полученного списка типичных действий. Правило ограничения создается таким образом, чтобы соответствующему приложению было разрешено совершать только действия из созданного списка типичных действий, а все остальные действия блокировались. На этапе 380 средство формирования правил ограничения 160 добавит все созданные правила ограничения для запускаемого приложения 70 в базу правил ограничения 120. Далее на заключительном этапе 390 средство контроля приложений 110 разрешит запуск приложения 70, производя контроль данного приложению 70 с помощью добавленных правил ограничения.

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

В еще одном частном случае реализации после этапа 310 средство 110 может предварительно определять, контролируется ли запускаемое приложение 70 каким-либо правилом ограничения из базы правил ограничения 120. В случае если запускаемое приложение 70 будет контролироваться, по крайней мере, одним правилом ограничения из базы 120, то средство 110 разрешит запуск приложения 70, применяя, по крайней мере, одно найденное правило ограничения для контроля запускаемого приложения 70, и данное приложение будет выполняться на этапе 340. В противном случае, если не было выявлено ни одного правила ограничения из базы правил ограничения 120, запуск приложения приостанавливается, а приложение 70 передается средству проверки 130 на этап 350.

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

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

После создания списка аномальных действий средство анализа приложений 150 на этапе 430 определяет уровень опасности уязвимости. Пример определения уровня опасности был раскрыт при описании Фиг.2. Далее на этапе 440 определяется, соответствует ли уровень опасности уязвимости уровню выше среднего. В описанном случае, если уровень опасности был определен как критический или существенный, то уровень опасности соответствует уровню выше среднего. В противном случае, если уровень опасности соответствует уровню средний или низкий, то уровень опасности соответствует уровню ниже среднего. Кроме того, если уровень опасности ниже среднего, то данная уязвимость не учитывается для создания дополнительных правил ограничения, и работа заканчивается. Если же уровень опасности выше среднего, то средство анализа приложений 150 направляет средству формирования правил ограничения 160 сформированный список аномальных действий. На этапе 450 средство формирования правил ограничения 160 создает, по крайней мере, одно дополнительное правило ограничения на основе списка аномальных действий для ограничения действий во время исполнения приложения, содержащего соответствующую уязвимость. Стоит отметить, что дополнительное правило ограничения, основанное на списке аномальных действий, будет запрещать приложению совершать действия, содержащиеся в данном списке. После чего средство формирования правил ограничения 160 добавит созданное правило ограничения в базу правил ограничения 120 и закончит работу на этапе 460.

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

Фиг.5 представляет пример компьютерной системы общего назначения (может быть как персональным компьютер, так и сервером) 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, представленного на Фиг.5. В вычислительной сети могут присутствовать также и другие устройства, например, маршрутизаторы, сетевые станции, пиринговые устройства или иные сетевые узлы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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