فرض کنید کارشناس واحد مالی تقریباً هر روز ساعت ۸ صبح وارد شبکه می‌شود، اما امروز ساعت ۱۰:۱۵ لاگین کرده است. اگر سیستم فقط رفتار گذشته همین کاربر را ببیند، تغییر زمان ورود می‌تواند به‌عنوان Anomaly ثبت شود و Risk Score بالا برود. چند دقیقه بعد مشخص می‌شود کل تیم مالی به‌دلیل جلسه پایان ماه دیرتر کار را شروع کرده‌اند.

اینجا یک سؤال مهم مطرح می‌شود: آیا رفتار این کاربر واقعاً مشکوک است، یا فقط با گذشته خودش فرق دارد؟ Peer Grouping در Log360 UEBA دقیقاً برای اضافه‌کردن همین Context طراحی شده است. به‌جای مقایسه یک کاربر فقط با Baseline شخصی، رفتار او با گروهی از کاربران یا موجودیت‌های مشابه نیز مقایسه می‌شود تا Risk Scoring دقیق‌تر و False Positive کمتر شود.

در ManageEngine Log360 دو مدل اصلی Peer Grouping وجود دارد: Dynamic Peer Grouping که گروه‌ها را براساس رفتار واقعی می‌سازد و Static Peer Grouping که از Attributeهای سازمانی و LDAP مانند Department، Title یا Role استفاده می‌کند. این دو مدل رقیب هم نیستند؛ در بسیاری از محیط‌ها استفاده ترکیبی از آن‌ها Context بهتری برای SOC ایجاد می‌کند.

Peer Grouping چه مشکلی را در UEBA حل می‌کند؟

UEBA برای تشخیص رفتار غیرعادی ابتدا باید بداند «رفتار عادی» چیست. این Baseline می‌تواند زمان ورود، تعداد عملیات، الگوی دسترسی، Hostهای مورد استفاده یا سایر رفتارهای یک User یا Entity را پوشش دهد. مشکل زمانی ایجاد می‌شود که رفتار مشروع سازمانی از Baseline فردی فاصله بگیرد.

برای مثال، کارشناس مالی در پایان ماه ساعات کاری طولانی‌تری دارد، DBA برای Maintenance ساعت ۳ بامداد وارد Database Server می‌شود یا تیم زیرساخت در یک Change Window حجم زیادی از عملیات مدیریتی انجام می‌دهد. اگر Context شغلی و گروهی وجود نداشته باشد، این رفتارها ممکن است به‌صورت غیرضروری Risk Score را افزایش دهند.

Log360 UEBA با Peer Group Analysis رفتار User را در کنار افراد مشابه ارزیابی می‌کند. طبق مستندات رسمی ManageEngine، اگر Peerهای یک کاربر رفتار مشابهی داشته باشند، Confidence آن Anomaly می‌تواند کاهش پیدا کند و Risk Score نیز متناسب با آن تعدیل شود. اگر رفتار کاربر هم با Baseline خودش و هم با Peerهایش متفاوت باشد، سیگنال امنیتی ارزش بیشتری پیدا می‌کند.

Dynamic Peer Grouping در Log360 چیست؟

در Dynamic Peer Grouping، عضویت کاربران از قبل توسط مدیر تعریف نمی‌شود. Log360 از Eventهای رفتاری استفاده می‌کند و کاربرانی را که Patternهای مشابه دارند در Clusterهای رفتاری قرار می‌دهد. این گروه‌ها با تغییر رفتار کاربران می‌توانند به‌مرور تغییر کنند.

برای مثال ممکن است دو کاربر از نظر عنوان شغلی متفاوت باشند اما هر دو در ساعات مشابه، از سیستم‌های مشابه و با الگوی عملیاتی نزدیک کار کنند. Dynamic Peer Grouping می‌تواند این شباهت را از داده واقعی تشخیص دهد؛ چیزی که صرفاً از روی Department یا Job Title لزوماً قابل مشاهده نیست.

