بسیاری از مراکز عملیات امنیت (SOC) در مواجهه با حساب‌های کاربری سازش‌شده (Compromised Accounts)، از Playbookهایی استفاده می‌کنند که برای انسان‌ها طراحی شده است. برای مثال، در ۱۵ دقیقه اول پاسخ، تحلیل‌گر سعی می‌کند با کاربر تماس بگیرد تا صحت ورود در ساعت ۲ بامداد از یک کشور ناشناس را بررسی کند. اما اگر با یک Service Account، یک API Key در خط لوله ساخت (Build Pipeline) یا یک OAuth Token قدیمی طرف باشید، این روش کاملاً بی‌اثر است.
چالش مقیاس و شناسایی
تعداد هویت‌های ماشینی بسیار بیشتر از هویت‌های انسانی است؛ طبق تحقیقات CyberArk، به ازای هر هویت انسانی، تقریباً ۸۲ هویت ماشینی وجود دارد. مشکل اینجاست که تعداد کمی از این هویت‌ها پشت MFA هستند و بسیاری از آن‌ها دسترسی‌های بسیار بیشتری نسبت به نیاز واقعی خود دارند. علاوه بر این، ترافیک این هویت‌ها معمولاً در نویز پس‌زمینه مانیتورینگ گم می‌شود و توسط فیلترها حذف می‌گردد.
موانع در مسیر مهار (Containment)
اولین مانع، شناسایی مالکیت (Ownership) است. در حالی که شناسایی مدیر یک کارمند از طریق HR سریع است، پیدا کردن تیم سازنده یک Service Account مشکوک ممکن است ساعت‌ها زمان ببرد و اغلب به پیمانکارانی ختم شود که سال‌ها پیش سازمان را ترک کرده‌اند.
دومین مانع، ترس از اختلال در کسب‌وکار است. غیرفعال کردن حساب یک کاربر ممکن است فقط یک بعدازظهر او را مختل کند، اما ابطال یک Credential که یک سیستم پرداخت به آن وابسته است، می‌تواند منجر به توقف کامل خدمات مشتریان شود. این موضوع باعث می‌شود تحلیل‌گران SOC برای مهار تهدید، منتظر تایید مدیران ارشد بمانند و در این فاصله، عامل تهدید به فعالیت خود ادامه دهد.
درس‌هایی از حوادث واقعی
- Cloudflare: مهاجمان از توکن‌های دسترسی و Service Accountهایی استفاده کردند که از نشت قبلی Okta به دست آمده بود. با وجود چرخش (Rotation) هزاران Credential، چهار مورد به دلیل تصور اشتباه تیم امنیت مبنی بر عدم استفاده از آن‌ها، نادیده گرفته شدند.
- Microsoft: در حمله Midnight Blizzard، مهاجمان از یک حساب تست قدیمی بدون MFA و یک اپلیکیشن OAuth تست که دسترسی‌های سطح بالا داشت، برای ورود به ایمیل‌های سازمانی استفاده کردند.
- Drift: مهاجمان با سرقت OAuth Tokenهای چت‌بات Drift، به مدت ۱۰ روز داده‌های مشتریان را از Salesforce استخراج کردند تا به دنبال AWS Access Keyها و رمزهای عبور برای نفوذ به سازمان‌های بعدی بگردند.
راهکارهای عملی برای تدوین Playbook
برای ایجاد یک Playbook موثر، ابتدا به یک موجودی (Inventory) دقیق نیاز دارید. برای هر هویت غیرانسانی با سطح دسترسی بالا، موارد زیر را مستند کنید:
- تیم مسئول مدیریت آن هویت.
- توضیحی کوتاه درباره اینکه در صورت حذف این هویت، چه سرویسی دچار اختلال می‌شود.
سپس، این هویت‌ها را بر اساس Blast Radius (دامنه اثرگذاری) دسته‌بندی کنید. برای سطوح حساس، از پیش تعیین کنید که چه کسی اجازه دارد دستور ابطال (Revoke) فوری را صادر کند، حتی اگر منجر به توقف سرویس شود. این تصمیم باید بر عهده مدیران اجرایی باشد، نه تحلیل‌گر شیفت.
تایید و مهار بدون تخریب کسب‌وکار
به جای پرسش «آیا این شما بودید؟»، از تحلیل Logها استفاده کنید. بررسی مکان ورود (Location) و مقایسه دسترسی‌های فعلی با الگوهای چند ماه گذشته (Permissions Analysis) می‌تواند سریع‌ترین راه برای شناسایی ناهنجاری باشد. مهاجمان معمولاً مستقیماً به سراغ Scopeهای پرخطر می‌روند که برای مدت‌ها بدون استفاده مانده‌اند.
برای کاهش زمان توقف، Replacement Credentials را از پیش آماده کنید. اگر تیم‌های توسعه نحوه تولید و ذخیره‌سازی Credential جدید در سیستم‌های Secret Management را تمرین کرده باشند، زمان توقف از یک روز به ۱۰ دقیقه کاهش می‌یابد.
بازیابی و پیشگیری بلندمدت
در مرحله Recovery، باید علت ریشه‌ای مشکل را حل کنید. به جای استفاده از Static Secretها، به سمت استفاده از توکن‌های کوتاه‌مدت از طریق Workload Identity Federation یا دسترسی‌های Just-In-Time (JIT) حرکت کنید.
در نهایت، پیش از نهایی کردن Playbook، یک Tabletop Simulation با حضور مالکان اپلیکیشن و تیم SOC برگزار کنید تا سرعت تصمیم‌گیری در لحظات بحرانی سنجیده شود.
