فرض کنید کاربری که معمولاً بین ساعت ۸ تا ۱۷ فعالیت دارد، نیمه‌شب به یک سرور حساس وارد می‌شود، چند فایل غیرمعمول را می‌خواند، حجم زیادی از داده را جابه‌جا می‌کند و سپس از یک USB استفاده می‌کند. ممکن است هیچ‌کدام از این رویدادها به‌تنهایی «هشدار قطعی» نباشند؛ اما کنار هم، یک الگوی رفتاری غیرعادی می‌سازند که برای تیم SOC اهمیت بالایی دارد.

این دقیقاً همان نقطه‌ای است که User and Entity Behavior Analytics یا UEBA وارد می‌شود. در ManageEngine Log360، UEBA با ساخت Baseline رفتاری، تحلیل Anomaly، Risk Score و Peer Grouping به تیم امنیت کمک می‌کند فعالیت‌هایی را ببیند که در Logهای خام ممکن است کاملاً عادی به نظر برسند.

در این مقاله تمرکز ما روی یک Use Case مشخص است: تشخیص Insider Threat با Log360 UEBA؛ از اولین رفتار غیرعادی تا ساخت یک Incident قابل اقدام برای SOC، بدون اینکه هر انحراف رفتاری را به‌اشتباه حمله تلقی کنیم.

Insider Threat فقط «کارمند مخرب» نیست

تهدید داخلی یا Insider Threat می‌تواند چند شکل داشته باشد:

• کاربری که آگاهانه اطلاعات حساس را خارج می‌کند؛
• کاربری که دسترسی بیش از نیاز دارد و از آن سوءاستفاده می‌کند؛
• حساب کاربری معتبری که Credential آن سرقت شده است؛
• کاربری که بدون قصد مخرب، رفتار پرریسک و خلاف الگوی عادی انجام می‌دهد؛
• حساب Service یا Admin که فعالیت آن از Baseline تاریخی خود فاصله می‌گیرد.

بنابراین UEBA قرار نیست نیت انسان را تشخیص دهد. وظیفه آن این است که انحراف قابل‌توجه از رفتار معمول را به داده قابل بررسی برای SOC تبدیل کند.

Log360 UEBA چگونه رفتار غیرعادی را می‌بیند؟

طبق مستندات رسمی ManageEngine، UEBA در Log360 فعالیت کاربران و Entityها را تحلیل می‌کند، Baseline رفتاری می‌سازد و انحراف‌ها را شناسایی می‌کند. در معماری Log360 Cloud، مدل‌ها برای تشخیص انواع مختلف Anomaly آموزش می‌بینند و خروجی آن‌ها در قالب Risk Score و Alert قابل استفاده می‌شود.

سه دسته Anomaly مهم در مستندات Log360 عبارت‌اند از:

مزیت این رویکرد این است که تحلیل فقط بر «وجود یک Event» تکیه نمی‌کند؛ بلکه زمان، تکرار، توالی و Context را هم وارد تصمیم می‌کند.

سناریوی واقعی‌تر: از Login غیرعادی تا Data Exfiltration

ManageEngine در Use Case رسمی UEBA خود سناریویی را توضیح می‌دهد که در آن یک کاربر در ساعتی غیرمعمول وارد سیستم می‌شود، تعداد زیادی سند را می‌خواند یا تغییر می‌دهد و سپس داده را به رسانه قابل‌حمل منتقل می‌کند. نکته مهم این سناریو این است که هر مرحله Risk را افزایش می‌دهد.

در یک طراحی SOC بالغ، بهتر است همین منطق مرحله‌ای را حفظ کنیم:

1. Login غیرعادی فقط یک سیگنال اولیه است.
2. دسترسی به منابع حساس Context را تقویت می‌کند.
3. افزایش شدید تعداد File Access یا Modification اهمیت رویداد را بالا می‌برد.
4. استفاده از USB یا انتقال غیرمتعارف داده می‌تواند Risk Category را به Data Exfiltration نزدیک کند.
5. Incident Workbench باید برای بررسی User، Device، Process و Timeline استفاده شود.

این نگاه باعث می‌شود تیم SOC به جای واکنش به یک Alert منفرد، روی زنجیره رفتار تمرکز کند.

Risk Score چه کمکی می‌کند؟

در UEBA، Risk Score یکی از مهم‌ترین ابزارهای Prioritization است. Log360 می‌تواند بر اساس رفتار مشاهده‌شده و مقایسه با Baseline یا Peer Group، امتیاز ریسک را تغییر دهد. در مستندات رسمی، قابلیت تنظیم وزن عوامل نیز برای Risk Scoring مطرح شده است.