ManageEngine توضیح می‌دهد که Dynamic Peer Grouping در Log360 برای گزارش‌های UEBA گروه‌های رفتاری ایجاد می‌کند و فعالیت User بر اساس Clusterهایی که عضو آن‌هاست ارزیابی می‌شود. یک User حتی می‌تواند هم‌زمان عضو چند Cluster باشد، چون رفتار او از چند زاویه قابل مقایسه است.

Static Peer Grouping چیست و چه زمانی بهتر عمل می‌کند؟

Static Peer Grouping به‌جای یادگیری مستقیم رفتار، کاربران را براساس Attributeهای مشترک LDAP دسته‌بندی می‌کند. نمونه‌های رایج عبارت‌اند از:

• Department؛ مانند Finance، HR یا IT
• Title یا Designation؛ مانند DBA، Help Desk Technician یا Network Engineer
• Location یا Branch
• Reporting Manager
• Role یا سایر Attributeهای سازمانی قابل استفاده در Directory

این مدل وقتی مفید است که ساختار Active Directory تمیز و به‌روز باشد و سازمان بخواهد رفتار افراد را با همتایان رسمی خود مقایسه کند. مثلاً اگر یک کارشناس Marketing ناگهان در ساعت ۳ صبح روی Database Server فعالیت مدیریتی داشته باشد، مقایسه او با کاربران مشابه واحد Marketing می‌تواند Context روشنی ایجاد کند.

در مستندات فعلی Log360 UEBA، برای فعال‌سازی Static Peer Grouping حداقل یک Domain باید پیکربندی شده باشد و مدیر می‌تواند Attributeهای مناسب را برای ساخت گروه‌ها انتخاب کند.

مقایسه Dynamic و Static Peer Grouping

Peer Grouping چگونه روی Risk Score اثر می‌گذارد؟

Risk Score در UEBA باید نشان دهد کدام User یا Entity در حال حاضر ارزش بررسی بیشتری دارد. اگر امتیاز فقط براساس تعداد Anomalyها بالا برود، SOC خیلی سریع با Alert Fatigue مواجه می‌شود. Context باعث می‌شود همه Anomalyها وزن یکسانی نداشته باشند.

در Log360 UEBA، وقتی Activity از Baseline مورد انتظار فاصله می‌گیرد Risk Score می‌تواند افزایش پیدا کند. مدیر امنیت همچنین می‌تواند Weight و Time Decay Factor فعالیت‌های مختلف را تنظیم کند. Peer Grouping یک لایه دیگر به این مدل اضافه می‌کند: رفتار User در برابر گروه مشابه هم سنجیده می‌شود.

سناریوی ساده را در نظر بگیرید:

1. کاربری ساعت ۲ بامداد Login می‌کند؛ درحالی‌که معمولاً ساعت ۸ صبح وارد می‌شود.
2. UEBA این رفتار را نسبت به Baseline شخصی غیرعادی می‌بیند.
3. اگر بیشتر Peerهای همان کاربر نیز همان شب به‌دلیل Maintenance در آن ساعت فعال باشند، Confidence Anomaly می‌تواند پایین‌تر بیاید.
4. اگر هیچ Peer مشابهی آن رفتار را نداشته باشد، Context به نفع جدی‌تر گرفتن رخداد عمل می‌کند.

هدف این نیست که Peer Grouping هر رفتار مشابهی را Safe اعلام کند. Peer Context فقط یکی از ورودی‌های Risk Assessment است و باید در کنار نوع Event، Asset Criticality، Privilege، Threat Intelligence و سایر سیگنال‌ها دیده شود.

چه نوع Anomalyهایی از Peer Context بهره می‌برند؟

مستندات Log360 UEBA Anomalyها را در دسته‌هایی مانند Time، Count، Pattern و Seasonality بررسی می‌کنند. برای Anomalyهای زمانی، تعدادی و الگویی، اطلاعات Peer Behavior می‌تواند به تحلیل کمک کند.

