شکار سوءاستفاده از هویت ابری با لاگ‌های احراز هویت

مفاهیم و تهدیدات مرتبط با سوءاستفاده از هویت ابری

سوءاستفاده از هویت ابری یکی از چالش‌های جدی در حوزه امنیت سایبری است که مهاجمان با بهره‌گیری از اعتبارنامه‌های معتبر، به منابع ابری دسترسی غیرمجاز پیدا می‌کنند. این تکنیک که در چارچوب MITRE ATT&CK با شناسه T1078.004 ثبت شده، به مهاجم امکان می‌دهد تا از طریق حساب‌های ابری معتبر، به‌عنوان یک کاربر قانونی وارد محیط شده و بدون نیاز به ابزارهای مخرب، فعالیت‌های خود را پنهان نگه دارد. این روش می‌تواند برای دسترسی اولیه، حفظ ماندگاری، افزایش امتیاز یا دور زدن دفاع‌ها مورد استفاده قرار گیرد.

در کنار این تکنیک، کشف حساب (T1087.004) نیز به مهاجم کمک می‌کند تا فهرستی از حساب‌های کاربری معتبر، نام‌های کاربری و آدرس‌های ایمیل را در محیط ابری به دست آورد. این اطلاعات برای مهاجم حیاتی است؛ زیرا او می‌تواند با شناسایی حساب‌های دارای امتیاز بالا، هدف‌های مناسبی برای حملات بعدی مانند جستجوی اعتبارنامه یا تصاحب حساب انتخاب کند. محیط‌های ابری معمولاً رابط‌های کاربری ساده‌ای برای فهرست‌کردن کاربران فراهم می‌کنند که این کار را برای مهاجم آسان‌تر می‌سازد.

ترکیب این دو تکنیک می‌تواند زنجیره حمله‌ای خطرناک ایجاد کند: مهاجم ابتدا با کشف حساب‌ها (T1087.004) محیط را شناسایی کرده و سپس با استفاده از اعتبارنامه‌های به‌دست‌آمده از طریق روش‌های دیگر، از تکنیک T1078.004 برای ورود به سیستم استفاده می‌کند. این زنجیره به مهاجم امکان می‌دهد تا بدون جلب توجه، به داده‌های حساس دسترسی یافته و فعالیت‌های مخرب خود را انجام دهد. بنابراین، پایش لاگ‌های احراز هویت و تحلیل رفتار کاربران برای شناسایی این الگوها ضروری است.

علاوه بر این، مهاجمان ممکن است از حساب‌های غیرفعال یا حساب‌های کاربرانی که دیگر در سازمان نیستند استفاده کنند تا احتمال شناسایی کاهش یابد. این حساب‌ها اغلب فاقد نظارت کافی هستند و فعالیت‌های مشکوک روی آن‌ها ممکن است برای مدت طولانی ناشناخته بماند. بنابراین، سازمان‌ها باید فرآیندی برای شناسایی و غیرفعال‌سازی خودکار حساب‌های غیرفعال داشته باشند.

• تکنیک T1078.004 شامل بهره‌برداری از حساب‌های ابری معتبر برای دسترسی اولیه، ماندگاری، افزایش امتیاز و دور زدن دفاع است.
• تکنیک T1087.004 به مهاجم امکان می‌دهد تا فهرست کاربران و نقش‌های آنان را در محیط ابری استخراج کند.
• مهاجمان معمولاً از حساب‌های غیرفعال یا حساب‌های کاربرانی که دیگر در سازمان نیستند برای کاهش احتمال شناسایی استفاده می‌کنند.
• کشف حساب‌ها می‌تواند به مهاجم در انتخاب اهداف برای حملات بعدی مانند جستجوی اعتبارنامه یا حملات فیشینگ کمک کند.

شواهد و تله‌متری‌های مرتبط با احراز هویت ابری

در حوزه امنیت سایبری، شناسایی سوءاستفاده از هویت‌های ابری نیازمند پایش مستمر و دقیق لاگ‌های احراز هویت است. بر اساس چارچوب MITRE ATT&CK، تکنیک T1078 (حساب‌های معتبر) یکی از رایج‌ترین روش‌هایی است که مهاجمان برای دسترسی اولیه، ماندگاری، افزایش امتیاز یا گریز از دفاع از آن استفاده می‌کنند. در این تکنیک، مهاجم از اعتبارنامه‌های معتبر (مانند نام کاربری و رمز عبور کاربران واقعی) برای ورود به سامانه‌ها و سرویس‌های ابری استفاده می‌کند. این اعتبارنامه‌ها ممکن است از طریق فیشینگ، بدافزار، یا خرید از وب تاریک به دست آمده باشند.

