چرخه مهندسی قواعد Sigma برای SIEMهای سازمانی

مفاهیم پایه و ساختار قواعد Sigma

قالب Sigma به عنوان یک استاندارد باز و ساختاریافته برای توصیف رفتارهای قابل شناسایی در رویدادهای امنیتی طراحی شده است. این قالب با استفاده از فایل‌های YAML، امکان اشتراک‌گذاری قواعد تشخیصی بین سازمان‌ها و ابزارهای مختلف SIEM را فراهم می‌کند. در نسخه 2.1.0 مشخصات رسمی، ساختار فایل‌ها به گونه‌ای تعریف شده که قواعد از بخش‌های اجباری و اختیاری تشکیل می‌شوند. رعایت این ساختار برای اطمینان از سازگاری و قابلیت تبدیل قواعد به زبان‌های جستجوی مختلف ضروری است.

بخش‌های اصلی یک قاعده Sigma شامل عنوان (title)، منبع گزارش (logsource)، بخش تشخیص (detection) و شرط (condition) است. عنوان باید مختصر و گویا باشد و حداکثر ۲۵۶ کاراکتر را شامل شود. بخش logsource مشخص می‌کند که قاعده برای چه نوع رویدادی (مثلاً ایجاد فرآیند در ویندوز) طراحی شده است. بخش detection شامل شناسه‌های جستجو (search-identifier) است که الگوهای مورد نظر را تعریف می‌کنند و در نهایت شرط (condition) ترکیب منطقی این شناسه‌ها را مشخص می‌کند. همچنین فیلدهای اختیاری مانند شناسه یکتا (id)، وضعیت (status)، توضیحات (description)، مراجع (references)، سطح (level) و برچسب‌ها (tags) می‌توانند به قاعده اضافه شوند.

برای حفظ قابلیت تعامل، مشخصات رسمی توصیه‌های مشخصی برای نام‌گذاری فایل‌ها ارائه می‌دهد. نام فایل باید بین ۱۰ تا ۷۰ کاراکتر باشد، از حروف کوچک و اعداد استفاده کند، به جای فاصله از زیرخط ( _ ) استفاده شود و پسوند .yml داشته باشد. همچنین فایل‌ها باید با رمزگذاری UTF-8 و خطوط با LF ذخیره شوند. این الزامات به جلوگیری از مشکلات سازگاری در محیط‌های مختلف کمک می‌کند. به عنوان مثال، نام‌هایی مانند sysmon_file_block_exe.yml یا web_cve_2022_33891_spark_shell_command_injection.yml با این الگو مطابقت دارند.

• بخش‌های اجباری: title، logsource، detection، condition
• بخش‌های اختیاری: id، status، description، references، author، date، modified، fields، falsepositives، level، tags
• اصول نام‌گذاری: طول ۱۰ تا ۷۰ کاراکتر، حروف کوچک، بدون کاراکتر خاص، استفاده از زیرخط به جای فاصله

1. مشخص کردن عنوان کوتاه و گویا برای قاعده
2. تعریف منبع گزارش (logsource) با دسته‌بندی، محصول و سرویس
3. طراحی بخش detection با استفاده از شناسه‌های جستجو و فیلترها
4. تعیین شرط (condition) برای ترکیب منطقی شناسه‌ها
5. اختصاص شناسه یکتا (id) به صورت UUID نسخه 4 در صورت نیاز

title: Whoami Execution
description: Detects a whoami.exe execution
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image: 'C:\Windows\System32\whoami.exe'
  condition: selection
level: high

منابع داده و تله‌متری قابل پشتیبانی

