خلاصه اجرایی

کیفیت YARA حاصل تعادل میان Coverage، Precision، هزینه اجرا و قابلیت نگهداری است. رشته‌های منحصربه‌فرد، شروط چندسیگناله، مجموعه داده سالم و مخرب، Metadata شفاف و چرخه بازبینی، مهم‌تر از طولانی‌کردن Rule یا افزودن Hashهای بیشتر هستند.

چه چیزی یک Rule را باکیفیت می‌کند؟

یک Rule باکیفیت باید خانواده یا رفتار هدف را با شواهد کافی شناسایی کند، روی فایل‌های سالم سازمان Match گسترده نداشته باشد و منطق آن برای تحلیل‌گر بعدی قابل فهم باشد. Detection تک‌نمونه‌ای ممکن است در آزمایش اولیه موفق باشد اما با کوچک‌ترین تغییر در بدافزار از کار بیفتد.

چهار معیار را هم‌زمان اندازه بگیرید: Coverage روی نمونه‌های مرتبط، Precision روی داده سالم، Performance در اسکن واقعی و Maintainability. بهینه‌سازی یک معیار بدون توجه به سه مورد دیگر معمولاً بدهی عملیاتی ایجاد می‌کند.

  • هدف Rule به‌روشنی مشخص باشد: خانواده، Tool، رفتار یا Artifact.
  • Metadata شامل مرجع، تاریخ، مالک، نسخه و سطح اطمینان باشد.
  • رشته‌ها دلیل فنی داشته باشند و صرفاً از خروجی Strings کپی نشده باشند.
  • Condition قابل توضیح و متناسب با نوع فایل باشد.
  • Rule روی Corpus سالم و مخرب آزموده شده باشد.

انتخاب رشته: منحصربه‌فرد، پایدار و کم‌هزینه

رشته مناسب باید تا حد ممکن به پیاده‌سازی هدف نزدیک و در نرم‌افزارهای سالم نادر باشد. پیام خطای اختصاصی، نام Mutex، مسیر ویژه، Fragment پروتکل یا ترکیب چند ثابت می‌تواند مفید باشد. در مقابل، نام APIهای عمومی، عبارت‌های کوتاه و مسیرهای رایج معمولاً Noise زیادی دارند.

رشته‌ای که در هر Build تغییر می‌کند پایدار نیست. رشته‌ای که در هزاران برنامه سالم وجود دارد منحصربه‌فرد نیست. انتخاب درست اغلب به چند رشته متوسط با Condition منطقی نیاز دارد، نه یک رشته به‌ظاهر قطعی.

  • رشته‌های کوتاه یا بسیار عمومی را حذف یا در ترکیب با سیگنال دیگر استفاده کنید.
  • از Regular Expression پیچیده فقط وقتی لازم است استفاده کنید؛ هزینه آن را اندازه بگیرید.
  • Modifierهایی مانند nocase و wide دامنه Match را افزایش می‌دهند و باید توجیه داشته باشند.
  • Fullword برای Tokenهای متنی می‌تواند Match تصادفی را کم کند.
  • برای Binary، جایگاه یا محدوده Offset می‌تواند Precision را افزایش دهد.

Condition چندسیگناله

Ruleهایی که با یک رشته عمومی فعال می‌شوند شکننده‌اند. Condition بهتر، ساختار فایل و چند شاهد مستقل را ترکیب می‌کند. برای نمونه می‌توان Header فایل PE، اندازه منطقی، وجود دو رشته از یک مجموعه و یک Artifact اختصاصی را کنار هم قرار داد.

Condition نباید آن‌قدر سخت شود که Variants واقعی را از دست بدهد. برای مدیریت این تعادل، Ruleهای جداگانه با Confidence متفاوت یا Tagهای روشن بهتر از یک Rule مبهم و بسیار پیچیده هستند.

rule Example_Training_Only
{
  meta:
    purpose = "illustrative structure, not production detection"
  strings:
    $family_a = "unique-protocol-marker" ascii
    $family_b = "specific-error-token" ascii wide
    $context_1 = "campaign-config-key" ascii
  condition:
    uint16(0) == 0x5A4D and filesize < 8MB and
    2 of ($family_*) and $context_1
}

مجموعه تست سالم و مخرب

آزمون فقط روی نمونه‌ای که Rule از آن ساخته شده، نتیجه قابل اتکایی نمی‌دهد. حداقل به Positive set از Variantهای مرتبط، Negative set از نرم‌افزارهای سالم و Near-miss set از فایل‌های مشابه اما غیرهدف نیاز است.

Corpus سالم باید محیط واقعی سازمان را نمایندگی کند: ابزارهای مدیریتی، نرم‌افزارهای تخصصی، Installerها، Driverها و فایل‌های قدیمی. False Positiveهای سازمانی اغلب در داده عمومی دیده نمی‌شوند.

  1. Rule را روی نمونه‌های مرجع و Variantهای مستقل اجرا کنید.
  2. تمام Matchهای Corpus سالم را بررسی و دلیل Match را ثبت کنید.
  3. به‌جای افزودن Allowlist گسترده، رشته یا Condition مسئله‌دار را اصلاح کنید.
  4. زمان اسکن و تعداد Byteهای بررسی‌شده را در مقیاس واقعی اندازه بگیرید.
  5. نتایج Regression را با نسخه Rule نگهداری کنید.

کنترل Performance و پایداری

هزینه یک Rule در مجموعه هزاران‌تایی آشکار می‌شود. Regexهای نامحدود، الگوهای بسیار کوتاه، تعداد زیاد رشته و Scan روی فایل‌های بسیار بزرگ می‌توانند زمان ارزیابی را افزایش دهند. محدودکردن نوع فایل، اندازه و ساختار پیش از ارزیابی رشته‌های گران‌تر معمولاً مفید است.

بهینه‌سازی باید با اندازه‌گیری انجام شود. حذف یک سیگنال مهم صرفاً برای چند میلی‌ثانیه سود ممکن است Coverage را کاهش دهد. Ruleهای کند را پروفایل و سپس براساس فراوانی فایل هدف و ارزش Detection اصلاح کنید.

  • شرط‌های ارزان‌تر مانند Magic و filesize را زودتر لحاظ کنید.
  • Ruleهای مخصوص Memory و File را بدون دلیل در یک منطق ادغام نکنید.
  • برای آرشیوها و فایل‌های بزرگ محدودیت‌های اسکن را مستند کنید.
  • Timeout یا خطای Scanner را به‌عنوان نتیجه منفی تلقی نکنید.

چرخه نگهداری Rule

هر Rule باید مالک و زمان بازبینی داشته باشد. منبع حذف‌شده، تغییر خانواده، افزایش Match سالم یا تغییر موتور YARA می‌تواند اعتبار Rule را تغییر دهد. تاریخ Modified فقط هنگام تغییر معنادار منطق یا Metadata فنی به‌روزرسانی شود.

Ruleهای قدیمی الزاماً بی‌ارزش نیستند؛ Artifactهای تهدیدات قدیمی ممکن است در Compromise Assessment همچنان مهم باشند. تصمیم بازنشستگی باید بر اساس شواهد، Coverage جایگزین و ریسک محیط انجام شود.

منابع و مطالعه بیشتر

  1. Writing YARA rulesYARA Documentation
  2. YARA Performance GuidelinesYARA Documentation
  3. MITRE ATT&CK Data and ToolsMITRE ATT&CK