یکی از مهم‌ترین منابع شواهد برای شناسایی چنین حملاتی، لاگ‌های احراز هویت هستند. رویدادهای ورود موفق با آدرس IP غیرمعمول، زمان‌های غیرعادی (مثلاً خارج از ساعات کاری)، یا استفاده هم‌زمان از یک حساب در چندین موقعیت جغرافیایی متفاوت، می‌توانند نشانه‌هایی از سوءاستفاده از هویت باشند. همچنین، تلاش‌های ورود ناموفق متعدد که در بازه‌های زمانی کوتاه رخ می‌دهند (که ممکن است نشانه‌ای از حملات brute force باشد)، و تغییرات ناگهانی در مشخصات حساب (مانند تغییر رمز عبور، ایمیل بازیابی، یا تنظیمات احراز هویت چندمرحله‌ای) نیز از جمله شواهد مهم به شمار می‌روند.

در گزارش MITRE برای تکنیک T1078، اشاره شده است که مهاجمان ممکن است از اعتبارنامه‌های معتبر برای دسترسی به سرویس‌های خارجی مانند VPN، Outlook Web Access، دستگاه‌های شبکه و Remote Desktop استفاده کنند. این دسترسی‌ها می‌توانند به‌عنوان نقطه شروع برای نفوذ به شبکه و انجام فعالیت‌های مخرب بعدی عمل کنند. علاوه بر این، استفاده از حساب‌های غیرفعال (مثلاً حساب‌های کاربرانی که دیگر در سازمان حضور ندارند) نیز توسط مهاجمان مشاهده شده است، زیرا این حساب‌ها ممکن است کمتر مورد توجه قرار گیرند.

یکی دیگر از جنبه‌های مهم، فاز Discovery با تکنیک Account Discovery (T1087) است. در این مرحله، مهاجم سعی می‌کند فهرستی از حساب‌های کاربری معتبر در محیط ابری به دست آورد. به عنوان مثال، در محیط‌های ابری مانند AWS یا Azure، فراخوانی APIهایی که اطلاعات کاربران را برمی‌گردانند (مانند ListUsers) می‌تواند نشانه‌ای از این اقدام باشد. این رفتار ممکن است از طریق ابزارهای مدیریتی استاندارد یا اسکریپت‌های سفارشی انجام شود و در نتیجه، برای شناسایی آن باید به الگوهای دسترسی به API توجه ویژه‌ای داشت.

در نهایت، برای تشخیص مؤثر این نوع حملات، پیشنهاد می‌شود که سازمان‌ها به‌طور مستمر لاگ‌های احراز هویت را پایش کرده و رویدادهای زیر را مورد بررسی قرار دهند: ورودهای موفق از آدرس‌های IP ناشناخته یا غیرمعمول، تکرار تلاش‌های ناموفق ورود، تغییرات در نقش‌ها و دسترسی‌های حساب‌ها، و هرگونه فعالیتی که با رفتار معمول کاربر همخوانی ندارد. همچنین، پیاده‌سازی سیاست‌های امنیتی مانند فعال‌سازی احراز هویت چندمرحله‌ای (MFA) و بررسی دوره‌ای حساب‌های غیرفعال می‌تواند به کاهش سطح حمله کمک کند. لازم به ذکر است که این شواهد صرفاً مبتنی بر اطلاعات ارائه‌شده در منابع MITRE است و ممکن است موارد دیگری نیز در محیط‌های خاص وجود داشته باشد که نیاز به تحلیل دقیق‌تری دارند.

روند کار برای شناسایی سوءاستفاده از هویت ابری

شناسایی سوءاستفاده از هویت ابری نیازمند تحلیل دقیق لاگ‌های احراز هویت بر اساس چارچوب‌های معتبر امنیتی است. تکنیک T1078 (حساب‌های معتبر) به مهاجمان امکان می‌دهد تا با استفاده از اعتبارنامه‌های به‌دست‌آمده، به سامانه‌های ابری دسترسی اولیه، تداوم دسترسی یا افزایش امتیاز داشته باشند. لاگ‌های احراز هویت شامل اطلاعاتی مانند آدرس IP، زمان ورود، نوع پروتکل (مانند SAML، OAuth) و شناسه حساب کاربری هستند که برای تشخیص ناهنجاری‌ها حیاتی می‌باشند.

تکنیک T1087 (کشف حساب) نیز به مهاجمان امکان شمارش حساب‌های کاربری و شناسایی حساب‌های با امتیاز بالا را می‌دهد. ترکیب این دو تکنیک نشان می‌دهد که مهاجمان ابتدا حساب‌های معتبر را شناسایی کرده و سپس از آن‌ها برای دسترسی استفاده می‌کنند. بنابراین، تحلیل لاگ‌ها باید بر شناسایی الگوهای ورود غیرعادی مانند ورود از مکان‌های جغرافیایی غیرمنتظره، زمان‌های خارج از ساعات کاری، یا استفاده از حساب‌های غیرفعال متمرکز شود.

روند پیشنهادی شامل مراحل زیر است: جمع‌آوری لاگ‌های احراز هویت از سرویس‌های ابری (مانند AWS CloudTrail، Azure AD Sign-in Logs)، نرمال‌سازی داده‌ها برای استخراج فیلدهای کلیدی، و سپس اعمال قوانین تشخیصی مبتنی بر رفتار. توصیه می‌شود از ابزارهای SIEM برای خودکارسازی این فرآیند استفاده شود. همچنین، ایجاد خط پایه از رفتار عادی کاربران برای تشخیص ناهنجاری‌ها ضروری است.

برای پیاده‌سازی مؤثر، لازم است که تیم امنیتی ابتدا منابع داده را شناسایی کرده و اطمینان حاصل کند که تمام سرویس‌های ابری تحت پوشش قرار دارند. سپس باید فرآیند نرمال‌سازی داده‌ها به‌گونه‌ای طراحی شود که فیلدهای کلیدی به‌طور یکپارچه در دسترس باشند. در نهایت، قوانین تشخیصی باید به‌طور دوره‌ای بازبینی و به‌روزرسانی شوند تا با تغییرات محیط سازگار باشند.

• مرحله ۱: جمع‌آوری لاگ‌های احراز هویت از تمام سرویس‌های ابری و ذخیره‌سازی متمرکز.
• مرحله ۲: نرمال‌سازی داده‌ها با استخراج فیلدهای IP، زمان، نوع احراز هویت، و شناسه حساب.
• مرحله ۳: ایجاد خط پایه از رفتار عادی شامل مکان‌های معمول ورود، ساعات کاری، و دستگاه‌های مجاز.
• مرحله ۴: اعمال قوانین تشخیصی برای شناسایی ورود از IPهای ناشناخته، زمان‌های غیرمعمول، یا حساب‌های غیرفعال.
• مرحله ۵: بررسی دسترسی‌های حجیم به APIهای مدیریت حساب که می‌تواند نشانه کشف حساب (T1087) باشد.
• مرحله ۶: همبستگی رویدادها با سایر لاگ‌ها مانند تغییرات مجوزها یا ایجاد کاربر جدید.

1. گام اول: لاگ‌های احراز هویت را از سرویس‌های ابری مانند AWS CloudTrail، Azure AD Sign-in Logs، و GCP Audit Logs جمع‌آوری کنید.
2. گام دوم: داده‌ها را با استفاده از ابزارهای SIEM مانند Splunk یا Elastic Stack نرمال‌سازی کنید و فیلدهای کلیدی را استخراج نمایید.
3. گام سوم: یک خط پایه از رفتار عادی کاربران با استفاده از داده‌های تاریخی (حداقل ۳۰ روز) ایجاد کنید.
4. گام چهارم: قوانین تشخیصی برای شناسایی ناهنجاری‌ها مانند ورود از IPهای خارج از محدوده مجاز یا استفاده از حساب‌های غیرفعال پیاده‌سازی کنید.
5. گام پنجم: هشدارها را بررسی و با سایر لاگ‌ها مانند تغییرات گروه یا دسترسی به منابع حساس همبستگی دهید.

تریج و اولویت‌بندی هشدارها

در فرآیند تریج هشدارهای مرتبط با سوءاستفاده از هویت ابری، نخستین گام، بررسی زمینه (context) رویداد احراز هویت است. این بررسی باید شامل نوع حساب کاربری، موقعیت جغرافیایی درخواست، و رفتار تاریخی کاربر باشد. به عنوان مثال، ورود موفق با استفاده از حساب‌های غیرفعال (inactive accounts) که به افرادی تعلق دارند که دیگر در سازمان حضور ندارند، می‌تواند نشانه‌ای قوی از سوءاستفاده باشد؛ زیرا کاربر اصلی برای شناسایی فعالیت غیرعادی در دسترس نیست. همچنین استفاده از اعتبارنامه‌های به سرقت رفته (compromised credentials) که از طریق روش‌هایی مانند فیشینگ یا نشت داده‌ها به دست آمده‌اند، باید به عنوان یک زنگ خطر جدی در نظر گرفته شود.

برای اولویت‌بندی مؤثر هشدارها، لازم است که تحلیلگران امنیتی به جای تکیه صرف بر قوانین ایستا، از رویکردی مبتنی بر رفتار استفاده کنند. به این معنی که هر رویداد احراز هویت باید در بستر فعالیت‌های قبلی همان حساب و الگوهای معمول سازمان ارزیابی شود. به عنوان مثال، اگر حسابی که معمولاً از یک محدوده IP مشخص و در ساعات کاری وارد می‌شود، ناگهان از یک موقعیت جغرافیایی غیرمنتظره و در زمان غیرعادی اقدام به ورود کند، این موضوع باید به عنوان یک ناهنجاری با اولویت بالا علامت‌گذاری شود. همچنین، ترکیب چندین عامل مانند استفاده از حساب‌های دارای دسترسی بالا (privileged accounts) و انجام فعالیت‌های کشف حساب (Account Discovery) می‌تواند نشان‌دهنده تلاش برای حرکت جانبی یا افزایش امتیاز باشد.

توصیه می‌شود که فرآیند تریج به صورت سلسله‌مراتبی طراحی شود: ابتدا هشدارهای مربوط به حساب‌های غیرفعال یا معلق بررسی شوند، سپس هشدارهای مربوط به حساب‌هایی که اخیراً اعتبارنامه‌های آن‌ها در معرض خطر قرار گرفته است (مانند موارد افشای عمومی)، و در نهایت هشدارهای مربوط به رفتارهای غیرعادی در حساب‌های فعال. در این مرحله، تحلیلگران باید از داده‌های زمینه‌ای مانند زمان، مکان، و نوع دستگاه استفاده کنند تا تصمیم بگیرند که آیا هشدار نیاز به اقدام فوری دارد یا خیر. لازم به ذکر است که این توصیه‌ها بر اساس منابع معتبر مانند MITRE ATT&CK است و هرگونه قضاوت نهایی باید با در نظر گرفتن شرایط خاص هر سازمان انجام شود.

برای اطمینان از اثربخشی فرآیند تریج، سازمان‌ها باید معیارهای مشخصی برای اولویت‌بندی تعریف کنند. به عنوان مثال، هشدارهای مربوط به حساب‌های مدیر یا حساب‌های دارای دسترسی به داده‌های حساس باید بالاترین اولویت را داشته باشند. همچنین، هشدارهایی که با سایر رویدادهای مشکوک همبستگی دارند (مانند تغییرات غیرمجاز در تنظیمات امنیتی) باید سریع‌تر بررسی شوند. این معیارها باید به‌طور دوره‌ای بازبینی و به‌روزرسانی شوند تا با تهدیدات نوظهور سازگار باشند.

• بررسی نوع حساب: حساب‌های غیرفعال، حساب‌های مهمان، یا حساب‌های دارای دسترسی بالا (مانند مدیران) را در اولویت قرار دهید.
• بررسی موقعیت جغرافیایی: ورود از کشورها یا شهرهایی که کاربر معمولاً در آن‌ها فعالیت ندارد، نیازمند بررسی بیشتر است.
• بررسی رفتار تاریخی: مقایسه الگوی ورود فعلی با ورودهای قبلی همان کاربر (زمان، فرکانس، و روش دسترسی).
• توجه به اعتبارنامه‌های به سرقت رفته: اگر اعتبارنامه‌ای در رویدادهای افشای عمومی دیده شده است، هرگونه استفاده از آن باید به عنوان هشدار بحرانی در نظر گرفته شود.