در چرخه مهندسی قواعد Sigma، شناسایی دقیق و پشتیبانی‌پذیر از منابع داده (logsource) نخستین گام برای طراحی یک قاعده مؤثر و پایدار در SIEM سازمانی است. ساختار استاندارد Sigma، سه مؤلفه اصلی category، product و service را برای توصیف منبع رویداد تعریف می‌کند. این مؤلفه‌ها باید به‌گونه‌ای انتخاب شوند که با رویدادهای خام تولیدشده توسط زیرساخت فنی سازمان (مانند ویندوز، لینوکس یا سرویس‌های ابری) سازگاری کامل داشته باشند. به‌عنوان مثال، برای پایش اجرای فرایندها در سیستم‌عامل ویندوز، مقدار استاندارد category: process_creation و product: windows در مستندات رسمی Sigma تعریف شده است و استفاده از این مقادیر، قابلیت تبدیل قاعده به زبان‌های جستجوی SIEMهای مختلف را تضمین می‌کند.

در محیط‌های ابری مانند AWS، انتخاب صحیح service نقشی حیاتی در کاهش نویز و افزایش دقت تشخیص دارد. برای نمونه، قاعده‌ای که به دنبال استفاده از حساب ریشه (Root) در AWS است، باید از product: aws و service: cloudtrail استفاده کند تا تنها رویدادهای مرتبط با CloudTrail مورد بررسی قرار گیرند. این انتخاب، برخلاف استفاده از productهای عمومی، باعث می‌شود که موتور جستجو تنها رویدادهای خام مرتبط با سرویس مشخص را پردازش کند و از ایجاد مثبت کاذب ناشی از رویدادهای نامرتبط جلوگیری شود. لازم به ذکر است که ادعای پشتیبانی از هر منبع داده یا تله‌متری خاص، باید صرفاً بر اساس مستندات رسمی Sigma و نمونه‌های تأییدشده در مخزن SigmaHQ صورت گیرد؛ هرگونه ادعای فراتر از این مستندات، نیازمند ارزیابی دقیق و مستندات تکمیلی از سوی تیم امنیتی سازمان است.

نگاشت صحیح رویدادهای خام به ساختار logsource، نیازمند درک عمیق از قالب‌بندی فیلدها و مقادیر در هر پلتفرم است. به‌عنوان مثال، در قاعده‌ای که برای شناسایی اجرای whoami.exe طراحی می‌شود، فیلد Image باید با مسیر کامل فایل در رویداد خام ویندوز مطابقت داشته باشد. این نگاشت، اگرچه در نگاه اول ساده به نظر می‌رسد، اما در عمل نیازمند بررسی دقیق اسکیمای رویدادهای تولیدشده توسط منابع داده (مانند Sysmon یا Windows Event Log) است. توصیه می‌شود که مهندسان امنیتی، پیش از نگارش قاعده، نمونه‌های واقعی رویدادهای خام را از محیط آزمایشگاهی جمع‌آوری و تحلیل کنند تا از صحت نام فیلدها و مقادیر مورد انتظار اطمینان حاصل نمایند. این فرایند، بخشی از چرخه مهندسی قاعده است که در نهایت به کاهش خطاهای تبدیل و افزایش قابلیت اطمینان تشخیص در محیط عملیاتی منجر می‌شود.

• مؤلفه category برای دسته‌بندی نوع رویداد (مانند process_creation یا network_connection) استفاده می‌شود و باید با اسکیمای رویداد خام هماهنگ باشد.
• مؤلفه product به پلتفرم یا سیستم‌عامل مبدأ اشاره دارد (مانند windows یا linux) و انتخاب آن باید بر اساس محیط هدف در سازمان انجام شود.
• مؤلفه service برای مشخص کردن سرویس یا زیرسیستم خاص (مانند cloudtrail یا security) به کار می‌رود و دقت قاعده را به‌طور قابل توجهی افزایش می‌دهد.
• برای منابع داده ابری، استفاده از مقادیر استاندارد تعریف‌شده در مستندات رسمی Sigma (مانند aws.cloudtrail) الزامی است و هرگونه انحراف باید مستندسازی شود.