اما یک اصل مهم وجود دارد: Risk Score حکم نهایی نیست. Risk Score باید برای مرتب‌سازی و اولویت‌بندی Investigation استفاده شود، نه برای تصمیم خودکار درباره مجرم‌بودن یک کاربر.

برای مثال، افزایش Risk Score می‌تواند دلایل مشروعی داشته باشد:

• شیفت اضطراری؛
• پروژه موقت؛
• مهاجرت داده؛
• وظیفه جدید سازمانی؛
• استفاده از سیستم جایگزین؛
• تغییر Location یا الگوی Remote Work.

به همین دلیل Incident باید با Context سازمانی تکمیل شود.

Peer Grouping چگونه False Positive را کم می‌کند؟

یکی از قابلیت‌های مهم Log360 UEBA، مقایسه رفتار کاربر با Peer Group است. اگر رفتار یک کاربر نسبت به همتایان سازمانی خود هم غیرعادی باشد، سیگنال قوی‌تر می‌شود.

برای مثال، Login ساعت ۲۳ برای تیم NOC ممکن است کاملاً عادی باشد، اما برای کاربری از واحد مالی که همیشه ساعات اداری فعالیت می‌کند، متفاوت است. اینجاست که Peer Grouping به کاهش False Positive کمک می‌کند.

در مدانت، مقاله Peer Grouping در Log360 UEBA این موضوع را با تمرکز روی گروه‌بندی پویا و ایستا بررسی کرده است.

Incident Workbench؛ جایی که Alert باید تبدیل به Investigation شود

طبق مستندات ManageEngine، Incident Workbench در Log360 و EventLog Analyzer امکان تحلیل User، Process و Threat Source را در یک کنسول واحد فراهم می‌کند. برای کاربر، اطلاعاتی مانند Risk Score Trend، Peak Risk Score و User Activity Overview قابل بررسی است.

برای Insider Threat، Investigation خوب باید حداقل این سؤالات را پاسخ دهد:

کدام Data Sourceها برای این Use Case مهم‌تر هستند؟

Log360 UEBA می‌تواند داده را از منابع مختلف تحلیل کند. مستندات رسمی Log360 Cloud، منابعی مانند Windows و Unix، Cloud Platforms، Firewallها، Applicationها و برخی Security Solutionها را در فهرست Data Sourceهای UEBA آورده‌اند.

برای Insider Threat، معمولاً این منابع ارزش بیشتری دارند:

• Active Directory و Windows Logon؛
• File Server Audit؛
• VPN و Remote Access؛
• Firewall و Proxy؛
• Cloud Services مانند Microsoft 365 یا AWS؛
• Database Audit؛
• Endpoint و Device Activity؛
• Privileged Account Activity.

هرچه Context بین این منابع بهتر Correlate شود، تشخیص الگوی رفتاری معتبرتر می‌شود.

تفاوت Insider Threat با Account Compromise چیست؟

از دید UEBA، رفتار غیرعادی ممکن است هم ناشی از کاربر داخلی باشد و هم از سرقت Credential. برای مثال، Login ساعت ۲ بامداد از IP غیرمعمول می‌تواند نشانه Compromised Account باشد، نه کارمند مخرب.

به همین دلیل تحلیل باید چند لایه باشد:

1. Identity Context؛
2. Device Context؛
3. Network Context؛
4. Privilege Context؛
5. Data Access Context؛
6. Behavior Baseline.

اگر فقط User Name را ببینیم، ممکن است Attribution اشتباه باشد.

چطور Insider Threat را به Incident قابل اقدام تبدیل کنیم؟

یک Alert زمانی برای SOC ارزش دارد که Action مشخصی داشته باشد. Runbook پیشنهادی می‌تواند چنین باشد:

1. Risk Score و Anomaly Type را بررسی کنید.
2. Timeline فعالیت کاربر را باز کنید.
3. Login Source و Device را اعتبارسنجی کنید.
4. دسترسی به فایل، دیتابیس یا Cloud Resource را بررسی کنید.
5. Privilege Escalation یا Policy Change را کنترل کنید.
6. Peer Behavior را مقایسه کنید.
7. در صورت نیاز User را با HR/Manager Context تطبیق دهید.
8. اگر شواهد کافی وجود دارد، Session یا Account را محدود کنید.
9. Incident را مستند و Evidence را حفظ کنید.
10. پس از Resolution، Rule، Baseline یا Access Policy را اصلاح کنید.

این چرخه باید با Incident Management سازمان هماهنگ باشد. برای تیم‌هایی که ServiceDesk Plus دارند، می‌توان Incidentهای امنیتی را با فرآیند ثبت، Assignment، SLA و Escalation مدیریت کرد. راهنمای Incident Management در سایت تخصصی ServiceDesk مدانت برای طراحی این جریان مفید است.

چه چیزی را خودکار کنیم و چه چیزی را نه؟

در Insider Threat، Automation باید با احتیاط استفاده شود. بعضی اقدامات کم‌ریسک و قابل‌برگشت هستند:

• ساخت Ticket؛
• افزودن Context به Incident؛
• Notification به SOC؛
• Enrichment با اطلاعات User و Device؛
• Tag کردن Incident بر اساس Risk Category.

اما اقداماتی مثل Disable Account، قطع Session یا Block گسترده بهتر است بر اساس سطح Risk، نوع دارایی و Policy سازمان کنترل شوند. در محیط‌های حساس، Human Approval هنوز نقش مهمی دارد.

چگونه از تبدیل UEBA به «کارخانه Alert» جلوگیری کنیم؟

UEBA اگر بدون Governance استفاده شود می‌تواند نویز زیادی ایجاد کند. برای کنترل آن:

• Baseline را برای گروه‌های مختلف جداگانه بسازید؛
• Peer Groupها را بازبینی کنید؛
• Risk Weight را بر اساس Criticality تنظیم کنید؛
• Service Accountها را از Userهای عادی جدا کنید؛
• Known Administrative Activity را مستند کنید؛
• False Positiveهای تکراری را به Rule Improvement تبدیل کنید؛
• Risk Score را با Asset Criticality ترکیب کنید؛
• Detection را با Incident Outcome ارزیابی کنید، نه فقط تعداد Alert.

چه KPIهایی برای UEBA و Insider Threat مناسب هستند؟

ارتباط این موضوع با لایسنس و معماری Log360

UEBA فقط یک Feature جدا نیست؛ باید در معماری کلی SIEM، Log Sourceها، Data Volume، Cloud/On-Premises و Use Caseهای SOC دیده شود. اگر Data Sourceهای لازم وارد Log360 نشوند، حتی بهترین مدل رفتاری هم Context ناقصی خواهد داشت.

برای طراحی تجاری و فنی، صفحه Log360 در مدانت نقطه اصلی معرفی محصول است. همچنین مقاله محاسبه لایسنس Log360 توضیح می‌دهد چگونه Log Source، DC، Endpoint و Cloud Account در Sizing لایسنس اثر می‌گذارند.

نکات کلیدی

• UEBA نیت کاربر را تشخیص نمی‌دهد؛ انحراف رفتاری را شناسایی می‌کند.
• Time، Count و Pattern Anomaly در کنار هم تصویر دقیق‌تری از Insider Threat می‌سازند.
• Risk Score برای Prioritization است، نه حکم قطعی.
• Peer Grouping می‌تواند False Positive را کاهش دهد.
• Incident Workbench برای بررسی User، Process و Timeline اهمیت بالایی دارد.
• Insider Threat و Compromised Account ممکن است علائم مشابه داشته باشند.
• Data Source و Context مناسب شرط اصلی Detection معتبر است.
• Automation باید در اقدامات پرریسک با کنترل و Approval همراه باشد.

منابع

• ManageEngine Log360 — Features
• ManageEngine Log360 — UEBA for Threat Detection
• Log360 Cloud UEBA Architecture
• Log360 Cloud — Anomaly Model Training
• Log360 Incident Workbench — User Analytics
• ManageEngine Log360 — Anomaly Detection Use Cases

سخن پایانی

Insider Threat معمولاً با یک Event مشخص شروع و تمام نمی‌شود. ارزش UEBA در این است که رفتارهای کوچک و پراکنده را در کنار Baseline، Peer Group و Risk Score قرار می‌دهد تا تیم SOC بتواند زنجیره رفتار را ببیند. Log360 زمانی بیشترین ارزش را ایجاد می‌کند که UEBA به Log Sourceهای مناسب، Incident Workflow، Asset Criticality و Runbook پاسخ متصل باشد.

مدانت خدمات خرید و تمدید لایسنس Log360، طراحی معماری SIEM، استقرار، تنظیم Use Case، یکپارچه‌سازی با ServiceDesk Plus و پشتیبانی ManageEngine را ارائه می‌دهد. برای بررسی نیاز سازمان، Sizing یا طراحی سناریوی UEBA و SOC می‌توانید از طریق مشاوره مدانت اقدام کنید.