یکی از حساسترین و در عین حال کمتر مورد توجه قرارگرفتهترین بخشهای ارائه خدمات Managed Security Service Provider (MSSP)، طراحی فرآیند Incident Escalation است. بسیاری از شرکتها سرمایهگذاری قابل توجهی روی SIEM، XDR، SOAR، Threat Intelligence و Detection Engineering انجام میدهند، اما زمانی که یک رخداد واقعی شناسایی میشود، مشخص نیست چه کسی، در چه زمانی، از چه طریقی و با چه اختیاراتی باید تصمیمگیری کند. در عمل، شکست بسیاری از عملیاتهای امنیتی نه به دلیل ضعف فناوری، بلکه به دلیل ضعف در فرآیند تشدید رخداد و واکنش رخ میدهد.
یکی از اشتباهات رایج در طراحی خدمات MSSP، وابسته کردن فرآیند Escalation به سطح قرارداد مشتری است. برای مثال، تصور میشود مشتری Premium باید تماس تلفنی دریافت کند اما مشتری Standard تنها یک تیکت یا ایمیل دریافت کند. این رویکرد از منظر مدیریت ریسک قابل دفاع نیست؛ زیرا مهاجم به نوع قرارداد مشتری توجهی ندارد. اگر نشانههای باجافزار، تصاحب Domain Admin یا خروج گسترده اطلاعات مشاهده شود، تأخیر در اطلاعرسانی میتواند خسارتهایی ایجاد کند که چندین برابر ارزش کل قرارداد باشد.
به همین دلیل، اصل معماری باید بر این پایه استوار باشد که شدت رخداد (Severity) تعیینکننده مسیر Escalation باشد، نه ارزش مالی قرارداد یا سطح خدمات خریداریشده. تفاوت قراردادها میتواند در تعداد گزارشها، ساعات پشتیبانی، زمان پاسخ کارشناسان، خدمات Threat Hunting یا Incident Response باشد، اما در رخدادهای بحرانی، همه مشتریان باید از سریعترین فرآیند اطلاعرسانی بهرهمند شوند.
برای تحقق این هدف، میتوان یک معماری سهلایه برای Escalation طراحی کرد.
در Tier 1 رخدادهای با شدت پایین و متوسط مدیریت میشوند. این دسته شامل هشدارهایی است که هنوز شواهد کافی برای اثبات نفوذ وجود ندارد یا اثر تجاری آنها محدود است. اطلاعرسانی از طریق سامانه تیکتینگ و ایمیل انجام میشود و پاسخگویی مطابق SLA قرارداد خواهد بود. مسئولیت این سطح معمولاً بر عهده تحلیلگر شیفت است و نیازی به فعالسازی مدیر عملیات یا تماس خارج از ساعات اداری وجود ندارد.
در Tier 2 وضعیت متفاوت میشود. مشاهده نشانههایی مانند Privilege Escalation موفق، ارتباط تأییدشده با زیرساخت فرماندهی و کنترل (C2)، اجرای ابزارهای شناختهشده مهاجمان، یا همبستگی چندین IOC مستقل، احتمال وقوع یک Incident واقعی را افزایش میدهد. در این مرحله، علاوه بر ثبت تیکت، تماس تلفنی با نماینده اصلی مشتری انجام میشود؛ حتی اگر رخداد در نیمهشب یا تعطیلات رخ داده باشد. در صورت عدم پاسخ، تماس با نماینده دوم، ارسال پیامک و ایمیل انجام شده و تمام تلاشها با ثبت دقیق زمان مستندسازی میشوند. مدیریت این سطح باید توسط Shift Lead یا Incident Manager انجام شود تا تصمیمگیری تنها بر عهده تحلیلگر شیفت نباشد.
اما مهمترین بخش معماری، Tier 3 است؛ جایی که سازمان با یک بحران امنیتی واقعی مواجه است. آغاز عملیات باجافزار، حرکت جانبی گسترده، تصاحب حسابهای دارای دسترسی مدیریتی، تخریب سرویسهای حیاتی یا خروج انبوه اطلاعات، نمونههایی از این سطح هستند. در چنین شرایطی، تماس تلفنی باید به صورت همزمان با حداقل دو نفر از فهرست Escalation مشتری برقرار شود. تجربه بسیاری از مراکز عملیات امنیت نشان داده است که تماس ترتیبی با افراد، بهویژه در ساعات غیراداری، باعث از دست رفتن دقایق ارزشمند میشود. تماس موازی احتمال برقراری ارتباط را افزایش داده و زمان واکنش را کاهش میدهد.
یکی از مهمترین چالشهای MSSP در این مرحله، مسئله اختیار اقدام (Authority to Act) است. بسیاری از شرکتها رخداد را شناسایی میکنند اما از ترس مسئولیت حقوقی، هیچ اقدامی انجام نمیدهند و منتظر تأیید مشتری میمانند. در مقابل، برخی نیز بدون مجوز اقدام به ایزولهسازی سیستم یا مسدودسازی سرویس میکنند و بعداً با اعتراض مشتری مواجه میشوند. راهحل این تعارض، تعریف Pre-Authorized Emergency Action در قرارداد است. در این مدل، مشتری از همان ابتدا اجازه انجام مجموعهای از اقدامات محدود و مشخص مانند ایزوله کردن یک Endpoint، غیرفعال کردن یک حساب کاربری آلوده یا مسدودسازی ارتباط با یک IP مخرب را صادر میکند. بنابراین در زمان بحران، تصمیمگیری جدیدی انجام نمیشود و MSSP صرفاً اختیار از پیش توافقشده را اجرا میکند.
البته طراحی چنین فرآیندی نیز بدون چالش نیست. نخستین چالش، تعریف صحیح Severity است. اگر معیارها بیش از حد حساس باشند، تعداد زیادی رخداد به اشتباه در Tier 3 قرار میگیرند و تیم عملیات با هشدارهای اضطراری مکرر مواجه میشود؛ پدیدهای که به مرور موجب Alert Fatigue و کاهش حساسیت کارشناسان خواهد شد. از سوی دیگر، اگر معیارها بیش از حد سختگیرانه باشند، ممکن است رخدادهای واقعی دیر تشخیص داده شوند. بنابراین Severity باید بر اساس تحلیل ریسک، داراییهای حیاتی، تجربیات گذشته و نیازهای هر مشتری تنظیم شود.
چالش دوم، در دسترس نبودن افراد مسئول مشتری است. در بسیاری از رخدادهای واقعی، SOC موفق به شناسایی حمله شده اما هیچیک از افراد معرفیشده پاسخگو نبودهاند. تغییر شماره تماس، جابهجایی مدیران، مرخصی یا خروج کارکنان از سازمان از دلایل رایج این مشکل است. به همین دلیل، فهرست Escalation باید حداقل هر سه ماه یکبار بازبینی و صحت اطلاعات آن تأیید شود.
چالش سوم، مستندسازی دقیق است. عبارت «تماس گرفته شد» در گزارش حادثه ارزش حقوقی چندانی ندارد. در مقابل، ثبت ساعت دقیق تماس، مدت زمان، شماره مقصد، نتیجه تماس، نام فرد پاسخدهنده و روشهای جایگزین اطلاعرسانی، در صورت بروز اختلافات قراردادی یا بررسیهای حقوقی، به یکی از مهمترین مستندات تبدیل میشود.
چالش چهارم، تفاوت مسئولیت میان MSSP و تیم پاسخگویی مشتری است. MSSP مسئول تشخیص، تحلیل، اطلاعرسانی و در برخی قراردادها اجرای اقدامات اولیه است؛ اما مسئولیت نهایی مدیریت کسبوکار، پذیرش ریسک و تصمیمات کلان همچنان بر عهده مشتری باقی میماند. مرزبندی دقیق این مسئولیتها باید در قرارداد، RACI Matrix و Runbookهای عملیاتی بهصورت شفاف تعریف شود تا در زمان بحران هیچ ابهامی وجود نداشته باشد.
چالش پنجم، هماهنگی بین فناوری و فرآیند است. بسیاری از سازمانها ابزارهای پیشرفتهای مانند SIEM، SOAR و XDR را خریداری میکنند، اما فرآیند Escalation همچنان به تماس دستی، پیامرسانهای شخصی یا تصمیمات فردی وابسته است. بلوغ واقعی زمانی ایجاد میشود که فناوری، فرآیند و نیروی انسانی در کنار یکدیگر عمل کنند؛ بهگونهای که ایجاد Incident با Severity بحرانی، بهصورت خودکار زنجیره اطلاعرسانی، ثبت مستندات، فعالسازی تیم Incident Response و اجرای اقدامات از پیش مجاز را آغاز کند.
در نهایت، بلوغ یک MSSP تنها با تعداد Ruleهای تشخیصی یا ابزارهای امنیتی سنجیده نمیشود؛ بلکه توانایی مدیریت دقایق نخست یک بحران، مهمترین معیار ارزیابی آن است. تجربه نشان داده است که در بسیاری از حملات بزرگ، فاصله میان یک رخداد قابل مهار و یک فاجعه سازمانی، تنها چند دقیقه بوده است. طراحی یک معماری استاندارد برای Escalation، مبتنی بر شدت رخداد، همراه با تعریف اختیارات از پیش توافقشده، مستندسازی دقیق، بازبینی دورهای اطلاعات تماس و تعیین شفاف مسئولیتها، میتواند این فاصله را به نفع سازمان کاهش دهد. این رویکرد علاوه بر افزایش تابآوری سایبری، از منظر حقوقی، قراردادی و اعتباری نیز جایگاه MSSP را بهعنوان یک شریک حرفهای و قابل اعتماد تقویت خواهد کرد.