1. بررسی اسناد فنی و مستندات رسمی Sigma برای شناسایی مقادیر مجاز و استاندارد مؤلفه‌های logsource مرتبط با زیرساخت سازمان.
2. جمع‌آوری نمونه‌های واقعی رویدادهای خام از محیط آزمایشگاهی یا تولیدی برای هر منبع داده موردنظر و تحلیل ساختار فیلدها.
3. انتخاب ترکیب مناسب category، product و service بر اساس نمونه‌های جمع‌آوری‌شده و تطبیق آن‌ها با قواعد نمونه موجود در مخزن SigmaHQ.
4. ثبت و مستندسازی تصمیمات اتخاذشده در فرایند نگاشت، به‌همراه دلایل فنی، برای استفاده در بازبینی‌های آتی چرخه مهندسی قاعده.

logsource:
  category: process_creation
  product: windows

گردش کار توسعه و اشتراک‌گذاری قواعد

چرخه مهندسی قواعد سیگما در سازمان‌ها معمولاً با شناسایی یک رفتار قابل تشخیص آغاز می‌شود. این رفتار می‌تواند از تحلیل رویدادهای امنیتی، گزارش‌های تیم قرمز یا مطالعات تهدیدات به دست آید. در این مرحله، تیم Detection Engineering باید اطمینان حاصل کند که رفتار مورد نظر به‌طور دقیق تعریف شده و داده‌های لاگ مرتبط با آن در دسترس است. سپس قاعده اولیه با استفاده از ساختار استاندارد YAML و رعایت الزامات مشخصات سیگما (نسخه 2.1.0) نوشته می‌شود. این الزامات شامل استفاده از رمزگذاری UTF-8، خطوط LF، تورفتگی چهار فاصله و کلیدهای کوچک است.

پس از ایجاد قاعده، مرحله اعتبارسنجی و آزمایش آغاز می‌شود. در این مرحله، قاعده باید در محیط آزمایشی با داده‌های واقعی یا شبیه‌سازی‌شده اجرا شود تا میزان نویز و مثبت کاذب آن سنجیده شود. بر اساس نتایج، وضعیت قاعده (Status) تعیین می‌شود: وضعیت experimental برای قواعد آزمایشی که ممکن است نویز داشته باشند، وضعیت test برای قواعد نسبتاً پایدار که نیاز به تنظیمات جزئی دارند، و وضعیت stable برای قواعدی که برای استفاده در تولید مناسب هستند. این وضعیت‌ها در بخش status قاعده ثبت می‌شوند.

یکی از جنبه‌های کلیدی در چرخه توسعه، مدیریت شناسه‌ها و روابط بین قواعد است. هر قاعده باید دارای یک شناسه یکتای جهانی (UUID نسخه 4) باشد. این شناسه در بخش id قرار می‌گیرد. در صورت تغییرات عمده، ادغام قواعد، یا ایجاد قاعده جدید از روی قاعده موجود، باید شناسه جدیدی تولید شود. برای حفظ ردیابی روابط، از بخش related استفاده می‌شود که انواع روابط مانند derived (مشتق‌شده)، obsolete (منسوخ‌شده)، merged (ادغام‌شده)، renamed (تغییرنام‌یافته) و similar (مشابه) را تعریف می‌کند. این روابط به تحلیلگران کمک می‌کند تا تاریخچه و ارتباط قواعد را درک کنند.

پس از اطمینان از کیفیت قاعده، نوبت به اشتراک‌گذاری آن می‌رسد. مخزن SigmaHQ به عنوان مرجع اصلی برای انتشار قواعد جامعه شناخته می‌شود. مشارکت‌کنندگان می‌توانند قاعده خود را از طریق فرایند پیشنهاد تغییر (Pull Request) در گیت‌هاب ارائه دهند. در این فرایند، بازبینی‌کنندگان جامعه کیفیت قاعده را بررسی می‌کنند و در صورت تأیید، قاعده در مخزن قرار می‌گیرد. این فرایند به بهبود مستمر قواعد و همکاری جامعه کمک می‌کند. لازم به ذکر است که جزئیات دقیق فرایند نسخه‌برداری در اینجا مورد بحث نیست.

• استفاده از UUID نسخه 4 برای شناسه یکتای هر قاعده
• تعریف وضعیت‌های stable، test، experimental، deprecated و unsupported در بخش status
• استفاده از فیلد related برای ثبت روابط بین قواعد (مانند derived یا obsolete)
• رعایت الزامات قالب YAML مانند تورفتگی ۴ فاصله و استفاده از کلیدهای کوچک

1. شناسایی رفتار مورد نظر و اطمینان از وجود لاگ‌های مرتبط
2. نوشتن قاعده اولیه با رعایت ساختار استاندارد و بخش‌های اجباری
3. اعتبارسنجی قاعده با داده‌های آزمایشی و تعیین وضعیت مناسب
4. انتشار قاعده در مخزن جامعه (مانند SigmaHQ) پس از بازبینی

id: 929a690e-bef0-4204-a928-ef5e620d6fcc
status: experimental
related:
  - id: 08fbc97d-0a2f-491c-ae21-8ffcfd3174e9
    type: derived

فرایند تبدیل و اجرا در SIEM

در معماری‌های سازمانی، قواعد سیگما به‌عنوان یک فرمت توصیفی و مستقل از پلتفرم، نیازمند گذر از لایه‌ی تبدیل برای اجرا در SIEM هستند. این تبدیل توسط ابزارهایی مانند pySigma یا sigma convert انجام می‌شود که قواعد YAML را به زبان جستجوی بومی SIEM (مانند SPL برای Splunk) ترجمه می‌کنند. نکته‌ی کلیدی این است که قواعد سیگما به‌طور پیش‌فرض از یک taxonomy استاندارد استفاده می‌کنند که نام فیلدها و مقادیر را مشخص می‌کند؛ برای مثال، در یک قاعده‌ی مرتبط با AWS CloudTrail، فیلد userIdentity.type به‌عنوان یک فیلد استاندارد تعریف شده است.

هنگام تبدیل، ابزارهای مذکور باید این نام‌های عمومی را به معادل‌های بومی SIEM نگاشت کنند. برای نمونه، در خروجی تبدیل به SPL، ممکن است sourcetype به‌صورت aws:cloudtrail و فیلد userIdentity.type به‌صورت userIdentity.type ظاهر شود. این نگاشت معمولاً از طریق فایل‌های پیکربندی (config.yml) انجام می‌شود که در آن، نام فیلدها و مقادیر به‌صورت صریح به معادل‌های SIEM متصل می‌شوند. بدون این سازگاری، قواعد ممکن است به‌درستی اجرا نشوند یا نتایج ناقصی تولید کنند.

اهمیت این سازگاری در محیط‌های سازمانی دوچندان است؛ زیرا داده‌های ورودی به SIEM معمولاً از منابع مختلف (مانند Sysmon، Windows Event Log، CloudTrail) جمع‌آوری می‌شوند و هرکدام ساختار فیلدهای خاص خود را دارند. بنابراین، پیش از استقرار هر قاعده، لازم است که نگاشت فیلدها با taxonomy پیش‌فرض سیگما بررسی شود. در صورت وجود فیلدهای سفارشی، باید از بخش definition در logsource استفاده کرد تا تعریف دقیق منبع داده ارائه شود. این کار باعث کاهش خطاهای تبدیل و افزایش دقت تشخیص می‌شود.

• ابزارهای تبدیل مانند pySigma به‌صورت خودکار قواعد را به زبان‌های جستجوی SIEM ترجمه می‌کنند.
• فایل‌های پیکربندی (config.yml) نقش کلیدی در نگاشت فیلدها به معادل‌های بومی دارند.
• تطبیق با taxonomy پیش‌فرض سیگما برای جلوگیری از ناسازگاری در اجرا ضروری است.

1. بررسی ساختار YAML قاعده و اطمینان از وجود بخش logsource با تعریف دقیق منبع داده.
2. انتخاب ابزار تبدیل مناسب (مثلاً pySigma) و تنظیم فایل پیکربندی برای SIEM هدف.
3. اجرای تبدیل و بررسی خروجی برای اطمینان از نگاشت صحیح فیلدها و مقادیر.
4. تست قاعده در محیط آزمایشی SIEM با داده‌های نمونه و ارزیابی نتایج.

sigma convert -t splunk -p config.yml rule.yml

تحلیل هشدارها و تریاژ اولیه

در فرآیند بررسی هشدارهای تولیدشده توسط قواعد سیگما، دو فیلد کلیدی در ساختار هر قاعده نقش تعیین‌کننده‌ای در ارزیابی اولیه دارند: فیلد `level` و فیلد `falsepositives`. فیلد `level` شدت رویداد شناسایی‌شده را بر اساس نظر نویسنده قاعده نشان می‌دهد. مقادیری مانند `low`، `medium`، `high` و `critical` در مشخصات سیگما به‌عنوان سطوح رایج پیشنهاد شده‌اند، اما این مقادیر صرفاً راهنمایی برای اولویت‌بندی اولیه هستند و لزوماً به‌معنی قطعیت تشخیص حمله نیستند.

فیلد `falsepositives` فهرستی از سناریوهای شناخته‌شده و معتبر را ارائه می‌دهد که در آن‌ها رفتار موردنظر ممکن است به‌صورت مشروع رخ دهد. این فیلد به‌ویژه در تصمیم‌گیری درباره‌ی صحت هشدار سودمند است: وجود یک یا چند مورد در این فهرست می‌تواند نشان دهد که هشدار در محیط‌هایی با ویژگی‌های خاص، احتمال تولید مثبت کاذب بیشتری دارد. ارزیابی اولیه باید این فهرست را با شرایط محیطی سازمان و داده‌های مشاهده‌شده مقایسه کند تا مشخص شود آیا منطبق بر آن‌هاست یا نه.

ترکیب سطح (level) و فهرست مثبت کاذب‌ها پایه‌ای برای تصمیم‌گیری در مورد مرحله بعدی است. به‌طور کلی، قاعده‌ای با سطح `high` و بدون مثبت کاذب شناخته‌شده، اولویت بالای برای بررسی دارد. در مقابل، قاعده‌ای با سطح `medium` اما با چندین مورد مثبت کاذب مستند ممکن است در غیاب شواهد تکمیلی، نیازمند بررسی بیشتری باشد. افزودن بر این، فیلد `level` صرفاً یک حدس اولیه است و تریاژ نهایی باید بر اساس اطلاعات کمکی دیگر از جمله منابع ثبت و وقایع مرتبط انجام شود. درک این نکته حیاتی است که فیلد `falsepositives` تنها هیئت وارنبندی ارائه شده توسط نویسنده را مشخص می‌کند و ممکن است تمام موارد محیکی را پوشش ندهد.

• فیلد `level` نشان‌دهنده‌ی درجه‌ی شدت از دید سازنده‌ی قاعده است و مقادیر رایج آن شامل low, medium, high, critical می باشد.
• فیلد `falsepositives` شامل فهرستی از شرایط شناخته‌شده است که ممکن است به‌صورت مشروع الگوی یکسان ایجاد کنند.
• نبود مثبت کاذب در قاعده همیشه به معنای تشخیص قطعی نیست؛ عوامل محیطی ممکن است سناریوهای دیگری را ایجاد کنند.

1. گام اول: مشاهده‌ی مقدار فیلد `level` در قاعده و یادداشت آن، مثلاً high یا critical.
2. گام دوم: مطالعه‌ی فیلد `falsepositives` و استخراج موارد ذکرشده به‌عنوان شرایط معتبر.
3. گام سوم: مقایسه‌ی مورد فهرست‌شده با وضعیت جاری سیستم هدف (مثلاً وجود یک فرآیند خاص یا ابزار مدیریب) بر اساس رویدادهای ثبت‌شده.
4. گام چهارم: تصمیم‌گیری اولیه: اگر سطح بالا و هیچ مورد در `falsepositives` منطبق بر شرایط محیطی نیست، هشدار را با اولویت بالا بررسی کنید؛ در غیر این‌صورت سطح اولویت را نکول ضبط کرده و به جستجوی بیشتر بپردازید.

# نمونه‌ای از یک قاعده ساده با فیلدهای level و falsepositives
title: Example Detection
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image: 'C:\\Windows\\System32\\whoami.exe'
  condition: selection
falsepositives:
  - 'پنهانRun تعاملی توسط مهندس پشتیبانی'
  - 'اسکریپت‌های مربوط به عملیات رباتیک'
level: medium

مثبت‌های کاذب و راه‌های کاهش آن

در مهندسی قواعد Sigma برای SIEMهای سازمانی، مثبت‌های کاذب (False Positives) یکی از چالش‌های اصلی در استقرار و نگهداری سیستم‌های تشخیص نفوذ محسوب می‌شوند. این رویدادها نه‌تنها حجم هشدارهای غیرضروری را افزایش می‌دهند، بلکه می‌توانند منجر به خستگی تحلیلگران امنیتی و نادیده گرفته شدن هشدارهای واقعی شوند. بنابراین، طراحی دقیق ساختار detection با هدف کاهش مثبت‌های کاذب، از اهمیت بالایی برخوردار است.

منابع رایج مثبت‌های کاذب شامل فعالیت‌های مدیریتی مجاز، ابزارهای نظارتی داخلی، و فرآیندهای خودکار سیستم‌عامل هستند. برای مثال، در نظر بگیرید که یک قانون Sigma برای شناسایی استفاده از حساب ریشه (Root) در AWS طراحی شده است. در محیط‌های سازمانی، برخی سرویس‌های AWS به‌صورت خودکار از حساب ریشه استفاده می‌کنند (مانند رویدادهای AwsServiceEvent). بدون فیلتر مناسب، این قانون برای هر رویداد سرویس، هشدار ایجاد می‌کند که منجر به حجم بالای مثبت‌های کاذب می‌شود.

برای کاهش این مشکل، مهندسان امنیتی می‌توانند از فیلترها (filters) در ساختار detection استفاده کنند. در مثال AWS Root، فیلتر eventType: AwsServiceEvent به‌صورت صریح رویدادهای سرویسی را از تشخیص حذف می‌کند. این رویکرد، که در مستندات SigmaHQ نیز به آن اشاره شده است، نشان می‌دهد که چگونه می‌توان با شناخت دقیق محیط و الگوهای رفتاری مجاز، دقت تشخیص را افزایش داد. به‌طور کلی، استفاده از فیلترها باید بر اساس تحلیل دقیق داده‌های لاگ و درک عمیق از زیرساخت سازمان انجام شود.

• شناسایی منابع رایج مثبت‌های کاذب: فعالیت‌های مدیریتی مجاز، ابزارهای نظارتی، فرآیندهای خودکار
• استفاده از فیلترها برای حذف رویدادهای بی‌خطر: مانند فیلتر eventType: AwsServiceEvent در قانون AWS Root
• تست و اعتبارسنجی قواعد در محیط آزمایشی قبل از استقرار در تولید

1. بررسی لاگ‌های تاریخی برای شناسایی الگوهای تکراری که منجر به هشدارهای کاذب می‌شوند.
2. طراحی فیلترهای دقیق بر اساس ویژگی‌های خاص محیط (مانند نام سرویس، نوع رویداد، یا آدرس IP مجاز).
3. اعمال فیلترها در بخش detection قانون Sigma با استفاده از ساختار condition و عملگر not.
4. اجرای قانون در محیط آزمایشی و ارزیابی نرخ هشدارهای کاذب در بازه زمانی مشخص.

detection:
  selection:
    userIdentity.type: Root
  filter:
    eventType: AwsServiceEvent
  condition: selection and not filter

محدودیت‌های ذاتی قواعد Sigma

