Кращі практики інтелекту загроз: поради

Багато людей кажуть, що інтелект загроз (TI) смакує добре, але небагато розуміють, як його готувати. Є ще менше тих, хто знає, які процеси потрібно задіяти, щоб TI працював і приносив прибуток. Крім того, ледве хтось знає, як вибрати постачальника даних, де перевірити індикатор помилкових позитивів і чи варто блокувати домен, який ваш колега надіслав вам через WhatsApp.

У нас були дві комерційні підписки APT, десять інформаційних обмінів, близько десятка безкоштовних джерел даних і великий список вузлів виходу з мережі TOR. Ми також використовували пару потужних інструментів для аналізу зворотної складності, майстерські скрипти PowerShell, сканер Loki і платну підписку на VirusTotal. Не тому, що центр реагування на інциденти безпеки не працюватиме без цих інструментів, але якщо ви хочете ловити складні атаки, вам потрібно зробити все можливе.

Що мене особливо турбувало, так це потенційна автоматизація перевірки індикаторів компрометації (IOCs). Немає нічого так морально неправильного, як штучний інтелект, який замінює людину в діяльності, яка вимагає думання. Однак я зрозумів, що моя компанія зіштеться з цією проблемою раніше чи пізніше, оскільки кількість наших клієнтів зростала.

За кілька років постійної діяльності TI я наступив на багато підступів і хочу надати деякі поради, які допоможуть новачкам уникнути поширених помилок.

Порада 1. Не покладайте надію на пошук за хешами: більшість шкідливих програм сьогодні поліформна

Дані про інтелект загроз приходять у різних форматах і проявах. Це можуть бути IP-адреси центрів управління ботнетами, електронні адреси, які беруть участь у фішингових кампаніях, і статті про техніки ухилення, які групи APT скоро почнуть використовувати. Коротко кажучи, це можуть бути різні речі.

Щоб впорядкувати цю суцільну кашу, Девід Б’янко запропонував використовувати так звану Піраміду болю. Вона описує кореляцію між різними індикаторами, які ви використовуєте для виявлення нападника, і кількістю “болю”, яку ви завдасте нападнику, якщо ви ідентифікуєте певний IOC.

Наприклад, якщо ви знаєте MD5-хеш шкідливого файлу, його можна легко і точно виявити. Однак це не завдасть великого болю нападнику, оскільки додавання лише 1 біту інформації до цього файлу повністю змінить його хеш.

Порада 2. Спробуйте використовувати індикатори, які нападнику буде технічно складно або дорого змінити

Антиципуючи питання про те, як дізнатися, чи існує файл з заданим хешем у нашій корпоративній мережі, я скажу наступне: є різні способи. Одним з найлегших методів є використання рішення, яке підтримує базу даних MD5-хешів усіх виконуваних файлів у корпорації.

Давайте повернемось до Піраміди болю. На відміну від виявлення за хешем, більш продуктивно ідентифікувати тактику, техніку і процедури (TTP) нападника. Це важче зробити і вимагає більше зусиль, але ви завдасте більше болю супернику.

Наприклад, якщо ви знаєте, що група APT, яка націлена на ваш сектор економіки, відправляє фішингові електронні листи з *.HTA-файлами на борту, то створення правила виявлення, яке шукає такі електронні листи, завдасть удар нападнику нижче пояса. їм доведеться змінити тактику спаму і, можливо, навіть витратити гроші на покупку 0-день або 1-день експлойтів, які не дешеві.

Порада 3. Не покладайте надію на правила виявлення, створені іншими людьми, оскільки вам потрібно перевірити ці правила на помилкові позитиви і налаштувати їх

Під час створення правил виявлення завжди є спокуса використовувати готові правила. Sigma – це приклад безкоштовного репозиторію. Це формат методів виявлення, незалежний від SIEM, який дозволяє перекладати правила з мови Sigma в ElasticSearch, а також правила Splunk або ArcSight. Репозиторій містить сотні правил. Це здається хорошим речем, але диявол, як завжди, ховається в деталях.

Давайте розглянемо одне з правил виявлення мімікату. Це правило виявляє процеси, які намагалися прочитати пам’ять процесу lsass.exe. Мімікат робить це, коли намагається отримати хеші NTLM, і правило ідентифікує шкідливе ПО.

Однак, це критично для нас – експертів, які не тільки виявляють, але й реагують на інциденти – переконатися, що це справді шкідливий актор. На жаль, є численні законні процеси, які читають пам’ять lsass.exe (наприклад, деякі інструменти антивірусу). Тому в реальному сценарії правило такого типу завдасть більше помилкових позитивів, ніж користі.

Я не хочу звинувачувати когось у цьому відношенні – всі рішення генерують помилкові позитиви; це нормально. Однак спеціалістам з інтелекту загроз потрібно зрозуміти, що подвійна перевірка і налаштування правил, отриманих з відкритих і закритих джерел, все ще необхідні.

Порада 4. Перевірте доменні імена і IP-адреси на шкідливу поведінку не тільки на проксі-сервері і брандмауері, але й у журналах DNS-сервера – і зверніть увагу як на успішні, так і на невдалі спроби розрішення

