Способ обнаружения аномалии в поведении доверенного процесса и система для его реализации Российский патент 2023 года по МПК G06F21/50 G06N20/00 

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

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

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

Борьба с вредоносными программами – одна из самых важных задач современной компьютерной безопасности. В области технических средств противодействия вредоносным программам за последний десяток лет стал наблюдаться кризис. Соперничество между злоумышленниками, использующими вредоносные программы и уязвимости в программном обеспечении, и разработчиками антивирусного программного обеспечения привело к тому, что последние играют роль «догоняющих». Злоумышленники каждый раз изощряются при создании вредоносной программы или использовании уязвимости доверенных программ для получения выгоды.

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

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

• позволяют выстроить индивидуальную защиту устройства пользователя;

• не требуют частого обновления баз;

• способны обнаруживать как известные, так и неизвестные ранее угрозы.

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

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

Раскрытие изобретения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На Фиг. 1 представлен схематически пример реализации системы для осуществления способа обнаружения аномалий в поведении доверенных процессов на основании цепей Маркова и алгоритма машинного обучения.

На Фиг. 2 представлен пример базовой модели поведения доверенного процесса в виде ориентированного графа.

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

На Фиг. 4 представлена блок-схема, иллюстрирующая пример формирования базовой модели поведения и модели машинного обучения (Модель ML) для доверенного процесса.

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

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

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

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

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

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

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

Далее представлены некоторые варианты воплощения заявленного изобретения.

На Фиг. 1 представлен схематический пример реализации системы 100 для осуществления способа обнаружения аномалий в поведении доверенных процессов на основании цепей Маркова и алгоритма машинного обучения.

Система 100 включает такие средства, как: модуль обучения 110, хранилище данных 120, средство контроля 130 и средство анализа 140. В свою очередь хранилище данных 120 содержит статистические данные о работе процессов 150, базовые модели поведения 160 и модели ML (англ. Machine Learning – машинное обучение) 170.

Для реализации заявленного изобретения требуется провести сбор информации о работе программного обеспечения (ПО) на компьютерной системе, при этом если заявленное изобретение используется на нескольких компьютерных системах, объединенных в сеть, например, в корпоративную сеть, такой сбор может быть произведен на всех компьютерных системах (КС) сети. На основании информации об используемом ПО определяется перечень процессов, исполнение (работа) которых на КС будет считаться доверенным. Далее при помощи модуля обучения 110 формируется базовая модель поведения 160 и модель ML 170 для каждого ПО и его доверенного процесса. Каждая базовая модель поведения 160 основана на принципе цепи Маркова и дополнительно содержит весовой коэффициент для каждого события в цепочке. Базовая модель поведения 160 формируется на основании собираемой информации о работе ПО, которая представлена в виде поведенческого лога. Модель ML 170 представляет собой модель машинного обучения.

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

В другом варианте реализации базовые модели поведения 160 формируются непосредственно в начале работы, в режиме подготовки к работе. В этом режиме в реальном времени производится сбор информации о работе по крайней мере одного ПО во время его исполнения, формирование базовых моделей поведения 160 для этих процессов и формирование модели ML 170 для каждого ПО. Такой подход предпочтителен для не распространённого ПО либо при использовании в закрытой корпоративной сети.

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

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

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

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

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

Пример подхода формирования поведенческого лога (сбора информации) основан на следующем принципе.

Процесс операционной системы (ОС) Windows состоит из набора потоков, при этом каждый процесс состоит хотя бы из одного потока. ПО стартует с точки входа и исполняется до его завершения, при этом продолжительность работы может быть не ограничена. В процессе работы поток взаимодействует только со своей оперативной памятью. Для изменения состояния ОС (например, при выполнении чтения или записи в файл, работе с сетью или другими процессами) поток вызывает сервис ядра ОС с помощью одной из команд: syscall, sysenter или int XXh, т.е. происходит системный вызов. Все сервисы ядра пронумерованы, адреса их функции-обработчиков содержатся в системной таблице SSDT. Как правило, используются функции из системных библиотек ОС, которые являются обертками над этими вызовами (ntdll.dll, kernel32.dll и другие).

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

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

