خلاصه برای تصمیم‌گیری
ارزش یک ارزیابی امنیتی خوب با تعداد ابزارهای اجراشده تعیین نمی‌شود؛ مهم این است که کدام ریسک با چه شواهدی روشن شده است. مجوز مکتوب، محیط کنترل‌شده و بررسی پس از اصلاح، یافته فنی را به تصمیمی قابل اجرا برای کسب‌وکار تبدیل می‌کند.
۱. هدف و مجوز آزمون از ابتدا روشن باشد
ابتدا پرسشی را که می‌خواهید پاسخ دهید مشخص کنید: آیا دو مشتری می‌توانند رکورد یکدیگر را ببینند؟ آیا عملیات مدیر قابل نظارت است؟ آیا دسترسی غیرضروری به رابط مدیریت شعبه وجود دارد؟ پرسش محدود و قابل اندازه‌گیری، یافته تیم آزمون را به کار مشخص توسعه‌دهنده یا مدیر شبکه مرتبط می‌کند. گزارش اسکن، بازبینی کد و تست نفوذ دامنه‌های متفاوتی دارند؛ در پرونده خرید آن‌ها را یک خدمت یکسان معرفی نکنید.
NIST SP 800-115 برنامه‌ریزی ارزیابی امنیت، تحلیل یافته و اقدامات اصلاحی را بررسی می‌کند؛ پیوست B یک الگوی آغازین برای قواعد اجرای کار ارائه می‌دهد. [1] در مجوز مکتوب باید مالک سامانه، دارایی‌های داخل دامنه، بازه زمانی، فعالیت مجاز، محدوده ممنوع، قواعد پردازش داده و مسئول توقف روشن باشند. اگر خدمت ابری یا شخص ثالث استفاده می‌شود، سیاست‌های آزمون همان ارائه‌دهنده نیز باید جداگانه بررسی شوند.
۲. آزمایشگاه آموزشی را از محیط عملیاتی جدا کنید
آزمایشگاه کنترل‌شده می‌تواند از دستگاه آزمون، برنامه هدف و اجزای مشاهده تشکیل شود. شبکه مجازی جدا و قواعد دسترسی باید مسیر رسیدن به سامانه‌های عملیاتی را مسدود کنند و اتصال بیرونی فقط به خدمات لازم محدود شود. دسترسی مدیریتی نیز باید جدا بماند. برچسب ماشین مجازی یا محدوده IP متفاوت به‌تنهایی ثابت نمی‌کند جداسازی کار می‌کند؛ مسیرهای مجاز و مسیرهایی که باید مسدود باشند، هر دو باید کنترل شوند.
برای آموزش می‌توان از برنامه‌هایی استفاده کرد که عمداً ضعف امنیتی دارند؛ OWASP Juice Shop یکی از این پروژه‌های آموزشی است. [2] پرکردن چنین هدفی با اطلاعات مشتری یا قراردادن آن روی سرور عملیاتی عمومی، طراحی مناسبی برای آزمایشگاه نیست. محیطی زیر مدیریت خودتان با دسترسی محدود ایجاد کنید. مهارت حاصل از آموزش، مجوز آزمون سامانه اشخاص ثالث محسوب نمی‌شود. این راهنما نیز دستورالعمل آزمون اهداف بیرونی ارائه نمی‌کند.
۳. داده و هویت‌ها متعلق به آزمایشگاه باشند
با رکورد مصنوعی مشتری، سفارش و کاربر کار کنید. اگر داده واقعی ضروری است، از روش تأییدشده مسئول داده سازمان و دامنه دسترسی محدود استفاده کنید؛ هرجا ممکن است داده را ماسک یا کمینه کنید. کلید API، گذرواژه و اطلاعات پرداخت محیط عملیاتی نباید به نسخه آزمایشی منتقل شوند. مالک، نقش و زمان بسته‌شدن حساب‌هایی که برای آزمون باز می‌شوند باید مشخص باشد.
برای بررسی مجوزها، حساب‌هایی با نقش متفاوت و مشتریان نمونه متفاوت لازم است. رویکرد آزمون مجوز OWASP کمک می‌کند دسترسی مورد انتظار میان نقش‌ها و عملیات در ماتریسی روشن جمع‌آوری شود. [3] برای نمونه، اگر یک نقش فقط باید رکورد خود را بخواند، نتیجه آزمون و رخداد متناظر در گزارش برنامه با هم ثبت می‌شوند. هدف، به‌دست‌آوردن اطلاعات فرد واقعی نیست؛ باید با داده کنترل‌شده سنجید مرز تعریف‌شده عمل می‌کند یا نه.
۴. وضعیت آغازین و مشاهده تکرارپذیر ایجاد کنید
نسخه برنامه، تنظیمات، داده آزمون و قواعد شبکه را در ثبت وضعیت آغازین بیاورید. باید مشخص باشد پس از پایان آزمایش، محیط چگونه به وضعیت پاک بازمی‌گردد. تصویر لحظه‌ای می‌تواند کمک کند، اما ممکن است وضعیت خدمات بیرونی یا مخازن داده متصل را خودکار بازنگرداند. برنامه بازگردانی باید همه وابستگی‌های سامانه تحت بررسی را پوشش دهد.
از گزارش‌هایی با زمان هماهنگ، ثبت عملیات و در صورت نیاز تصویر شواهد با حداقل اطلاعات حساس استفاده کنید. فایل شواهد باید فقط در دسترس تیم مجاز باشد و دوره نگهداری و مسئول حذف مشخص شوند. معیار توقف را کاربردی انتخاب کنید: مشاهده اتصال غیرمنتظره به محیط عملیاتی، داده خارج از دامنه یا اثر غیرقابل قبول بر خدمت باید کار را متوقف کند و به مسئول اطلاع داده شود. مشاهده منظم، هم امنیت آزمون و هم فهم آن پس از پایان را بهتر می‌کند.
۵. یافته، اصلاح و آزمون دوباره در یک زنجیره باشند
راهنمای آزمون امنیت وب OWASP آزمون امنیت را به چرخه توسعه مرتبط می‌کند؛ یک ابزار همه مسائل امنیتی را پوشش نمی‌دهد. [4] در گزارش فقط درجه اهمیت ننویسید؛ جریان کاری متأثر، پیش‌شرط، نتیجه مشاهده‌شده و کنترل پیشنهادی را توضیح دهید. خلاصه مدیریتی باید تصمیم‌گیری را آسان کند و پیوست فنی باید به‌اندازه‌ای روشن باشد که تیم مجاز بتواند یافته را دوباره ارزیابی کند.
پس از اصلاح، همان پرسش را از نسخه جدید بپرسید و بررسی کنید جریان عادی کاربر نیز مختل نشده باشد. تعیین مسئول، تاریخ هدف و معیار پذیرش برای هر یافته مانع بایگانی‌شدن صرف گزارش می‌شود. موفقیت در آزمایشگاه به معنای حذف همه ریسک‌های محیط عملیاتی نیست؛ تفاوت محیط‌ها را گزارش کنید. هنگام ارزیابی طراحی شبکه و دسترسی با MyFi Business، نیاز اتصال، جداسازی و هماهنگی فنی محیط آزمون نیز می‌تواند جداگانه تعریف شود.
۶. پیش از آغاز کار بررسی کنید
کار فنی نباید پیش از آماده‌شدن موارد زیر آغاز شود. اگر موردی تغییر کرد، مسئول دامنه و تیم اجرا باید از یک سند به‌روز مشترک استفاده کنند.
- مجوز مکتوب، فهرست دارایی، بازه زمانی و مسئول توقف موجود است؟
- شرایط خدمات ابری و اشخاص ثالث بررسی شده است؟
- دسترسی آزمایشگاه به محیط عملیاتی و مقصدهای بیرونی غیرضروری محدود شده است؟
- داده مصنوعی، حساب آزمایشی جدا و تنظیمات آغازین آماده‌اند؟
- مسئول دسترسی به شواهد، نگهداری، پاک‌سازی و بازگردانی مشخص است؟
- گزارش، اصلاح و تحویل نتیجه آزمون دوباره صریحاً در دامنه آمده‌اند؟
منابع و اسناد
نیاز ارتباطی‌تان را به یک درخواست روشن تبدیل کنیم.
یک نقطه تماس برای گزینه‌های اتصال و تیم‌های درگیر. نیاز فنی، شرایط تجاری و مراحل اجرا را به برنامه‌ای روشن و قابل پیگیری تبدیل می‌کنیم.
درخواست پیشنهاد سازمانی