Шкідливі доменні імена і IP-адреси – це оптимальні індикатори з точки зору простоти виявлення і кількості болю, яку ви завдаєте нападнику. Однак вони здаються легкими для обробки тільки на перший погляд. Як мінімум, вам потрібно запитати себе, де взяти журнал домену.

Якщо ви обмежуєте свою роботу тільки перевіркою журналів проксі-сервера, ви можете пропустити шкідливе ПО, яке намагається запитати мережу безпосередньо або запитує доменне ім’я, згенероване за допомогою DGA, не кажучи вже про тунелювання DNS – жодна з цих речей не буде перерахована у журналах корпоративного проксі-сервера. Злочинці також можуть використовувати сервіси VPN з розширеними функціями або створювати власні тунелі.

Порада 5. Моніторьте або блокуйте – вирішіть, яке з цих дій вибрати тільки після того, як дізнаєтеся, який індикатор ви виявили і визнаєте можливі наслідки блокування

Кожен експерт з інформаційної безпеки зіштався з не тривіальною дилемою: блокувати загрозу чи моніторити її поведінку і починати розслідування, коли вона спрацьовує сигнали. Деякі інструкції однозначно рекомендують вибирати блокування, але іноді робити так є помилкою.

Якщо індикатор компрометації – це доменне ім’я, використовуване групою APT, не блокуйте його – починайте моніторити його замість цього. Сучасні тактики розгортання цільових атак передбачають наявність додаткового секретного каналу зв’язку, наприклад, аплікацій для відстеження мобільних телефонів, який можна виявити тільки шляхом глибокого аналізу. Автоматичне блокування завадить вам знайти цей канал у цьому сценарії; крім того, суперники швидко зрозуміють, що ви помітили їхні дії.

З іншого боку, якщо IOC – це домен, використовуваний крипто-шантажистами, його потрібно блокувати негайно. Але не забудьте моніторити всі невдалі спроби звернутися до заблокованих доменів – конфігурація шкідливого коду може містити кілька URL-адрес командних і контрольних серверів. Деякі з них можуть не бути у джерелах даних і, отже, не будуть заблоковані. Невдовзі інфекція досягне їх, щоб отримати ключ шифрування, який буде негайно використаний для шифрування хоста. Єдиним надійним способом переконатися, що ви заблокували всі C&C, є зворотний аналіз зразка.

Порада 6. Перевірте всі нові індикатори на актуальність перед моніторингом або блокуванням їх

Пам’ятайте, що дані про загрози генеруються людьми, які схильні до помилок, або алгоритмами машинного навчання, які не є безпомилковими. Я був свідком того, як різні постачальники платних звітів про діяльність груп APT випадково додавали законні зразки до списків шкідливих хешів MD5. Враховуючи те, що навіть платні звіти про загрози містять низькоякісні IOC, ті, які отримані через відкритий інтелект, повинні бути обов’язково перевірені на актуальність. Спеціалісти з інтелекту загроз не завжди перевіряють свої індикатори на помилкові позитиви, що означає, що клієнту потрібно виконувати цю роботу за них.

Наприклад, якщо ви отримали IP-адресу, використану новою ітерацією TrickBot, перед тим, як використовувати її у ваших системах виявлення, ви повинні переконатися, що це не частина сервісу хостингу або не походить з вашого IP. В іншому випадку ви будете мати труднощі з численними помилковими позитивами щоразу, коли користувачі, які відвідують сайт, розміщений на цій платформі хостингу, переходять на абсолютно безпечні веб-сторінки.

Порада 7. Автоматизуйте всі робочі процеси даних про загрози до максимуму. Починайте з повної автоматизації перевірки помилкових позитивів через попередній список, інструктуючи SIEM моніторити IOC, які не спрацьовують помилкові позитиви

Щоб уникнути великої кількості помилкових позитивів, пов’язаних з інтелектом і отриманих з відкритих джерел, ви можете виконати попередній пошук цих індикаторів у попередніх списках. Для створення цих списків ви можете використовувати топ-1000 веб-сайтів за трафіком, адреси внутрішніх підмереж, а також доменні імена, використовувані великими постачальниками послуг, такими як Google (GOOGL ), Amazon (AMZN ) AWS, MS Azure та інші. Це також хороша ідея реалізувати рішення, яке динамічно змінює попередні списки, що складаються з топ-доменів/IP-адрес, до яких співробітники компанії зверталися протягом останнього тижня або місяця.

Створення цих попередніх списків може бути проблематичним для середнього SOC, тому має сенс розглянути можливість прийняття так званих платформ інтелекту загроз.

Порада 8. Сканіруйте весь підприємство на індикатори хостів, а не тільки хости, підключені до SIEM

Зазвичай не всі хости в підприємстві підключені до SIEM. Тому неможливо перевірити їх на наявність шкідливого файлу з певною назвою або шляхом, використовуючи тільки стандартну функціональність SIEM. Ви можете вирішити цю проблему наступними способами:

1. Використовуйте сканери IOC, такі як Loki. Ви можете використовувати SCCM для запуску його на всіх хостах підприємства, а потім переслати результати у спільну мережеву папку.
2. Використовуйте сканери уразливостей. Деякі з них мають режими відповідності, які дозволяють перевірити мережу на наявність певного файлу у певному шляху.
3. Напишіть скрипт PowerShell і запустіть його через WinRM.

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