1. جمع‌آوری لاگ‌های احراز هویت از تمام سرویس‌های ابری (مانند IaaS، SaaS) و یکپارچه‌سازی آن‌ها در یک پلتفرم مدیریت رویداد و اطلاعات امنیتی (SIEM).
2. تعریف پروفایل پایه برای هر حساب بر اساس داده‌های تاریخی (زمان‌های ورود معمول، آدرس‌های IP مجاز، و دستگاه‌های شناخته‌شده).
3. پیاده‌سازی قوانین تشخیص ناهنجاری که ترکیبی از عوامل مانند حساب غیرفعال، موقعیت جغرافیایی غیرمعمول، و زمان غیرعادی را در نظر می‌گیرند.
4. ایجاد یک صف تریج که هشدارها را بر اساس شدت (کم، متوسط، زیاد) و اعتبار زمینه مرتب می‌کند.
5. برای هر هشدار، بررسی خودکار تاریخچه ورود کاربر و جستجو برای نشانه‌های کشف حساب (مانند فراخوانی API برای لیست کاربران) به منظور تأیید یا رد سوءاستفاده.

مثبت‌های کاذب و چالش‌های تشخیص

در پایش لاگ‌های احراز هویت برای شناسایی سوءاستفاده از هویت ابری، یکی از چالش‌های اصلی، تمایز بین فعالیت‌های مشکوک و رفتارهای قانونی اما غیرعادی است. به عنوان مثال، ورود موفق از یک مکان جغرافیایی غیرمعمول یا در ساعات غیرکاری ممکن است برای یک تحلیلگر هشدار ایجاد کند، اما در بسیاری از موارد این رویدادها ناشی از سفرهای کاری، دورکاری یا استفاده از شبکه‌های خصوصی مجازی هستند. چنین شرایطی می‌تواند منجر به تولید حجم بالایی از هشدارهای مثبت کاذب شود که منابع تیم امنیتی را تحلیل می‌برد و ممکن است باعث خستگی تحلیلگران و نادیده گرفته شدن هشدارهای واقعی شود.

چالش دیگر مربوط به حساب‌های مشترک یا حساب‌هایی است که توسط چندین کاربر قانونی استفاده می‌شوند. در چنین سناریوهایی، الگوهای ورود ممکن است به طور طبیعی متنوع باشند و تشخیص ناهنجاری دشوار شود. همچنین، همانطور که در منابع MITRE اشاره شده است، سوءاستفاده از حساب‌های غیرفعال (مثلاً حساب کاربرانی که دیگر در سازمان نیستند) می‌تواند به مهاجم امکان دهد تا از دید کاربر اصلی پنهان بماند، زیرا کاربر اصلی برای شناسایی فعالیت‌های غیرعادی حضور ندارد. این موضوع تشخیص را پیچیده‌تر می‌کند، زیرا هیچ مرجع انسانی برای تأیید مشروعیت ورود وجود ندارد.

برای کاهش مثبت‌های کاذب، پیشنهاد می‌شود که تحلیلگران از ترکیبی از زمینه‌های غنی استفاده کنند، مانند اطلاعات دستگاه، الگوهای رفتاری تاریخی کاربر، و همبستگی با سایر رویدادهای امنیتی. به عنوان مثال، یک ورود از یک مکان جدید که با یک تغییر رمز عبور یا دسترسی به داده‌های حساس همراه است، باید نسبت به یک ورود ساده از همان مکان، اولویت بالاتری داشته باشد. همچنین، ایجاد یک خط پایه از رفتار عادی برای هر کاربر و به‌روزرسانی منظم آن می‌تواند به شناسایی ناهنجاری‌های واقعی کمک کند. در نهایت، توصیه می‌شود که هشدارهای مربوط به حساب‌های غیرفعال به عنوان موارد پرخطر در نظر گرفته شوند و فرآیندهای تأیید خودکار یا دستی برای آن‌ها تعریف شود.

علاوه بر این، سازمان‌ها باید فرآیندی برای بازخورد و یادگیری از هشدارهای قبلی ایجاد کنند. با تحلیل موارد مثبت کاذب، می‌توان قوانین تشخیصی را بهبود بخشید و آستانه‌ها را تنظیم کرد. همچنین، آموزش تحلیلگران برای شناخت الگوهای رایج رفتار قانونی می‌تواند به کاهش خطاهای انسانی کمک کند. این اقدامات به مرور زمان دقت تشخیص را افزایش می‌دهد و بار کاری تیم امنیتی را کاهش می‌دهد.

