پروژه تمام شده، اما نسخه آزمایشی سایت هنوز روی یک زیردامنه فعال است. وضعیت استفاده از آن روشن نیست و مسئول مشخصی هم برای به‌روزرسانی سرور وجود ندارد. از نگاه سازمان، این دارایی فراموش شده است؛ برای مهاجم، همچنان یک سرویس قابل بررسی در اینترنت است.
مدیریت سطح حمله به پیداکردن چنین فاصله‌هایی کمک می‌کند: تفاوت میان دارایی‌هایی که تصور می‌کنید تحت کنترل‌اند و مسیرهایی که واقعاً امکان دسترسی به سازمان را فراهم می‌کنند. ارزش آن زمانی مشخص می‌شود که کشف دارایی به تعیین مسئول، بررسی خطر و اقدام اصلاحی برسد.
مدیریت سطح حمله (ASM) چیست؟
مدیریت سطح حمله یا Attack Surface Management، فرایند مستمر شناسایی، ارزیابی و کاهش نقاطی است که مهاجم می‌تواند از آن‌ها برای دسترسی غیرمجاز، اثرگذاری بر سیستم یا استخراج اطلاعات استفاده کند. برنامه‌ها، سرویس‌ها، رابط‌های مدیریتی و مسیرهای تبادل داده می‌توانند بخشی از این سطح باشند. بررسی نیز به خود دارایی محدود نمی‌شود؛ مسیر دسترسی و کنترل‌های محافظ آن باید در نظر گرفته شوند.
سطح حمله سازمان فقط دارایی‌های اینترنتی نیست؛ سیستم‌ها و دسترسی‌های داخلی نیز بخشی از آن‌اند. وقتی تمرکز بر دارایی‌های قابل کشف و دسترسی از بیرون باشد، از اصطلاح مدیریت سطح حمله خارجی یا EASM استفاده می‌شود. بخش عمده مثال‌های این مقاله به همین محدوده مربوط است. پس از پیداکردن یک سرویس، هنوز چند سؤال باقی است: متعلق به چه کسی است، چرا در دسترس قرار دارد و آیا این وضعیت با نیاز فعلی سازمان سازگار است؟
مدیریت سطح حمله چه دارایی‌ها و نقاط ورودی را پوشش می‌دهد؟
دارایی‌های اینترنتی، سرویس‌های ابری و نقاط دسترسی خارجی
برای تعیین محدوده بررسی، فقط به سرورهای مستقر در سازمان نگاه نکنید. یک برنامه روی زیرساخت پیمانکار یا سرویسی در حساب ابری یک واحد سازمانی نیز ممکن است داده یا دسترسی مرتبط با کسب‌وکار را در اختیار داشته باشد. محل میزبانی، به‌تنهایی معیار کنارگذاشتن دارایی نیست.
در محدوده خارجی، معمولاً این موارد بررسی می‌شوند:
- دامنه‌ها، زیردامنه‌ها و رکوردهای DNS؛
- نشانی‌های IP عمومی و سرویس‌های قابل دسترسی؛
- وب‌سایت‌ها، برنامه‌های تحت وب و APIها؛
- درگاه‌های VPN و سایر مسیرهای دسترسی راه دور؛
- رابط‌های مدیریتی و منابع ابری در دسترس از اینترنت؛
- محیط‌های توسعه و آزمایشی منتشرشده در اینترنت.
ارتباط میان دامنه‌ها، میزبان‌ها، IPها و گواهی‌های دیجیتال می‌تواند سرنخ کشف دارایی‌های دیگر باشد. مستندات Microsoft Defender EASM نیز نگهداری انواع دارایی و ارتباط میان آن‌ها را توضیح می‌دهد. وجود یک وب‌سایت عمومی، به‌خودی‌خود مشکل امنیتی نیست. مسئله این است که آیا همان بخش‌هایی در دسترس‌اند که برای خدمت‌رسانی لازم‌اند، یا سرویس و رابط مدیریتی دیگری هم بدون ضرورت منتشر شده است.
دارایی‌های ناشناخته و مدیریت‌نشده سازمان
دارایی ناشناخته، لزوماً مخرب نیست. ممکن است تیمی برای یک پروژه، سرویس ابری تهیه کرده باشد و اطلاعات آن به فهرست مرکزی نرسیده باشد. در مقابل، دارایی مدیریت‌نشده می‌تواند کاملاً شناخته‌شده باشد، اما مسئول نگهداری یا برنامه اصلاح مشکلات نداشته باشد.
این دو وضعیت به اقدام یکسانی نیاز ندارند. برای دارایی ناشناخته، ابتدا ارتباط آن با سازمان و کاربردش را بررسی کنید؛ برای دارایی مدیریت‌نشده، مسئله اصلی تعیین مسئول و شرایط نگهداری است. راهنمای CIS نیز مدیریت دارایی را فراتر از ثبت موجودی می‌بیند و شناسایی و کنترل تجهیزات فیزیکی، مجازی، راه دور و ابری را در بر می‌گیرد.
البته نام مشابه یا میزبانی مشترک، مالکیت را ثابت نمی‌کند. ارتباط قدیمی با یک پیمانکار هم ممکن است دیگر معتبر نباشد؛ چنین مواردی تا زمان تأیید باید جدا از دارایی‌هایی نگهداری شوند که ارتباطشان با سازمان روشن است.
مدیریت سطح حمله چگونه انجام می‌شود؟
شناسایی و فهرست‌برداری مستمر دارایی‌ها
کار را با دامنه‌ها، محدوده‌های IP، حساب‌های ابری و دارایی‌های شناخته‌شده آغاز کنید. یافته‌های جدید را با سوابق زیرساخت، اطلاعات تیم‌های توسعه و قراردادهای مرتبط تطبیق دهید. پیش از ورود یک یافته به فهرست تأییدشده، باید شواهد کافی برای ارتباط آن با سازمان داشته باشید. پس از این تأیید، اطلاعاتی را ثبت کنید که رسیدگی به دارایی را ممکن می‌کنند: مسئول فنی، کاربرد، مسیر دسترسی و وابستگی آن به خدمات سازمان. اگر مسئول هنوز مشخص نیست، همین وضعیت باید در فهرست دیده شود تا تعیین تکلیف آن قابل پیگیری باشد.
جزئیاتی مانند زمان آخرین مشاهده و سابقه تغییر نشانی یا سرویس، به تشخیص تغییرات بعدی کمک می‌کنند. تکمیل همه این اطلاعات نباید بررسی یک دسترسی پرخطر را به تأخیر بیندازد. تناوب کشف نیز به سرعت تغییر زیرساخت بستگی دارد. سازمانی که مرتب سرویس ابری یا برنامه جدید منتشر می‌کند، با بازبینی سالانه تصویر قابل اتکایی از وضعیت فعلی نخواهد داشت. کشف مستمر و تکمیل موجودی از قابلیت‌های محوری ابزارهای EASM است.
ارزیابی نقاط مواجهه و اولویت‌بندی ریسک‌ها
منظور از «مواجهه» در این بحث، وضعیت در معرض دسترسی بودن دارایی است؛ از جمله اینکه چه کسی، از چه مسیری و با چه محدودیت‌هایی می‌تواند به آن برسد.
قابل دسترسی‌بودن یک سرویس، با قابل سوءاستفاده‌بودن آن یکسان نیست؛ اما برای ایجاد خطر نیز همیشه وجود یک آسیب‌پذیری شناخته‌شده لازم نیست. رابط مدیریتی به‌روز، اگر بی‌دلیل در دسترس عموم باشد، همچنان نیاز به بررسی دارد. CISA نیز برای رابط‌های مدیریتی اینترنتی، حذف دسترسی مستقیم از اینترنت یا حفاظت از مسیر دسترسی را توصیه کرده است.
برای تعیین ترتیب رسیدگی، این سه پرسش را کنار هم بگذارید:
- مهاجم از کجا و با چه پیش‌نیازی می‌تواند به دارایی برسد؟
- چه ضعف یا پیکربندی نامناسبی امکان سوءاستفاده ایجاد می‌کند؟
- نفوذ به آن چه داده، خدمت یا فرایندی را تحت تأثیر قرار می‌دهد؟
نشانه سوءاستفاده فعال، دسترسی بدون احراز هویت به اطلاعات حساس یا یک مسیر مستقیم به سیستم حیاتی، می‌تواند رسیدگی سریع‌تر را توجیه کند. مهلت اقدام را باید با توجه به شرایط واقعی سازمان تعیین کرد؛ امتیاز فنی یک یافته، به‌تنهایی برای این تصمیم کافی نیست.
برای مثال، یک محیط آزمایشی بدون اطلاعات حساس و جدا از تولید، با درگاه پشتیبانی متصل به سیستم‌های حیاتی هم‌وزن نیست. ممکن است رسیدگی به اولی در برنامه اصلاحات قرار گیرد، درحالی‌که دومی پیش از اصلاح کامل به محدودکردن فوری دسترسی نیاز داشته باشد.
اصلاح مشکلات و پایش تغییرات سطح حمله
در سناریوی ابتدای مقاله، نخست باید مشخص شود نسخه آزمایشی هنوز کاربردی دارد یا نه. اگر پروژه به آن نیاز ندارد، جمع‌آوری سرویس مطرح است. ادامه استفاده، تصمیم دیگری می‌طلبد: چه کسی نگهداری آن را بر عهده می‌گیرد و چه کسانی واقعاً باید به آن دسترسی داشته باشند؟
برای سایر یافته‌ها نیز نوع اقدام به علت خطر بستگی دارد. نصب وصله، اصلاح پیکربندی یا محدودکردن مسیر دسترسی باید به تیمی ارجاع شود که اختیار اجرای آن را دارد. اگر اصلاح اصلی زمان می‌برد، بررسی کنید آیا کنترل موقتی می‌تواند در فاصله انتظار، خطر را کاهش دهد.
بستن هر یافته به تأیید نتیجه اصلاح نیاز دارد. بسته‌شدن تیکت یا تغییر تنظیمات، به‌تنهایی ثابت نمی‌کند که مشکل برطرف شده است. مسیر مرتبط را دوباره بررسی کنید و تغییرات بعدی را زیر نظر بگیرید تا بازگشت سرویس یا ایجاد دسترسی مشابه پنهان نماند.
چرا مدیریت سطح حمله برای امنیت سازمان‌ها ضروری است؟
کنترل‌های امنیتی زمانی پوشش مؤثری دارند که دارایی در محدوده آن‌ها قرار گرفته باشد. سرویسی که در فهرست اسکن نیست، مسئول مشخص ندارد یا رویدادهایش جمع‌آوری نمی‌شوند، ممکن است با وجود ابزارهای حفاظتی سازمان، از فرایندهای معمول جا بماند.
واگذاری پروژه به پیمانکار، توسعه شعب و جابه‌جایی سرویس‌ها از موقعیت‌هایی هستند که این فاصله را ایجاد می‌کنند. پس از چنین تغییراتی باید پرسید: آیا محدوده حفاظت هنوز با زیرساخت واقعی سازمان مطابقت دارد؟
این پرسش در سطح برنامه هم مطرح است. تغییر یک API، افزودن رابط مدیریتی یا اتصال به سیستم دیگر می‌تواند نقاط ورود و خروج داده را تغییر دهد. OWASP توصیه می‌کند تغییرات سطح حمله در بررسی ریسک برنامه لحاظ شوند.
تفاوت مدیریت سطح حمله با مدیریت آسیب‌پذیری چیست؟
ASM بیشتر بر شناخت دارایی‌ها، مسیرهای مواجهه و تغییرات آن‌ها تمرکز دارد؛ مدیریت آسیب‌پذیری، ضعف‌های دارایی‌ها را شناسایی و تا مرحله اصلاح پیگیری می‌کند. این دو فرایند هم‌پوشانی دارند و ابزارهای مدیریت آسیب‌پذیری نیز ممکن است قابلیت کشف دارایی داشته باشند.
| مدیریت سطح حمله | مدیریت آسیب‌پذیری |
| چه دارایی‌ها و مسیرهایی در معرض دسترسی قرار دارند و کدام نیاز به اقدام دارند؟ | چه ضعف‌هایی در سیستم‌ها وجود دارد و چگونه اصلاح شوند؟ |
| تمرکز بر کشف دارایی، تأیید ارتباط آن با سازمان، ضرورت دسترسی و تغییرات آن | تمرکز بر ضعف‌های نرم‌افزاری، پیکربندی و اولویت اصلاح آن‌ها |
| خروجی شامل نقشه دارایی‌ها و مسیرهای دسترسی، مسئولیت‌ها و اقدامات است. | خروجی شامل یافته‌های آسیب‌پذیری و وضعیت رفع آن‌هاست. |
| از نتایج ارزیابی آسیب‌پذیری برای دقیق‌ترکردن اولویت‌ها استفاده می‌کند. | از دارایی‌های کشف‌شده در ASM برای تکمیل پوشش استفاده می‌کند. |
اگر فهرست دارایی‌های سازمان ناقص است، اجرای اسکن روی همان فهرست، به‌تنهایی شکاف پوشش را برطرف نمی‌کند؛ ابتدا باید محدوده بررسی تکمیل شود. وقتی دارایی شناسایی شده است، اما وضعیت ضعف‌های آن روشن نیست، ارزیابی آسیب‌پذیری اطلاعات لازم برای اصلاح را فراهم می‌کند.
گاهی هم نتیجه کشف، حذف دارایی است. سرور فراموش‌شده‌ای که دیگر کاربرد ندارد، ممکن است به جمع‌آوری نیاز داشته باشد، نه برنامه‌ای دائمی برای وصله‌کردن و نگهداری.
خروجی مدیریت سطح حمله برای تیم امنیت سازمان چیست؟
برای ارجاع اولیه یک یافته، باید روشن باشد کدام دارایی مطرح است، چه دسترسی یا وضعیت پرخطری مشاهده شده و چرا نیاز به رسیدگی دارد. شواهد فنی و زمان مشاهده نیز به تیم مسئول کمک می‌کنند وضعیت را بازبینی کند. اگر مسئول دارایی مشخص نیست، تعیین او باید بخشی از پیگیری باشد؛ یافته نباید به همین دلیل کنار گذاشته شود.
جدول زیر خروجی‌های موردنیاز برای پیگیری تا مرحله بسته‌شدن را نشان می‌دهد. بخشی از این اطلاعات، مانند مهلت اقدام و نتیجه بازبینی، در جریان رسیدگی تکمیل می‌شوند.
| خروجی | کاربرد برای تیم امنیت |
| فهرست دارایی‌ها همراه با شواهد ارتباط با سازمان | تفکیک دارایی‌های تأییدشده از مواردی که ارتباطشان با سازمان هنوز روشن نیست |
| شرح وضعیت مواجهه و مستندات فنی | مشخص‌کردن مسیر دسترسی و علت ایجاد خطر |
| مسئول فنی و مالک کسب‌وکار | ارجاع کار به فرد یا تیم دارای اختیار اصلاح |
| اولویت مستدل و مهلت اقدام | تعیین ترتیب رسیدگی بر اساس اثر و امکان سوءاستفاده |
| نتیجه بازبینی و سابقه تغییرات | تأیید رفع مشکل و تشخیص بازگشت آن |
برای سنجش پیشرفت، فقط تعداد دارایی‌های کشف‌شده را گزارش نکنید. افزایش این عدد ممکن است نتیجه بهترشدن دید سازمان باشد. تعداد یافته‌های پرریسک بدون مسئول، زمان تعیین تکلیف آن‌ها و مواردی که پس از اصلاح دوباره ظاهر شده‌اند، شاخص‌های پیشنهادی کاربردی‌تری هستند. در انتخاب ابزار نیز قابلیت کشف و ارزیابی سطح حمله خارجی را جداگانه بررسی کنید. کسپرسکی ماژول External Attack Surface را در سرویس Digital Footprint Intelligence معرفی کرده است. پیش از انتخاب، بررسی کنید قابلیت موردنیاز در پیشنهاد فنی و لایسنس شما گنجانده شده باشد.
برای بررسی راهکار متناسب با سطح حمله سازمان، با تیم راد سکیور تماس بگیرید. دامنه‌های اصلی، محیط‌های ابری و مسئله‌ای را که می‌خواهید برطرف کنید توضیح دهید تا درباره محدوده ارزیابی و راهکارهای مرتبط با نیازتان راهنمایی بگیرید.
