فرض کنید یکی از کاربران واحد مالی میخواهد ایمیلی برای یک گیرنده بیرون از سازمان بفرستد. در متن ایمیل چند شماره کارت یا دادهای با الگوی حساس وجود دارد و فایل پیوست هم با برچسب «Confidential» طبقهبندی شده است. سیاست DLP سازمان ارسال را Block میکند؛ اما این فقط نصف ماجراست.
سؤال بعدی مهمتر است: چه کسی این رخداد را بررسی میکند؟ آیا تلاش کاربر اشتباه بوده یا عمدی؟ آیا Policy بیش از حد سختگیرانه تنظیم شده؟ آیا مورد مشابهی قبلاً برای همین کاربر یا Device رخ داده؟ چه تصمیمی گرفته شد و چه کسی آن را بست؟
در DataSecurity Plus Build 6310 که در اوت ۲۰۲۶ منتشر شده، ManageEngine یک Incident Management Console جدید معرفی کرده تا نقضهای DLP از مرحله تشخیص و اعمال Policy تا بررسی، تخصیص، مستندسازی و Resolution در یک جریان واحد مدیریت شوند. این تغییر مهم است چون DLP را از «ابزار Block کردن» به «فرآیند قابلپیگیری مدیریت رخداد داده» نزدیکتر میکند.
اگر در حال ارزیابی این محصول هستید، صفحه DataSecurity Plus مدانت معرفی کلی راهکار و ماژولهای آن را ارائه میدهد. این نوشتار روی یک قابلیت مشخص و جدید تمرکز دارد تا با صفحه محصول رقابت نکند.
چرا Block کردن بهتنهایی کافی نیست؟
یک DLP Policy ممکن است جلوی خروج داده را بگیرد، اما سازمان هنوز باید بفهمد چه اتفاقی افتاده است. اگر همه نقضها فقط در Report باقی بمانند، چند مشکل ایجاد میشود:
- رخدادهای مهم بین Eventهای متعدد گم میشوند.
- مالک مشخصی برای Investigation وجود ندارد.
- کارشناس بعدی نمیداند چه اقداماتی قبلاً انجام شده است.
- False Positiveها به Policy برنمیگردند و Ruleها اصلاح نمیشوند.
- برای Audit مشخص نیست چه کسی چه تصمیمی گرفته است.
- تیم Security نمیتواند Backlog رخدادهای باز را مدیریت کند.
مدیریت رخداد یعنی Detection به یک Workflow برسد. این Workflow باید حداقل مالک، وضعیت، شدت، Context، Timeline و نتیجه داشته باشد. Incident Management Console جدید DataSecurity Plus دقیقاً همین لایه را روی Policy Violationهای DLP اضافه میکند.
Incident Management Console در Build 6310 چه چیزی اضافه کرده است؟
طبق Release Notes رسمی ManageEngine، Build 6310 قابلیت Incident Management را برای رهگیری سرتاسری نقضهای DLP معرفی کرده است. Administrator میتواند رخدادها را مشاهده کند، آنها را برای Remediation به افراد مشخص Assign کند، روند Resolution را مدیریت کند و Activity Record جزئی داشته باشد.
مستند رسمی Incident Management نیز Workflow را بهصورت مشخص تعریف میکند:
- یک Event با شروط DLP Policy تطبیق پیدا میکند.
- Action تعریفشده در Policy اجرا میشود: Allow، Warn یا Block.
- Event بهصورت خودکار به یک Security Incident تبدیل میشود.
- Administrator رخداد را Review میکند.
- Incident به Technician مناسب Assign میشود.
- Technician با استفاده از Event Context، Audit Log و User Activity علت و Intent را بررسی میکند.
- پس از اقدام لازم، Incident به وضعیت Resolved میرسد.
این یعنی Policy Violation دیگر فقط یک سطر در Log نیست؛ Lifecycle دارد.
محدودیت مهم: Incident Console فعلاً از کدام Source تغذیه میشود؟
در زمان نگارش این مطلب، مستندات رسمی ManageEngine یک محدودیت مهم را صریح بیان میکنند: Incident Management Console فعلاً Incidentها را از DLP Policy Management دریافت میکند و پشتیبانی از Sourceهای دیگر برای نسخههای بعدی برنامهریزی شده است.
از طرف دیگر، مسیر جدید Policy Management در Build 6310 فعلاً روی Email DLP برای Outlook متمرکز است. DataSecurity Plus در کل محصول قابلیتهای گستردهتری برای Endpoint DLP، USB، Clipboard، Printer، Cloud و File Activity دارد، اما نباید تصور کنیم همه این Eventها همین امروز الزاماً وارد Incident Console جدید میشوند.
این تفکیک برای طراحی معماری مهم است. هنگام POC یا خرید باید دقیقاً مشخص کنید کدام Use Caseها وارد Workflow جدید Incident Management میشوند و کدامها هنوز از Report، Alert یا ماژولهای قبلی مدیریت خواهند شد.
یک سناریوی واقعی: ارسال اطلاعات حساس با Outlook
فرض کنیم Policy زیر در DataSecurity Plus تعریف شده است:
- Scope: Device Group واحد مالی
- Channel: Outlook Email
- Detection: شماره کارت بانکی + فایل دارای Classification = Confidential
- Destination: گیرنده خارج از دامنه سازمان
- Severity: High
- Response: Block
کاربر سعی میکند ایمیل را ارسال کند. DataSecurity Plus Policy را Match میکند و ارسال را Block میکند. سپس یک Incident ایجاد میشود.
Administrator در Security Incidents اطلاعات User، Device، زمان رخداد، Channel، Severity، Threat Type، Status و Assignee را میبیند. بعد Incident را برای کارشناس امنیت داده Assign میکند.
کارشناس وارد Event Details میشود و میتواند Context مربوط به ایمیل را بررسی کند؛ از جمله Policy Trigger شده، User، اطلاعات Exit Point و در سناریوی ایمیل جزئیاتی مانند Subject، Sender، تعداد Attachment و اطلاعات مرتبط با رخداد. در تب Data Identifiers Matched نیز مشخص میشود چه Identifierهایی و با چه تعداد Match باعث Trigger شدهاند.
حالا تصمیم از حالت حدس خارج میشود.
چه اطلاعاتی برای Triage در اختیار کارشناس است؟
Incident Console چند گروه Context مفید ارائه میدهد:
| اطلاعات | کاربرد در Investigation |
|---|---|
| User | مشخص میکند چه حسابی Event را ایجاد کرده است |
| Device | مبدأ رخداد و Endpoint مرتبط را نشان میدهد |
| Communication Channel | مشخص میکند داده از چه Exit Pointی در حال خروج بوده است |
| Event Time | برای Correlation با رخدادهای دیگر و Audit اهمیت دارد |
| Severity | برای اولویتبندی Backlog استفاده میشود |
| Triggered Policy | مشخص میکند کدام Rule باعث Incident شده است |
| Matched Data Identifiers | نشان میدهد چه نوع داده حساسی Match شده است |
| Assignee | مالک Investigation را مشخص میکند |
| Timeline | Audit Trail کامل تغییرات و اقدامات را نگه میدارد |
داشتن این Context کمک میکند Analyst فقط نپرسد «چه چیزی Block شد؟» بلکه بپرسد «چرا Block شد و تصمیم بعدی چیست؟»
چه Statusهایی برای Incident وجود دارد؟
در مستند فعلی چهار وضعیت اصلی دیده میشود:
- Open: Incident ایجاد شده و هنوز رسیدگی کامل شروع نشده است.
- In Progress: Investigation در حال انجام است.
- Dismissed: رخداد پس از بررسی بینیاز از اقدام یا نامعتبر تشخیص داده شده است.
- Resolved: بررسی و اقدامات لازم تمام شدهاند.
این Statusها سادهاند، اما همین سادگی باعث میشود بتوان یک صف عملیاتی واقعی ساخت. مهم این است که تیم Security برای هر وضعیت Definition of Done مشخص داشته باشد. مثلاً Incident نباید فقط چون «کاربر گفت اشتباه کردم» Resolved شود؛ باید Evidence و Comment کافی ثبت شود.
Severity را فقط از Policy کپی نکنید
Incident Details اجازه میدهد Severity در طول Investigation اصلاح شود. این قابلیت مهم است، چون شدت اولیه Policy همیشه برابر Business Impact واقعی نیست.
مثلاً Policy ممکن است هر ارسال شماره کارت را High در نظر بگیرد، اما در Investigation مشخص شود داده Test بوده و گیرنده Vendor مورداعتماد است. برعکس، Eventی که ابتدا Medium بوده ممکن است در بررسی مشخص کند کاربر چند بار متوالی سعی کرده محدودیت را دور بزند.
یک ماتریس ساده میتواند Severity را استاندارد کند:
| معیار | Low | Medium | High/Critical |
|---|---|---|---|
| حساسیت داده | Internal | Confidential | Restricted / PII / PCI |
| حجم داده | کم | متوسط | انبوه |
| گیرنده | داخلی مجاز | Third Party شناختهشده | External ناشناخته |
| تکرار | اولین بار | تکرارشونده | الگوی مستمر یا دور زدن کنترل |
| Intent | خطای روشن | نامشخص | مشکوک یا عمدی |
این مدل نمونه است و باید با Data Classification و Risk Appetite واقعی سازمان تنظیم شود.
Timeline چرا برای Audit ارزش دارد؟
یکی از مفیدترین بخشهای Incident Console، Timeline است. Timeline نشان میدهد Incident چه زمانی ایجاد شده، چه کسی آن را Assign کرده، Status یا Severity چه زمانی تغییر کرده و چه Commentهایی ثبت شدهاند.
برای تیم Audit این تفاوت مهم است. Report ساده فقط میگوید یک Policy Violated شده؛ Timeline میتواند نشان دهد سازمان چگونه به آن پاسخ داده است.
در ممیزیهای امنیتی معمولاً سؤال فقط این نیست که «کنترل دارید؟» بلکه این است که «وقتی کنترل Trigger شد چه کردید؟» Incident Timeline برای پاسخ به همین سؤال مفید است.
False Positive را باید به Policy برگرداند
مدیریت خوب Incident فقط Closing نیست؛ Feedback Loop است.
اگر Analyst بعد از بررسی تشخیص دهد رخداد Legitimate بوده، دو انتخاب دارد: فقط Incident را Dismiss کند، یا علت False Positive را در Policy اصلاح کند.
ManageEngine در سناریوی رسمی خودش نیز پیشنهاد میکند اگر رفتار مشروع بوده، Policy با Exclusion یا Condition دقیقتر Fine-tune شود. این نکته بسیار مهم است، چون بدون این Loop، DLP به مرور اعتماد کاربران و Analysts را از دست میدهد.
برای کاهش False Positive میتوان موارد زیر را بررسی کرد:
- Device Group بیش از حد گسترده تعریف نشده باشد.
- Data Identifierها Regex یا Keyword بسیار عمومی نداشته باشند.
- Classification Label بهدرستی استفاده شود.
- Sender/Recipient Exceptionها فقط در حد نیاز تعریف شوند.
- Attachment Type و Size در Rule لحاظ شوند.
- Policy Priority با سایر Policyها تضاد نداشته باشد.
- Warn قبل از Block در فاز Pilot استفاده شود.
Policy Priority در Build 6310 چه اثری روی Incident دارد؟
در Policy Management جدید، چند Policy میتوانند روی یک Event Match شوند. هر Match میتواند Incident جداگانه ایجاد کند. اگر Responseها متفاوت باشند، محصول محدودکنندهترین پاسخ را اعمال میکند؛ مثلاً بین Warn و Block، پاسخ Block اجرا میشود.
این رفتار منطقی است، اما از دید Incident Volume باید مراقب بود. اگر Policyها Overlap زیادی داشته باشند، یک فعالیت کاربر میتواند چند Incident تولید کند و Backlog را بیدلیل بالا ببرد.
پس هنگام طراحی Policy Architecture بهتر است Scope و Responsibility هر Policy روشن باشد.
Device Groups چه نقشی در طراحی DLP دارند؟
Build 6310 مفهوم Configured Groups را به Device Groups تبدیل و آن را به Configuration مرکزی منتقل کرده است. هدف این است که Groupهای Endpoint در Policyها، Monitoring Profileها و تنظیمات دیگر بهصورت سازگار استفاده شوند.
این تغییر برای Enterprise مهم است، چون DLP Policy بدون Scope خوب خیلی زود یا بیش از حد محدود یا بیش از حد گسترده میشود.
نمونه Device Groupهای منطقی:
- Finance-EndPoints
- HR-Laptops
- Developers
- Privileged-Admins
- Contractors
- Remote-Workers
یک Policy مربوط به اطلاعات حقوق و دستمزد الزاماً نباید روی تمام Endpointهای سازمان با یک شدت اعمال شود.
Data Identifier Group چیست و چرا اهمیت دارد؟
Policy باید بداند چه دادهای «حساس» است. در Build 6310، Data Identifierها و Identifier Groupها نقش پایه Detection Logic را دارند. Identifier میتواند مبتنی بر Regex، Keyword و Match Condition باشد و گروهها امکان استفاده مجدد از مجموعه Identifierها را در Policyهای مختلف میدهند.
برای مثال یک Identifier Group با نام Financial Sensitive Data میتواند شامل شماره کارت، شماره حساب، شناسه مالیاتی و Keywordهای سازمانی باشد.
مزیت Grouping این است که اگر Detection Logic تغییر کند، مجبور نیستید تکتک Policyها را جداگانه بازنویسی کنید.
Incident Management چه فرقی با SIEM Incident دارد؟
DataSecurity Plus Incident Management برای Context نزدیک به DLP Policy Violation ساخته شده است. SIEM مثل Log360 دامنه وسیعتری از Eventهای امنیتی را Correlate میکند: Authentication، Endpoint، Network، Cloud، Threat Intelligence و سایر Sourceها.
بنابراین این دو را جایگزین هم ندانید.
| DataSecurity Plus Incident | SIEM Incident |
|---|---|
| تمرکز روی DLP Policy Violation | تمرکز روی Correlation چند Source امنیتی |
| Context غنی از Data Identifier و Exit Point | Context گسترده از Eventهای امنیتی |
| Fine-tuning مستقیم Policy داده | Threat Detection و Investigation وسیعتر |
| مناسب Data Protection Team | مناسب SOC |
در معماری بالغ، یک DLP Incident مهم میتواند برای Correlation گستردهتر وارد SOC شود. برای مطالعه مدل تحلیل تکنیک مهاجم در SIEM میتوانید مقاله MITRE ATT&CK در Log360 را هم ببینید.
ارتباط DLP Incident با ITSM چیست؟
همه Security Incidentها لازم نیست داخل Service Desk مدیریت شوند، اما در سازمانی که فرآیند Incident، Change، Problem و Audit دارد، باید مرز بین Security Tool و ITSM روشن باشد.
DataSecurity Plus باید Evidence تخصصی DLP را نگه دارد. ITSM میتواند برای Coordination، Escalation، Business Communication، Change یا Taskهای بینتیمی استفاده شود.
برای مثال اگر Investigation نشان دهد Policy درست است اما Outlook Add-in روی گروهی از Endpointها مشکل دارد، اصلاح فنی ممکن است به Change نیاز داشته باشد. یا اگر رخداد Data Leakage باعث اختلال Business شده، فرآیند Incident Management سازمان وارد کار میشود.
برای مطالعه ساختار عمومی Incident Management میتوانید راهنمای Incident Management در ServiceDeskPlus.ir را ببینید.
یک Runbook پیشنهادی برای DLP Incident
برای اینکه Console به یک صفحه پر از Status تبدیل نشود، Runbook روشن لازم است.
- Validate: آیا Incident واقعی است یا Duplicate/False Positive؟
- Classify: نوع داده، حساسیت، User، Device و Exit Point مشخص شود.
- Assess: آیا داده واقعاً خارج شده یا Policy قبل از خروج آن را Block کرده است؟
- Assign: مالک Investigation تعیین شود.
- Contain: در صورت نیاز دسترسی، Device یا Channel محدود شود.
- Investigate: Event Details، Identifier Match و سابقه User بررسی شود.
- Correct: Policy، Exception، آموزش کاربر یا کنترل فنی اصلاح شود.
- Document: Comment و Evidence کافی ثبت شود.
- Resolve: فقط بعد از انجام Action لازم Incident بسته شود.
- Review: رخدادهای تکراری برای Policy Improvement تحلیل شوند.
چه KPIهایی برای Incident Management مفیدند؟
صرف تعداد Incidentها معیار خوبی نیست. افزایش Incident ممکن است نشانه Detection بهتر باشد یا نشانه Policy بد.
| KPI | هدف |
|---|---|
| Open Incident Backlog | کنترل حجم کار حلنشده |
| Mean Time to Assign | سرعت مالکدار شدن رخداد |
| Mean Time to Resolve | سرعت تکمیل Investigation |
| False Positive Rate | کیفیت Policy |
| Repeated Violations per User | کشف الگوی رفتاری یا Training Gap |
| Incidents by Policy | شناسایی Ruleهای پرنویز |
| Incidents by Device Group | کشف Scopeهای پرریسک |
| Dismissed / Resolved Ratio | بررسی ارزش واقعی Alertها |
پیش از Upgrade به Build 6310 چه چیزهایی را بررسی کنیم؟
صفحه دانلود رسمی ManageEngine در حال حاضر DataSecurity Plus 6.3 Build 6310 را ارائه میکند. قبل از Upgrade Production بهتر است:
- Backup محصول و Database مطابق راهنمای Vendor انجام شود.
- Compatibility سیستمعامل و Database بررسی شود.
- Policyهای Endpoint DLP موجود مستند شوند.
- Device Groupهای فعلی و Migration خودکار آنها بررسی شود.
- Outlook Pilot Group برای Policy Management جدید انتخاب شود.
- Role و Technicianهای مسئول Incident از قبل مشخص شوند.
- Retention و Audit نیاز سازمان تعیین شود.
- Integration احتمالی با SOC و ITSM طراحی شود.
Build 6310 علاوه بر قابلیتهای جدید DLP، بهروزرسانیهای امنیتی Platform مانند ارتقای JRE و Tomcat و رفع چند آسیبپذیری را نیز در Release Notes ثبت کرده است؛ بنابراین Upgrade فقط موضوع Feature نیست و باید در Change Plan امنیتی هم دیده شود.
مدل پیشنهادی Rollout در سه فاز
فاز اول: Monitor و Baseline
یک Device Group محدود مثل Finance Pilot انتخاب کنید. Policyهای محدود و قابل توضیح بسازید. در صورت امکان ابتدا Warn یا Scope کوچک استفاده کنید تا False Positiveها مشخص شوند.
فاز دوم: Incident Workflow
Assignee، Severity Matrix، SLA داخلی Investigation و Comment Standard تعریف کنید. Backlog روزانه Review شود.
فاز سوم: Enforcement و Scale
پس از کاهش False Positive، Policyهای High Confidence را روی Block قرار دهید و Scope را به Departmentهای دیگر گسترش دهید. KPIها را ماهانه بررسی کنید.
اشتباههای رایج در استقرار DLP Incident Management
- ساخت دهها Policy قبل از شناخت Data Classification.
- Block کردن همهچیز از روز اول.
- نداشتن Owner برای Incident.
- بستن Incident بدون Comment و Evidence.
- Dismiss کردن False Positive بدون اصلاح Policy.
- تعریف Device Group بسیار بزرگ و بدون Context کسبوکار.
- فرض اینکه Incident Console جدید همه ماژولهای DLP را پوشش میدهد.
- نداشتن مسیر Escalation برای رخدادهای عمدی یا تکرارشونده.
نکات کلیدی
- Incident Management Console در Build 6310 یک قابلیت جدید اوت ۲۰۲۶ است.
- در Workflow جدید، Policy ابتدا Allow/Warn/Block را اجرا میکند و بعد Incident برای Investigation ساخته میشود.
- Console در وضعیت فعلی از DLP Policy Management تغذیه میشود؛ این Scope را هنگام POC دقیق بررسی کنید.
- Policy Management جدید فعلاً Email DLP روی Outlook را پوشش میدهد.
- Incident Details شامل Event Context، Matched Data Identifiers و Timeline است.
- False Positive باید به Fine-tuning Policy منجر شود، نه فقط Dismiss شدن Incident.
- DataSecurity Plus Incident Management مکمل SIEM و ITSM است، نه جایگزین کامل آنها.
سخن پایانی
DLP زمانی بالغ میشود که سازمان فقط جلوی خروج داده را نگیرد، بلکه بتواند درباره هر نقض مهم پاسخ دهد: چه اتفاقی افتاد، چه دادهای درگیر بود، چه کسی آن را بررسی کرد، چه تصمیمی گرفته شد و آیا Policy بعد از Investigation بهتر شد یا نه.
Incident Management Console جدید DataSecurity Plus همین حلقه را کاملتر میکند. Build 6310 نقض Policy را از یک Event منفرد به یک Incident قابل تخصیص، قابل بررسی و قابل Audit تبدیل کرده است. برای سازمانهایی که Data Protection را جدی دنبال میکنند، این تغییر میتواند فاصله میان DLP Detection و عملیات واقعی Security را کمتر کند.
اگر قصد دارید DataSecurity Plus را برای DLP، Data Discovery، File Audit یا Data Risk Assessment ارزیابی کنید، صفحه DataSecurity Plus مدانت را ببینید. برای برآورد لایسنس میتوانید از استعلام قیمت محصولات ManageEngine و برای طراحی معماری، POC یا جلسه فنی از درخواست دمو و پروپوزال مدانت استفاده کنید.
منابع
- ManageEngine DataSecurity Plus – Incident Management
- DataSecurity Plus Release Notes – Build 6310
- Setting up DLP Policies in DataSecurity Plus
- DataSecurity Plus Architecture
- Verizon Data Breach Investigations Report 2026
