👆👆چطور تولید کنندگان معتبر دنیای IT هم با اصول ISSAP فاصله دارند ؟


از منظر معماری امنیت در ISSAP، می‌توان دو انتخاب تاریخی ویندوز را نقد کرد؛ البته ISSAP استاندارد طراحی سیستم‌عامل نیست و تعبیر «مغایرت با اصول معماری امنیت» دقیق‌تر است.
نمونه ای از رفتار مایکروسافت که مغایر متن درسی ISSAP است.

❇️ حفاظت ناکافی از اسرار احراز هویت: در معماری سنتی ویندوز، اسراری مانند هش NTLM و بلیت‌های Kerberos در حافظه فرایند LSASS نگهداری می‌شدند. مهاجمی که دسترسی ممتاز و امکان خواندن این حافظه را کسب می‌کرد، می‌توانست با ابزارهایی مانند Mimikatz اعتبارنامه‌ها را استخراج کند. نقد معماری، صرفاً وجود یک ابزار حمله نیست؛ مسئله این است که تسلط بر محیط اجرایی سیستم‌عامل می‌توانست به تسلط بر اسرار هویتی تبدیل شود. این وضعیت با اصول جداسازی، دفاع در عمق و محدودسازی دامنه اعتماد تناقض دارد. در نسخه های جدید ویندوز ، Credential Guard با جداسازی اسرار منتخب در محیط مبتنی بر مجازی‌سازی، این ضعف را کاهش می‌دهد.

❇️اختیار گسترده سرویس‌ها با LocalSystem: این حساب اختیارات بسیار بالایی دارد؛ بنابراین آسیب‌پذیری یک سرویس تحت آن می‌تواند پیامدی فراتر از همان سرویس ایجاد کند. از نگاه معماری، اجرای کاری محدود با چنین اختیاراتی، اصل حداقل اختیار و مهار دامنه خسارت را تضعیف می‌کند. خود مایکروسافت تصریح می‌کند بیشتر سرویس‌ها به این سطح اختیار نیاز ندارند. البته انتخاب LocalSystem برای سرویس‌های غیرضروری، غالباً تصمیم توسعه‌دهنده یا پیکربندی است؛ وجود این قابلیت به‌تنهایی نقض اصل محسوب نمی‌شود اما مطلبی قابل تامل است .


** مطالبی در باب آشنایی با دوره و مدرک ISSAP
معماری ارشد امنیت اطلاعات

Comments

Be the first to add a comment