Чарівна формула або як побачити загрозу

    Будь-яка система працює за унікальним алгоритмом, без алгоритму — це не система. Гнучкому, жорсткому, лінійному, розгалужується, детерминированному, стохастическому — не важливо. Важливо, що для досягнення найкращого результату система підкоряється певним правилам. Нам часто задають питання про алгоритми нашого продукту, зокрема: як вдається краще конкурентів обчислювати майбутні загрози? Зі зрозумілих причин все-все деталі цієї чарівної формули розкрити не можна, але можна легенько прочинити двері нашої технологічної кухні і дещо дізнатися.
 
У загальному випадку ми використовуємо дедуктивний метод, тобто йдемо від загального до приватного. У нашому випадку це могло б виглядати приблизно так: все зловредів роблять те-то -> даний файл це теж робить -> 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: Містить входження "\ Registry \ Machine \ Software \ Classes \ * \ shellex \ ContextMenuHandlers \ Notepad + +"

 Аргумент 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 тис. знаків. І це дійсно тільки «злегка прочинені двері»: насправді знайомство з детальним описом технології займе декілька днів і безліч уточнень.
 
До речі, ви можете уточнити прямо зараз, нижче, в коментарях.
    
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.