Всякая система работает по уникальному алгоритму, без алгоритма — это не система. Гибкому, жёсткому, линейному, разветвляющемуся, детерминированному, стохастическому — не важно. Важно, что для достижения наилучшего результата система подчиняется неким правилам. Нам часто задают вопрос об алгоритмах нашего продукта, в частности: как удаётся лучше конкурентов вычислять будущие угрозы? По понятным причинам все-все детали этой волшебной формулы раскрыть нельзя, но можно легонько приоткрыть дверь нашей технологической кухни и кое-что узнать.
В общем случае мы используем дедуктивный метод, то есть идем от общего к частному. В нашем случае это могло бы выглядеть примерно так: все зловреды делают то-то —> данный файл это тоже делает —> cледовательно, файл — зловред. Но на практике не всё так просто и гладко.
Прежде всего, невозможно выделить конкретные действия, которые однозначно указывают на вредоносность объекта. Классический пример с доступом к MBR — нельзя считать всё, что дёргает эту команду зловредом, есть множество других её применений в мирных целях. То же самое относится ко всем остальным действиям. Ведь в оригинале все команды были созданы для совершения каких-то полезных вещей.
Иными словами, задача «отделить зёрна от плевел» здесь неуместна. Другое дело — прикинуть пропорции и состав зёрен и плевел, оценить те же параметры в соседнем амбаре, проанализировать результаты и уже тогда принять обоснованное решение о постановке запятой во фразе «лечить нельзя пропустить». Для этого мы используем технологию с незатейливым названием SR (Security Rating) — этакую развесистую самообучаемую систему весов, помогающую лучше понять истинную природу объекта в процессе его формальной оценки и эмуляции.
При анализе принимаются во внимание состав и плотность генерируемых объектом событий и его внешние атрибуты (имя, размер, местоположение, сжатие и пр.). На основании комплекса правил каждый из параметров получает индивидуальный рейтинг опасности (0-100%). Первый пакет правил (а их сейчас более 500) был результатом «ручного» изучения более 80 тыс. уникальных зловредов различных семейств. Сейчас же правила разрабатываются в основном автоматически, а эксперты-аналитики лишь «подкручивают» алгоритмы самообучения.
Для удобства тестирования и сопровождения правила разделены на группы (например, «Интернет», «Пароли», «Реестр» и т.д.) и если объект «наследил» своим поведением в одном или нескольких из них к нему принимаются соответствующие санкции.
Примеры простейших правил:
Правило «Загрузка драйвера через низкоуровневое API ntdll.dll»
API функция: Загрузка драйвера (NtLoadDriver)
Аргумент 1: *
Аргумент 2: *
Аргумент 3..N: *
Оценка: единичная операция — 40%, 2-3 операции — 50%, >3 операций — 60%
Вредоносность: Нет
Правило «Анализ машинного кода ядра (снятие хуков)»
API функция: Создание/открытие файла (CreateFile)
Аргумент 1: Содержит вхождение «ntoskrnl.exe»
Аргумент 2: *
Аргумент 3..N: *
Оценка: единичная операция — 100%, 2-3 операции — 100%, >3 операций — 100%
Вредоносность: Да
Итоговый рейтинг объекта — сумма всех частных рейтингов после проверки по всей базе данных правил. Иными словами, это типичная нейронная сеть, которая собирает сигналы от множества сенсоров, анализирует их качественные и количественные характеристики, исследует связи и выносит вердикт. Примерно в таком виде SR заступил на вахту в 2007г. (патент US7530106). Как вы догадались, у нас сразу же зачесалось технологию накормить, воспитать и прокачать.
Проблема Номер Один состояла в том, что анализируемый файл может генерировать огромное число незначительных событий, которые не могут повлиять на конечный вердикт о его вредоносности. Например, Delphi-приложение при запуске порождает до 500 таких событий. Они будут идентичны у любого приложения, написанного на этом языке и при этом не несут ровным счётом никакой полезной информации о реальных намерениях файла. Этот «шум» не только потреблял ресурсы компьютера, но и затруднял анализ.
Для отсеивания такого шума мы сделали фильтр. Причём в отличие от обычных правил тут достаточно булева признака. Таким образом, правило сильно упрощается и, соответственно, ускоряется его работа. В итоге правила содержат только имя API функции и маски для её аргументов.
Например:
SysAllocString (*,-NULL-,-NULL-)
Здесь если первый аргумент функции имеет любое значение, а остальные отсутствуют, то событие будет признано незначительным.
Для автоматической генерации правил фильтрации незначительных событий мы использовали три метода.
Первый — «метод дрозофил». Готовим приложение типа “Hello World” с помщью среды разработки X, по возможности используем его наиболее популярные библиотеки. Скармливаем скомпилированное приложение эмулятору, а все генерируемые «дрозофилой» события записываем в графу «незначительные».
Второй — «метод упакованных дрозофил». Аналогичен первому, за исключеним того, что нас интересуют поведенческие события пакера/протектора. Для этого пустышку на Ассемблере обрабатываем по очереди всякими упаковщиками и протекторами, скармливаем эмулятору и… ну, дальше вы догадались.
Третий метод — статистический. Проводим анализ поведения большого количества легитимных и вредоносных файлов, и выделяем API-вызовы, которые часто встречаются в поведении у тех и других. Этот метод дополняет первые два и эффективен в случае, если нет возможности создать «дрозофилу». Типовой пример выявленных таким образом функций — функции для работы с GUI и выделения памяти.
Но это был один из самых мелких челленджей. Дальше — интереснее.
Первая версия SR работала на конкретном защищённом компьютере практически в изоляции. У нас не было глобальной картины, мы не понимали какие правила, как часто и как точно срабатывают и не могли быстро менять их рейтинги. Результат — большие неиспользованные возможности повышения эффективности :) Тогда же у нас полным ходом развивалось облако KSN и к нему мы уже прикрутили экспертную систему Astraea для анализа гигантского объёма сигналов от защищённых компьютеров и выдачи разумных заключений об эпидемиологической обстановке в мире.
В 2009г., к всеобщей радости следующая версия SR (SR2, US8640245) срослась с KSN и Astraea.
А бигдата с хорошей экспертной надстройкой — это в нашей области «матчасть» формулы успеха!
По сути, мы получили рычаг для (i) «отстрела» неэффективных и «мёртвых» правил, (ii) временного отключения или тестирования правил, (iii) практически real-time коррекции рейтингов правил с помощью коэффициентов. При этом размер базы коэффициентов составил смешные килобайты и её обновление даже в те годы практически не нагружало Интернет-канал.
Astraea также расширила статистическую базу для вычисления рейтингов: в этом процессе принимали участие не только сигналы от различных эмуляторов, но и многих других сенсоров, которые также отчитывались в KSN. Кроме того, продукт мог получить из облака уже известный вердикт и принять решение, не доводя процесс эмуляции до конца (а в некоторых случаях вообще его не запуская). И ещё приятный плюс — мы можем с высокой степенью достоверности выцеплять из потока для ручного исследования неизвестных «зверей», которые не набирали порогового значения рейтинга, но вели себя уж очень подозрительно.
Важно, что Astraea делает коррекцию правил автоматически — за человеком остаётся функция регулярно оценивать эффективность используемой математической модели и оптимизировать её (патентная заявка US20140096184).
Наличие глобальной бигдаты сразу раскатало нашу губу на новые идеи для решения старых проблем. Прежде всего — фалсы. В принципе, эту тему мы подкручивали с самого первого дня реализации SR в продуктах. Но в 2011г. выкатили сразу несколько новых фичей для минимизации ложных срабатываний.
Есть много операций, которые выполняются легитимным софтом с вполне мирными целями. Например, инсталляторы удаляют файлы в папке System32. Авторегулировка рейтинга этой операции приведёт к его необоснованной деградации и мы начнём пропускать реальных зловредов. Здесь требуется некое компромиссное решение, чтобы и волки были сыты и овцы целы. И тогда мы решили разделить механизм вычисления рейтинга на 3 части.
Во-первых, описанная выше калькуляция: чем опаснее поведение и чаще встречается, тем выше рейтинг. Во-вторых, своего рода вайтлист-правила, которые отменяют или корректируют действия обычных правил применимо к конкретным ситуациям или файлам. В-третьих, правила детекта легитимных приложений, которые снижают рейтинг опасности при обнаружении характерного поведения и даже могут формировать рейтинг безопасности.
Пример:
Правило «Создание ключа автозапуска»
API функция: Реестр: установка значения параметра (RegSetValueEx)
Аргумент 1: Содержит вхождение "RegistryMachineSoftwareClasses*shellexContextMenuHandlersNotepad++"
Аргумент 2: *
Аргумент 3..N: *
Оценка: единичная операция – 1%, 2-3 операции – 1%, >3 операций – 1%
Вредоносность: Нет
Здесь ясно видно, что дёргается ключ реестра, однако это всего лишь Notepad++ кидает свою библиотеку. Аргумент правила снимает фолсу, при этом основное правило остаётся неизменным и на другие попытки изменить ключ сработает как положено.
А в 2011 г. мы внедрили ещё одну полезную фичу. Как говорилось выше, в SR правила работали автономно друг от друга и таким образом мы не могли изучить сложные зависимости типа «загрузка файла» — «сохранение файла на диск» — «прописывание в автозапуск». Ведь если проследить подобную зависимость, то можно выдать рейтинг куда больше, чем сумма рейтингов отдельных событий. Или меньше :) И тогда мы решили реализовать в SR2 корреляцию событий для более точного детекта неизвестных зловредов.
Сделали это двумя способами. Во-первых, создали битовые маски, выделяющие группы правил или отдельные правила по OR и AND. Базовое описание — битовый индекс классификации поведения. Изначально такое было придумано для кластеризации зловредов по особенностям их поведения, но аналогичный подход можно применять и для уточнения оценки рейтинга — с помощью масок реализовать функцию типа (RULE76 or RULE151) and (RULE270 or RULE540). Достоинство таких масок — компактность и быстрота работы, недостаток — низкая гибкость.
Во-вторых, сделали специальные скрипты, которые проводят глобальный анализ уже после вычисления SR (патент US8607349). Скрипты могут запускаться поочередно, как независимо, так и по срабатыванию правила. Каждый из них имеет доступ к базе накопленной статистики ранее сработавших правил и групп правил. Как следствие, у нас появилась возможность (i) использовать сложную логику — условия, вычисления, циклы, вызов подпрограмм; (ii) по максимуму использовать нейронные сети; (iii) формировать скриптом не только уточнение к SR рейтингу, но и новые знания, которые будут применяться последующими скриптами.
Например, первый скрипт на основе анализа десятка правил делает вывод «приложение пытается получить пароли других программ». Второй скрипт аналогично делает вывод «приложение передает что-то в Интернет». Третий скрипт делает вывод типа «если приложение проявляет интерес к паролям И передает что-то в Интернет, ТО +100% рейтинга».
Кроме того, скрипты можно «прицеплять» к любому правилу, в итого правило становится своего рода «спусковым крючком» для какого-то алгоритма.
Пример скрипта:
Var
S : string;
begin
if copy(ExtractFilePath(APIArg[1]), 2, 100)=':' then begin
AddSR(20);
s := LowerCase(ExtractFileExt(APIArg[1]));
if S = '.exe' then AddSR(40);
if S = '.com' then AddSR(50);
if S = '.pif' then AddSR(60);
if S = '.zip' then AddSR(-20);
end;
end.
В этом примере скрипт оценивает операцию создания файла. Проверяем факт создания файла в корне диска, и за это сразу начисляем 20% SR. Дальше, в зависимости от расширения файла производим начисление дополнительного рейтинга со знаком «+» или «-».
Приведенный пример демонстрирует главный плюс скриптов — возможность сложной дифференцированной оценки аргументов функции с выставлением индивидуального SR рейтинга по результатам различных проверок. Причем некоторые проверки могут повышать рейтинг, некоторые — понижать, что позволяет делать сложные проверки и сложный анализ, нацеленный на дополнительное подавление фалсов.
В качестве бонуса — рисунок руки автора описанной выше технологии. Как есть, практически на салфетке:
А теперь немного о будущем.
Совсем скоро выходит линейка персональных продуктов 2015 года. В общем, мы подумали-взвесили и решили вообще отказаться от локального SR и полностью перевести расчёт рейтинга в облако. У такого подхода сразу много преимуществ. Качество анализа не пострадает, но на порядок снизится потребление ресурсов защищаемого компьютера — все вычисления будут происходить в нашей инфраструктуре. При этом задержка доставки вердикта будет составлять… мнэээ… да практически ничего не будет составлять: эти доли миллисекунд сможет заметить только специальный софт.
Ну, вот так кратенько о нашей волшебной формуле, всего на 10 тыс. знаков. И это действительно только «слегка приоткрытая дверь»: на самом деле знакомство с детальным описанием технологии займёт несколько дней и множество уточнений.
Кстати, вы можете уточнить прямо сейчас, ниже, в комментариях.
Автор:
