Correlation Rule در Log360؛ تبدیل انبوه Eventها به Incident قابل اقدام

SIEM زمانی ارزش دارد که از میان میلیون‌ها Event بتواند داستان حمله را بیرون بکشد. یک Failed Login به‌تنهایی شاید مهم نباشد. ساخت User جدید هم شاید عادی باشد. تغییر Group Membership هم می‌تواند مجاز باشد. اما اگر این سه اتفاق در یک بازه کوتاه و روی یک Account خاص رخ دهند، ماجرا فرق می‌کند.

Correlation Rule در Log360 برای همین طراحی شده است: چند Event پراکنده را بر اساس زمان، کاربر، Host، IP یا الگوی رفتاری به هم وصل کند و به‌جای صدها Alert بی‌ربط، یک Incident معنی‌دار بسازد.

Correlation چیست؟

Correlation یعنی یافتن ارتباط میان Eventهایی که جداگانه شاید کم‌اهمیت باشند اما کنار هم یک Pattern امنیتی می‌سازند. این Pattern می‌تواند نشان‌دهنده Brute Force، Privilege Escalation، Lateral Movement، Data Exfiltration یا فعالیت مشکوک Administrator باشد.

چرا Rule تک‌رویدادی کافی نیست؟

اگر برای هر Failed Login هشدار بسازید، SOC خیلی زود با Alert Flood روبه‌رو می‌شود. Correlation می‌تواند بگوید فقط زمانی Alert بساز که مثلاً ۱۰ Failure از یک IP رخ دهد و بعد Login موفق اتفاق بیفتد.

این Context همان چیزی است که Noise را به Signal تبدیل می‌کند.

اجزای یک Correlation Rule

یک Rule خوب معمولاً چند بخش دارد: Event Pattern، شرط‌های Match، Sequence، Time Window، Threshold و Action. هرکدام باید با سناریوی واقعی Attack طراحی شوند.

Event Sequence

ترتیب Eventها در بسیاری از حملات مهم است. Failed Loginهای متعدد → Login موفق → تغییر Group Membership معنای دیگری دارد نسبت به همان سه Event در ترتیب متفاوت.

اگر Rule فقط Count ببیند و Sequence را نادیده بگیرد، False Positive بالا می‌رود.

Time Window

دو Event مرتبط اگر با فاصله چند روز رخ دهند شاید هیچ ارتباطی نداشته باشند. Window زمانی مشخص می‌کند زنجیره باید در چه بازه‌ای شکل بگیرد.

Window خیلی کوتاه Detection را از دست می‌دهد و Window خیلی بلند Noise را بالا می‌برد. تنظیم آن باید بر اساس Use Case باشد.

Correlation بر اساس User

در حملات Account Compromise، User محور اصلی است. Rule می‌تواند چند Event را فقط زمانی مرتبط بداند که Username مشترک باشد.

این کار برای Password Spray، Impossible Activity یا Privilege Escalation مفید است.

Correlation بر اساس IP و Host

گاهی Source IP یا Host مهم‌تر از User است. مثلاً یک Host که در مدت کوتاه به چند Server مختلف Login می‌کند یا چند Account را امتحان می‌کند می‌تواند نشانه حرکت جانبی باشد.

نمونه سناریو؛ Brute Force موفق

Rule را طوری طراحی کنید که Failed Loginهای متعدد از یک IP را بشمارد و اگر در همان بازه Login موفق برای همان User رخ داد، Severity را بالا ببرد. این بهتر از هشدار روی تک‌تک Failureهاست.

نمونه سناریو؛ Privilege Escalation

ساخت User جدید، افزودن آن به گروه Privileged و Login بعدی همان Account اگر در فاصله کوتاه اتفاق بیفتد، سناریوی بسیار مهم‌تری از هر Event به‌تنهایی است.

Correlation باید این Chain را ببیند.

نمونه سناریو؛ Lateral Movement