• استفاده از حساب‌های غیرفعال به عنوان یک چالش کلیدی در تشخیص، زیرا کاربر اصلی حضور ندارد.
• ورودهای قانونی از مکان‌های غیرعادی یا ساعات غیرکاری می‌توانند منجر به هشدارهای اشتباه شوند.
• حساب‌های مشترک، تشخیص ناهنجاری را به دلیل تنوع طبیعی الگوهای ورود دشوار می‌کنند.

1. ایجاد خط پایه رفتاری برای هر کاربر بر اساس تاریخچه ورود، دستگاه‌ها و مکان‌های معمول.
2. استفاده از زمینه‌های اضافی مانند همبستگی با سایر رویدادها (تغییر رمز، دسترسی به داده‌های حساس) برای اولویت‌بندی هشدارها.
3. تعیین فرآیند تأیید برای حساب‌های غیرفعال، مانند بررسی با مدیر یا غیرفعال کردن خودکار آن‌ها پس از مدتی.

محدودیت‌های تحلیل لاگ‌های احراز هویت

تحلیل لاگ‌های احراز هویت، اگرچه یکی از ابزارهای اصلی در شناسایی سوءاستفاده از هویت ابری است، با محدودیت‌های ذاتی مواجه است که آگاهی از آن‌ها برای ارزیابی دقیق و طراحی راهکارهای مکمل ضروری است. یکی از مهم‌ترین این محدودیت‌ها، عدم وجود دید کامل نسبت به تمامی سرویس‌ها و منابع درگیر است. در بسیاری از محیط‌های ابری، لاگ‌ها به‌صورت پراکنده و در سرویس‌های مختلف تولید می‌شوند و ممکن است برخی از رویدادهای مرتبط با احراز هویت، مانند استفاده از توکن‌های کوتاه‌مدت یا دسترسی‌های مستقیم به API، در لاگ‌های استاندارد ثبت نشوند. این شکاف اطلاعاتی می‌تواند منجر به از دست رفتن نشانه‌های حیاتی فعالیت‌های مشکوک شود.

محدودیت دیگر، رمزنگاری ترافیک شبکه است. بسیاری از پروتکل‌های احراز هویت مدرن، مانند OAuth و SAML، ترافیک رمزنگاری‌شده دارند و تحلیل محتوای آن‌ها بدون دسترسی به کلیدهای رمزنگاری یا نقاط پایانی میانی ممکن نیست. در نتیجه، تحلیلگران تنها به فراداده‌ها و رویدادهای سطح بالا دسترسی دارند که ممکن است برای تشخیص الگوهای پیچیده سوءاستفاده کافی نباشد. همچنین، تأخیر در جمع‌آوری لاگ‌ها از سرویس‌های ابری مختلف می‌تواند باعث شود که تحلیل‌های بلادرنگ با داده‌های ناقص یا قدیمی انجام شوند و واکنش به موقع به تهدیدات را با چالش مواجه کند.

علاوه بر این، یکی از محدودیت‌های بنیادین که در منابع معتبر مانند MITRE ATT&CK نیز به آن اشاره شده است، عدم وجود کاربر اصلی برای شناسایی فعالیت غیرعادی است. در مواردی که مهاجم از اعتبارنامه‌های حساب‌های معتبر استفاده می‌کند، به‌ویژه حساب‌های غیرفعال یا متعلق به افرادی که دیگر در سازمان حضور ندارند، کاربر اصلی در دسترس نیست تا فعالیت غیرعادی را تأیید یا رد کند. این موضوع تشخیص را بسیار دشوار می‌کند، زیرا رفتارهای حاصل از سوءاستفاده ممکن است از دیدگاه آماری مشابه رفتار عادی کاربر باشد. بنابراین، تحلیل لاگ‌ها به تنهایی نمی‌تواند تصویر کاملی از تهدید ارائه دهد و نیاز به ترکیب با سایر منابع اطلاعاتی و تحلیل‌های رفتاری دارد.

برای غلبه بر این محدودیت‌ها، سازمان‌ها باید از رویکردهای مکمل مانند تحلیل رفتار کاربر و موجودیت (UEBA)، تهدید هوشمندی، و همبستگی با سایر رویدادهای امنیتی استفاده کنند. همچنین، استفاده از ابزارهای پیشرفته مانند یادگیری ماشین می‌تواند به شناسایی الگوهای پیچیده کمک کند. با این حال، هیچ راهکاری نمی‌تواند به تنهایی کامل باشد و ترکیب چندین لایه دفاعی ضروری است.