سناریو اول: تیم Finance در پایان ماه

فرض کنید اکثر اعضای Finance معمولاً ساعت ۸ تا ۱۷ کار می‌کنند، اما دو روز آخر ماه تا ساعت ۲۱ فعال هستند. برای یک User جدید، Login در ساعت ۲۰ ممکن است در Baseline شخصی سابقه کافی نداشته باشد و Anomaly ایجاد کند.

Static Peer Grouping می‌تواند نشان دهد اعضای همان Department در پایان ماه رفتار مشابهی دارند. Dynamic Peer Grouping نیز اگر Pattern رفتاری گروه را یاد گرفته باشد، Context مشابهی ایجاد می‌کند. در چنین شرایطی، SOC به‌جای صرف زمان روی یک Alert کم‌ارزش می‌تواند تمرکز خود را روی کاربری بگذارد که هم از Baseline خودش و هم از رفتار گروه فاصله گرفته است.

سناریو دوم: فعالیت DBA در ساعت ۳ بامداد

برای یک DBA، Maintenance شبانه می‌تواند طبیعی باشد؛ برای یک کاربر Marketing نه. اگر Rule صرفاً «Login در ساعت ۳ بامداد» باشد، هر دو ممکن است هشدار مشابهی ایجاد کنند.

Peer Grouping این تفاوت را بهتر نمایان می‌کند. در Static Model، Title یا Department Context رسمی می‌دهد. در Dynamic Model، Patternهای واقعی دسترسی به Database و ساعات Maintenance مبنا قرار می‌گیرند. اگر کاربر Marketing رفتاری مشابه DBAها نشان دهد، این تغییر از نظر امنیتی ارزش بررسی بسیار بیشتری دارد.

سناریو سوم: Privileged Access و PAM360

Log360 UEBA می‌تواند برای شناسایی Anomalyهای دسترسی ممتاز با PAM360 نیز یکپارچه شود. این ترکیب وقتی ارزشمند می‌شود که سؤال فقط این نباشد که «چه Credentialی استفاده شد؟»، بلکه بررسی کنیم رفتار Privileged User نسبت به Baseline و Peer Group چقدر غیرعادی بوده است.

برای مثال، اگر چند Administrator در Maintenance Window مشخص به Serverهای Production متصل شوند، Context گروهی ممکن است این رفتار را طبیعی‌تر نشان دهد. اما اگر یک حساب ممتاز خارج از Window، روی Resource نامرتبط و با Pattern متفاوت فعال شود، Risk Score و Investigation باید جدی‌تر دنبال شود. برای آشنایی با راهکار مدیریت دسترسی ممتاز مدانت می‌توانید صفحه PAM360 را نیز ببینید.

چرا Dynamic Peer Grouping به داده کافی نیاز دارد؟

Dynamic Model از رفتار گذشته یاد می‌گیرد. اگر Event Data ناقص باشد، Clusterها هم تصویر ناقصی از رفتار واقعی خواهند داشت. بنابراین قبل از قضاوت درباره کیفیت Peer Grouping باید مطمئن شوید Data Sourceهای کلیدی به‌درستی وارد Log360 می‌شوند.

برای مثال، اگر فقط Domain Controller Logها جمع‌آوری شوند ولی VPN، Database، Endpoint یا Firewall Visibility ناقص باشد، بخشی از رفتار User دیده نمی‌شود. مدل رفتاری قوی به Telemetry کافی و پایدار نیاز دارد.

ManageEngine نیز در راهنمای Static/Dynamic Peer Grouping تأکید می‌کند که برای Dynamic Configuration باید UEBA با Eventهای User آموزش ببیند تا Clusterها شکل بگیرند و Anomalyها قابل ارزیابی شوند.

Cluster Death چیست و چرا مهم است؟

رفتار سازمان ثابت نمی‌ماند. افراد Role عوض می‌کنند، پروژه‌های جدید شروع می‌شوند، ساعات کاری تغییر می‌کند و Applicationهای تازه وارد چرخه می‌شوند. اگر Dynamic Peer Group برای همیشه ثابت بماند، Baseline به‌مرور قدیمی خواهد شد.

در توضیحات فنی ManageEngine درباره Peer Group Analysis، مفهوم Cluster Death برای حذف Clusterهای قدیمی و جایگزینی آن‌ها با Clusterهای جدید مطرح شده است. اگر مدت طولانی Event جدیدی وارد یک Cluster نشود، آن Cluster دیگر نماینده رفتار فعلی نیست و مدل باید خود را تطبیق دهد.

این موضوع برای SOC مهم است چون کاهش False Positive فقط با ساخت یک Baseline اولیه اتفاق نمی‌افتد؛ Baseline باید با تغییر محیط زنده بماند.

Static Peer Grouping بدون Data Hygiene می‌تواند گمراه‌کننده باشد

اگر Department، Title یا Manager در Active Directory قدیمی باشد، Static Peer Grouping نیز User را در گروه اشتباه قرار می‌دهد. مثلاً کاربری که شش ماه قبل از Finance به IT منتقل شده اما هنوز Department قبلی را دارد، ممکن است با Peerهای اشتباه مقایسه شود.

قبل از Rollout Static Peer Grouping بهتر است این موارد بررسی شوند:

• Departmentهای تکراری یا با املای متفاوت پاک‌سازی شوند.
• Job Titleها استاندارد شوند.
• Manager و Reporting Line کاربران به‌روز باشد.
• حساب‌های غیرفعال یا پیمانکاران منقضی‌شده مشخص شوند.
• Attributeهای یکتا مثل Employee ID برای ساخت Peer Group عمومی استفاده نشوند.

Static Peer Grouping زمانی قدرتمند است که Directory واقعاً ساختار سازمان را منعکس کند.

چطور Peer Grouping را در Log360 UEBA راه‌اندازی کنیم؟

در مستندات فعلی Log360 UEBA، تنظیمات Peer Group در بخش Settings/Configuration قرار دارد و Static و Dynamic Configuration بخش مشخص خود را دارند. مسیر دقیق UI ممکن است بین Buildها تغییر کند، بنابراین قبل از اجرا Build فعلی محصول را با مستندات همان نسخه تطبیق دهید.

گام ۱: Domain و Data Sourceها را بررسی کنید

برای Static Peer Grouping حداقل یک Domain پیکربندی‌شده لازم است. برای Dynamic Peer Grouping نیز Event Data کافی باید در اختیار UEBA قرار گیرد.

گام ۲: Static Attributeهای مناسب را انتخاب کنید

Department، Title، Manager یا Attributeهای گروهی مشابه را انتخاب کنید. از Attributeهای یکتا که برای هر User مقدار متفاوت دارند استفاده نکنید.

گام ۳: Dynamic Peer Grouping را روی Scope کنترل‌شده فعال کنید

به مدل زمان بدهید تا Eventهای کافی ببیند. از تغییر هم‌زمان چندین Policy، Data Source و Risk Weight خودداری کنید؛ در غیر این صورت تشخیص علت تغییر در Alert Quality دشوار می‌شود.

گام ۴: Peer Group Detail را در Anomaly Reports بررسی کنید

Log360 اجازه می‌دهد در Anomaly Reports جزئیات Static یا Dynamic Peer Group و اعضای Cluster مشاهده شوند. این مرحله برای Validate کردن مدل ضروری است؛ صرف اینکه Cluster ساخته شده به این معنی نیست که Context آن برای تیم امنیت منطقی است.

گام ۵: Risk Weight و Decay را Tune کنید

Risk Scoring را با اولویت‌های واقعی سازمان هماهنگ کنید. Privilege Escalation، Sensitive Data Access یا رفتارهای مرتبط با Assetهای حیاتی می‌توانند وزن بیشتری نسبت به فعالیت‌های کم‌ریسک داشته باشند.

چه KPIهایی نشان می‌دهند Peer Grouping واقعاً مفید بوده است؟

موفقیت این پروژه فقط با کم‌شدن تعداد Alert سنجیده نمی‌شود. اگر Alertها کمتر شوند اما Detection مهمی از دست برود، کاهش Noise ارزشی ندارد.

اشتباه اول: هدف را «کم‌کردن Alert» تعریف نکنید

اگر تنها KPI پروژه کاهش تعداد Alert باشد، ساده‌ترین راه افزایش Thresholdها و کاهش حساسیت است؛ اما این کار می‌تواند Detection را ضعیف کند. هدف بهتر، افزایش Signal-to-Noise Ratio است.

Peer Grouping باید باعث شود رفتارهای عادی گروهی کمتر مزاحم SOC شوند و رفتارهای واقعاً متفاوت Context بیشتری پیدا کنند. این تفاوت با خاموش‌کردن Alert کاملاً فرق دارد.

اشتباه دوم: Dynamic را جایگزین Static ندانید

Dynamic Peer Grouping رفتار واقعی را بهتر می‌بیند، اما همیشه ساختار رسمی سازمان را نمی‌شناسد. Static Peer Grouping Context Role و Department را وارد تحلیل می‌کند، اما ممکن است تفاوت‌های رفتاری واقعی را از دست بدهد.

در یک محیط بالغ می‌توان هر دو نگاه را کنار هم داشت: «این User طبق ساختار سازمان با چه کسانی هم‌رده است؟» و «طبق رفتار واقعی شبیه چه کسانی عمل می‌کند؟» اختلاف بین این دو نگاه خودش می‌تواند برای Investigation ارزشمند باشد.

اشتباه سوم: Risk Score را بدون Runbook رها نکنید

Risk Score فقط وقتی عملیاتی است که تیم بداند با هر سطح چه کاری انجام دهد. برای مثال:

• Risk پایین: ثبت و Trend Monitoring
• Risk متوسط: بررسی Context و Asset
• Risk بالا: Investigation توسط SOC
• Risk بسیار بالا همراه با Privilege یا Data Access حساس: Escalation و Containment طبق Playbook

اگر همه Risk Scoreها نهایتاً به یک صف بدون اولویت بروند، Peer Grouping هم اثر محدودی روی عملیات واقعی خواهد داشت.

Peer Grouping و MITRE ATT&CK چگونه مکمل هم هستند؟

Peer Grouping می‌گوید رفتار یک User یا Entity نسبت به Baseline و همتایانش چقدر غیرعادی است. MITRE ATT&CK کمک می‌کند Analyst بفهمد رفتار مشاهده‌شده ممکن است با کدام Technique یا مرحله حمله مرتبط باشد.

ترکیب این دو Context بسیار مفید است: یک Login غیرعادی به‌تنهایی ممکن است ارزش متوسطی داشته باشد، اما اگر همراه با Privilege Escalation، Lateral Movement یا رفتارهای مرتبط دیگر دیده شود، Investigation اولویت بیشتری پیدا می‌کند. در مقاله MITRE ATT&CK در Log360؛ از هشدار امنیتی تا تشخیص تکنیک مهاجم این بخش از تحلیل تهدید را جداگانه بررسی کرده‌ایم.

Peer Grouping برای چه سازمان‌هایی بیشترین ارزش را دارد؟

تقریباً هر محیطی که تعداد کاربران، نقش‌ها و Patternهای کاری آن زیاد باشد می‌تواند از این قابلیت بهره ببرد، اما ارزش آن در این سناریوها بیشتر است:

• سازمان‌های بزرگ با چند Department و چند شعبه
• محیط‌هایی با Shift Work یا Maintenance Windowهای متعدد
• SOCهایی که با حجم بالای UEBA Alert مواجه‌اند
• سازمان‌هایی با Privileged User و PAM
• محیط‌های Hybrid که رفتار User بین AD، Cloud، VPN و Applicationها توزیع شده است
• سازمان‌هایی که می‌خواهند Insider Threat Detection را از Rule ثابت فراتر ببرند

