چگونه یک ریسک بنویسم که کسب‌وکار بر اساس آن اقدام کند؟

اکثر یافته‌های امنیتی در صفحه گسترده می‌میرند چون برای افراد دیگر امنیت نوشته شده‌اند، نه برای کسی که بودجه را تایید می‌کند. اگر گزارش شما بگوید «CVE-2023-XXXX، CVSS 9.8، فوراً پچ کنید»، شما آسیب‌پذیری را توصیف کرده‌اید، نه ریسک. کسب‌وکار بر اساس آسیب‌پذیری اقدام نمی‌کند. بر اساس پیامدهایی که می‌تواند تصور کند اقدام می‌کند.

چرا امتیازات شدت تنهایی هیچ‌کس را متحرک نمی‌کند

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

ریسکی که بر اساس آن اقدام می‌شود سه عنصر دارد: مسیر معقولی برای تأثیر، هزینه‌ای به تومان یا عملیاتی که به آن تأثیر متصل است، و صاحبی که می‌تواند واقعاً آن را تصحیح کند. اگر از یکی از اینها صرف‌نظر کنید، یافته در backlog می‌نشیند.

یافته را بر اساس یک سناریو بسازید، نه خروجی scanner

به جای «SQL injection در /login endpoint یافت شد»، سناریو را بنویسید: «یک مهاجم بدون احراز هویت می‌تواند جدول کامل مشتری را از جمله رمزهای عبور هشمند و آدرس‌های صورتحساب از طریق فرم ورود استخراج کند. این جدول 40000 حساب فعال را پشتیبانی می‌کند و همان دیتابیس تاریخچه سفارش را در محدوده PCI نگه می‌دارد.» اکنون خواننده یک کلاس آسیب‌پذیری را تجزیه نمی‌کند، بلکه نامه اطلاع‌دهی نقض و تماس compliance را تصور می‌کند.

ساختار مفید برای هر یافته:

• چه اتفاقی می‌تواند بیفتد — مسیر حمله به زبان ساده، یک یا دو جمله.
• چه چیزی را تحت تأثیر می‌دهد — سیستم خاص، داده خاص، فرایند تجاری خاص.
• هزینه آن چقدر است — ساعت‌های downtime،노출نظارتی، اعتماد مشتری، پنالتی‌های قراردادی. جایی که دارید از اعداد واقعی استفاده کنید (شرط‌های پنالتی SLA، هزینه‌های حادثه‌ای گذشته، قابل‌کسر بیمه سایبر).
• تصحیح آن چه زمانی می‌برد — تلاش، نه فقط «پچ کنید.» گاهی تصحیح یک WAF rule امروز و یک تغییر کد در sprint بعدی است.
• مالک تصحیح کیست — یک نام یا یک تیم، نه «IT».

یافته را به چیزی که کسب‌وکار پیگیری می‌کند متصل کنید

هر شرکتی معیاری دارد که رهبری پیگیری می‌کند: SLA‌های uptime، churn، یافته‌های حسابرسی از آخرین چرخه SOC 2، پریمیوم بیمه سایبر، یک قرارداد مشتری خاص با شرط امنیتی. اگر بتوانید یافته خود را به یکی از آن خطوط موجود متصل کنید — «این همان نوع مسئله‌ای است که بیمه‌گر ما در آخرین تجدید بررسی کرد» یا «این جریان داده در محدوده حسابرسی SOC 2 در Q3 است» — شما از آنها نمی‌خواهید درباره چیز جدیدی نگران باشند. شما یک تهدید به چیزی را نشان می‌دهید که آنها قبلاً مسئول آن هستند.

این جایی است که صحبت با سمت کسب‌وکار قبل از نهایی کردن گزارش بازده داده‌های بسیاری را دارد. یک مکالمه ده‌دقیقه‌ای با finance یا ops درباره‌ی اینکه یک outage چهار ساعته بر روی یک سیستم خاص واقعاً چقدر هزینه دارد، بهتر از هر خط «آسیب به شهرت» عمومی است. عدد را بگیرید، استناد کنید، ادامه دهید.

بر اساس قابل‌بهره‌برداری و blast radius رتبه‌بندی کنید، نه فقط CVSS

روش تأولویت‌بندی قابل‌استفاده:

1. آیا قابل‌دسترسی از اینترنت است یا ابتدا به دسترسی داخلی نیاز دارد؟
2. آیا exploit عمومی وجود دارد یا نظری است؟
3. آیا داده‌های تنظیمی را تحت تأثیر می‌دهد (PCI، PHI، PII) یا سیستم‌های crown-jewel را؟
4. هزینه و زمان واقعی اصلاح در مقابل هزینه رهاشدن آن چیست؟

یافته‌هایی که امتیاز بالایی در reachability و blast radius دارند اما فقط امتیاز متوسط در CVSS گاهی شایسته‌تر از bug critical-rated هستند که سه hop شبکه پشت یک jump box با MFA گم شده‌اند.

درخواست را بنویسید، نه فقط مسئله

هر یافته را با درخواست خاصی پایان دهید: یک خط بودجه، یک change window، یک استثنای سیاست برای بستن، یا یک تصمیم نام‌گذاری‌شده که به یک تاریخ نیاز است. «ما اصلاح را توصیه می‌کنیم» نادیده گرفته می‌شود. «ما به یک پنجره نگهداری چهار ساعته قبل از 15th برای پچ درگاه پرداخت نیاز داریم، یا ریسک باقی‌مانده را به صورت کتبی می‌پذیریم» یک تصمیم را به یک طرف یا طرف دیگر وادار می‌کند. رهبری را با یک گزینه accept-the-risk صریح، به صورت کتبی، با نام آنها بر روی آن، اغلب آنچه در نهایت تصحیح را تایید می‌کند.

اگر می‌خواهید خروجی scan خام را به یافته‌هایی مثل این تبدیل کنید، بخش‌های Blue Team و Offensive در Korra Studio را با هم کار کنید — جفت کردن زمینه بهره‌برداری با drills گزارش‌دهی جایی است که این مهارت واقعاً تیز می‌شود.