Чарівна формула чи як побачити загрозу
Будь-яка система працює за унікальним алгоритмом, без алгоритму — це не система. Гнучкого, жорсткого, лінійного, розгалуженого, детермінованого, стохастичного — не важливо. Важливо, що з досягнення найкращого результату система підпорядковується певним правилам. Нам часто ставлять питання про алгоритми нашого продукту, зокрема: як вдається краще за конкурентів обчислювати майбутні погрози? По зрозумілих причин всі деталі цієї чарівної формули відчинити не можна, але можна легенько прочинити двері нашої технологічної кухні і дещо дізнатися. У загальному випадку ми використовуємо дедуктивний метод, тобто йдемо від загального до приватного. У нашому випадку це могло б виглядати приблизно так: усі зловреди роблять те-то - & gt; цей файл це теж робить -> Отже, файл - зловред. Але на практиці не все так просто і гладко.
Насамперед неможливо виділити конкретні дії, які однозначно вказують на шкідливість об'єкта. Класичний приклад з доступом до 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 функції та маски для її аргументів.
Тут якщо перший аргумент функції має будь-яке значення, інші відсутні, то подія буде визнано незначним.
Для автоматичного створення правил фільтрації незначних подій ми використовували три методи.
Перший - "метод дрозофіл". Готуємо додаток типу “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) та (RULE270 or RULE540). Достоїнство таких масок – компактність та швидкість роботи, недолік – низька гнучкість.
По-друге, зробили спеціальні скрипти, які проводять глобальний аналіз після обчислення SR (патент US8607349). Скрипти можуть запускатися по черзі, як незалежно, так і щодо спрацьовування правила. Кожен із них має доступ до бази накопиченої статистики ранішеправил і груп правил. Як наслідок, у нас з'явилася можливість (i) використати складну логіку – умови, обчислення, цикли, виклик підпрограм; (ii) максимально використовувати нейронні мережі; (iii) формувати скриптом не лише уточнення до SR рейтингу, а й нові знання, які будуть застосовуватись наступними скриптами.
Наприклад, перший скрипт на основі аналізу десятка правил робить висновок «додаток намагається отримати паролі інших програм». Другий скрипт аналогічно робить висновок "додаток передає щось в Інтернет". Третій скрипт робить висновок типу «якщо програма виявляє інтерес до паролів І передає щось в Інтернет, ТО +100% рейтингу».
Крім того, скрипти можна «причіпляти» до будь-якого правила, у результаті правило стає свого роду «спусковим гачком» для якогось алгоритму.
У цьому прикладі скрипт оцінює операцію створення файлу. Перевіряємо факт створення файлу в корені диска, і це відразу нараховуємо 20% SR. Далі, залежно від розширення файлу, проводимо нарахування додаткового рейтингу зі знаком «+» або «-».
Наведений приклад демонструє головний плюс скриптів – можливість складної диференційованої оцінки аргументів функції з виставленням індивідуального рейтингу SR за результатами різних перевірок. Причому деякі перевірки можуть підвищувати рейтинг, деякі знижувати, що дозволяє робити складні перевірки та складний аналіз, націлений на додаткове придушення фалсів.
А тепер трохи про майбутнє.
Незабаром виходить лінійка персональних товарів 2015 року. Загалом ми подумали-зважили і вирішили взагалі відмовитися від локального SR і повністю перевести розрахунок рейтингу в хмару. У такого підходу одразу багато переваг. Якість аналізу не постраждає, але на порядокзнизиться споживання ресурсів комп'ютера, що захищається — всі обчислення відбуватимуться в нашій інфраструктурі. При цьому затримка доставки вердикту становитиме… Мене… та практично нічого не становитиме: ці частки мілісекунд зможе помітити тільки спеціальний софт.
Ну, ось так коротко про нашу чарівну формулу, всього на 10 тис. знаків. І це дійсно тільки «злегка прочинені двері»: насправді знайомство з детальним описом технології займе кілька днів і безліч уточнень.