یک Rollout پیشنهادی برای سازمان واقعی

برای شروع لازم نیست Peer Grouping را روی کل سازمان یک‌باره فعال و Tune کنید. یک مسیر کم‌ریسک‌تر می‌تواند این باشد:

1. Scope محدود: یک Domain یا Business Unit با ساختار مشخص انتخاب کنید.
2. Data Quality: Attributeهای LDAP و Data Sourceهای رفتاری را Validate کنید.
3. Baseline: به Dynamic Model زمان کافی برای Training بدهید.
4. Parallel Review: چند هفته Alertهای قبل و بعد را مقایسه کنید.
5. Peer Validation: Clusterهای ساخته‌شده را با تیم‌های Business و Security بررسی کنید.
6. Risk Tuning: Weight، Decay و Thresholdها را براساس Incident واقعی تنظیم کنید.
7. Expansion: بعد از اثبات کیفیت، Scope را مرحله‌ای افزایش دهید.

این روش باعث می‌شود اگر Grouping یا Risk Scoring نیاز به اصلاح داشت، مشکل در Scope کوچک تشخیص داده شود نه در کل SOC.

نکات کلیدی

• Dynamic Peer Grouping کاربران و Entityها را براساس رفتار واقعی در Clusterهای پویا قرار می‌دهد.
• Static Peer Grouping از Attributeهای LDAP مانند Department، Title و Role استفاده می‌کند.
• وجود Peer با رفتار مشابه می‌تواند Confidence بعضی Anomalyها و در نتیجه Risk Score را کاهش دهد.
• Dynamic Model به Event Data و Training کافی نیاز دارد.
• Static Model به Data Hygiene در Active Directory وابسته است.
• هدف Peer Grouping خاموش‌کردن Alert نیست؛ هدف دقیق‌تر کردن Context و اولویت‌بندی است.
• Risk Scoring باید با Runbook، Asset Criticality و فرآیند Investigation SOC هماهنگ شود.

سخن پایانی

اگر UEBA فقط هر User را با گذشته خودش مقایسه کند، بخشی از Context سازمانی از دست می‌رود. یک رفتار می‌تواند برای یک فرد جدید باشد اما برای همکاران او کاملاً عادی باشد؛ یا برعکس، رفتاری که در ظاهر ساده است ممکن است در مقایسه با Peerهای واقعی همان User بسیار غیرمعمول باشد.

Peer Grouping در Log360 UEBA این فاصله را پر می‌کند. Dynamic Peer Grouping از داده رفتاری برای ساخت Clusterهای زنده استفاده می‌کند و Static Peer Grouping ساختار رسمی سازمان را وارد تحلیل می‌کند. در کنار Risk Scoring، Seasonality، Identity Mapping و سایر قابلیت‌های UEBA، این دو مدل می‌توانند به SOC کمک کنند False Positive را کاهش دهد بدون اینکه هدف اصلی یعنی تشخیص تهدیدهای واقعی فراموش شود.

اگر می‌خواهید Log360، UEBA و معماری SIEM سازمانتان را بر اساس Data Sourceها، تعداد کاربر، Retention، Compliance و سناریوهای SOC ارزیابی کنید، صفحه Log360 مدانت نقطه شروع محصول است. برای برآورد لایسنس می‌توانید از استعلام قیمت محصولات ManageEngine استفاده کنید و برای طراحی، دمو، پیاده‌سازی یا پشتیبانی نیز درخواست جلسه و پروپوزال مدانت را ثبت کنید.

منابع

• ManageEngine Log360 — Dynamic Peer Grouping
• ManageEngine Log360 UEBA — Static and Dynamic Peer Grouping
• ManageEngine Log360 UEBA — Risk Scoring
• ManageEngine Log360 — Anomaly Detection and Contextual Risk Scoring
• ManageEngine Log360 UEBA — Anomaly Reports and Peer Group Details