كيف أكتب نتيجة مخاطر ستتخذ الشركة إجراءً بشأنها؟

معظم النتائج الأمنية تموت في جدول بيانات لأنها مكتوبة لأشخاص أمنيين آخرين، وليس للشخص الذي يوافق على الميزانية. إذا قال تقريرك "CVE-2023-XXXX، CVSS 9.8، طبّق الرقعة على الفور," فقد وصفت ثغرة أمنية، وليس خطراً. الشركة لا تتصرف بناءً على الثغرات الأمنية. تتصرف بناءً على العواقب التي يمكنها تصورها.

لماذا درجات الشدة وحدها لا تحرك أحداً

CVSS يخبرك كم تكون الثغرة سيئة بمعزل عن السياق. لا يقول شيئاً عما إذا كانت الثغرة قابلة للوصول، أو ما إذا كان الأصل خلفها مهماً للإيرادات، أو ما إذا كانت الضوابط التعويضية قد خففتها بالفعل. درجة 9.8 على صندوق تطوير داخلي بدون مسار إنترنت وبدون بيانات حساسة ليست نفس المحادثة مثل 7.5 على بوابة الدفع. إذا صنفت النتائج حسب CVSS فقط، فستنفق مصداقيتك في وضع رقع للأشياء التي لم يكن أحد سيستغلها أبداً، والنتيجة التي أهمت فعلاً تضيع وسط الضجيج.

المخاطر التي يتم التصرف بناءً عليها لها ثلاثة مكونات: مسار معقول للتأثير، تكلفة بالدولار أو التشغيل المرتبطة بهذا التأثير، ومالك يمكنه فعلاً إصلاحها. إذا فاتك أي واحد من هذه، فإن النتيجة تجلس في المراجعة.

بناء النتيجة حول سيناريو، لا مخرجات الماسح

بدلاً من "وجدنا SQL injection على /login endpoint," اكتب السيناريو: "يمكن لمهاجم غير مصرح الوصول إلى جدول العملاء الكامل، بما في ذلك كلمات المرور المجزأة وعناوين الفواتير، من خلال نموذج تسجيل الدخول. يدعم هذا الجدول 40,000 حساب نشط وتحتفظ قاعدة البيانات ذاتها بسجل الطلبات المرتبط بـ PCI scope." الآن القارئ لا يقتصر على تحليل فئة ثغرة أمنية، بل يتخيل رسالة إخطار انتهاك وجرس الامتثال.

هيكل مفيد لكل نتيجة:

• ما يمكن أن يحدث — مسار الهجوم باللغة العادية، جملة أو جملتان.
• ما تلمسه — النظام المحدد، البيانات المحددة، العملية التجارية المحددة.
• ما تكلفته — ساعات التوقف، التعرض التنظيمي، ثقة العملاء، العقوبات التعاقدية. استخدم أرقاماً حقيقية حيث تتوفر (فقرات عقوبات SLA، تكاليف الحوادث السابقة، خصم التأمين الإلكتروني).
• ما يستغرقه الإصلاح — الجهد، وليس فقط "طبّق الرقعة." أحياناً يكون الإصلاح قاعدة WAF اليوم وتغيير الكود في السباق التالي.
• من يمتلك الإصلاح — اسم أو فريق، لا "تقنية المعلومات."

ربط النتيجة بشيء تتبعه الشركة بالفعل

كل شركة لديها مقاييس تراقبها القيادة بالفعل: SLAs للعمل المستمر، معدل الخسارة، نتائج التدقيق من آخر دورة SOC 2، أقساط التأمين الإلكتروني، عقد عميل محدد به بند أمان. إذا استطعت ربط نتيجتك بأحد هذه الخطوط الموجودة — "هذه نفس فئة المشكلة التي أشار إليها مؤمننا عند آخر تجديد" أو "تدفق البيانات هذا ضمن نطاق SOC 2 audit في Q3" — فأنت لا تطلب منهم الاهتمام بشيء جديد. أنت تريهم تهديداً لشيء هم بالفعل مسؤولون عنه.

هذا أيضاً حيث يؤتي التحدث مع جانب الشركة ثماره قبل أن تنهي التقرير. محادثة لمدة عشر دقائق مع التمويل أو العمليات حول ما يكلفه انقطاع لمدة أربع ساعات على نظام محدد يتفوق على أي سطر عام "ضرر سمعة." احصل على الرقم، استشهد به، تحرك.

صنف حسب قابلية الاستغلال ونطاق التأثير، وليس فقط CVSS

نهج تحديد الأولويات القابل للعمل:

1. هل يمكن الوصول إليها عبر الإنترنت أم تتطلب الوصول الداخلي أولاً؟
2. هل هناك استغلال عام أم أنه نظري؟
3. هل تلمس بيانات منظمة (PCI، PHI، PII) أو أنظمة المجوهرات الملكية؟
4. ما هو الوقت الفعلي وتكلفة المعالجة مقابل تكلفة تركها؟

النتائج التي تسجل درجات عالية في الوصول ونطاق التأثير ولكن فقط درجة متوسطة على CVSS غالباً ما تستحق القفز على قائمة الانتظار على مقابل خطأ حرج مدفون ثلاث قفزات شبكة خلف صندوق قفز مع MFA.

اكتب الطلب، لا المشكلة فقط

أنهِ كل نتيجة بطلب محدد: سطر ميزانية، نافذة تغيير، استثناء سياسة للإغلاق، أو قرار مسمى مطلوب بحلول تاريخ. "نوصي بالمعالجة" يتم تجاهله. "نحتاج إلى نافذة صيانة لمدة أربع ساعات قبل الـ 15 للرقعة على بوابة الدفع، أو نقبل بالخطر المتبقي كتابياً" يفرض قراراً بطريقة أو أخرى. إعطاء القيادة خياراً صريحاً بقبول الخطر، كتابياً، مع وضع اسمهم عليه، غالباً ما يكون هو ما يحصل أخيراً على الموافقة على الإصلاح بدلاً من ذلك.

إذا كنت تريد ممارسة تحويل مخرجات الماسح الخام إلى نتائج مثل هذه، فقم بالعمل من خلال أجزاء Blue Team و Offensive الخاصة بـ Korra Studio معاً — إن إقران سياق الاستغلال مع تدريبات الإبلاغ هو حيث يتحدد هذا المهارة فعلاً.