Login یک Account به چند Host، استفاده از Credential مشابه و رخدادهای Remote Service می‌توانند کنار هم نشانه حرکت جانبی باشند. مقاله تشخیص Lateral Movement با Log360 UEBA این سناریو را عمیق‌تر بررسی می‌کند.

Correlation و UEBA چه تفاوتی دارند؟

Correlation عمدتاً Rule-based و Pattern-driven است. UEBA روی Baseline رفتار و Anomaly تمرکز دارد. این دو مکمل‌اند؛ Rule می‌گوید «این زنجیره مشکوک است»، UEBA می‌گوید «این رفتار برای این User غیرعادی است».

MITRE ATT&CK و Correlation

Ruleها اگر به Techniqueهای MITRE نگاشت شوند، Coverage SOC قابل اندازه‌گیری‌تر می‌شود. مثلاً می‌توانید بدانید چه Ruleهایی Credential Access، Persistence یا Privilege Escalation را پوشش می‌دهند.

برای این موضوع مقاله MITRE ATT&CK در Log360 را ببینید.

False Positive از کجا می‌آید؟

Ruleهای خیلی عمومی، Window نامناسب، نبود Whitelist و نادیده‌گرفتن Context سازمانی اصلی‌ترین عوامل False Positive هستند. Rule باید با واقعیت محیط شما Tune شود.

مثلاً رفتار Admin Jump Server با Workstation عادی یکسان نیست.

Threshold را چطور انتخاب کنیم؟

Threshold را از حدس شروع نکنید. چند هفته داده تاریخی را ببینید، Baseline عادی را مشخص کنید و سپس آستانه‌ای انتخاب کنید که رفتار غیرعادی را جدا کند.

Severity باید متناسب با Context باشد

همه Correlationها Critical نیستند. Severity باید بر اساس Asset Criticality، User Privilege، Technique و Confidence تعیین شود.

اگر همه‌چیز Critical باشد، عملاً هیچ‌چیز Critical نیست.

Rule Naming و Documentation

نام Rule باید سناریو را روشن کند؛ مثلاً Multiple Failed Logins Followed by Success. همچنین Objective، Data Source، Owner، MITRE Mapping، Threshold و Exceptionها را مستند کنید.

Rule Lifecycle

Correlation Rule یک‌بار ساخته نمی‌شود و تمام. باید Detection Rate، False Positive، تغییر زیرساخت و تغییر رفتار مهاجم را بررسی و Rule را Tune کرد.

ارتباط با Incident Workflow

Alert خوب باید Action ایجاد کند. وقتی Correlation Match شد، SOC باید بداند چه Playbookی اجرا شود: Verify User، Isolate Host، Disable Account یا Escalate به Incident Response.

Cloud و Hybrid Environment

در محیط Hybrid، Eventها از Active Directory، Firewall، Endpoint، Microsoft 365 و Cloud Provider می‌آیند. ارزش Correlation دقیقاً در اتصال این منابع دیده می‌شود.

مقاله Cloud SIEM با Log360 معماری Hybrid را توضیح می‌دهد.

KPIهای Detection Engineering

False Positive Rate، Mean Time to Triage، تعداد Alertهای بدون Action، Detection Coverage و Ruleهای بدون Match طولانی‌مدت را اندازه بگیرید.

سخن پایانی

SOC خوب با تعداد Alert سنجیده نمی‌شود؛ با کیفیت Detection سنجیده می‌شود. Correlation Rule در Log360 کمک می‌کند Eventهای پراکنده به یک روایت امنیتی تبدیل شوند و Analyst به‌جای جست‌وجوی دستی میان هزاران Log، روی Incidentهای واقعی تمرکز کند.

برای شناخت کامل‌تر محصول، Log360 و راهنمای لایسنس Log360 را ببینید.

منابع

ManageEngine Log360 Help
ManageEngine Log360