مشخصات فعلی قواعد Sigma، به‌عنوان یک زبان توصیفی برای تشخیص تهدید، عمدتاً بر تطبیق الگوهای ایستا در رویدادهای لاگ متمرکز است. این مشخصات به‌صراحت پشتیبانی از منطق پیچیده زمانی مانند تشخیص توالی رویدادها در یک بازه زمانی مشخص یا تحلیل همبستگی مبتنی بر وضعیت (stateful correlation) را در قالب استاندارد خود لحاظ نکرده است. در عمل، برای پوشش سناریوهایی مانند زنجیره نفوذ چندمرحله‌ای یا فعالیت‌های توزیع‌شده در طول زمان، تحلیلگران باید به قابلیت‌های بومی SIEM یا زبان‌های پردازش جریان رویداد (مانند queryهای سفارشی) تکیه کنند و قواعد Sigma را صرفاً به‌عنوان نقطه شروع برای شناسایی اولیه در نظر بگیرند. این یک محدودیت ساختاری است و نه نقص در پیاده‌سازی؛ بنابراین در طراحی چرخه مهندسی باید به‌عنوان یک پیش‌فرض در نظر گرفته شود.

دومین محدودیت ذاتی، وابستگی شدید کیفیت و کارایی قواعد به ساختار و محتوای لاگ‌های ورودی است. مشخصات Sigma فرض را بر وجود فیلدهای استاندارد و مقادیر قابل پیش‌بینی می‌گذارد؛ اما در محیط‌های سازمانی واقعی، منابع داده اغلب غیراستاندارد هستند، نام فیلدها در پلتفرم‌های مختلف متفاوت است و مقادیر ممکن است شامل نویز، رمزنگاری یا قالب‌بندی سفارشی باشند. مشخصات برای مدیریت این وضعیت، امکان تعریف taxonomy سفارشی را فراهم کرده است که در آن می‌توان نام فیلدها، مقادیر و حتی نام دسته‌های logsource را به شکلی اختصاصی بازتعریف کرد. با این حال، استفاده از taxonomy سفارشی به‌معنای خروج از حالت پیش‌فرض (sigma) است و مستلزم آن است که ابزار تبدیل یا SIEM مقصد، توانایی ترجمه این taxonomy به ساختار قابل فهم خود را داشته باشد. در غیر این صورت، قاعده عملاً غیرقابل استفاده خواهد بود و ممکن است وضعیت آن به‌عنوان unsupported علامت‌گذاری شود.

سومین محدودیت مهم، به مقیاس‌پذیری و نگهداری مجموعه قواعد در سازمان‌های بزرگ بازمی‌گردد. مشخصات، فیلدهایی مانند status و related را برای مدیریت چرخه حیات قاعده تعریف کرده است؛ اما این ابزارها صرفاً جنبه توصیفی دارند و بار تصمیم‌گیری درباره اعتبار، همپوشانی یا منسوخ‌شدن قواعد را بر دوش تیم امنیتی می‌گذارند. در یک محیط با هزاران قاعده، بدون فرآیند منظم بازبینی و بدون معیارهای عینی برای سنجش نرخ مثبت کاذب و منفی کاذب، مجموعه قواعد به‌سرعت دچار آشفتگی می‌شود. همچنین، مشخصات به‌صراحت اشاره دارد که قواعد با وضعیت unsupported (مانند فرمت همبستگی قدیمی یا فیلدهای سفارشی) در حالت فعلی قابل استفاده نیستند؛ این امر نیاز به یک خط‌مشی روشن برای ارتقا یا حذف تدریجی چنین قواعدی را در چرخه مهندسی ضروری می‌سازد. لازم به ذکر است که این تحلیل صرفاً بر اساس متن مشخصات ارائه شده است و قضاوتی درباره کارایی کلی اکوسیستم Sigma در اینجا مطرح نمی‌شود.

• عدم پشتیبانی بومی از منطق زمانی پیچیده و همبستگی وضعیتی در مشخصات
• وابستگی شدید به کیفیت و استانداردبودن لاگ‌های ورودی؛ نیاز به taxonomy سفارشی برای منابع غیراستاندارد
• ماهیت توصیفی فیلدهای status و related؛ نیاز به فرآیندهای انسانی برای نگهداری و بازبینی
• خطر غیرقابل استفاده‌شدن قواعد دارای فیلدهای سفارشی یا فرمت قدیمی (وضعیت unsupported)

