Область техники
Настоящее изобретение относится к области информационной безопасности в компьютерных системах и сетях, в частности к серверу и способу для определения вредоносных файлов в сетевом трафике.
Уровень техники
В настоящее время, ввиду непрерывного научно-технического прогресса в области информационных технологий, все большую актуальность приобретают вопросы обеспечения информационной безопасности, в частности защиты от целенаправленных атак злоумышленников.
Целевые или таргетированные атаки представляют собой атаки, направленные на конкретную организацию, группу компаний, отрасль или т.п. и реализуемые в целом в течение длительного периода времени с использованием значительных ресурсов злоумышленников. При проведении таких целевых атак часто используют вредоносный код, разработанный или модифицированный специально для достижения целей злоумышленников. В уровне техники вышеуказанные атаки также часто называют целевыми кибератаками или атаками типа «развитая устойчивая угроза» (Advanced Persistant Threats, APT). Основными особенностями атак данного вида атак являются длительный характер воздействия на цель и сложность их обнаружения. Злоумышленник «закрепляется» в скомпрометированной информационной системе и действует максимально скрытно, за счет чего он длительное время сохраняет контроль и доступ к конфиденциальной информации. Изначально объектами целевых атак становились крупные правительственные организации, объекты военной и промышленной инфраструктуры, крупные банки, однако с течением времени у большего числа злоумышленников появлялась возможность использования скриптов типа «эксплойт» (exploit) и угроз «нулевого дня» (zero day), в следствие чего значительно расширился круг потенциальных целей. На сегодняшний день следует уже говорить не только об угрозах целевых атак в их изначальном понимании, но и о более массовых атаках с использованием модифицированных вирусов, позволяющих обходить стандартные сигнатурные методы обнаружения и блокировки. В алгоритме проведения большинства целевых атак можно выявить последовательность действий, предпринимаемых злоумышленником при подготовке и проведении своей атаки. В уровне техники такую последовательность действий злоумышленника называют «убийственная» цепочка (Cyber-Kill Chain). В рамках этой цепочки выделяют семь стадий проведения атаки. Первая стадия заключается в проведении разведки (reconnaissance). Согласно первой стадии злоумышленник собирает данные о потенциальной жертве и анализирует возможные пути проникновения в информационную систему, при этом для сбора необходимой информации злоумышленник часто использует открытые источники данных, такие как профайлы в социальных сетях, сайты компании, списки, рассылки и т.п. Вторая стадия заключается в вооружении (weaponization). Согласно второй стадии злоумышленники подготавливают файл с вредоносным содержимым, обычно имеющий широко используемый формат, такой как, например, PDF-формат или форма файла из Microsoft Office, для его дальнейшей доставки жертве. Третья стадия заключается в доставке (delivery) подготовленного вредоносного файла. Согласно третьей стадии злоумышленники доставляют жертве вредоносный файл посредством электронного сообщения (e-mail), веб-ресурса или носителя данных, такого как USB-флешка. Четвертая стадия заключается в заражении (exploitation) рабочей станции жертвы. Согласно четвертой стадии вредоносный код запускают на целевой рабочей станции жертвы. Пятая стадия заключается в установке (installation) вредоносной программы на целевой рабочей станции жертвы. Шестая стадия заключается в получении управления (command and control) над зараженной рабочей станцией. Согласно шестой стадии организуют скрытый канал управления зараженной рабочей станцией, а также осуществляют получение дополнительных модулей вредоносного кода и обеспечивают взаимодействие с C&C-серверами. Седьмая стадия является заключительной и состоит в выполнении запрограммированных действий (actions on objective). Согласно седьмой стадии собирают и крадут конфиденциальные данные, шифруют файлы, перехватывают управление, подменяют данные и осуществляют иные действия в зависимости от целей такой атаки.
В настоящее время рынок решений по противодействию и обнаружению целевых атак и сложных типов APT-атак находится в стадии становления. Наиболее распространенные средства защиты от АРТ-атак представляют собой специализированные программно-аппаратные комплексы, работающие на уровне сети и основанные на анализе аномальной сетевой активности (Network Behaviour & Anomaly Detection). Обычно такие решения собирают информацию о сетевой активности посредством SPAN-протокола и NetFlow-протокола, строят эталонную модель активности в сети и отслеживают возникающие отклонения. К недостаткам данного типа решений можно отнести невозможность работы в режиме блокирования и сравнительно высокие требования к квалификации эксплуатирующего персонала.
Кроме того, существуют решения типа «защита конечных точек нового поколения» (Next-Generation/Advanced Endpoint Protection). В основе таких решений лежат не сигнатурные методы обнаружения, а алгоритмы отслеживания аномальной и/или опасной активности на рабочей станции пользователя. Принципы работы таких решений могут существенно различаться в зависимости от конкретного решения и его производителя, в частности в основе работы может лежать машинное обучение, поведенческий анализ, механизмы «контейнеризации» и формирование списка разрешенного программного обеспечения (white listening), мониторинг системных процессов и файлов.
Вышеописанные средства защиты могут быть полезными в качестве «последнего эшелона», однако, ввиду их недостаточной эффективности, они явно не подходят для их использования в качестве единственного средства защиты от АРТ-атак.
В настоящее время одним из наиболее эффективных решений из имеющихся на рынке средств и систем защиты являются специализированные программно-аппаратные комплексы, называемые в уровне техники как «песочницы». Такие средства защиты позволяют проводить автоматизированный статистический и динамический анализ подозрительных файлов в виртуализированной среде и, при необходимости, блокировать их, что позволяет безопасно оценить «поведение» и последствия открытия подозрительного файла. При этом решения данного класса полагаются не на сигнатурные механизмы обнаружения вредоносного кода, а на оценку действий, выполняемых кодом, их безопасности и корректности в данном программном окружении. Подозрительный файл автоматически анализируют в виртуальной среде, идентичной сборке операционной системы (версия операционной системы, прикладное программное обеспечение и т.п.), используемой пользователем на своей рабочей станции. В отличие от альтернативных решений по защите от целевых атак «песочницы» позволяют не только обнаруживать следы целевой атаки в информационной системе, но и позволяют заблокировать эту атаку еще на стадии доставки зловредного кода пользователю-жертве. Кроме того, независимость от сигнатурных методов детектирования позволяет «песочницам» обнаруживать вредоносный код «нулевого дня», специально разработанный или модифицированный для проведения целевой атаки.
Один из иллюстративных примеров «песочницы» описан в патенте США №8,776,229 (G06F 21/00, H04L 29/06, G06F 21/56; опубликован 08 июля 2014 года).
В US 8776229 раскрыта система для обнаружения вредоносного сетевого трафика, содержащая анализирующее устройство для анализа сетевого трафика и сетевое устройство. Анализирующее устройство в системе по US 8776229 выполнено с возможностью анализа сетевого трафика, принимаемого по сети связи, и возможностью создания копии сетевых пакетов данных из принятого сетевого трафика, в отношении которых, с помощью эвристического анализа на соответствие эвристическому пороговому значению, определено, что их характеристики связаны с вредоносным трафиком. Сетевое устройство в системе по US8776229 содержит управляющий блок, имеющий связь с одной или более виртуальными машинами, выполненными с возможностью (i) приема копий сетевых пакетов данных от анализирующего устройства; (ii) отслеживания поведения первой виртуальной машины из указанных виртуальных машин в ответ на обработку принятых копий пакетов данных в этой первой виртуальной машине; (iii) идентификации аномального поведения как непредвиденного события в отслеживаемом поведении и (iv) определения, на основании идентифицированного аномального поведения, наличия вредоносного трафика в копиях сетевых пакетов данных.
Следует отметить, что реализация механизмов защиты, описанных в патенте US 8776229, требует значительных вычислительных ресурсов, в результате чего реализация такой защитной системы на уровне конечных рабочих станций или серверов часто либо невозможна, либо неэффективна.
Таким образом, очевидна потребность в дальнейшем совершенствовании систем и способов защиты от целенаправленных атак, для организации которых злоумышленники используют передаваемые по сети файлы широко используемых форматов с вредоносным содержимым, в частности для эффективного распределения вычислительных ресурсов, затрачиваемых на обеспечение такой автоматизированной защиты.
Следовательно, техническая проблема, решаемая настоящим изобретением, состоит в создании системы и способа для определения вредоносных файлов в сетевом трафике, в которых по меньшей мере частично устранён обозначенный выше недостаток известных систем и способов защиты, заключающийся в неэффективном использовании вычислительных ресурсов при обеспечении автоматизированной защиты.
Раскрытие сущности
Вышеупомянутая техническая проблема решена в одном из аспектов настоящего изобретения, согласно которому предложен сервер для определения вредоносных файлов в сетевом трафике, содержащий: модуль связи, выполненный с возможностью получения сетевого трафика из сети передачи данных, фильтрующий модуль, выполненный с возможностью подключения к модулю связи для получения от него захваченного сетевого трафика и возможностью выполнения по меньшей мере следующих операций: (i) извлечение множества файлов из полученного сетевого трафика, (ii) анализ указанных извлеченных файлов с обеспечением выявления по меньшей мере одного подозрительного файла из указанного множества файлов, модуль системного мониторинга, выполненный с возможностью подключения к фильтрующему модулю для получения от него указанных подозрительных файлов и возможностью выполнения по меньшей мере следующих операций: (i) запуск каждого полученного подозрительного файла по меньшей мере на одной виртуальной машине, характеризующейся заданным набором параметров состояния, и (ii) регистрация изменений в заданном наборе параметров состояния указанной по меньшей мере одной виртуальной машины, и процессинговый модуль, выполненный с возможностью подключения к модулю системного мониторинга для получения от него зарегистрированных изменений параметров состояния и с возможностью анализа полученных изменений параметров состояния с использованием заданного набора правил анализа с обеспечением отнесения указанного запущенного файла к вредоносным файлам, если проанализированные изменения параметров состояния характерны для вредоносных файлов.
В одном из вариантов реализации настоящего изобретения серверный модуль связи может быть дополнительно выполнен с возможностью подключения по меньшей мере к одному из устройств захвата сетевого трафика, включенных в сеть передачи данных.
Еще в одном варианте реализации настоящего изобретения при анализе извлеченных файлов серверный фильтрующий модуль может проверять, является ли подозрительным формат каждого из указанных извлеченных файлов, с обеспечением отнесения проверяемого файла к доверенным файлам, если его формат не является подозрительным, или к подозрительным файлам, если его формат является подозрительным.
В другом варианте реализации настоящего изобретения при проверке формата каждого из указанных извлеченных файлов на подозрительность, серверный фильтрующий модуль может выполнять по меньшей мере следующие операции: (i) идентификация формата каждого из указанных извлеченных файлов, (ii) получение данных об известных вредоносных форматах файлов, (iii) установление совпадения идентифицированного формата каждого извлеченного файла с одним из известных вредоносных форматов файлов из указанных полученных данных.
В некоторых вариантах реализации настоящего изобретения в ответ на то, что формат извлеченного файла является подозрительным, серверный фильтрующий модуль может быть дополнительно выполнен с возможностью определения, имеется ли поведенческий отчет для извлеченного файла с подозрительным форматом.
В других вариантах реализации настоящего изобретения при выявлении наличия поведенческого отчета серверный фильтрующий модуль может выполнять по меньшей мере следующие операции: (i) получение данных о поведенческих отчетах, (ii) вычисление хеш-суммы каждого извлеченного файла, (iii) установление, путем сравнения вычисленной хеш-суммы извлеченного файла с хеш-суммами, идентифицирующими поведенческие отчеты в указанных полученных данных, соответствия каждого извлеченного файла одному из имеющихся поведенческих отчетов.
Еще в одних вариантах реализации настоящего изобретения в ответ на то, что для извлеченного файла с подозрительным форматом имеется поведенческий отчет, серверный фильтрующий модуль может быть дополнительно выполнен с возможностью проверки, является ли имеющийся поведенческий отчет актуальным, с обеспечением отнесения извлеченного файла к доверенным файлам или вредоносным файлам в случае признания его таковым в актуальном поведенческом отчете.
Согласно одному из вариантов реализации настоящего изобретения, в ответ на то, что имеющийся поведенческий отчет не является актуальным, серверный фильтрующий модуль может быть дополнительно выполнен с возможностью проверки, подписан ли анализируемый файл доверенной электронной подписью, с обеспечением отнесения проверяемого файла к доверенным файлам, если он подписан доверенной электронной подписью.
Согласно еще одному варианту реализации настоящего изобретения, при проверке наличия у извлеченного файла доверенной электронной цифровой подписи серверный фильтрующий модуль может выполнять по меньшей мере следующие операции: (i) идентификация владельца электронной подписи, которой подписан извлеченный файл, (ii) получение данных о доверенных владельцах электронных подписей, (iii) установление совпадения идентифицированного владельца электронной подписи с одним из доверенных владельцев электронных подписей из указанных полученных данных.
Согласно другому варианту реализации настоящего изобретения, в ответ на то, что извлеченный файл не подписан доверенной электронной подписью, серверный фильтрующий модуль может быть дополнительно выполнен с возможностью проверки, происходит ли указанный файл из доверенного источника данных, с обеспечением отнесения проверяемого файла к доверенным файлам, если он происходит из доверенного источника данных.
Согласно некоторым вариантам реализации настоящего изобретения, при проверке происхождения извлеченного файла серверный фильтрующий модуль может выполнять по меньшей мере следующие операции: (i) определение источника извлеченного файла, (ii) получение данных о доверенных источниках, (iii) установление совпадения определенного источника происхождения анализируемого файла с одним из доверенных источников данных из указанных полученных данных.
Согласно другим вариантам реализации настоящего изобретения, в ответ на то, что извлеченный файл не происходит из доверенного источника данных, серверный фильтрующий модуль может быть дополнительно выполнен с возможностью проверки, был ли присвоен извлеченному файлу идентификатор доверенного файла, с обеспечением отнесения проверяемого файла к доверенным файлам, если ему был присвоен идентификатор доверенного файла.
Согласно другим вариантам реализации настоящего изобретения, при проверке наличия у извлеченного файла идентификатора доверенного файла серверный фильтрующий модуль может выполнять по меньшей мере следующие операции: (i) вычисление хеш-суммы извлеченного файла, (ii) получение данных о доверенных файлах, каждый из которых поставлен в соответствие с конкретной хеш-суммой, (iii) установление совпадения вычисленной хеш-суммы анализируемого файла с хеш-суммой одного из доверенных файлов из указанных полученных данных.
В одном из вариантов реализации настоящего изобретения в ответ на то, что извлеченный файл не имеет идентификатора доверенного файла, серверный фильтрующий модуль может быть дополнительно выполнен с возможностью передачи извлеченного файла в модуль системного мониторинга.
Еще в одном варианте реализации настоящего изобретения для запуска каждого подозрительного файла в указанной виртуальной машине модуль системного мониторинга дополнительно выполнен с возможностью выполнения по меньшей мере следующих операций: (i) идентификация по меньшей мере одного атрибута каждого полученного подозрительного файла, (ii) получение данных об имеющихся виртуальных машинах, каждая из которых характеризуется заданным набором атрибутов настройки, (iii) выявление в имеющихся виртуальных машинах из указанных полученных данных дефолтной виртуальной машины, по меньшей мере один атрибут настройки которой из заданного набора атрибутов настройки совпадает с указанным идентифицированным атрибутом подозрительного файла, (iv) запуск подозрительного файла в выявленной дефолтной виртуальной машине с обеспечением идентификации по меньшей мере ещё одного атрибута запущенного файла и установление совпадения указанного еще одного идентифицированного атрибута по меньшей мере еще с одним из указанных атрибутов настройки дефолтной виртуальной машины, (v) в случае, если указанный по меньшей мере еще один идентифицированный атрибут запущенного файла не совпадает с указанным по меньшей мере еще одним атрибутом настройки дефолтной виртуальной машины, повторный запуск подозрительного файла еще на одной виртуальной машине из имеющихся виртуальных машинах, указанные атрибуты настройки которой совпадают с указанными атрибутами подозрительного файла.
В некоторых вариантах реализации настоящего изобретения при регистрации изменений в заданном наборе параметров состояния указанной по меньшей мере одной виртуальной машины модуль системного мониторинга отслеживает указанные изменения в течение заданного периода времени, составляющего 2-3 минуты.
В других вариантах реализации настоящего изобретения серверный модуль системного мониторинга может дополнительно обеспечивать возможность изменения заданного набора параметров состояния каждой виртуальной машины и/или возможностью изменения заданного набора правил анализа.
Еще в одних вариантах реализации настоящего изобретения в ответ на отнесение файла, запущенного на указанной по меньшей мере одной виртуальной машине, к вредоносным файлам, серверный модуль системного мониторинга может дополнительно обеспечивать возможность выдачи предупредительного сообщения, блокировки вредоносного файла, блокировки источников вредоносного файла, внесение вредоносного файла в базу данных вредоносных файлов и/или создание поведенческого отчета для вредоносного файла.
Вышеупомянутая техническая проблема также решена еще в одном из аспектов настоящего изобретения, согласно которому предложен способ определения вредоносных файлов в сетевом трафике, исполняемый на сервере и включающий: (i) получение, посредством серверного модуля связи, сетевого трафика из сети передачи данных, (ii) извлечение, посредством серверного фильтрующего модуля, множества файлов из полученного сетевого трафика, (iii) анализ, посредством серверного фильтрующего модуля, указанных извлеченных файлов с обеспечением выявления по меньшей мере одного подозрительного файла из указанного множества файлов, (iv) запуск, посредством серверного модуля системного мониторинга, каждого полученного подозрительного файла по меньшей мере на одной виртуальной машине, характеризующейся заданным набором параметров состояния, (v) регистрация, посредством серверного модуля системного мониторинга, изменений в заданном наборе параметров состояния указанной по меньшей мере одной виртуальной машины и (vi) анализ, посредством процессингового модуля, полученных изменений параметров состояния с использованием заданного набора правил анализа с обеспечением отнесения указанного запущенного файла к вредоносным файлам, если проанализированные изменения параметров состояния характерны для вредоносных файлов.
В одном из вариантов реализации настоящего изобретения этап получения сетевого трафика из сети передачи данных в предложенном способе может включать подключение, посредством серверного модуля связи, по меньшей мере к одному из устройств захвата сетевого трафика, включенных в сеть передачи данных.
Еще в одном варианте реализации настоящего изобретения этап анализа извлеченных файлов в предложенном способе может включать проверку, является ли подозрительным формат каждого из указанных извлеченных файлов, с обеспечением отнесения проверяемого файла к доверенным файлам, если его формат не является подозрительным, или к подозрительным файлам, если его формат является подозрительным.
В другом варианте реализации настоящего изобретения этап проверки формата каждого из указанных извлеченных файлов на подозрительность в предложенном способе может включать по меньшей мере следующие подэтапы: (i) идентификация формата каждого из указанных извлеченных файлов, (ii) получение данных об известных вредоносных форматах файлов, (iii) установление совпадения идентифицированного формата каждого извлеченного файла с одним из известных вредоносных форматов файлов из указанных полученных данных.
В некоторых вариантах реализации настоящего изобретения в ответ на то, что формат извлеченного файла является подозрительным, согласно предложенному способу дополнительно определяют, посредством серверного фильтрующего модуля, имеется ли поведенческий отчет для извлеченного файла с подозрительным форматом.
В других вариантах реализации настоящего изобретения этап выявления наличия поведенческого отчета в предложенном способе может включать получение данных о поведенческих отчетах, вычисление хеш-суммы каждого извлеченного файла и установление, путем сравнения вычисленной хеш-суммы извлеченного файла с хеш-суммами, идентифицирующими поведенческие отчеты в указанных полученных данных, соответствия каждого извлеченного файла одному из имеющихся поведенческих отчетов.
В иных вариантах реализации настоящего изобретения в ответ на то, что для извлеченного файла с подозрительным форматом имеется поведенческий отчет, согласно предложенному способу дополнительно проверяют, посредством серверного фильтрующего модуля, является ли имеющийся поведенческий отчет актуальным, с обеспечением отнесения извлеченного файла к доверенным файлам или вредоносным файлам в случае признания его таковым в актуальном поведенческом отчете.
Согласно одному из вариантов реализации настоящего изобретения, в ответ на то, что имеющийся поведенческий отчет не является актуальным, согласно предложенному способу дополнительно проверяют, посредством серверного фильтрующего модуля, подписан ли анализируемый файл доверенной электронной подписью, с обеспечением отнесения проверяемого файла к доверенным файлам, если он подписан доверенной электронной подписью.
Согласно еще одному варианту реализации настоящего изобретения, этап проверки наличия у извлеченного файла доверенной электронной цифровой подписи в предложенном способе может включать выполнение по меньшей мере следующих подэтапов: (i) идентификация владельца электронной подписи, которой подписан извлеченный файл, (ii) получение данных о доверенных владельцах электронных подписей, (iii) установление совпадения идентифицированного владельца электронной подписи с одним из доверенных владельцев электронных подписей из указанных полученных данных.
Согласно другому варианту реализации настоящего изобретения, в ответ на то, что извлеченный файл не подписан доверенной электронной подписью, согласно предложенному способу дополнительно проверяют, посредством серверного фильтрующего модуля, происходит ли указанный файл из доверенного источника данных, с обеспечением отнесения проверяемого файла к доверенным файлам, если он происходит из доверенного источника данных.
Согласно некоторым вариантам реализации настоящего изобретения, этап проверки происхождения извлеченного файла в предложенном способе может включать выполнение по меньшей мере следующих подэтапов: (i) определение источника извлеченного файла, (ii) получение данных о доверенных источниках, (iii) установление совпадения определенного источника происхождения анализируемого файла с одним из доверенных источников данных из указанных полученных данных.
Согласно другим вариантам реализации настоящего изобретения, в ответ на то, что извлеченный файл не происходит из доверенного источника данных, согласно предложенному способу дополнительно проверяют, посредством серверного фильтрующего модуля, был ли присвоен извлеченному файлу идентификатор доверенного файла, с обеспечением отнесения проверяемого файла к доверенным файлам, если ему был присвоен идентификатор доверенного файла.
Согласно иным вариантам реализации настоящего изобретения, этап проверки наличия у извлеченного файла идентификатора доверенного файла в предложенном способе может включать выполнение по меньшей мере следующих подэтапов: (i) вычисление хеш-суммы извлеченного файла, (ii) получение данных о доверенных файлах, каждый из которых поставлен в соответствие с конкретной хеш-суммой, (iii) установление совпадения вычисленной хеш-суммы анализируемого файла с хеш-суммой одного из доверенных файлов из указанных полученных данных.
В одном из вариантов реализации настоящего изобретения в ответ на то, что извлеченный файл не имеет идентификатора доверенного файла согласно предложенному способу дополнительно передают, посредством серверного фильтрующего модуля, извлеченный файл в модуль системного мониторинга.
Еще в одном варианте реализации настоящего изобретения этап запуска каждого подозрительного файла в виртуальной машине в предложенном способе может включать: (i) идентификацию по меньшей мере одного атрибута каждого полученного подозрительного файла, (ii) получение данных об имеющихся виртуальных машинах, каждая из которых характеризуется заданным набором атрибутов настройки, (iii) выявление в имеющихся виртуальных машинах из указанных полученных данных дефолтной виртуальной машины, по меньшей мере один атрибут настройки которой из заданного набора атрибутов настройки совпадает с указанным идентифицированным атрибутом подозрительного файла, (iv) запуск подозрительного файла в выявленной дефолтной виртуальной машине с обеспечением идентификации по меньшей мере ещё одного атрибута запущенного файла и установление совпадения указанного еще одного идентифицированного атрибута по меньшей мере еще с одним из указанных атрибутов настройки дефолтной виртуальной машины, (v) в случае, если указанный по меньшей мере еще один идентифицированный атрибут запущенного файла не совпадает с указанным по меньшей мере еще одним атрибутом настройки дефолтной виртуальной машины, повторный запуск подозрительного файла еще на одной виртуальной машине из имеющихся виртуальных машинах, указанные атрибуты настройки которой совпадают с указанными атрибутами подозрительного файла.
В ином варианте реализации настоящего изобретения этап регистрации изменений в заданном наборе параметров состояния указанной по меньшей мере одной виртуальной машины в предложенном способе может включать отслеживание, посредством модуля системного мониторинга, указанных изменений в течение заданного периода времени, составляющего 2-3 минуты.
Еще в одном варианте реализации настоящего изобретения согласно предложенному способу дополнительно обеспечивают возможность изменения, посредством серверного модуля системного мониторинга, заданного набора параметров состояния каждой виртуальной машины и/или изменения заданного набора правил анализа.
В некоторых вариантах реализации настоящего изобретения в ответ на отнесение файла, запущенного на указанной по меньшей мере одной виртуальной машине, к вредоносным файлам, согласно предложенному способу дополнительно обеспечивают, посредством серверного модуля системного мониторинга, возможность выдачи предупредительного сообщения, блокировки вредоносного файла, блокировки источников вредоносного файла, внесения вредоносного файла в базу данных вредоносных файлов и/или создания поведенческого отчета для вредоносного файла.
В других вариантах реализации настоящего изобретения согласно предложенному способу дополнительно настраивают каждую из указанных виртуальных машин путем установки операционной системы с необходимой архитектурой, выбор языка локализации операционной системы, установку необходимого программного обеспечения и/или настройки установленного программного обеспечения.
В контексте настоящего описания, если конкретно не указано иное, по меньшей мере часть из конструктивных модулей предложенного сервера, таких как, например, фильтрующий модуль 1.2, модуль 1.3 системного мониторинга и процессинговый модуль 1.4, могут подразумевать под собой компьютерную программу, установленную на подходящем вычислительном оборудовании и способную получать команды/инструкции/запросы и/или данные по сети передачи данных с обеспечением выполнения полученных команд/инструкций/запросов и/или обработки полученных данных (например, данных из сетевого трафика), и/или инициировать выполнение полученных команд/инструкций/запросов и/или инициировать обработку полученных данных. Вычислительное оборудование может представлять собой один физический компьютер, одну физическую компьютерную систему или любое другое подходящее вычислительное устройство, известное в уровне техники, однако ни то, ни другое не является обязательным для данного технического решения. В контексте настоящего технического решения использование выражения «сервер» не означает, что каждая задача (например, полученные команды, инструкции или запросы) или какая-либо конкретная задача будет получена, выполнена или инициирована к выполнению одним и тем же сервером (то есть одним и тем же программным обеспечением и/или аппаратным обеспечением); это означает, что любое количество элементов программного обеспечения или аппаратных устройств может быть вовлечено в прием/передачу, выполнение или инициирование выполнения любых из запроса/команды/инструкции и/или в последствия выполнения таких запроса/команды/инструкции, а также в обработку данных, при этом все это программное и/или аппаратное обеспечение может представлять собой один сервер или несколько серверов, а оба этих варианта реализации по существу включены в выражение «по меньшей мере один сервер».
В контексте настоящего описания, если четко не указано иное, термин «модуль» подразумевает под собой программное обеспечение (соответствующее конкретному аппаратному контексту), которое является необходимым и достаточным для выполнения конкретной(ых) указанной(ых) функции(й).
Вышеупомянутая техническая проблема также решена еще в одном аспекте настоящего изобретения, согласно которому машиночитаемый носитель для длительного хранения данных, хранящий машиночитаемые инструкции, которые, при их исполнении серверным процессором, вызывают выполнение этапов способа согласно второму аспекту настоящего изобретения.
Краткое описание чертежей
Прилагаемые чертежи, которые включены в настоящий документ и составляют его часть, иллюстрируют различные варианты реализации и аспекты настоящего изобретения, а также совместно с приведенным далее описанием поясняют сущность настоящего изобретения. На чертежах:
на фиг. 1 показана структурная схема системы для определения вредоносных файлов в сетевом трафике согласно настоящему изобретению;
на фиг. 2 показана блок-схема способа работы сервера, используемого в системе, показанной на фиг. 1.
Осуществление
Нижеследующее описание представлено только как описание иллюстративного примера настоящего технического решения. Это описание не предназначено для определения объема или установления границ настоящего технического решения.
Некоторые полезные примеры модификаций описываемого способа и системы для определения вредоносных веб-ресурсов также могут быть охвачены нижеследующим описанием. Целью этого является также исключительно помощь в понимании, а не определение объема и границ настоящего технического решения. Эти модификации не представляют собой исчерпывающий список, и специалистам в данной области техники будет понятно, что возможны и другие модификации. Кроме того, это не должно интерпретироваться так, что там, где не были изложены примеры модификаций, никакие модификации невозможны, и/или что-то, что описано, является единственным вариантом осуществления этого элемента настоящего технического решения. Как будет понятно специалисту в данной области техники, это, скорее всего, не так. Кроме того, следует иметь в виду, что способ и система для определения вредоносных файлов в сетевом трафике представляет собой в некоторых конкретных проявлениях достаточно простые варианты осуществления настоящего технического решения, которые в подобных случаях представлены здесь с целью облегчения понимания. Как будет понятно специалисту в данной области техники, многие варианты осуществления настоящего технического решения будут обладать гораздо большей сложностью.
Следует отметить, что основными каналами получения вредоносного кода, в частности различного рода вирусов, являются файлы, скачиваемые пользователями рабочих станций с различных веб-ресурсов в сети Интернет или получаемые ими в результате взаимодействия с неблагонадежными веб-ресурсами в сети Интернет, и файлы вложений в электронной почте. В частности, наибольшее распространение среди злоумышленников для организации своих атак получили файлы со следующими широко распространенными форматами, используемыми для организации электронного документооборота в большинстве организаций и компаний во всем мире:
1) из офисного пакета приложений от компании «Microsoft» для различных операционных систем:
1.1) программное приложение «Microsoft Excel» для работы с электронными таблицами: XLS, XLSX, XLT, XLM, XLTX, XLSM, XLTM, XLSB, XLA, XLAM, XLL и XLW;
1.2) программное приложение «Microsoft PowerPoint» для работы с электронными презентациями: PPT, PPTX, PPS, PPTM, POTX, POTM, PPAM, PPSX, PPSM, SLDX и SLDM;
1.3) программное приложение «Microsoft Word» для работы с электронными текстовыми документами: DOC, DOCX, DOT, DOCM, DOTX, DOTM, в том числе с шифрованием (AES) вредоносного кода (payload) макроса в документах «Microsoft Word»;
1.4) прочие программные приложения от компании «Microsoft» и прочие офисные пакеты приложений других компаний, схожие с офисным пакетом приложений от компании «Microsoft»;
2) прочие офисные приложения: MSOLE2, MSWORD_MACS, MDB, ACCDB, MNY, NEW_OFFICE, HWP;
3) Архивные файлы: TAR, ZIP, 7ZIP, RAR, Seven-Z, JAR и прочие аналогичные форматы, в том числе с защитой архива паролем;
4) пакет программ «Adobe Acrobat» от компании «Adobe Systems» для создания и просмотра электронных публикаций: PDF;
5) пакет программ «Adobe Flash» от компании «Adobe Systems» для создания мультимедийных презентаций и веб-приложений (мультимедийных файлов): SWF;
6) исполняемые файлы: EXE, MSEXE, JARPACK и пр.;
7) файлы общего назначения: RTF, CSV, SCR и JAR и др.;
8) прочие менее распространенные форматы файлов.
Кроме того, злоумышленники часто используют почтовые сообщения с содержащимися в них веб-ссылками на вредоносный файл одного из вышеперечисленных форматов, в том числе с использованием «коротких» URL (URL shortening), а также применяют различные технологии загрузки зловредного кода по частям.
Для виртуальной эмуляции угроз, которые могут нести собой вышеуказанные файлы, в частности заражения рабочей станции, вызванного эксплойтами, атаками «нулевого дня», целевыми атаками и т.п., может быть использована система 10 для определения вредоносных файлов в сетевом трафике, показанная на фиг. 1, которая позволяет выявлять в сетевом трафике подозрительные файлы, в частности файлы, имеющие потенциально опасный формат, и запускать их на виртуальных машинах, реализующих технологи, известную в уровне техники как виртуальная «песочница», для выявления в их поведении признаков потенциально опасного поведения.
Система
Система 10 для определения вредоносных файлов в сетевом трафике, показанная в виде упрощенной структурной схемы на фиг. 1, содержит сервер 1, облачное хранилище 4 поведенческих отчетов, соединенное с возможностью обмена данными с сервером 1, и устройства 2 захвата трафика, включенные в сеть 3 передачи данных с возможностью извлечения из нее сетевого трафика. Сервер 1 также соединен с возможностью обмена данными с устройствами 2 захвата трафика для получения от них сетевого трафика, извлеченного из сети 3 передачи данных, и выполнен с возможностью дальнейшей обработки полученного сетевого трафика для определения в нем вредоносных файлов, способных вызвать заражение целевой рабочей станции пользователя-жертвы при открытии таких вредоносных файлов в операционной системе указанной рабочей станции с последующем выполнением набора запрограммированных вредоносных действий, таких как кража конфиденциальных данных, шифрование файлов, перехват управления, подмена данных и т.п. в зависимости от целей злоумышленников.
В системе 10, показанной на фиг. 1, устройства 2 захвата трафика соединены с сервером 1 проводным способом, например с помощью сетевого кабеля, и представляют собой по меньшей мере одно из следующих известных сетевых устройств для перехвата и передачи сетевого трафика: сетевые коммутаторы L2-уровня, работающие с использованием технологии зеркалирования сетевого трафика необходимых сегментов сети, такой как, например, SPAN-технология зеркалирования сетевого трафика в оборудовании компании «CISCO», средства обеспечения прозрачности сети, также называемые как платформы доставки безопасности (Security Delivery Platform) или сетевые пакетные брокеры (NPB), и ответвители сетевого трафика (Test Access Point) различных типов, а также прокси-серверы с поддержкой ICAP-протокола, работающие в рамках установленного TCP-соединения, почтовые серверы с поддержкой SMTP-протокола и др.
В одном из вариантов реализации настоящего изобретения сервер 1 может быть включен непосредственно в сеть 3 передачи данных или соединен непосредственно с сетью 3 передачи данных с возможностью извлечения или захвата из нее сетевого трафика для его дальнейшего анализа и обработки с целью выявления вредоносных файлов в указанном сетевом трафике. Другими словами, в таком варианте реализации сервер 1 может иметь функциональные возможности вышеописанных устройств 2 захвата трафика, при этом сервер 1, при необходимости, может использовать защищенный канал приема/передачи данных для получения сетевого трафика, извлеченного из сети 3 передачи данных.
Еще в одном варианте реализации настоящего изобретения вышеописанные устройства 2 захвата сетевого трафика могут быть встроены или интегрированы в сервер 1.
В некоторых вариантах реализации настоящего изобретения сервер 1 может быть соединен с устройствами 2 захвата трафика беспроводным образом.
Облачное хранилище поведенческих отчетов
В системе 10, показанной на фиг. 1, облачное хранилище 4 поведенческих отчетов соединено с сервером 1 беспроводным способом и предназначено для хранения в нем поведенческих отчетов, в каждом из которых представлены собранные модулем 1.3 системного мониторинга сведения об особенностях поведения конкретного вредоносного файла, характеризующиеся изменением многочисленных параметров виртуальной машины, отражающих ее состояние, при этом каждый поведенческий отчет, имеющийся в облачном хранилище 4 поведенческих отчетов, поставлен в соответствие с хеш-суммой файла, для которого этот поведенческий отчет был создан, так что конкретная хеш-сумма по существу идентифицирует конкретный поведенческий отчет. Каждый поведенческий отчет также содержит данные о версии модуля 1.3 системного мониторинга, который был использован для анализа файла, для которого этот поведенческий отчет был создан, и заключение, принятое процессинговым модулем 1.4 на основании сведений, собранных модулем 1.3 системного мониторинга (доверенный файл или вредоносный файл). Облачное хранилище 4 поведенческих отчетов также выполнено с возможностью сохранения в нем по меньшей мере одного нового поведенческого отчета и с возможностью обновления по меньшей мере одного из поведенческих отчетов, хранящихся в хранилище 4, на основании новых поведенческих данных, связанных с указанным по меньшей мере одним поведенческим отчетом.
Данные поведенческих отчетов в облачном сетевом хранилище 4 поведенческих отчетов, используемом в системе 10, могут находиться как на одиночном удаленном файловом сервере, включенном в сеть 3 передачи данных или в иную сеть передачи данных, отличную от сети 3 передачи данных, так и на множестве удаленных файловых серверов, распределенных в сети 3 передачи данных или в иной сети передачи данных, отличной от сети 3 передачи данных, при этом сервер 1 выполнен с возможностью установления связи с таким облачным хранилищем 4 поведенческих отчетов с использованием, например, по меньшей мере одного известного коммутирующего устройства с получением доступа к хранящимся в нем данных поведенческих отчетов.
В одном из вариантов реализации настоящего изобретения хранилище 4 поведенческих отчетов и сервер 1 могут быть подключены непосредственно к сети 3 передачи данных с обеспечением возможности обмена данными между ними через указанную сеть 3 передачи данных. При необходимости, в данном варианте реализации сервер 1 и хранилище 4 могут использовать защищенный канал приема/передачи данных для организации обмена данными между собой через сеть 3 передачи данных.
Еще в одном из вариантов реализации настоящего изобретения хранилище 4 поведенческих отчетов может быть встроено или интегрировано в сервер 1, представляя собой, таким образом, локальное хранилище поведенческих отчетов.
В некоторых вариантах реализации настоящего изобретения хранилище поведенческих отчетов может быть соединено с сервером 1 через сеть передачи данных, отличную от сети 3 передачи данных, при этом, при необходимости, для обмена данными между сервером 1 и хранилищем 4 может быть использован защищенный канал приема/передачи данных.
В другом варианте реализации настоящего изобретения сервер 1 и облачное хранилище 4 поведенческих отчетов могут быть подключены к разным сетям передачи данных, для соединения которых могут быть использованы специальные коммутирующие устройства, такие как сетевые концентраторы, также известные как сетевые хабы, сетевые маршрутизаторы и прочие известные коммутирующие устройства.
В некоторых вариантах реализации настоящего изобретения сервер 1 может быть соединен с облачным хранилищем 4 поведенческих отчетов проводным способом, например с помощью сетевого кабеля известного типа.
Сервер
В системе 10, показанной на фиг. 1, сервер 1 по существу представляет собой программно-аппаратный комплекс и содержит модуль 1.1 связи, фильтрующий модуль 1.2, модуль 1.3 системного мониторинга, процессинговый модуль 1.4 и локальное хранилище 1.5 данных, каждый из которых соединен с шиной 1.6 связи, при этом каждый из модуля 1.1 связи, фильтрующего модуля 1.2, модуля 1.3 системного мониторинга и процессингового модуля 1.4 выполнен с возможностью обмена данными, посредством шины 1.6 связи, с локальным хранилищем 1.5 данных, модуль 1.1 связи выполнен с возможностью обмена данными, посредством шины 1.6 связи, с фильтрующим модулем 1.2, который в свою очередь выполнен с возможностью обмена данными, посредством шины 1.6 связи, с модулем 1.3 системного мониторинга и возможностью обмена данными, посредством модуля 1.1 связи, имеющего связь с фильтрующим модулем 1.2 через шину 1.6 связи, с вышеописанным облачным хранилищем 4 поведенческих отчетов, а модуль 1.3 системного мониторинга соединен с возможностью обмена данными, посредством шины 1.6 связи, с процессинговым модулем 1.4, который в свою очередь выполнен с возможностью обмена данными, посредством модуля 1.1 связи, имеющего связь с процессинговым модулем 1.4 через шину 1.6 связи, с вышеописанным облачным хранилищем 4 поведенческих отчетов.
Локальное хранилище данных
Локальное хранилище 1.5 данных предназначено для хранения исполняемых программных инструкций, которые могут управлять работой модуля 1.1 связи, фильтрующего модуля 1.2, модуля 1.3 системного мониторинга и процессингового модуля 1.4, а также различных данных, используемых при работе сервера 1, в частности данных об известных вредоносных форматах файлов, данных о текущей версии модуля 1.3 системного мониторинга, характеризующейся заданным набором анализируемых параметров и заданным набором выполняемых проверок, данных об известных доверенных владельцах электронных подписей, и данных о доверенных файлах, которые снабжены меткой или идентификатором доверенного файла и каждый из которых поставлен в соответствие с конкретной хеш-суммой файла. Кроме того, локальное хранилище 1.5 данных может хранить файлы образов виртуальных машин, каждая из которых характеризуется обособленным набором атрибутов настройки (то есть имеет обособленную сборку).
В некоторых вариантах реализации настоящего изобретения данные об имеющихся поведенческих отчетах могут быть сохранены в локальном хранилище 1.5 данных. В других вариантах реализации настоящего изобретения данные об имеющихся поведенческих отчетах могут быть сохранены в обособленном локальном хранилище поведенческих отчетов (не показано), которое может быть соединено, посредством шины 1.6 связи, с фильтрующим модулем 1.2 с предоставлением возможности фильтрующему модулю 1.2 получать доступ к этому хранилищу поведенческих отчетов для получения из него данных об имеющихся поведенческих отчетах, а также с процессинговым модулем 1.4 с предоставлением возможности процессинговому модулю 1.4 получать доступ к этому хранилищу поведенческих отчетов для обновления хранящихся в нем поведенческих отчетов или записи в него нового поведенческого отчета.
В одном из вариантов реализации настоящего изобретения сервер 1 может содержать обособленное локальное хранилище вредоносных форматов файлов (не показано), предназначенное для хранения данных о вредоносных форматах файлов. Такое хранилище вредоносных форматов файлов может быть соединено, посредством шины 1.6 связи, с фильтрующим модулем 1.2 с предоставлением возможности фильтрующему модулю 1.2 получать доступ к этому хранилищу вредоносных форматов файлов для получения из него данных об известных вредоносных форматах файлов с целью их последующего использования для выявления подозрительных (потенциально опасных) файлов в сетевом трафике, полученном от модуля 1.1 связи, что более подробно описано ниже.
Еще в одном из вариантов реализации настоящего изобретения может иметься обособленное удаленное хранилище вредоносных форматов файлов (не показано), предназначенное для хранения данных о вредоносных форматах файлов, а фильтрующий модуль 1.2 может быть выполнен с возможностью подключения или получения доступа, посредством модуля 1.1 связи, с которым фильтрующий модуль 1.2 соединен посредством шины 1.6 связи, к такому удаленному хранилищу вредоносных форматов файлов для получения из него данных об известных вредоносных форматах файлов с целью их последующего использования для выявления подозрительных (потенциально опасных) файлов в сетевом трафике, полученном от модуля 1.1 связи, что более подробно описано ниже.
В одном из вариантов реализации настоящего изобретения сервер 1 может содержать обособленное локальное хранилище (не показано), предназначенное для хранения данных о текущей версии (например, порядковый номер сборки) модуля 1.3 системного мониторинга, данных о конкретном наборе анализируемых параметров, используемых в указанной текущей версии, и данных о конкретном наборе проверок, используемых в указанной текущей версии. Такое локальное хранилище может быть соединено, посредством шины 1.6 связи, с фильтрующим модулем 1.2 с предоставлением возможности фильтрующему модулю 1.2 получать доступ к этому локальному хранилищу для получения из него данных о текущей версии модуля 1.3 системного мониторинга с целью их последующего использования для проверки актуальности соответствующих поведенческих отчетов, хранящихся в облачном хранилище 4 поведенческих отчетов. Кроме того, такое локальное хранилище может быть соединено с модулем 1.3 системного мониторинга с предоставлением возможности модулю 1.3 системного мониторинга получать доступ к этому локальному хранилищу для обновления хранящихся в нем данных о текущей версии модуля 1.3 системного мониторинга или записи в него новых данных о текущей версии модуля 1.3 системного мониторинга в случае изменения набора анализируемых параметров и/или набора проверок, используемых в модуле 1.3 системного мониторинга.
Еще в одном варианте реализации настоящего изобретения может иметься обособленное удаленное хранилище (не показано), предназначенное для хранения данных о текущей версии модуля 1.3 системного мониторинга, данных о конкретном наборе анализируемых параметров, используемых в указанной текущей версии, и данных о конкретном наборе проверок, используемых в указанной текущей версии. Фильтрующий модуль 1.2 может быть выполнен с возможностью подключения или получения доступа, посредством модуля 1.1 связи, с которым фильтрующий модуль 1.2 соединен посредством шины 1.6 связи, к такому удаленному хранилищу для получения из него данных о текущей версии модуля 1.3 системного мониторинга с целью их последующего использования для проверки актуальности соответствующих поведенческих отчетов, хранящихся в облачном хранилище 4 поведенческих отчетов. Модуль 1.3 системного мониторинга также может быть выполнен с возможностью подключения или получения доступа, посредством модуля 1.1 связи, с которым модуль 1.3 системного мониторинга соединен посредством шины 1.6 связи, к такому удаленному хранилищу для обновления хранящихся в нем данных о текущей версии модуля 1.3 системного мониторинга или записи в него новых данных о текущей версии модуля 1.3 системного мониторинга в случае изменения набора анализируемых параметров и/или набора проверок, используемых в модуле 1.3 системного мониторинга.
В одном из вариантов реализации настоящего изобретения сервер 1 может содержать обособленное локальное хранилище (не показано) доверенных владельцев электронных подписей, предназначенное для хранения данных об известных доверенных владельцах электронных подписей. Такое локальное хранилище доверенных владельцев электронных подписей может быть соединено, посредством шины 1.6 связи, с фильтрующим модулем 1.2 с предоставлением возможности фильтрующему модулю 1.2 получать доступ к этому локальному хранилищу для получения из него данных об известных доверенных владельцах электронных подписей с целью их последующего использования для проверки того, подписан ли файл, анализируемый в фильтрующем модуле 1.2, доверенной электронной подписью, что более подробно описано ниже.
Еще в одном варианте реализации настоящего изобретения может иметься обособленное удаленное хранилище (не показано) доверенных владельцев электронных подписей, предназначенное для хранения данных об известных доверенных владельцах электронных подписей. Фильтрующий модуль 1.2 может быть выполнен с возможностью подключения или получения доступа, посредством модуля 1.1 связи, с которым фильтрующий модуль 1.2 соединен посредством шины 1.6 связи, к такому удаленному хранилищу доверенных владельцев электронных подписей для получения из него данных об известных доверенных владельцах электронных подписей с целью их последующего использования для проверки того, подписан ли файл, анализируемый в фильтрующем модуле 1.2, доверенной электронной подписью, что более подробно описано ниже.
В одном из вариантов реализации настоящего изобретения сервер 1 может содержать обособленное локальное хранилище (не показано) доверенных источников данных, предназначенное для хранения данных об известных доверенных источниках. Такое локальное хранилище доверенных источников данных может быть соединено, посредством шины 1.6 связи, с фильтрующим модулем 1.2 с предоставлением возможности фильтрующему модулю 1.2 получать доступ к этому локальному хранилищу для получения из него данных об известных доверенных источниках с целью их последующего использования для проверки того, происходит ли файл, анализируемый в фильтрующем модуле 1.2, из доверенного источника данных, что более подробно описано ниже.
Еще в одном варианте реализации настоящего изобретения может иметься обособленное удаленное хранилище (не показано) доверенных источников данных, предназначенное для хранения данных об известных доверенных источниках данных. Фильтрующий модуль 1.2 может быть выполнен с возможностью подключения или получения доступа, посредством модуля 1.1 связи, с которым фильтрующий модуль 1.2 соединен посредством шины 1.6 связи, к такому удаленному хранилищу доверенных источников данных для получения из него данных об известных доверенных источников данных с целью их последующего использования для проверки того, происходит ли файл, анализируемый в фильтрующем модуле 1.2, из доверенного источника данных, что более подробно описано ниже.
В одном из вариантов реализации настоящего изобретения сервер 1 может содержать обособленное локальное хранилище (не показано) доверенных файлов, предназначенное для хранения данных о доверенных файлах. Такое локальное хранилище доверенных файлов может быть соединено, посредством шины 1.6 связи, с фильтрующим модулем 1.2 с предоставлением возможности фильтрующему модулю 1.2 получать доступ к этому локальному хранилищу доверенных файлов для получения из него данных о доверенных файлах с целью их последующего использования для проверки, был ли присвоен анализируемому файлу идентификатор доверенного файла, а также для записи в это локальное хранилище доверенных файлов данных о новом доверенном файле, поставленном в соответствие с его хеш-суммой, в случае отнесения фильтрующим модулем 1.2 анализируемого файла к доверенным файлам в результате реализации одной из своих нижеописанных функциональных возможностей.
Еще в одном варианте реализации настоящего изобретения может иметься обособленное удаленное хранилище (не показано) доверенных файлов, предназначенное для хранения данных о доверенных файлах. Фильтрующий модуль 1.2 может быть выполнен с возможностью подключения или получения доступа, посредством модуля 1.1 связи, с которым фильтрующий модуль 1.2 соединен посредством шины 1.6 связи, к такому удаленному хранилищу доверенных файлов для получения из него данных о доверенных файлах с целью их последующего использования для проверки, был ли присвоен анализируемому файлу идентификатор доверенного файла, а также для записи в это удаленное хранилище доверенных файлов данных о новом доверенном файле, поставленном в соответствие с его хеш-суммой, в случае отнесения фильтрующим модулем 1.2 анализируемого файла к доверенным файлам в результате реализации одной из своих нижеописанных функциональных возможностей.
В одном из вариантов реализации настоящего изобретения сервер 1 может содержать обособленное локальное хранилище (не показано) образов виртуальных машин, предназначенное для хранения файлов образов виртуальных машин. Такое локальное хранилище образов виртуальных машин может быть соединено, посредством шины 1.6 связи, с фильтрующим модулем 1.2 с предоставлением возможности фильтрующему модулю 1.2 получать доступ к этому локальному хранилищу образов виртуальных машин для получения из него файлов образов виртуальных машин с целью их последующего использования для анализа активности подозрительных файлов.
Еще в одном варианте реализации настоящего изобретения может иметься обособленное удаленное хранилище (не показано) образов виртуальных машин, предназначенное для хранения файлов образов виртуальных машин. Фильтрующий модуль 1.2 может быть выполнен с возможностью подключения или получения доступа, посредством модуля 1.1 связи, с которым фильтрующий модуль 1.2 соединен посредством шины 1.6 связи, к такому удаленному хранилищу образов виртуальных машин для получения из него файлов образов виртуальных машин с целью их последующего использования для анализа активности подозрительных файлов.
Фильтрующий модуль 1.2, модуль 1.3 системного мониторинга и процессинговый модуль 1.4 могут быть реализованы в виде одиночного процессора, такого как процессор общего назначения или процессор специального назначения (например, процессоры для цифровой обработки сигналов, специализированные интегральные схемы и т.п.). Таким образом, процессор, реализующий фильтрующий модуль 1.2, модуль 1.3 системного мониторинга и процессинговый модуль 1.4 в сервере 1, может быть выполнен с возможностью исполнения программных инструкций, хранящихся в локальном хранилище 1.5 данных с обеспечением реализации функциональных возможностей фильтрующего модуля 1.2 по выявлению подозрительных файлов в полученном сетевом трафике, функциональных возможностей модуля 1.3 системного мониторинга по созданию специального log-файла о поведении конкретного подозрительного файла в операционной системе и функциональных возможностей процессингового модуля 1.4 по вынесению окончательного решения в отношении вредоносности подозрительного файла с использованием созданного log-файла.
В одном из вариантов реализации настоящего изобретения каждый из фильтрующего модуля 1.2, модуля 1.3 системного мониторинга и процессингового модуля 1.4 может быть реализован в виде по меньшей мере одного обособленного процессора. В данном варианте реализации первый процессор, использованный в сервере 1 для реализации фильтрующего модуля 1.2, может быть выполнен с возможностью исполнения программных инструкций, хранящихся в локальном хранилище 1.5 данных с обеспечением реализации функциональных возможностей фильтрующего модуля 1.2 по выявлению подозрительных файлов в полученном сетевом трафике. Второй процессор, реализующий модуль 1.3 системного мониторинга, может быть выполнен с возможностью исполнения программных инструкций, хранящихся в локальном хранилище 1.5 данных с обеспечением реализации функциональных возможностей модуля 1.3 системного мониторинга по созданию специального log-файла о поведении конкретного подозрительного файла с конкретным форматом в операционной системе с конкретной сборкой. Третий процессор, использованный в сервере 1 для реализации процессингового модуля 1.4, может быть выполнен с возможностью исполнения программных инструкций, хранящихся в локальном хранилище 1.5 данных с обеспечением реализации функциональных возможностей процессингового модуля 1.4 по вынесению окончательного решения в отношении вредоносности подозрительного файла с использованием созданного log-файла.
Локальное хранилище 1.5 данных может быть реализовано, например, в виде одного или более известных в уровне техники машиночитаемых носителей для длительного хранения данных. В некоторых вариантах реализации настоящего изобретения локальное хранилище 1.5 данных может быть реализовано с использованием одиночного физического устройства (например, одного оптического запоминающего устройства, магнитного запоминающего устройства, органического запоминающего устройства или запоминающего устройства другого типа, или запоминающего устройства на дисках), а в других вариантах реализации локальное хранилище 1.5 данных может быть реализовано с использованием двух или более физических устройств.
Модуль связи
В сервере 1 системы 10, показанной на фиг. 1, модуль 1.1 связи соединен проводным способом, например с помощью коаксиального кабеля, витой пары, оптоволоконного кабеля или другого физического соединения, с устройствами 2 захвата трафика с возможностью получения от них сетевого трафика. Таким образом, модуль 1.1 связи выполнен с возможностью подключения к одному или более из вышеописанных устройств 2 захвата трафика, включенных в сеть 3 передачи данных, и с возможностью приема сетевого трафика, извлеченного указанными устройствами 2 захвата трафика из сети 3 передачи данных, от указанного одного или более устройств 2 захвата трафика.
Еще в одном варианте реализации настоящего изобретения модуль 1.1 связи может быть соединен с устройствами 2 захвата трафика беспроводным способом, например с помощью линии связи на основе технологии «WiFi», линии связи на основе технологии «3G», линии связи на основе технологии «LTE» и т.п.
Кроме того, в сервере 1 системы 10 модуль 1.1 связи также соединен с вышеописанным хранилищем 4 поведенческих отчетов беспроводным способом, например с помощью линии связи на основе технологии «WiFi», линии связи на основе технологии «3G», линии связи на основе технологии «LTE» и/или линии связи на основе иной известной беспроводной технологии связи.
Модуль 1.1 связи в сервере 1 согласно настоящему изобретению может быть реализован в виде комбинации из первого сетевого адаптера, снабженного необходимыми разъемами для подключения к ним физических кабелей необходимых типов в зависимости от типов физических соединений, использованных для обеспечения связи с устройствами 2 захвата трафика, и второго сетевого адаптера в форме WiFi-адаптера, 3G-адаптера, LTE-адаптера или иного адаптера беспроводной связи в зависимости от типа линии беспроводной связи, использованной для обеспечения связи с хранилищем 4 поведенческих отчетов.
Таким образом, модуль 1.1 связи в сервере 1 по существу может быть выполнен с возможностью приема или получения входных данных от одного или более устройств проводным способом и/или беспроводным способом, а также с возможностью отправки или выдачи выходных данных на другие устройства проводным способом и/или беспроводным способом.
Модуль 1.1 связи также может представлять собой известное устройство связи, такое как передатчик, приемник, приемопередатчик, модем и/или сетевая интерфейсная карта для обмена данными с внешними устройствами любого типа посредством проводной или беспроводной сети связи, например с помощью сетевого соединения стандарта «Ethernet», цифровой абонентской линия связи (DSL), телефонной линии, коаксиального кабеля, телефонной системы сотовой связи и т.п.
В некоторых вариантах реализации настоящего изобретения пакеты данных сетевого трафика, полученного модулем 1.1 связи, могут быть по меньшей мере временно сохранены в локальном хранилище 1.5 данных.
В других вариантах реализации настоящего изобретения пакеты данных сетевого трафика, полученного модулем 1.1 связи, могут быть по меньшей мере временно сохранены в обособленном локальном хранилище сетевого трафика (не показано), отличном от локального хранилища 1.5 данных и соединенном с шиной 1.6 связи.
Фильтрующий модуль
В сервере 1 системы 10, показанной на фиг. 1, фильтрующий модуль 1.2 выполнен с возможностью подключения или связи, посредством шины 1.6 связи, к модулю 1.1 связи с обеспечением возможности получения от него захваченного сетевого трафика. Фильтрующий модуль 1.2 извлекает множество отдельных файлов из полученного сетевого трафика, например поддерживает прикладные протоколы передачи файлов, такие как, например, http, ftp, smtp и др., и анализирует каждый из указанного множества извлеченных файлов с обеспечением выявления по меньшей мере одного подозрительного файла из анализируемого множества файлов.
В варианте реализации настоящего изобретения, в котором полученный сетевой трафик хранится в локальном хранилище 1.5 данных, фильтрующий модуль 1.2 может быть выполнен с возможностью получения доступа к локальному хранилищу 1.5 данных или возможностью связи с ним с использованием шины 1.6 связи с обеспечением извлечения из него сохраненных пакетов данных анализируемого сетевого трафика для последующего их анализа с целью выявления по меньшей мере одного подозрительного файла, как описано выше.
В варианте реализации настоящего изобретения, в котором полученный сетевой трафик хранится в обособленном локальном хранилище сетевого трафика (не показано), фильтрующий модуль 1.2 может быть выполнен с возможностью получения доступа к такому хранилищу сетевого трафика или возможностью связи с ним с использованием шины 1.6 связи с обеспечением извлечения из него сохраненных пакетов данных анализируемого сетевого трафика для последующего их анализа с целью выявления по меньшей мере одного подозрительного файла, как описано выше.
При анализе каждого файла, извлеченного из полученного сетевого потока, фильтрующий модуль 1.2 проверяет, является ли подозрительным (потенциально вредоносным) формат анализируемого файла, с обеспечением отнесения анализируемого файла к доверенным файлам, если его формат не является подозрительным, или к подозрительным файлам, если его формат является подозрительным, при этом в случае отнесения анализируемого файла к доверенным файлам ему присваивают метку или идентификатор доверенного файла.
При проверке формата каждого анализируемого файла на подозрительность фильтрующий модуль 1.2 выполняет по меньшей мере следующие операции: (i) идентифицирует формат указанного анализируемого файла, (ii) получает доступ к локальному хранилищу 1.5 данных или устанавливает с ним связь, посредством шины 1.6 связи, с обеспечением получения из него данных об известных вредоносных форматах файлов и (iii) устанавливает, путем сравнения идентифицированного формата с известными вредоносными форматами файлов из указанных полученных данных, соответствие идентифицированного формата анализируемого файла одному из известных вредоносных форматов файлов. Таким образом, фильтрующий модуль 1.2 относит анализируемый файл к доверенным файлам, если его формат соответствует одному из известных вредоносных форматов, или к подозрительным файлам, если его формат не соответствует ни одному из известных вредоносных форматов, при этом анализируемый файл, в отношении которого было установлено, что его формат является подозрительным, получает метку или идентификатор подозрительного файла.
В дальнейшем, в ответ на то, что формат анализируемого файла является подозрительным, фильтрующий модуль 1.2 дополнительно определяет, имеется ли поведенческий отчет для анализируемого файла с подозрительным форматом.
Для выявления наличия поведенческого отчета фильтрующий модуль 1.2 выполняет по меньшей мере следующие операции: (i) получает доступ к облачному хранилищу 4 поведенческих отчетов или устанавливает с ним связь, посредством модуля 1.1 связи, с которым фильтрующий модуль 1.2 соединен посредством шины 1.6 связи, с обеспечением получения из него данных об имеющихся поведенческих отчетах, каждый из которых поставлен в соответствие с конкретной хеш-суммой файла, для которого этот поведенческий отчет был создан, (ii) вычисление хеш-суммы анализируемого файла с использованием, например, одного из наиболее известных алгоритмов: SHA-1, MD5, CRC и т.п., и (iii) установление, путем сравнения с полученными данными о поведенческих отчетах по хеш-сумме, соответствия каждого анализируемого файла одному из имеющихся поведенческих отчетов. Таким образом, фильтрующий модуль 1.2 сравнивает вычисленную хеш-сумму анализируемого файла с хеш-суммами, идентифицирующими поведенческие отчеты, в полученных данных о поведенческих отчетах, при этом совпадение хеш-суммы анализируемого файла с хеш-суммой, идентифицирующей один из имеющихся поведенческих отчетов, означает, что для анализируемого файла уже имеется поведенческий отчет, хранящийся в облачном хранилище 4 поведенческих отчетов.
В дальнейшем в ответ на то, что для анализируемого файла с подозрительным форматом имеется поведенческий отчет, фильтрующий модуль 1.2 дополнительно проверяет, является ли имеющийся поведенческий отчет актуальным, с обеспечением отнесения анализируемого файла к доверенным файлам или вредоносным файлам в случае признания его таковым в указанном актуальном поведенческом отчете. Для проверки актуальности имеющегося поведенческого отчета фильтрующий модуль 1.2 (i) идентифицирует версию модуля 1.3 системного мониторинга, использованного в сервере 1 на момент создания данного поведенческого отчета, (ii) получает доступ к локальному хранилищу 1.5 данных или устанавливает с ним связь, посредством шины 1.6 связи, с обеспечением получения из него данных о текущей версии модуля 1.3 системного мониторинга, используемого в сервере 1, и (iii) проверяет, совпадает ли указанная текущая версия модуля 1.3 системного мониторинга с версией модуля 1.3 системного мониторинга в указанных полученных данных, так что в случае совпадения указанных версий модуля 1.3 системного мониторинга фильтрующий модуль 1.2 относит поведенческий отчет, имеющийся для анализируемого файла, к актуальным, а в случае несовпадения указанных версий модуля 1.3 системного мониторинга фильтрующий модуль 1.2 относит поведенческий отчет, имеющийся для анализируемого файла, к неактуальным.
В ответ на то, что имеющийся поведенческий отчет является актуальным, фильтрующий модуль 1.2 дополнительно извлекает из указанного поведенческого отчета данные о заключении, принятом процессинговым модулем 1.4 на основании сведений, собранных модулем 1.3 системного мониторинга, в отношении файла с хеш-суммой, совпадающей с хеш-суммой анализируемого файла. Если в отношении файла с хеш-суммой, совпадающей с хеш-суммой анализируемого файла, было принято заключение о его отнесении к доверенным файлам, фильтрующий модуль 1.2 относит анализируемый файл к доверенным файлам, а если в отношении файла с хеш-суммой, совпадающей с хеш-суммой анализируемого файла, было принято заключение о его отнесении к вредоносным файлам, фильтрующий модуль 1.2 относит анализируемый файл к вредоносным файлам.
В ответ же на то, что имеющийся поведенческий отчет не является актуальным, фильтрующий модуль 1.2 дополнительно проверяет, подписан ли анализируемый файл доверенной электронной подписью, с обеспечением отнесения проверяемого файла к доверенным файлам, если он подписан доверенной электронной подписью.
Для проверки наличия у анализируемого файла доверенной электронной цифровой подписи фильтрующий модуль 1.2 (i) идентифицирует владельца электронной подписи, которой подписан извлеченный файл, (ii) получает доступ к локальному хранилищу 1.5 данных или устанавливает с ним связь, посредством шины 1.6 связи, с обеспечением получения из него данных об известных доверенных владельцах электронных подписей, (iii) установление совпадения идентифицированного владельца электронной подписи с одним из доверенных владельцев электронных подписей из указанных полученных данных, так что в случае совпадения указанных владельцев электронной подписи фильтрующий модуль 1.2 устанавливает, что анализируемый файл подписан доверенной электронной подписью с последующим отнесением этого анализируемого файла к доверенным файлам, в результате чего анализируемого файлу присваивают метку или идентификатор доверенного файла.
В ответ на то, что анализируемый файл не подписан доверенной электронной подписью, фильтрующий модуль 1.2 дополнительно проверяет, происходит ли этот анализируемый файл из доверенного источника данных (например, домен для http-запроса), с обеспечением отнесения проверяемого файла к доверенным файлам, если он происходит из доверенного источника данных.
Для проверки происхождения анализируемого файла фильтрующий модуль 1.2 (i) определяет источник извлеченного файла, (ii) получает доступ к локальному хранилищу 1.5 данных или устанавливает с ним связь, посредством шины 1.6 связи, с обеспечением получения из него данных об известных доверенных источниках, (iii) устанавливает совпадение определенного источника происхождения анализируемого файла с одним из известных доверенных источников данных из указанных полученных данных, так что в случае совпадения указанных источников данных фильтрующий модуль 1.2 устанавливает, что анализируемый файл происходит из доверенного источника данных с последующим отнесением этого анализируемого файла к доверенным файлам, в результате чего анализируемого файлу присваивают метку или идентификатор доверенного файла.
Следует также отметить, что для анализируемого файла с идентификатором доверенного файла, который может быть присвоен ему фильтрующим модулем 1.2 в вышеописанных случаях, фильтрующий модуль 1.2 вычисляет хеш-сумму этого анализируемого файла с использованием, например, одного из наиболее известных алгоритмов: SHA-1, MD5, CRC и т.п., и получает доступ к локальному хранилищу 1.5 данных или устанавливает с ним связь с обеспечением записи в него данных о новом доверенном файле, поставленных в соответствие с вычисленной хеш-суммой этого доверенного файла.
В ответ на то, что анализируемый файл не происходит из доверенного источника данных, фильтрующий модуль 1.2 дополнительно проверяет, имеет ли анализируемый файл идентификатор доверенного файла, с обеспечением отнесения проверяемого файла к доверенным файлам, если ему был присвоен идентификатор доверенного файла, или передачи анализируемого файла, посредством шины 1.6 связи, в модуль 1.3 системного мониторинга для его последующей обработки, как будет более подробно описано ниже.
Для проверки, был ли присвоен анализируемому файлу идентификатор доверенного файла, фильтрующий модуль 1.2 (i) вычисляет хеш-сумму анализируемого файла с использованием, например, одного из наиболее известных алгоритмов: SHA-1, MD5, CRC и т.п., (ii) получает доступ к локальному хранилищу 1.5 данных или устанавливает с ним связь, посредством шины 1.6 связи, с обеспечением получения из него данных о доверенных файлах, каждый из которых поставлен в соответствие с конкретной хеш-суммой, (iii) установление совпадения вычисленной хеш-суммы анализируемого файла с хеш-суммой одного из доверенных файлов из указанных полученных данных, так что в случае совпадения указанных хеш-сумм файлов фильтрующий модуль 1.2 устанавливает, что анализируемый файл происходит из доверенного источника данных с последующим отнесением этого анализируемого файла к доверенным файлам.
Таким образом, согласно приведенному выше описанию функциональных возможностей фильтрующего модуля 1.2, фильтрующий модуль 1.2 обеспечивает возможность фильтрации по меньшей мере части файлов, извлеченных из полученного сетевого трафика, с использованием минимальных вычислительных ресурсов сервера 1, что в свою очередь значительно ускоряет процесс выявления вредоносных файлов в сетевом трафике.
Модуль системного мониторинга
В сервере 1 системы 10, показанной на фиг. 1, модуль 1.3 системного мониторинга выполнен с возможностью подключения или связи, посредством шины 1.6 связи, к фильтрующему модулю 1.2 с обеспечением возможности получения от него подозрительных файлов (потенциально вредоносных), выявленных фильтрующим модулем 1.2, как описано выше. Следует отметить, что каждый файл из подозрительных файлов, получаемых модулем 1.3 системного мониторинга, характеризуется заданным набором атрибутов, например разрядностью (32-разрядный или 64-разрядный) и языком (например, русский (rus) или английский (eng)).
После получения подозрительный файлов от фильтрующего модуля 1.2 модуль 1.3 системного мониторинга идентифицирует по меньшей мере один атрибут каждого полученного подозрительного файла, а затем получает доступ к локальному хранилищу 1.5 данных или устанавливает с ним связь, посредством шины 1.6 связи, с обеспечением получения из него файлов образов виртуальных машин, при этом виртуальная машина в каждом файле образа виртуальной машины характеризуется обособленным набором атрибутов настройки (то есть имеет обособленную сборку) и характеризуется заданным набором параметров состояния, а по меньшей мере одной из виртуальных машин в полученных файлах образов виртуальных машин предварительно присвоен идентификатор или предварительно присвоена метка дефолтной виртуальной машины (то есть виртуальной машины, используемой в работе модуля 1.3 системного мониторинга по умолчанию).
Следует отметить, что набор атрибутов настройки, заданный для каждой из виртуальных машин в полученных файлах образов виртуальных машин, может содержать, например, конкретную комбинацию из следующих атрибутов настройки: операционная система, язык и разрядность.
В дальнейшем модуль 1.3 системного мониторинга выявляет в имеющихся виртуальных машинах из полученных файлов образов виртуальных машин дефолтную виртуальную машину, по меньшей мере один атрибут настройки которой из ее обособленного набора атрибутов настройки совпадает по меньшей мере с одним идентифицированным атрибутом подозрительного файла, и запускает этот подозрительный файл в выявленной дефолтной виртуальной машине.
После запуска подозрительного файла в выявленной дефолтной виртуальной машине модуль 1.3 системного мониторинга дополнительно идентифицирует по меньшей мере еще один атрибут указанного запущенного файла и устанавливает совпадение указанного еще одного идентифицированного атрибута по меньшей мере еще с одним атрибутом настройки дефолтной виртуальной машины из ее обособленного набора атрибутов настройки. Таким образом, модуль 1.3 системного мониторинга по существу определяет, подходит ли дефолтная виртуальная машина, в которой запускают конкретный подозрительный файл, для анализа поведения этого конкретного подозрительного файла. В случае, когда дефолтная виртуальная машина подходит для анализа конкретного подозрительного файла, то есть когда по меньшей мере еще один атрибут, идентифицированный у подозрительного файла, запущенного в дефолтной виртуальной машине, совпадает по меньшей мере с еще одним атрибутом настройки дефолтной виртуальной машины, модуль 1.3 системного мониторинга продолжает анализ указанного подозрительного файла в течение заданного периода времени, обычно составляющего 2-3 минуты (то есть анализ подозрительного файла в дефолтной виртуальной машине преждевременно не прерывается), с последующим завершением работы дефолтной виртуальной машины по истечению указанного периода времени.
В случае, когда дефолтная виртуальная машина не подходит для анализа конкретного подозрительного файла, то есть когда по меньшей мере еще один атрибут, идентифицированный у подозрительного файла, запущенного в дефолтной виртуальной машине, не совпадает по меньшей мере с еще одним атрибутом настройки дефолтной виртуальной машины, модуль 1.3 системного мониторинга прекращает работу дефолтной виртуальной машины до истечения заданного периода времени работы виртуальной машины и повторно запускает этот подозрительный файл еще на одной виртуальной машине из имеющихся виртуальных машинах в полученных файлах образов виртуальных машин, которая является отличной от дефолтной виртуальной машины и атрибуты настройки которой совпадают с атрибутами подозрительного файла, то есть на другой виртуальной машине, у которой в дополнение к тому, что по меньшей мере один атрибут настройки совпадает по меньшей мере с одним атрибутом подозрительного файла, как описано выше в отношении дефолтной виртуальной машины, указанный по меньшей мере еще один атрибут настройки совпадает с указанным еще одним атрибутом подозрительного файла.
В качестве дефолтной виртуальной машины из виртуальных машин, имеющихся в полученных файлах образов виртуальных машин, для запуска в ней 32-разрядных подозрительных файлов может быть использована, например, виртуальная машина со следующим заданным набором атрибутов настройки: операционная система - Windows XP, архитектура – x86 (32-разрядная), язык – русский (rus). В качестве же дефолтной виртуальной машины из виртуальных машин, имеющихся в полученных файлах образов виртуальных машин, для запуска в ней 64-разрядных подозрительных файлов может быть использована, например, виртуальная машина со следующим заданным набором атрибутов настройки: операционная система - Windows 7, архитектура – x64 (64-разрядная), язык – английский (eng).
В частности, в настоящем изобретении модуль 1.3 системного мониторинга сначала запускает каждый полученный подозрительный файл в дефолтной виртуальной машине, разрядность которой совпадает с разрядностью этого подозрительного файла, и в дальнейшем устанавливает совпадение языка подозрительного файла, запущенного в дефолтной виртуальной машине, с языком этой дефолтной виртуальной машины, при этом в случае несовпадения указанных языков модуль 1.3 системного мониторинга преждевременно останавливает работу дефолтной виртуальной машины и повторно запускает указанный подозрительный файл в другой виртуальной машине, отличной от дефолтной виртуальной машины и имеющей разрядность и язык, совпадающий с языком указанного подозрительного файла.
Таким образом, как описано выше, модуль 1.3 системного мониторинга запускает каждый полученный подозрительный файл по меньшей мере на одной виртуальной машине, одна из которых является подходящей для анализа указанного подозрительного файла. При запуске подозрительного файла на подходящей виртуальной машине модуль 1.3 системного мониторинга в течение заданного периода времени выявляет и регистрирует изменения в заданном наборе параметров состояния этой подходящей виртуальной машины с обеспечением создания специального отчета или лог-файла, содержащего все изменения, зарегистрированные модулем 1.3 системного мониторинга, в указанном заданном наборе параметров состояния за указанный период времени и отражающие активность указанного подозрительного файла в указанной виртуальном машине.
В одном из вариантов реализации настоящего изобретения лог-файл с данными об изменениях параметров состояния виртуальной машины, подготовленный или созданный модулем 1.3 системного мониторинга для каждого подозрительного файла, проанализированного в указанной виртуальной машине, может быть сохранен в локальном хранилище 1.5 данных, с которым модуль 1.3 системного мониторинга соединен посредством шины 1.6 связи, для последующего использования такого отчета в процессинговом модуле 1.4, соединенном с локальным хранилищем 1.5 данных посредством шины 1.6 связи.
Еще в одном варианте реализации настоящего изобретения лог-файл с данными об изменениях параметров состояния виртуальной машины, подготовленный или созданный модулем 1.3 системного мониторинга для каждого подозрительного файла, проанализированного в указанной виртуальной машине, может быть сохранен в обособленном локальном хранилище отчетов (не показано) на сервере 1, отличном от локального хранилища 1.5 данных. Такое локальное хранилище отчетов может быть соединено, посредством шины 1.6 связи, с фильтрующим модулем 1.2 с обеспечением возможности фильтрующему модулю 1.2 получать доступ к этому локальному хранилищу отчетов для сохранения в нем указанного лог-файла для его последующего использования в процессинговом модуле 1.4, соединенном с локальным хранилищем 1.5 данных посредством шины 1.6 связи.
В другом варианте реализации настоящего изобретения лог-файл с данными об изменениях параметров состояния виртуальной машины, подготовленный или созданный модулем 1.3 системного мониторинга для каждого подозрительного файла, проанализированного в указанной виртуальной машине, может быть сохранен в обособленном удаленном хранилище отчетов (не показано) на сервере 1. Такое удаленное хранилище отчетов может быть соединено с фильтрующим модулем 1.2, посредством модуля 1.1 связи, с которым фильтрующий модуль 1.2 соединен с помощью шины 1.6 связи, с обеспечением возможности фильтрующему модулю 1.2 получать доступ к этому удаленному хранилищу отчетов для сохранения в нем указанного лог-файла для его последующего использования в процессинговом модуле 1.4, соединенном с удаленным хранилищем 1.5 данных посредством модуля 1.1 связи, с которым процессинговый модуль 1.4 соединен с помощью шины 1.6 связи.
Модуль 1.3 системного мониторинга снабжен специальным фреймворком (программной платформой), позволяющим, например, оператору сервера 1 изменять заданный набор правил анализа, используемых модулем 1.3 системного мониторинга для выявления и регистрации изменений в заданном наборе параметров состояния запущенной виртуальной машины, например задавать или добавлять новые правила анализа (определять новые поведенческие маркеры), которые в дальнейшем будут использованы в работе модуля 1.3 системного мониторинга, что обеспечивает расширение функциональных возможностей модуля 1.3 системного мониторинга и сервера 1 в целом. Изменение набора правил, используемых в работе модуля 1.3 системного мониторинга, по существу приводит к изменению текущей версии модуля 1.3 системного мониторинга, в результате чего модуль 1.3 системного мониторинга получает доступ к локальному хранилищу 1.5 данных или устанавливает с ним связь, посредством шины 1.6 связи, с обеспечением записи в него данных о новой версии модуля 1.3 системного мониторинга или обновления в нем данных о ранее записанной или сохраненной версии модуля 1.3 системного мониторинга, при этом новые или обновленные данные, отражающие текущую версию модуля 1.3 системного мониторинга, будут в дальнейшем использованы в работе фильтрующего модуля 1.2 для проверки актуальности поведенческого отчета, выявленного среди имеющихся поведенческих отчетов для анализируемого файла, как более подробно описано выше.
Как было описано выше, в каждом лог-файле, создаваемом модулем 1.3 системного мониторинга по завершению работы подходящей виртуальной машины, отражены все изменения параметров состояния указанной виртуальной машины, характеризующие поведение конкретного подозрительного файла в этой виртуальной машине. Ниже приведены некоторые примеры изменений параметров состояния запущенной виртуальной машины, зарегистрированных модулем 1.3 системного мониторинга для файлов с разным вредоносным кодом.
Запуск подозрительного файла, например в виде zip-архива, доставленного потенциальной жертве в электронном сообщении, в подходящей виртуальной машине может привести, например, к следующим возможным основным изменениям в параметрах состояния этой виртуальной машины, выявляемых и регистрируемых модулем 1.3 системного мониторинга: cбор сведений о системе через различные системные вызовы и реестр; реализация функций типа «keylogger»; многократные попытки «уснуть»; внесение правок в реестр; попытка кражи паролей FTP-клиента, MS Outlook и др. через реестр; создание файла с результатами подключения к внешнему серверу методом «HTTP POST» и отправка данных с обфускацией.
Запуск подозрительного файла, содержащего, например, зловредный код типа «Trojan.Generic» (маскируется под файл системы обновления «Windows» с последующей кражей логинов и паролей приложений пользователей, включая браузеры, почту, FTP-клиенты, и отправкой собранных сведений на командный центр), в подходящей виртуальной машине может привести, например, к следующим возможным основным изменениям в параметрах состояния этой виртуальной машины, выявляемых и регистрируемых модулем 1.3 системного мониторинга: сбор данных о рабочей станции через реестр и системные вызовы; попытка «уснуть», настройка через реестр однократного автоматического запуска инсталлятора; отключение «debugger» и отслеживание процессов на уровне операционной системы через реестр; попытки подключения к серверам «C&C» и скачивания обновления.
Запуск подозрительного файла, содержащего, например, зловредный код типа «Trojan.Adwind» (семейство кроссплатформенных вирусов, написанных на языке «Java»), например в виде jar-архива, доставленного потенциальной жертве в электронном сообщении, в подходящей виртуальной машине может привести, например, к следующим возможным основным изменениям в параметрах состояния этой виртуальной машины, выявляемых и регистрируемых модулем 1.3 системного мониторинга: создание и запуск VBScript-скриптов; создание временного текстового файла; создание скрытого файла; обеспечение автозапуска через реестр; сокрытие папки с помощью «attrib.exe»; удаление ранее созданного «VBScript».
Запуск подозрительного файла, содержащего, например, зловредный код типа «Bartallex.InfoStealer» (семейство вирусов, использующих макросы в документах MS Word/Excel и применяемых для дальнейшей загрузки дополнительного вредоносного кода), например в виде doc-файла, доставленного потенциальной жертве в электронном сообщении. В подходящей виртуальной машине может привести, например, к следующим возможным основным изменениям в параметрах состояния этой виртуальной машины, выявляемых и регистрируемых модулем 1.3 системного мониторинга: сбор сведений о системе через различные системные вызовы и реестр; многократные попытки «уснуть»; создание и запуск исполняемых файлов; запуск команд «Command Line»; инъекция кода из «eboz.exe» в «ms.exe», «winword.exe» и «explorer.exe» (попытка обхода антивируса); открытие одного из портов порта TCP-сокета; подключение к внешнему серверу для получения конфигурации.
Запуск подозрительного файла, содержащего, например, зловредный код типа «Ransom.Troldesh» (вирус, который является модификацией «трояна-криптолокера» и который шифрует данные пользователя, а в дальнейшем выдает сообщение с требованием заплатить «выкуп» злоумышленнику для расшифровки данных, или который может быть также использован для загрузки дополнительного зловредного кода на скомпрометированную рабочую станцию), например в виде tmp-файла», доставленного потенциальной жертве в электронном сообщении. В подходящей виртуальной машине может привести, например, к следующим возможным основным изменениям в параметрах состояния этой виртуальной машины, выявляемых и регистрируемых модулем 1.3 системного мониторинга: сбор сведений о системе (различные системные вызовы); перебор запущенных процессов; изменение настроек IE через реестр; инъекция кода в копию своего процесса (метод обхода антивирусов); создание файлов, похожих на системные процессы и обеспечение автозапуска через реестр; многократные попытки «уснуть»; перебор процессов «Windows», захват окна; открытие TCP-сокета на одном из локальных портов и подключение к нему (метод обхода антивирусов); создание ключа в реестре с «private key»; создание текстовых файлов на диске «С» с руководством к оплате «выкупа»; попытки связаться с внешними серверами по IP для получения ключей.
Запуск подозрительного файла, содержащего, например, зловредный код типа «Web.Exploit.Malware.Binary» (зловредный код типа «веб-эксплойт», после первичной компрометации рабочей станции проводит инъекцию в процесс «iexplorer.exe» (Internet Explorer) и загрузку частей вредоносного кода (HTML, JavaScript, Flash) с различных веб-ресурсов), загружаемый и выполняемый на рабочей станции потенциальной жертвы в качестве Flash-кода или JavaScipt-кода при загрузке веб-страницу на этой рабочей станции. В подходящей виртуальной машине может привести, например, к следующим возможным основным изменениям в параметрах состояния этой виртуальной машины, выявляемых и регистрируемых модулем 1.3 системного мониторинга: инъекция кода в процесс «iexplorer.exe» (Internet Explorer); попытки скачивания частей вредоносного кода с веб-ресурсов; создание временных исполняемых.
В целом модуль 1.3 системного мониторинга может зарегистрировать изменения параметров состояния запущенной виртуальной машины в следующих категориях: файловая система, системный реестр, структуры оперативной памяти, включая регионы памяти сторонних процессов, специфичные последовательности системных вызовов, установление удаленных соединений, создание мьютексов и т.д.
В зависимости от вычислительных возможностей сервера 1 модуль 1.3 системного мониторинга может по существу одновременно (в режиме реального времени) загружать множество виртуальных машин для анализа в каждой из них поведения отдельного подозрительного файла.
Процессинговый модуль
В сервере 1 системы 10, показанной на фиг. 1, процессинговый модуль 1.4 выполнен с возможностью подключения, посредством шины 1.6 связи, к модулю 1.3 системного мониторинга или возможностью связи, посредством шины 1.6 связи, с ним с обеспечением возможности получения от него лог-файлов, подготовленных или созданных модулем 1.3 системного мониторинга, как описано выше.
Процессинговый модуль 1.4 анализирует зарегистрированные изменения параметров состояния виртуальной машины, содержащиеся в каждом из полученных лог-файлов, с использованием заданного набора правил анализа с обеспечением отнесения подозрительного файла, для которого был создан указанный лог-файл, к доверенным файлам, если проанализированные изменения параметров состояния виртуальной машины характерны для доверенных файлов, или к вредоносным файлам, если проанализированные изменения параметров состояния виртуальной машины характерны для вредоносных файлов. Таким образом, процессинговый модуль 1.4 принимает окончательное решение или выносит окончательный вердикт в отношении вредоносности или безвредности подозрительного файла с использованием лог-файла, созданного модулем 1.3 системного мониторинга для указанного подозрительного файла.
В частности, в основе работы процессингового модуля 1.4 лежит набор предварительно обученных классификаторов, каждый из которых принимает свое решение или выносит свой вердикт в отношении вредоносности или безвредности подозрительного файла с использованием признаков, которые извлекают с помощью известных алгоритмов или скриптов из одного и того же лог-файла, полученного от модуля 1.3 системного мониторинга, и каждый из которых по существу соответствует по меньшей мере одному из изменений параметров состояния виртуальной машины. В частности, одними из основных классификаторов в наборе предварительно обученных классификаторов, являются классификатор на базе линейной модели и классификатор на базе одного из известных алгоритмов машинного обучения (MLA), например на базе алгоритма машинного обучения «Random Forest». Согласно классификатору на базе линейной модели каждому признаку, извлеченному из полученного лог-файла, присваивают заданный вес, а в дальнейшем определяют суммарный вес всех извлеченных признаков и проверяют, попадает ли этот определенный суммарный вес в заданный числовой отрезок, ограниченный с двух сторон заданными пороговыми значениями, или проверяют, больше или меньше ли определенный суммарный вес заданного порогового значения, являющегося по существу заданной константой. Классификатор на базе одного из MLA-алгоритмов принимает свое решение или выносит свой вердикт в отношении вредоносности или безвредности подозрительного файла на основании извлеченных взвешенных признаков, как описано выше для классификатора на базе линейной модели, и иных статических (не имеющих заданного веса) признаков, таких как, например, тип файла и его иные характеристики, с использованием алгоритма, реализующего наиболее эффективное дерево решений, отобранное на этапе обучения алгоритма экспертами с использованием файлов с заведомого известным вредоносным кодом, характеризующихся известным поведением.
Окончательный вердикт в отношении безвредности подозрительного файла процессинговый модуль 1.4 выносит в случае, в котором по меньшей мере один из заданного набора классификаторов или хотя бы один из заданного набора классификаторов вынес персональный вердикт в отношении безвредности подозрительного файла, в противном же случае, в котором ни один из заданного набора классификаторов не вынес персонального вердикта в отношении безвредности подозрительного файла, процессинговый модуль 1.4 выносит окончательный вердикт в отношении вредоносности подозрительного файла.
В одном из вариантов реализации настоящего изобретения процессинговый модуль 1.4 может выносит свой окончательный вердикт в отношении вредоносности или безвредности подозрительного файла путем сравнения суммарного веса персональных вердиктов, принятых заданным набором классификаторов в процессинговом модуле 1.4, с заданным пороговым значением, являющимся по существу константой, при этом любому персональному вердикту, вынесенному каждым классификатором из заданного набора классификаторов, автоматически присваивается свой предварительно заданный весовой коэффициент. Таким образом, процессинговый модуль 1.4 принимает тот или иной окончательный вердикт с учетом всех персональных вердиктов (промежуточных вердиктов) используемых классификаторов, имеющих тот или иной вес в суммарном весе, учитываемом процессинговым модулем 1.4 для вынесения окончательного вердикта.
После вынесения окончательного вердикта процессинговый модуль 1.4 подготавливает или создает отдельный поведенческий отчет по каждому подозрительному файлу, проанализированному в этом процессинговом модуле 1.4, причем такой поведенческий отчет по меньшей мере содержит все сведения из соответствующего лог-файла, созданного модулем 1.3 системного мониторинга для указанного подозрительного файла, в частности данные о поведении подозрительного файла в соответствующей виртуальной машине, данные о версии модуля 1.3 системного мониторинга, данные об окончательном вердикте, вынесенном процессинговым модулем 1.4 в отношении подозрительного файла, а также данные о классификаторах, использованных процессинговым модулем 1.4 для вынесения окончательного вердикта, и их персональных вердиктах в отношении вредоносности или безвредности подозрительного файла.
Процессинговый модуль 1.4 снабжен специальным фреймворком (программная платформа), позволяющим, например, оператору сервера 1 или экспертным специалистам вносить изменения в заданный набор классификаторов, используемых процессинговым модулем 1.4 для вынесения окончательного вердикта в отношении вредоносности или безвредности подозрительного файла, как более подробно описано выше.
В случае, когда процессинговый модуль 1.4 выносит окончательный вердикт о вредоносности подозрительного файла, то есть относит подозрительный файл, полученный от модуля 1.3 системного мониторинга, к вредоносным файлам, процессинговый модуль 1.4 может выполнить по меньшей мере одно из следующих действий: выдать предупредительное сообщение об обнаруженной угрозе, блокировать передачу вредоносного файла конечному получателю, блокировать источники вредоносного файла и/или сохранить созданный поведенческий отчет в облачном хранилище 4 поведенческих отчетов.
Для сохранения созданного поведенческого отчета в облачном хранилище 4 поведенческих отчетов процессинговый модуль 1.4 получает доступ к облачному хранилищу 4 поведенческих отчетов или устанавливает с ним связь с использованием модуля 1.1 связи, с которым процессинговый модуль 1.4 соединен с помощью шины 1.6 связи, с обеспечением проводной и/или беспроводной передачи указанного поведенческого отчета в облачное хранилище 4 поведенческих отчетов. В случае, в котором поведенческий отчет, созданный процессинговым модулем 1.4 для конкретного вредоносного файла, имеет более старую или предыдущую версию поведенческого отчета (то есть версию поведенческого отчета, созданного с использованием сведений из лог-файла модуля 1.3 системного мониторинга более ранней версии), ранее созданную процессинговым модулем 1.4 для указанного подозрительного файла и хранящуюся в облачном хранилище 4 поведенческих отчетов, процессинговый модуль 1.4 обеспечивает сохранение обеих версий указанного поведенческого отчета в облачном хранилище 4 поведенческих отчетов, при этом вновь созданный поведенческий отчет приобретает идентификатор, метку или статус последней версии поведенческого отчета, в результате чего именно этот поведенческий отчет последней версии будет использован в работе модуля 1.3 системного мониторинга при вышеописанном анализе следующего такого же подозрительного файла (то есть файла, имеющего ту же самую хеш-сумму, что файл, для которого имеется поведенческий отчет), полученного сервером 1.
В одном из вариантов реализации настоящего изобретения в случае, в котором поведенческий отчет, созданный процессинговым модулем 1.4 для конкретного вредоносного файла, имеет более старую или предыдущую версию поведенческого отчета (то есть версию поведенческого отчета, созданного с использованием сведений из лог-файла модуля 1.3 системного мониторинга более ранней версии), ранее созданную процессинговым модулем 1.4 для указанного подозрительного файла и хранящуюся в облачном хранилище 4 поведенческих отчетов, процессинговый модуль 1.4 обеспечивает обновление данных в облачном хранилище 4 поведенческих отчетов путем удаления предыдущей версии поведенческого отчета и записи новой версии поведенческого отчета.
Следует отметить, что модуль 1.1 связи, фильтрующий модуль 1.2, модуль 1.3 системного мониторинга и процессинговый модуль 1.4 реализуют свои вышеописанные функции по существу в режиме реального времени, то есть модуль 1.1 связи продолжает принимать сетевой трафик, фильтрующий модуль 1.2 выполняет свои операции по фильтрации по меньшей мере части из файлов, извлеченных из ранее принятого сетевого трафика, модуль 1.3 системного мониторинга выполняет свои операции по отслеживанию поведения по меньшей мере части из полученных подозрительных файлов, а процессинговый модуль 1.4 выполняет свои операции по анализу по меньшей мере части из лог-файлов, полученных от модуля 1.3 системного мониторинга, и сохранению по меньшей мере части из созданных поведенческих отчетов в облачном хранилище 4 поведенческих отчетов.
В одном из вариантов реализации настоящего изобретения модуль 1.3 системного мониторинга и процессинговый модуль 1.4 могут быть объединены, например, в одиночный модуль анализа подозрительных файлов, имеющий все вышеописанные функциональные возможности, присущие модулю 1.3 системного мониторинга и процессинговому модулю 1.4.
Еще в одном варианте реализации настоящего изобретения модуль 1.1 связи может быть разделен на несколько отдельных модулей связи, каждый из которых обеспечивает по меньшей мере один из известных способов проводной и/или беспроводной связи в сервере 1.
В некоторых вариантах реализации настоящего изобретения модуль 1.3 системного мониторинга может быть разделен на несколько независимых модулей, каждый из которых может выполнять по меньшей мере одну из вышеописанных функциональных возможностей, присущих модулю 1.3 системного мониторинга, и которые выполнены с возможностью связи друг с другом и остальными конструктивными модулями сервера 1 с помощью шины 1.6 связи. При этом один из таких независимых модулей может быть выполнен с возможностью создания лог-файла, как описано выше, или может иметься, например, дополнительный модуль создания лог-файлов, выполненный с возможностью связи с указанными независимыми модулями с помощью, например, шины 1.6 связи с обеспечением получения от них данных о поведении подозрительного файла для создания лог-файла для этого подозрительного файла.
В других вариантах реализации настоящего изобретения процессинговый модуль 1.4 может быть разделен на несколько других независимых модулей, каждый из которых может выполнять по меньшей мере одну из вышеописанных функциональных возможностей, присущих процессинговому модулю 1.4, и которые выполнены с возможностью связи друг с другом и остальными конструктивными модулями сервера 1 с помощью шины 1.6 связи. При этом один из таких независимых модулей может быть выполнен с возможностью создания поведенческого отчета, как описано выше, или может иметься, например, дополнительный модуль создания поведенческих отчетов, выполненный с возможностью связи с указанными независимыми модулями с помощью, например, шины 1.6 связи с обеспечением получения от них данных о результатах анализа полученного лог-файла для создания поведенческого отчета для конкретного подозрительного файла.
В другом варианте реализации настоящего изобретения фильтрующий модуль 1.2 может быть разделен на несколько других независимых модулей, каждый из которых может выполнять по меньшей мере одну из вышеописанных функциональных возможностей, присущих фильтрующему модулю 1.2, и которые выполнены с возможностью связи друг с другом и остальными конструктивными модулями сервера 1 с помощью шины 1.6 связи. При этом один из таких независимых модулей может быть выполнен с возможностью принятия решения, следует ли отнести анализируемый файл к доверенным/вредоносным файлам, еще один из таких независимых модулей может быть выполнен с возможностью принятия решения, следует ли отнести анализируемый файл к доверенным файлам или же следует направить этот анализируемый файл на анализ в модуль 1.3 системного мониторинга, как описано выше, а каждый из остальных независимых модулей из указанных независимых модулей может быть выполнен с возможностью принятия решения, следует ли отнести анализируемый файл к доверенным файлам или же следует направить этот анализируемый файл для дальнейшего анализа в другой независимый модуль из указанных независимых модулей. Кроме того, в рамках этого другого варианта реализации может иметься, например, отдельный дополнительный модуль для принятия решений, выполненный с возможностью связи с каждым из независимых модулей с помощью, например, шины 1.6 связи с обеспечением получения от каждого из них данных, полученных в результате их работы, для принятия решений, следует ли отнести анализируемый файл к доверенным/вредоносным файлам или же следует направить этот анализируемый файл для дальнейшего анализа в другой независимый модуль из указанных независимых модулей или же в процессинговый модуль 1.4.
В иных вариантах реализации настоящего изобретения каждый классификатор из заданного набора классификаторов, используемых в работе процессингового модуля 1.4, может быть реализован в виде отдельного классифицирующего модуля, выносящего свой персональный вердикт в отношении вредоносности или безвредности того или иного подозрительного файла, при этом указанные отдельные классифицирующие модули могут быть выполнены с возможностью связи с процессинговым модулем 1.4 с помощью, например, шины 1.6 связи, а процессинговый модуль 1.4 выносит окончательный вердикт в отношении вредоносности или безвредности того или иного подозрительного файла с использованием заданного набора правил принятия решения и персональных вердиктов, вынесенных классифицирующими модулями.
Согласно одному из вариантов реализации настоящего изобретения, по меньшей мере часть из вышеописанных функциональных возможностей, присущих фильтрующему модулю 1.2, модулю 1.3 системного мониторинга и/или процессинговому модулю 1.4 может быть реализована в виде отдельного функционального подмодуля или функционального блока, входящего в состав соответствующего одного из модулей 1.2, 1.3 и 1.4. Таким образом, фильтрующий модуль 1.2 может содержать несколько своих подмодулей, каждый из которых реализует по меньшей мере одну из вышеописанных функциональных возможностей, присущих фильтрующему модулю 1.2, модуль 1.3 системного мониторинга может содержать несколько своих подмодулей, каждый из которых реализует по меньшей мере одну из вышеописанных функциональных возможностей, присущих модулю 1.3 системного мониторинга, и процессинговый модуль 1.4 может содержать несколько своих подмодулей, каждый из которых реализует по меньшей мере одну из вышеописанных функциональных возможностей, присущих процессинговому модулю 1.4.
Таким образом, вышеописанные функциональные возможности фильтрующего модуля 1.2 обеспечивают возможность эффективной фильтрации большей части файлов, извлекаемых из сетевого трафика, в результате чего для анализа подозрительных файлов, получаемых от фильтрующего модуля 1.2, в модуле 1.3 системного мониторинга требуется значительно меньший объем вычислительных ресурсов, выделяемых сервером 1 на запуск виртуальных машин для анализа в них поведения подозрительных файлов. Кроме того, вышеописанные функциональные возможности фильтрующего модуля 1.3 системного мониторинга обеспечивают возможность эффективного анализа поведения подозрительного файла в виртуальной машине, а вышеописанные функциональные возможности процессингового модуля 1.4 обеспечивают возможность вынесения точного и достоверного вердикта в отношении вредоносности или безвредного подозрительного файла.
Согласно еще одному аспекту предложен способ определения вредоносных файлов в сетевом трафике, показанный в виде блок-схемы на фиг. 2.
Способ, показанный на фиг. 2, начинается в блоке 2, согласно которому обеспечивают наличие сервера 1 для определения вредоносных файлов в сетевом трафике, конструктивные блоки и функциональные возможности которого описаны выше. В блоке 2.1 способа получают, посредством серверного модуля связи, сетевой трафик из сети передачи данных. В блоке 2.2 способа извлекают, посредством серверного фильтрующего модуля, множество файлов из полученного сетевого трафика. В блоке 2.3 способа анализируют, посредством серверного фильтрующего модуля, извлеченные файлы с обеспечением выявления по меньшей мере одного подозрительного файла из указанного множества файлов. В блоке 2.4 запускают, посредством серверного модуля системного мониторинга, каждый полученный подозрительный файл по меньшей мере на одной виртуальной машине, характеризующейся заданным набором параметров состояния. В блоке 2.5 способа регистрируют, посредством серверного модуля системного мониторинга, изменения в заданном наборе параметров состояния указанной по меньшей мере одной виртуальной машины. В блоке 2.6 способа анализируют, посредством процессингового модуля, полученные изменения параметров состояния с использованием заданного набора правил анализа. В блоке 2.7 способа устанавливают, посредством процессингового модуля, характерны ли проанализированные изменения параметров состояния для вредоносных файлов. Если в блоке 2.7 способа было установлено, что проанализированные изменения параметров состояния характерны для вредоносных файлов, то способ переходит к блоку 2.8 способа, согласно которому относят, посредством процессингового модуля, указанный запущенный файл к вредоносным файлам с последующим завершением способа в блоке 2.10 способа. В противном случае, то есть когда в блоке 2.7 способа было установлено, что проанализированные изменения параметров состояния не характерны для вредоносных файлов, способ переходит к блоку 2.9 способа, согласно которому относят, посредством процессингового модуля, указанный запущенный файл к доверенным файлам с последующим завершением способа в блоке 2.10 способа.
Операции в блоке 2.1 способа включают подключение, посредством серверного модуля связи, по меньшей мере к одному из устройств захвата сетевого трафика, включенных в сеть передачи данных.
Операции в блоке 2.3 способа включают проверку, является ли подозрительным формат каждого из указанных извлеченных файлов, с обеспечением отнесения проверяемого файла к доверенным файлам, если его формат не является подозрительным, или к подозрительным файлам, если его формат является подозрительным. При этом вышеуказанная операция проверки формата каждого из указанных извлеченных файлов на подозрительность включает по меньшей мере следующие подэтапы: (i) идентификация формата каждого из указанных извлеченных файлов, (ii) получение данных об известных вредоносных форматах файлов, установление совпадения идентифицированного формата каждого извлеченного файла с одним из известных вредоносных форматов файлов из указанных полученных данных. Если в результате выполнения операции по проверке формата каждого из извлеченных файлов на подозрительность было установлено, что формат извлеченного файла является подозрительным, то дополнительно определяют, посредством серверного фильтрующего модуля, имеется ли поведенческий отчет для извлеченного файла с подозрительным форматом, для чего получают данные о поведенческих отчетах, вычисляют хеш-сумму каждого извлеченного файла и устанавливают, путем сравнения вычисленной хеш-суммы извлеченного файла с хеш-суммами, идентифицирующими поведенческие отчеты в указанных полученных данных, соответствие каждого извлеченного файла одному из имеющихся поведенческих отчетов.
В ответ на то, что для извлеченного файла с подозрительным форматом имеется поведенческий отчет, дополнительно проверяют, посредством серверного фильтрующего модуля, является ли имеющийся поведенческий отчет актуальным, с обеспечением отнесения извлеченного файла к доверенным файлам или вредоносным файлам в случае признания его таковым в актуальном поведенческом отчете. При этом в ответ на то, что имеющийся поведенческий отчет не является актуальным, дополнительно проверяют, посредством серверного фильтрующего модуля, подписан ли анализируемый файл доверенной электронной подписью, с обеспечением отнесения проверяемого файла к доверенным файлам, если он подписан доверенной электронной подписью.
Согласно предложенному способу, этап проверки наличия у извлеченного файла доверенной электронной цифровой подписи включает выполнение по меньшей мере следующих подэтапов: (i) идентификация владельца электронной подписи, которой подписан извлеченный файл, (ii) получение данных о доверенных владельцах электронных подписей, (iii) установление совпадения идентифицированного владельца электронной подписи с одним из доверенных владельцев электронных подписей из указанных полученных данных. В ответ на то, что извлеченный файл не подписан доверенной электронной подписью, согласно предложенному способу дополнительно проверяют, посредством серверного фильтрующего модуля, происходит ли указанный файл из доверенного источника данных, с обеспечением отнесения проверяемого файла к доверенным файлам, если он происходит из доверенного источника данных.
Согласно предложенному способу, этап проверки происхождения извлеченного файла включает выполнение по меньшей мере следующих подэтапов: (i) определение источника извлеченного файла, (ii) получение данных о доверенных источниках, (iii) установление совпадения определенного источника происхождения анализируемого файла с одним из доверенных источников данных из указанных полученных данных. В ответ на то, что извлеченный файл не происходит из доверенного источника данных, согласно предложенному способу дополнительно проверяют, посредством серверного фильтрующего модуля, был ли присвоен извлеченному файлу идентификатор доверенного файла, с обеспечением отнесения проверяемого файла к доверенным файлам, если ему был присвоен идентификатор доверенного файла.
Согласно предложенному способу, этап проверки наличия у извлеченного файла идентификатора доверенного файла включает выполнение по меньшей мере следующих подэтапов: (i) вычисление хеш-суммы извлеченного файла, (ii) получение данных о доверенных файлах, каждый из которых поставлен в соответствие с конкретной хеш-суммой, (iii) установление совпадения вычисленной хеш-суммы анализируемого файла с хеш-суммой одного из доверенных файлов из указанных полученных данных. В ответ на то, что извлеченный файл не имеет идентификатора доверенного файла согласно предложенному способу дополнительно передают, посредством серверного фильтрующего модуля, извлеченный файл в модуль системного мониторинга.
Операции в блоке 2.4 способа включают выполнение по меньшей мере следующих подэтапов: (i) идентификация по меньшей мере одного атрибута каждого полученного подозрительного файла, (ii) получение данных об имеющихся виртуальных машинах, каждая из которых характеризуется заданным набором атрибутов настройки, (iii) выявление в имеющихся виртуальных машинах из указанных полученных данных дефолтной виртуальной машины, по меньшей мере один атрибут настройки которой из заданного набора атрибутов настройки совпадает с указанным идентифицированным атрибутом подозрительного файла, (iv) запуск подозрительного файла в выявленной дефолтной виртуальной машине с обеспечением идентификации по меньшей мере ещё одного атрибута запущенного файла и установление совпадения указанного еще одного идентифицированного атрибута по меньшей мере еще с одним из указанных атрибутов настройки дефолтной виртуальной машины, (v) в случае, если указанный по меньшей мере еще один идентифицированный атрибут запущенного файла не совпадает с указанным по меньшей мере еще одним атрибутом настройки дефолтной виртуальной машины, повторный запуск подозрительного файла еще на одной виртуальной машине из имеющихся виртуальных машинах, указанные атрибуты настройки которой совпадают с указанными атрибутами подозрительного файла.
Согласно предложенному способу, этап регистрации изменений в заданном наборе параметров состояния указанной по меньшей мере одной виртуальной машины включает отслеживание, посредством модуля системного мониторинга, указанных изменений в течение заданного периода времени, составляющего 2-3 минуты. В предложенном способе также обеспечивают возможность изменения, посредством серверного модуля системного мониторинга, заданного набора параметров состояния каждой виртуальной машины и/или изменения заданного набора правил анализа.
В ответ на отнесение файла, проанализированного в серверном процессинговом модуле, к вредоносным файлам, согласно предложенному способу дополнительно обеспечивают, посредством серверного процессингового модуля, возможность выдачи предупредительного сообщения, блокировки вредоносного файла, блокировки источников вредоносного файла, внесения вредоносного файла в базу данных вредоносных файлов и/или создания поведенческого отчета для вредоносного файла. В предложенном способе также настраивают каждую из указанных виртуальных машин путем установки операционной системы с необходимой архитектурой, выбор языка локализации операционной системы, установку необходимого программного обеспечения и/или настройки установленного программного обеспечения.
Согласно еще одному аспекту настоящего изобретения предложен машиночитаемый носитель для длительного хранения данных, хранящий машиночитаемые инструкции, которые, при их исполнении серверным процессором, вызывают выполнение этапов способа, описанного в данном документе. Машиночитаемые инструкции могут содержать машиночитаемый программный код, который может быть передан с использованием любой подходящей среды передачи данных, в том числе с использованием беспроводных средств, проводных средств, волоконно-оптического кабеля, радиочастоты и/или т.п., и/или их любой подходящей комбинации. Машиночитаемый программный код может быть написан на одном из языков программирования или любой комбинации языков программирования, содержащих объектно-ориентированный язык программирования, такой как «Java», «Smalltalk», «C++» и/или т.п., и обычные процедурные языки программирования, такие как язык программирования «C». Машиночитаемый программный код может полностью или частично исполняться на сервере 1.
Таким образом, машиночитаемые программные инструкции, хранящиеся на машиночитаемом носителе, могут обеспечивать управление сервером 1 таким образом, что он будет функционировать вышеописанным образом, так что машиночитаемые инструкции, хранящиеся в машиночитаемом носителе, создают промышленное изделие, содержащее программные инструкции, которые реализуют функции/действия, указанные в блоках блок-схемы по фиг. 2, иллюстрирующей работу сервера 1.
В качестве машиночитаемого носителя для длительного хранения данных может быть использован один из следующих материальных машиночитаемых носителей, предназначенных для хранения данных в течение длительного периода времени: накопители на жестких дисках, постоянное запоминающее устройство (ROM), накопители на компакт-дисках (CD), накопители на универсальных цифровых дисках (DVD), накопители на гибких дисках, накопители на Blu-ray дисках и т.п.
Модификации и улучшения вышеописанных вариантов осуществления настоящего технического решения будут ясны специалистам в данной области техники. Предшествующее описание представлено только в качестве примера и не несет никаких ограничений. Таким образом, объем настоящего технического решения ограничен только объемом прилагаемой формулы изобретения.
Изобретение относится к области информационной безопасности, а именно к определению вредоносных файлов в сетевом трафике. Технический результат – повышение эффективности использования вычислительных ресурсов при обеспечении автоматизированной защиты. Сервер для определения вредоносных файлов в сетевом трафике содержит модуль связи, выполненный с возможностью получения сетевого трафика из сети передачи данных, фильтрующий модуль, выполненный с возможностью подключения к модулю связи для получения от него захваченного сетевого трафика и извлечения множества файлов из полученного сетевого трафика, анализа извлеченных файлов с обеспечением выявления по меньшей мере одного подозрительного файла из указанного множества файлов, модуль системного мониторинга, подключенный к фильтрующему модулю, выполненный с возможностью запуска каждого полученного подозрительного файла на виртуальной машине, характеризующейся заданным набором параметров состояния, регистрация изменений в заданном наборе параметров состояния указанной виртуальной машины, процессинговый модуль, подключенный к модулю системного мониторинга, выполненный с возможностью анализа полученных изменений параметров состояния с использованием заданного набора правил анализа с обеспечением отнесения указанного запущенного файла к вредоносным файлам, если проанализированные изменения параметров состояния характерны для вредоносных файлов. 3 н. и 35 з.п. ф-лы, 2 ил.
1. Сервер для определения вредоносных файлов в сетевом трафике, содержащий:
модуль связи, выполненный с возможностью получения сетевого трафика из сети передачи данных,
фильтрующий модуль, выполненный с возможностью подключения к модулю связи для получения от него захваченного сетевого трафика и возможностью выполнения по меньшей мере следующих операций:
извлечение множества файлов из полученного сетевого трафика,
анализ указанных извлеченных файлов с обеспечением выявления по меньшей мере одного подозрительного файла из указанного множества файлов,
модуль системного мониторинга, выполненный с возможностью подключения к фильтрующему модулю для получения от него указанных подозрительных файлов и возможностью выполнения по меньшей мере следующих операций:
запуск каждого полученного подозрительного файла по меньшей мере на одной виртуальной машине, характеризующейся заданным набором параметров состояния,
регистрация изменений в заданном наборе параметров состояния указанной по меньшей мере одной виртуальной машины,
процессинговый модуль, выполненный с возможностью подключения к модулю системного мониторинга для получения от него зарегистрированных изменений параметров состояния и с возможностью анализа полученных изменений параметров состояния с использованием заданного набора правил анализа с обеспечением отнесения указанного запущенного файла к вредоносным файлам, если проанализированные изменения параметров состояния характерны для вредоносных файлов.
2. Сервер по п. 1, в котором модуль связи дополнительно выполнен с возможностью подключения по меньшей мере к одному из устройств захвата сетевого трафика, включенных в сеть передачи данных.
3. Сервер по п. 1, в котором при анализе извлеченных файлов фильтрующий модуль проверяет, является ли подозрительным формат каждого из указанных извлеченных файлов, с обеспечением отнесения проверяемого файла к доверенным файлам, если его формат не является подозрительным, или к подозрительным файлам, если его формат является подозрительным.
4. Сервер по п. 3, в котором при проверке формата каждого из указанных извлеченных файлов на подозрительность, фильтрующий модуль выполняет по меньшей мере следующие операции:
идентификация формата каждого из указанных извлеченных файлов,
получение данных об известных вредоносных форматах файлов,
установление совпадения идентифицированного формата каждого извлеченного файла с одним из известных вредоносных форматов файлов из указанных полученных данных.
5. Сервер по п. 3, в котором в ответ на то, что формат извлеченного файла является подозрительным, фильтрующий модуль дополнительно выполнен с возможностью определения, имеется ли поведенческий отчет для извлеченного файла с подозрительным форматом.
6. Сервер по п. 5, в котором при выявлении наличия поведенческого отчета фильтрующий модуль выполняет по меньшей мере следующие операции:
получение данных о поведенческих отчетах,
вычисление хеш-суммы каждого извлеченного файла,
установление, путем сравнения вычисленной хеш-суммы извлеченного файла с хеш-суммами, идентифицирующими поведенческие отчеты в указанных полученных данных, соответствия каждого извлеченного файла одному из имеющихся поведенческих отчетов.
7. Сервер по п. 5, в котором в ответ на то, что для извлеченного файла с подозрительным форматом имеется поведенческий отчет, фильтрующий модуль дополнительно выполнен с возможностью проверки, является ли имеющийся поведенческий отчет актуальным, с обеспечением отнесения извлеченного файла к доверенным файлам или вредоносным файлам в случае признания его таковым в актуальном поведенческом отчете.
8. Сервер по п. 7, в котором в ответ на то, что имеющийся поведенческий отчет не является актуальным, фильтрующий модуль дополнительно выполнен с возможностью проверки, подписан ли анализируемый файл доверенной электронной подписью, с обеспечением отнесения проверяемого файла к доверенным файлам, если он подписан доверенной электронной подписью.
9. Сервер по п. 8, в котором при проверке наличия у извлеченного файла доверенной электронной цифровой подписи фильтрующий модуль выполняет по меньшей мере следующие операции:
идентификация владельца электронной подписи, которой подписан извлеченный файл,
получение данных о доверенных владельцах электронных подписей,
установление совпадения идентифицированного владельца электронной подписи с одним из доверенных владельцев электронных подписей из указанных полученных данных.
10. Сервер по п. 8, в котором в ответ на то, что извлеченный файл не подписан доверенной электронной подписью, фильтрующий модуль дополнительно выполнен с возможностью проверки, происходит ли указанный файл из доверенного источника данных, с обеспечением отнесения проверяемого файла к доверенным файлам, если он происходит из доверенного источника данных.
11. Сервер по п. 10, в котором при проверке происхождения извлеченного файла фильтрующий модуль выполняет по меньшей мере следующие операции:
определение источника извлеченного файла,
получение данных о доверенных источниках,
установление совпадения определенного источника происхождения анализируемого файла с одним из доверенных источников данных из указанных полученных данных.
12. Сервер по п. 10, в котором в ответ на то, что извлеченный файл не происходит из доверенного источника данных, фильтрующий модуль дополнительно выполнен с возможностью проверки, был ли присвоен извлеченному файлу идентификатор доверенного файла, с обеспечением отнесения проверяемого файла к доверенным файлам, если ему был присвоен идентификатор доверенного файла.
13. Сервер по п. 12, в котором при проверке наличия у извлеченного файла идентификатора доверенного файла фильтрующий модуль выполняет по меньшей мере следующие операции:
вычисление хеш-суммы извлеченного файла,
получение данных о доверенных файлах, каждый из которых поставлен в соответствие с конкретной хеш-суммой,
установление совпадения вычисленной хеш-суммы анализируемого файла с хеш-суммой одного из доверенных файлов из указанных полученных данных.
14. Сервер по п. 13, в котором в ответ на то, что извлеченный файл не имеет идентификатора доверенного файла фильтрующий модуль дополнительно выполнен с возможностью передачи извлеченного файла в модуль системного мониторинга.
15. Сервер по п. 1, в котором для запуска каждого подозрительного файла в указанной виртуальной машине модуль системного мониторинга дополнительно выполнен с возможностью выполнения по меньшей мере следующих операций:
идентификация по меньшей мере одного атрибута каждого полученного подозрительного файла,
получение данных об имеющихся виртуальных машинах, каждая из которых характеризуется заданным набором атрибутов настройки,
выявление в имеющихся виртуальных машинах из указанных полученных данных дефолтной виртуальной машины, по меньшей мере один атрибут настройки которой из заданного набора атрибутов настройки совпадает с указанным идентифицированным атрибутом подозрительного файла,
запуск подозрительного файла в выявленной дефолтной виртуальной машине с обеспечением идентификации по меньшей мере ещё одного атрибута запущенного файла и установление совпадения указанного еще одного идентифицированного атрибута по меньшей мере еще с одним из указанных атрибутов настройки дефолтной виртуальной машины,
в случае, если указанный по меньшей мере еще один идентифицированный атрибут запущенного файла не совпадает с указанным по меньшей мере еще одним атрибутом настройки дефолтной виртуальной машины, повторный запуск подозрительного файла еще на одной виртуальной машине из имеющихся виртуальных машинах, указанные атрибуты настройки которой совпадают с указанными атрибутами подозрительного файла.
16. Сервер по п. 1, в котором при регистрации изменений в заданном наборе параметров состояния указанной по меньшей мере одной виртуальной машины модуль системного мониторинга отслеживает указанные изменения в течение заданного периода времени, составляющего 2-3 минуты.
17. Сервер по п. 16, в котором модуль системного мониторинга дополнительно обеспечивает возможность изменения заданного набора параметров состояния каждой виртуальной машины и/или возможностью изменения заданного набора правил анализа.
18. Сервер по п. 1, в котором в ответ на отнесение файла, запущенного на указанной по меньшей мере одной виртуальной машине, к вредоносным файлам, модуль системного мониторинга дополнительно обеспечивает возможность выдачи предупредительного сообщения, блокировки вредоносного файла, блокировки источников вредоносного файла, внесение вредоносного файла в базу данных вредоносных файлов и/или создание поведенческого отчета для вредоносного файла.
19. Способ определения вредоносных файлов в сетевом трафике, исполняемый на сервере, включающий:
получение, посредством серверного модуля связи, сетевого трафика из сети передачи данных,
извлечение, посредством серверного фильтрующего модуля, множества файлов из полученного сетевого трафика,
анализ, посредством серверного фильтрующего модуля, указанных извлеченных файлов с обеспечением выявления по меньшей мере одного подозрительного файла из указанного множества файлов,
запуск, посредством серверного модуля системного мониторинга, каждого полученного подозрительного файла по меньшей мере на одной виртуальной машине, характеризующейся заданным набором параметров состояния,
регистрация, посредством серверного модуля системного мониторинга, изменений в заданном наборе параметров состояния указанной по меньшей мере одной виртуальной машины,
анализ, посредством процессингового модуля, полученных изменений параметров состояния с использованием заданного набора правил анализа с обеспечением отнесения указанного запущенного файла к вредоносным файлам, если проанализированные изменения параметров состояния характерны для вредоносных файлов.
20. Способ по п. 19, согласно которому этап получения сетевого трафика из сети передачи данных включает подключение, посредством серверного модуля связи, по меньшей мере к одному из устройств захвата сетевого трафика, включенных в сеть передачи данных.
21. Способ по п. 19, согласно которому этап анализа извлеченных файлов включает проверку, является ли подозрительным формат каждого из указанных извлеченных файлов, с обеспечением отнесения проверяемого файла к доверенным файлам, если его формат не является подозрительным, или к подозрительным файлам, если его формат является подозрительным.
22. Способ по п. 21, согласно которому этап проверки формата каждого из указанных извлеченных файлов на подозрительность включает по меньшей мере следующие подэтапы:
идентификация формата каждого из указанных извлеченных файлов,
получение данных об известных вредоносных форматах файлов,
установление совпадения идентифицированного формата каждого извлеченного файла с одним из известных вредоносных форматов файлов из указанных полученных данных.
23. Способ по п. 21, согласно которому в ответ на то, что формат извлеченного файла является подозрительным, дополнительно определяют, посредством серверного фильтрующего модуля, имеется ли поведенческий отчет для извлеченного файла с подозрительным форматом.
24. Способ по п. 23, согласно которому этап выявления наличия поведенческого отчета включает получение данных о поведенческих отчетах, вычисление хеш-суммы каждого извлеченного файла и установление, путем сравнения вычисленной хеш-суммы извлеченного файла с хеш-суммами, идентифицирующими поведенческие отчеты в указанных полученных данных, соответствия каждого извлеченного файла одному из имеющихся поведенческих отчетов.
25. Способ по п. 23, согласно которому в ответ на то, что для извлеченного файла с подозрительным форматом имеется поведенческий отчет, дополнительно проверяют, посредством серверного фильтрующего модуля, является ли имеющийся поведенческий отчет актуальным, с обеспечением отнесения извлеченного файла к доверенным файлам или вредоносным файлам в случае признания его таковым в актуальном поведенческом отчете.
26. Способ по п. 25, согласно которому в ответ на то, что имеющийся поведенческий отчет не является актуальным, дополнительно проверяют, посредством серверного фильтрующего модуля, подписан ли анализируемый файл доверенной электронной подписью, с обеспечением отнесения проверяемого файла к доверенным файлам, если он подписан доверенной электронной подписью.
27. Способ по п. 26, согласно которому этап проверки наличия у извлеченного файла доверенной электронной цифровой подписи включает выполнение по меньшей мере следующих подэтапов:
идентификация владельца электронной подписи, которой подписан извлеченный файл,
получение данных о доверенных владельцах электронных подписей,
установление совпадения идентифицированного владельца электронной подписи с одним из доверенных владельцев электронных подписей из указанных полученных данных.
28. Способ по п. 26, согласно которому в ответ на то, что извлеченный файл не подписан доверенной электронной подписью, дополнительно проверяют, посредством серверного фильтрующего модуля, происходит ли указанный файл из доверенного источника данных, с обеспечением отнесения проверяемого файла к доверенным файлам, если он происходит из доверенного источника данных.
29. Способ по п. 28, согласно которому этап проверки происхождения извлеченного файла включает выполнение по меньшей мере следующих подэтапов:
определение источника извлеченного файла,
получение данных о доверенных источниках,
установление совпадения определенного источника происхождения анализируемого файла с одним из доверенных источников данных из указанных полученных данных.
30. Способ по п. 28, согласно которому в ответ на то, что извлеченный файл не происходит из доверенного источника данных, дополнительно проверяют, посредством серверного фильтрующего модуля, был ли присвоен извлеченному файлу идентификатор доверенного файла, с обеспечением отнесения проверяемого файла к доверенным файлам, если ему был присвоен идентификатор доверенного файла.
31. Способ по п. 30, согласно которому этап проверки наличия у извлеченного файла идентификатора доверенного файла включает выполнение по меньшей мере следующих подэтапов:
вычисление хеш-суммы извлеченного файла,
получение данных о доверенных файлах, каждый из которых поставлен в соответствие с конкретной хеш-суммой,
установление совпадения вычисленной хеш-суммы анализируемого файла с хеш-суммой одного из доверенных файлов из указанных полученных данных.
32. Способ по п. 30, согласно которому в ответ на то, что извлеченный файл не имеет идентификатора доверенного файла, дополнительно передают, посредством серверного фильтрующего модуля, извлеченный файл в модуль системного мониторинга.
33. Способ по п. 19, согласно которому этап запуска каждого подозрительного файла в виртуальной машине включает выполнение по меньшей мере следующих подэтапов:
идентификация по меньшей мере одного атрибута каждого полученного подозрительного файла,
получение данных об имеющихся виртуальных машинах, каждая из которых характеризуется заданным набором атрибутов настройки,
выявление в имеющихся виртуальных машинах из указанных полученных данных дефолтной виртуальной машины, по меньшей мере один атрибут настройки которой из заданного набора атрибутов настройки совпадает с указанным идентифицированным атрибутом подозрительного файла,
запуск подозрительного файла в выявленной дефолтной виртуальной машине с обеспечением идентификации по меньшей мере ещё одного атрибута запущенного файла и установление совпадения указанного еще одного идентифицированного атрибута по меньшей мере еще с одним из указанных атрибутов настройки дефолтной виртуальной машины,
в случае, если указанный по меньшей мере еще один идентифицированный атрибут запущенного файла не совпадает с указанным по меньшей мере еще одним атрибутом настройки дефолтной виртуальной машины, повторный запуск подозрительного файла еще на одной виртуальной машине из имеющихся виртуальных машин, указанные атрибуты настройки которой совпадают с указанными атрибутами подозрительного файла.
34. Способ по п. 33, согласно которому этап регистрации изменений в заданном наборе параметров состояния указанной по меньшей мере одной виртуальной машины включает отслеживание, посредством модуля системного мониторинга, указанных изменений в течение заданного периода времени, составляющего 2-3 минуты.
35. Способ по п. 19, согласно которому дополнительно обеспечивают возможность изменения, посредством серверного модуля системного мониторинга, заданного набора параметров состояния каждой виртуальной машины и/или изменения заданного набора правил анализа.
36. Способ по п. 19, согласно которому в ответ на отнесение файла, проанализированного в серверном процессинговом модуле, к вредоносным файлам, дополнительно обеспечивают, посредством серверного процессингового модуля, возможность выдачи предупредительного сообщения, блокировки вредоносного файла, блокировки источников вредоносного файла, внесения вредоносного файла в базу данных вредоносных файлов и/или создания поведенческого отчета для вредоносного файла.
37. Способ по п. 19, согласно которому дополнительно настраивают каждую из указанных виртуальных машин путем установки операционной системы с необходимой архитектурой, выбор языка локализации операционной системы, установку необходимого программного обеспечения и/или настройки установленного программного обеспечения.
38. Машиночитаемый носитель для длительного хранения данных, хранящий машиночитаемые инструкции, которые, при их исполнении серверным процессором, вызывают выполнение этапов способа по любому из пп. 19-37.
US 8635696 B1, 21.01.2014 | |||
US 8850571 B2, 30.09.2014 | |||
US 9215239 B1, 15.12.2015 | |||
СИСТЕМА И СПОСОБ ОБНАРУЖЕНИЯ УГРОЗ В КОДЕ, ИСПОЛНЯЕМОМ ВИРТУАЛЬНОЙ МАШИНОЙ | 2012 |
|
RU2522019C1 |
СПОСОБ ОБНАРУЖЕНИЯ ВРЕДОНОСНЫХ ПРОГРАММ И ЭЛЕМЕНТОВ | 2015 |
|
RU2613535C1 |
СИСТЕМА И СПОСОБ АДАПТИВНОЙ ОПТИМИЗАЦИИ ПРОВЕРКИ ПОТОКА ДАННЫХ, ПЕРЕДАЮЩИХСЯ ПО СЕТИ, НА НАЛИЧИЕ УГРОЗ | 2012 |
|
RU2488880C1 |
Авторы
Даты
2019-02-26—Публикация
2018-01-17—Подача