• عدم پوشش کامل همه سرویس‌ها و رویدادهای احراز هویت در لاگ‌ها
• رمزنگاری ترافیک که تحلیل محتوای درخواست‌ها و پاسخ‌ها را محدود می‌کند
• تأخیر در جمع‌آوری و یکپارچه‌سازی لاگ‌ها از منابع مختلف
• نبود کاربر اصلی برای تأیید فعالیت‌های مشکوک در حساب‌های در معرض خطر

شاخص‌های کلیدی و معیارهای ارزیابی

برای ارزیابی اثربخشی فرآیند شناسایی سوءاستفاده از هویت ابری، تعریف شاخص‌های کلیدی عملکرد (KPI) و معیارهای موفقیت ضروری است. این شاخص‌ها باید به‌گونه‌ای طراحی شوند که قابلیت‌های موجود در تکنیک‌های T1078 (حساب‌های معتبر) و T1087 (کشف حساب) را پوشش دهند. معیارها باید بر اساس داده‌های قابل استخراج از لاگ‌های احراز هویت و رویدادهای مرتبط با مدیریت هویت تعریف شوند و از افزودن معیارهای خارج از این چارچوب خودداری شود.

یکی از مهم‌ترین شاخص‌ها، زمان تشخیص (Time to Detect) است که فاصله زمانی بین وقوع رفتار مشکوک و شناسایی آن توسط سیستم نظارتی را اندازه‌گیری می‌کند. این معیار باید برای سناریوهای مختلف مرتبط با T1078 و T1087 تعریف شود؛ به عنوان مثال، تشخیص استفاده از حساب‌های غیرفعال یا تلاش برای شمارش حساب‌ها از طریق APIهای ابری. کاهش این زمان نشان‌دهنده بهبود توانایی تیم دفاعی در واکنش سریع به تهدیدات است.

نرخ مثبت کاذب (False Positive Rate) نیز از اهمیت بالایی برخوردار است. این معیار نشان می‌دهد چه نسبتی از هشدارهای صادرشده، در واقع تهدید واقعی نبوده‌اند. برای جلوگیری از خستگی تحلیلگران و کاهش نویز، لازم است این نرخ در سطح قابل قبولی نگه داشته شود. همچنین پوشش حساب‌ها (Account Coverage) به عنوان معیاری برای اطمینان از اینکه تمام حساب‌های کاربری و سرویس‌های ابری تحت نظارت قرار دارند، تعریف می‌شود. این پوشش باید شامل حساب‌های فعال، غیرفعال و حساب‌های سرویس باشد.

علاوه بر این، نرخ تشخیص (Detection Rate) نشان می‌دهد که چه نسبتی از رویدادهای واقعی سوءاستفاده توسط سیستم شناسایی شده‌اند. این معیار باید با استفاده از داده‌های تاریخی و شبیه‌سازی حملات کنترل‌شده اندازه‌گیری شود. همچنین، زمان پاسخ (Time to Respond) به عنوان معیاری برای سرعت واکنش تیم امنیتی به هشدارهای تأیید شده تعریف می‌شود. این شاخص‌ها باید به‌طور دوره‌ای بازبینی و با اهداف سازمان تنظیم شوند.

• زمان تشخیص: میانگین زمان بین اولین رویداد مشکوک (مانند ورود ناموفق یا شمارش حساب) و صدور هشدار.
• نرخ مثبت کاذب: نسبت هشدارهای اشتباه به کل هشدارهای صادرشده در بازه زمانی مشخص.
• پوشش حساب‌ها: درصد حساب‌های تحت نظارت نسبت به کل حساب‌های موجود در محیط ابری.
• نرخ تشخیص: نسبت رویدادهای واقعی سوءاستفاده که توسط سیستم شناسایی شده‌اند.

1. گام اول: تعریف خط مبنا برای رفتار عادی هر حساب بر اساس داده‌های تاریخی لاگ‌های احراز هویت.
2. گام دوم: پیاده‌سازی قوانین تشخیصی مبتنی بر T1078 و T1087، مانند هشدار برای ورود از مکان‌های غیرمعمول یا شمارش انبوه کاربران.
3. گام سوم: تنظیم آستانه‌ها برای کاهش مثبت کاذب و بهینه‌سازی زمان تشخیص.
4. گام چهارم: ارزیابی دوره‌ای شاخص‌ها و به‌روزرسانی معیارها بر اساس تغییرات محیط.

عملیاتی‌سازی و بهبود مستمر