В еще одном варианте реализации хранилище данных 120 может находиться на удаленной КС, с которой производится взаимодействие через сеть, в частности, через сеть Интернет 190.

Модуль обучения 110 также предназначен для формирования модели машинного обучения (модель ML) 170. Модель ML для каждого ПО и его доверенного процесса формируется на базовых принципах формирования моделей машинного обучения для подобных задач, а именно для оценки вероятности наличия аномалии. Примерами моделей ML являются модели, созданные на одном или совместном использовании следующих принципов: наивном байесовском классификаторе (англ. naive Bayes classifiers), нейронных сетях (англ. artificial neural networks), дереве принятия решений (англ. decision tree), методе опорных векторов (англ. SVM, support vector machine).

Входными параметрами для обучения и дальнейшей работы каждой модели ML 170 являются параметры событий, происходящих во время работы доверенного процесса. В одном из вариантов реализации в качестве параметров используются текстовые данные (например, слова) из имен функций, которые встречались в происходящих событиях в доверенном процессе. Примером текстовых слов, которые соответствуют событиям, являются: CreateProcess, CreateFile и RegSetValue. В другом варианте реализации дополнительно в качестве параметров используются параметры функций. В еще одном варианте реализации модуль обучения 110 запрашивает модели ML 170 для необходимого ПО и соответствующих доверенных процессов у удаленного сервера, который содержит заранее сформированные модели ML 170 для различного ПО и соответствующих доверенных процессов, через сеть Интернет 190.

Стоит отметить, что в зависимости от реализации изобретения модуль обучения 110 может быть реализован и на другой КС. В этом случае связь с ним будет осуществляться через сеть, например, сеть Интернет 190.

После подготовки всех необходимых базовых моделей поведения 160 и обучения моделей ML 170 для обнаружения аномалий в поведении доверенных процессов на КС и их добавления в хранилище данных 120 заявленное изобретение переходит из режима подготовки к работе в режим основной работы.

В режиме основной работы при запуске нового доверенного процесса, например, процесса 105 с помощью средства контроля 130 производится его обнаружение. Затем средство контроля 130, обращаясь (делая запрос) к хранилищу данных 120, выбирает базовую модель поведения 160, которая соответствует обнаруженному доверенному процессу 105. После чего средство контроля 130 осуществляет контроль доверенного процесса 105. Во время контроля средство контроля 130 производит сравнение происходящих событий с событиями из базовой модели поведения 160, на основании которого в режиме реального времени подсчитывает общую вероятность появления происходящих событий. Подсчет осуществляется на основании определения вероятности происхождения (весового коэффициента) каждого события в цепочке событий из базовой модели поведения 160 и дальнейшего их перемножения между собой. При достижении заданного порога из пройденной части цепочки базовой модели поведения 160 извлекают данные и отправляют их средству анализа 140. Извлекаемыми данными является поведенческий лог, содержащий только произошедшие события, общая вероятность появления которых преодолела заданный порог, и параметры указанных событий. Например, в качестве параметров будут использованы текстовые слова, которые встретились в атрибутах произошедших событий.

Средство анализа 140 обращается (делает запрос) к хранилищу данных 120 для получения модели ML 170, которая соответствует анализируемому ПО. Далее средство анализа 140 передает полученные параметры от средства контроля 130 на вход модели МL 170. Средство анализа 140 с помощью модели ML 170 проводит анализ параметров. В одном из вариантов реализации модель ML разобьёт текстовые данные на слова, по которым и произведет анализ. По результатам анализа выносится решение о наличии аномального поведения в доверенном процессе. Так, например, решение будет говорить о наличии аномального поведения доверенного процесса, если в образовавшейся цепочке переходов между процессами и событиями вида: winword -> CreateProcess -> wmic -> CreateProcess, будут присутствовать строки: powershell и encodedcommand. Примером, когда решение будет говорить об отсутствии аномального поведения, будет являться сформированная цепочка вида: excel -> CreateProcess со строкой calc.exe.

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

