ارزیابی آسیب‌پذیری یا تست نفوذ؟

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

نسخه‌ی یک‌جمله‌ای

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

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

کار واقعاً چه تفاوتی دارد

مهم‌ترین سطر، بهره‌برداری است. ارزیابی تأیید می‌کند که ضعفی وجود دارد؛ تست ثابت می‌کند به کجا می‌انجامد. یک هدر امنیتی غایب و یک نقص مجوزدهی در سطح شیء، هر دو در ارزیابی به‌عنوان یافته ظاهر می‌شوند. فقط تست نشان می‌دهد که دومی سوابق همه‌ی مشتریان را افشا می‌کند، و همین جمله است که هیئت‌مدیره به آن نیاز دارد.

یک ضعف، دو گزارش

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

ارزیابی، پس از اینکه ابزار نقطه‌ی پایانی را علامت زد و یک نفر آن را تأیید کرد:

[High] Object-level authorisation not enforced (verified manually)
Endpoint:  GET /api/v1/orders/{id}   host: api.shop.example
Evidence:  order 10453 belongs to customer B; customer A's session got 200
Fix:       check on the server that the order belongs to the caller

تست نفوذ، با هدفی که از پیش توافق شده («خواندن داده‌ی مشتری دیگر بدون حساب او») و اندازه‌ی نمونه‌ای که قواعد تعامل اجازه داده است:

Goal     read another customer's personal data without their account
Step 1   signed in as test customer A; order ids are sequential
Step 2   GET /api/v1/orders/10453 with A's session -> 200, customer B's order
Step 3   each order carries the customer's name, address and phone number
Step 4   50 consecutive ids in the agreed sample -> 50 different customers
Impact   any signed-in customer can read every customer's contact details
Cause    the API checks that a session exists, not who owns the order

هر دو درست‌اند. اولی به توسعه‌دهنده می‌گوید چه چیزی را رفع کند. دومی به هیئت‌مدیره می‌گوید چه چیزی، و برای چند نفر، در خطر بود؛ و همین سطر است که رفع را به بالای صف می‌برد.

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

هر کدام برای چه کاری است

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

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

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

سه اشتباه رایج در خرید

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

قیمت را چگونه بخوانید

ارزیابی بر اساس گستره قیمت می‌خورد: تعداد میزبان، IP، برنامه. تست نفوذ بر اساس زمان: روزهای کاری یک فرد مشخص روی یک هدف تعریف‌شده. اگر پیشنهاد «تست نفوذ» به ازای هر میزبان قیمت خورده، یا پیشنهاد «ارزیابی» روزشمار و با یک هدف است، فروشنده دارد آن یکی خدمت را توصیف می‌کند. بخواهید نامش را درست کنند و بعد مثل با مثل مقایسه کنید.

یک قاعده برای این فصل

اگر هنوز نمی‌توانید سامانه‌های رو به اینترنت‌تان را با نسخه‌هایشان فهرست کنید، ارزیابی بخرید. اگر می‌توانید، و یکی از آن‌ها قرار است پول، هویت یا داده‌ی تحت مقررات را حمل کند، برای همان یکی تست بخرید. تقریباً هیچ‌کس به تست نفوذِ همه‌چیز نیاز ندارد؛ تقریباً همه به ارزیابیِ همه‌چیز و تست نفوذِ دو سه چیزی که مهم است نیاز دارند.