برای بهره‌برداری مؤثر از لاگ‌های احراز هویت در شناسایی سوءاستفاده از هویت ابری (T1078) و کشف حساب‌ها (T1087)، لازم است فرآیند شناسایی به صورت عملیاتی در زیرساخت امنیتی سازمان یکپارچه شود. نخستین گام، متمرکزسازی و نرمال‌سازی لاگ‌های احراز هویت از تمام سرویس‌های ابری (مانند IaaS، SaaS و Identity Provider) در یک پلتفرم مدیریت اطلاعات و رویدادهای امنیتی (SIEM) است. این کار امکان جستجو، همبستگی و تحلیل متمرکز رویدادها را فراهم می‌کند. توصیه می‌شود که لاگ‌ها با حفظ صحت و یکپارچگی، به صورت بلادرنگ یا با تأخیر کم به SIEM ارسال شوند.

پس از یکپارچه‌سازی، باید قواعد تشخیصی (Detection Rules) متناسب با تکنیک‌های T1078 و T1087 طراحی و مستقر شوند. برای نمونه، قواعدی که الگوهای غیرعادی ورود با حساب‌های معتبر را شناسایی می‌کنند، مانند ورود از مکان‌های جغرافیایی غیرمنتظره، ورود در ساعات غیرکاری، یا استفاده از حساب‌های غیرفعال. همچنین برای T1087، قواعدی که فراخوانی‌های حجیم به APIهای فهرست‌سازی حساب‌ها (مانند ListUsers) یا پرس‌وجوهای غیرعادی از دایرکتوری را در یک بازه زمانی کوتاه تشخیص می‌دهند. این قواعد باید بر اساس محیط سازمان تنظیم شوند و از هشدارهای بیش از حد (False Positive) جلوگیری شود.

برای بهبود مستمر، فرآیند بازخورد باید بین تیم‌های امنیتی، عملیات فناوری اطلاعات و مالکان سرویس‌های ابری برقرار شود. هر رویداد شناسایی‌شده باید تحلیل و از نظر صحت و ارتباط با تهدیدات واقعی بررسی شود. نتایج این تحلیل‌ها باید برای به‌روزرسانی قواعد تشخیصی، تنظیم آستانه‌ها و اصلاح سیاست‌های دسترسی استفاده شود. همچنین توصیه می‌شود که به صورت دوره‌ای (مثلاً ماهانه) اثربخشی قواعد با استفاده از داده‌های تاریخی و سناریوهای شبیه‌سازی‌شده ارزیابی شود. این چرخه بازخورد به شناسایی شکاف‌ها در پوشش لاگ‌ها و بهبود دقت تشخیص کمک می‌کند.

در نهایت، آموزش مستمر تیم امنیتی و به‌روزرسانی دانش آن‌ها در مورد تکنیک‌های جدید حمله و روش‌های تشخیص ضروری است. همچنین، همکاری با تیم‌های عملیاتی برای اطمینان از اجرای صحیح اقدامات اصلاحی و پیشگیرانه اهمیت دارد. با این رویکرد، سازمان‌ها می‌توانند قابلیت‌های دفاعی خود را در برابر سوءاستفاده از هویت ابری تقویت کنند.

• استقرار قواعد تشخیصی برای T1078: شناسایی ورود با حساب‌های غیرفعال، ورود از IPهای پرخطر، و استفاده از توکن‌های معتبر در بازه‌های زمانی غیرعادی.
• استقرار قواعد تشخیصی برای T1087: شناسایی فراخوانی‌های حجیم به APIهای فهرست‌سازی حساب‌ها یا پرس‌وجوهای غیرعادی از دایرکتوری.
• تعیین آستانه‌های هشدار بر اساس رفتار پایه هر حساب و سرویس، و تنظیم دوره‌ای آن‌ها.

1. اتصال منابع لاگ احراز هویت (مانند CloudTrail، Azure AD Sign-in Logs، Okta System Log) به SIEM.
2. نرمال‌سازی فیلدهای کلیدی مانند شناسه کاربر، آدرس IP، زمان، و نوع رویداد.
3. طراحی و پیاده‌سازی قواعد تشخیصی اولیه بر اساس سناریوهای T1078 و T1087.
4. تست قواعد با داده‌های تاریخی و شبیه‌سازی حملات کنترل‌شده.
5. راه‌اندازی فرآیند بازخورد و به‌روزرسانی دوره‌ای قواعد.