1. مستندسازی صریح محدودیت‌های مشخصات در ابتدای هر پروژه مهندسی قاعده، به‌عنوان ورودی طراحی
2. ارزیابی ساختار لاگ‌های موجود و تعیین نیاز به taxonomy سفارشی پیش از نگارش قاعده
3. تعریف خط‌مشی برای مدیریت قواعد با وضعیت unsupported؛ شامل برنامه ارتقا یا حذف
4. طراحی مکانیزم بازبینی دوره‌ای برای سنجش کارایی قواعد بر اساس معیارهای عملیاتی

عملیاتی‌سازی و نگهداری در مقیاس سازمانی

برای استقرار موفق قواعد Sigma در SIEM سازمانی، لازم است فرآیندی نظام‌مند برای مدیریت چرخه عمر قواعد تعریف شود. این فرآیند شامل شناسایی یکتای هر قاعده با استفاده از فیلد id (UUID نسخه ۴) و ثبت روابط میان قواعد از طریق فیلد related است. فیلد related امکان تعریف انواع روابط مانند derived (مشتق شده)، obsolete (منسوخ)، merged (ادغام شده)، renamed (تغییر نام یافته) و similar (مشابه) را فراهم می‌کند. این ساختار به تیم امنیتی اجازه می‌دهد تا تغییرات قواعد را ردیابی کرده و از نگهداری صحیح مخزن قواعد اطمینان حاصل کند.

وضعیت هر قاعده با فیلد status مشخص می‌شود که مقادیر استاندارد آن شامل stable (پایدار و قابل استفاده در تولید)، test (تقریباً پایدار با نیاز به تنظیمات جزئی)، experimental (آزمایشی با احتمال هشدار نادرست)، deprecated (جایگزین شده) و unsupported (غیرقابل استفاده) است. توصیه می‌شود قواعد با وضعیت experimental ابتدا در محیط آزمایشی ارزیابی شده و پس از تأیید به وضعیت test و سپس stable ارتقا یابند. قواعد deprecated باید با استفاده از فیلد related به قاعده جایگزین متصل شوند تا زنجیره تغییرات حفظ شود.

استفاده از بسته‌های قاعده رسمی SigmaHQ (Rule Packs) به عنوان منبع اصلی قواعد توصیه می‌شود. این بسته‌ها شامل قواعد تأیید شده توسط جامعه هستند و به صورت منظم به‌روزرسانی می‌شوند. برای استقرار، می‌توان از ابزار pySigma برای تبدیل قواعد به فرمت SIEM مقصد استفاده کرد. همچنین توصیه می‌شود فرآیند به‌روزرسانی دوره‌ای (مثلاً ماهانه) برای همگام‌سازی با مخزن اصلی SigmaHQ تعریف شود. در این فرآیند، قواعد جدید اضافه شده، قواعد به‌روزرسانی شده و قواعد منسوخ شناسایی و اعمال می‌شوند.

• مدیریت چرخه عمر قواعد با استفاده از فیلدهای id و related برای ردیابی تغییرات و روابط
• تعیین وضعیت قاعده با فیلد status و ارتقای تدریجی از experimental به stable پس از ارزیابی
• استفاده از بسته‌های قاعده رسمی SigmaHQ به عنوان منبع اصلی و به‌روزرسانی دوره‌ای
• تبدیل قواعد به فرمت SIEM مقصد با ابزار pySigma و استقرار در محیط آزمایشی پیش از تولید

1. مخزن قواعد Sigma را از مخزن رسمی SigmaHQ کلون کنید.
2. قواعد را با استفاده از pySigma به فرمت SIEM سازمانی تبدیل کنید.
3. قواعد با وضعیت experimental را در محیط آزمایشی استقرار و ارزیابی کنید.
4. پس از تأیید، وضعیت قاعده را به test و سپس stable تغییر دهید.
5. فرآیند به‌روزرسانی دوره‌ای (ماهانه) برای همگام‌سازی با مخزن اصلی تعریف کنید.

related:
  - id: 08fbc97d-0a2f-491c-ae21-8ffcfd3174e9
    type: derived
  - id: 929a690e-bef0-4204-a928-ef5e620d6fcc
    type: obsolete