Пример обнаружения аномалий в поведении доверенного процесса на примере исполняемого файла «winword.exe» программного обеспечения Microsoft Word.

Допустим, что для исполняемого файла «winword.exe» создана базовая модель поведения, выраженная в виде цепи Маркова, и обученная для нее модель ML.

Также предположим, что базовая модель поведения для доверенного процесса исполняемого файла «winword.exe» включает следующие события:

winword.exe выполнить:

Запуск приложения (Вероятность появления или весовой коэффициент: 0.9);

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

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

1. winword.exe (Вероятность: 1.0, так как является корневым процессом).

2. Запуск приложения (Вероятность: 0.9).

3. cmd.exe (Вероятность: 0.8).

4. Запуск приложения (Вероятность: 0.8).

5. svchost.exe (Вероятность: 0.2).

Следовательно, выход цепочки (общая вероятность появления произошедших событий) будет соответствовать: 1.0 х 0.9 х 0.8 х 0.8 х 0.2 = 0.11520000000000002.

Если заданный порог был равен 0.2, то общая вероятность его перешла. Соответственно, средство контроля 130 вынесет предварительное решение о наличии аномалии. Далее извлекаются данные и передаются средству анализа 140 на вход модели ML. Допустим, в качестве данных используются слова из атрибутов системных вызовов (например, имен функций и событий) из цепочки. Средство анализа 140 с помощью модели ML проводит анализ полученных данных по словам, на основании которых выносит окончательное решение об аномальном поведении.

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

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

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

На этапе 310 (предварительном) с помощью модуля обучения 110 проводят подготовительную работу, включающую создание базовой модели поведения и модели ML для по меньшей мере одного доверенного процесса. Указанная подготовительная работа представлена при описании Фиг. 1.

На этапе 320 с помощью средства контроля 130 обнаруживают запуск доверенного процесса.

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

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

На этапе 350 с помощью средства контроля 130 определяют, превышает ли общая вероятность заданный порог.

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

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

На этапе 370 с помощью средство анализа 140 выносят решение о наличии аномального поведения в доверенном процессе на основании анализа данных при помощи модели ML.

На Фиг. 4 представлена блок-схема, иллюстрирующая пример формирования базовой модели поведения и модели машинного обучения (Модель ML) для доверенного процесса. Представленный пример реализуется с помощью средств системы, представленных при описании Фиг. 1.

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

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

На этапе 430 с помощью модуля обучения 110 дополнительно запрашивают статистические данные о работе подобного доверенного процесса. Запрос направляется к хранилищу данных и/или к удаленному серверу.

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

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

На этапе 460 с помощью модуля обучения 110 обучают модель ML на основании выявленных параметров событий.

На этапе 470 с помощью модуля обучения 110 добавляют базовую модель поведения и модель ML в хранилище данных 120.

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

1. Способ обнаружения аномалии в поведении доверенного процесса, в соответствии с которым:

а. обнаруживают запуск доверенного процесса в компьютерной системе;

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

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

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

ii. определяют вероятность появления каждого события в доверенном процессе с помощью применения цепи Маркова и

iii. рассчитывают общую вероятность появления произошедших событий;

г. сравнивают общую вероятность появления произошедших событий с заданным порогом;

д. при превышении заданного порога выделяют события, которые произошли в процессе следования по цепи Маркова, и передают данные о событиях на вход Модели ML, при этом данные включают цепочку произошедших событий;

е. анализируют данные событий при помощи Модели ML, в результате анализа выносят решение об аномальном поведении.

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

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

4. Способ по п. 1, в котором Модель ML заранее обучена на вхождении текстовых слов, которые встречались в атрибутах событий в цепочке.

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

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

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

8. Способ по п. 7, в котором получают результат проверки ложного срабатывания, при этом если обнаружена ошибка в решении о выявленной аномалии, то проводят переобучение Модели ML путем переобучения совместно с данными, при анализе которых возникла ошибка.

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

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