العميل يريد التقرير بالإنجليزية، كيف نجهّز وثائق إدارة الثغرات؟

لدى العملاء المؤسسيين، لجان التدقيق تحديدًا تنظر إلى الصيغ الإنجليزية الموحّدة أكثر من اللغة المحلية. إياك أن تقع في خطأ الكتابة بالتركية ثم الإرسال إلى مكتب ترجمة؛ فمترجم لا يعرف المصطلحات التقنية قد يجعل شروح الثغرات غير معروفة. يجب أن يعتاد الفريق على التوثيق بالإنجليزية مباشرة.

عند إعداد التقرير أنصحك بالالتزام الكامل بهذه المعايير الخمسة: 1) الملخص التنفيذي يجب أن يكون قائمًا على المخاطر، 2) كل نتيجة يجب أن تحمل سلسلة متجه CVSS الرسمية، 3) خطوات Proof of Concept تُعرض بوضوح مع لقطات الشاشة، 4) اقتراح الحل يجب ألا يكون توصية عامة بل يتضمن أمرًا أو تصحيحًا برمجيًا قابلًا للتطبيق، 5) الإشارة إلى أرقام CWE وCVE ذات الصلة.

تعديل: كتبت خطأً أعلاه، أرجو المعذرة.

أكثر موضع يكثر فيه الخطأ في المصطلحات هو تصنيف المخاطر. بدل أن تقول من تلقاء نفسك متوسط أو مرتفع، حدّد بوضوح معاملات CVSS Base Score وTemporal Score. مثلًا إبقاء مكوّنات المتجه مثل Attack Vector: Network أو Privileges Required: Low بصيغتها الأصلية في النص الإنجليزي يسهّل عمل المدقق كثيرًا.

واجهنا طلبًا مشابهًا العام الماضي وأعطينا التقرير التركي في البداية لترجمة تقنية احترافية. بلغت تكلفة ترجمة تقرير واحد من 40 صفحة 850 يورو، وأمضى فريقنا يومين كاملين في تصحيح أخطاء المصطلحات. بعدها انتقلنا إلى قالب أمني إنجليزي جاهز، وطالت مدة إعداد التقارير قليلًا في البداية لكن التكلفة صارت صفرًا.

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

المديرون عمومًا لا يقرؤون التفاصيل التقنية أصلًا. لما تحط في الصفحة الأولى رسمًا ملوّنًا لتوزيع المخاطر وملخصًا تنفيذيًا نظيفًا من 3 فقرات، يقتنع الإدارة عند العميل فورًا، والتفاصيل الأدنى يفحصها فريقهم التقني بنفسه.

يجب الانتباه إلى اتفاقية السرية وبروتوكولات أمن البيانات الموقّعة مع العميل. نقل الوثائق الحساسة التي تتضمن ثغرات أمنية ونقاط ضعف في الأنظمة إلى أدوات ذكاء اصطناعي تابعة لطرف ثالث أو مزوّدي خدمات خارجيين بغرض الترجمة قد يخلق مخاطر قانونية؛ يجب إعداد كل الوثائق داخل بيئة آمنة في الشركة.

هل يجب أن نبلّغ في التقرير الإنجليزي عن كل خطأ تكوين صغير نرصده؟ أم يكفي كتابة النتائج الحرجة والمرتفعة فقط التي درجة CVSS فيها 7 فأعلى؟

أنا مشروع صغير، دعوني أشرح من منظوري. إذا كانت قناة الإشعارات طويلة، فلن تصل الإشعارات؛ والإشعار غير الواصل يعني حدثًا يُكتشف متأخرًا.

بالطبع يختلف الأمر إذا كانت حالتك مختلفة.

سأتحدث من الطرف الآخر، فأنا من جانب الموردين. عند اتخاذ القرار، اكتب أسوأ سيناريو أيضًا، وليس الأفضل فقط.

هذا كل شيء، أرجو المعذرة إذا أطالت.

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

بالتوفيق.

دعني أوضح الجانب التقني قليلاً. معظم إضاعة الوقت تتراكم في المهام المنتظرة للموافقة.

مثبت بالتجربة.

هناك نقطة أثارت فضولي. إذا قمت بتوبيخ الإنذارات الكاذبة، فلن يقوم أحد بالإبلاغ مرة أخرى.

أتمنى أن يفيدك هذا.

إذا كنت ستسلك هذا المسار، فحل هذه المشكلة من البداية. يعني معظم إضاعة الوقت تتراكم في المهام المنتظرة للموافقة.

كل بند غير مكتوب هو بند سيتذكره الطرفان بشكل مختلف لاحقًا.

مررت بهذا الطريق، دعني أشرح. محاولة فعل هذا بمفردك هي أغلى الطرق.

صححوا لي إن أخطأت.

أعتقد أن الحديث بهذه القطعية في جانب إدارة الثغرات بالإنجليزية صعب. بيئات الاختبار المنسية تصبح ثغرات أمنية أكثر تكرارًا من الأنظمة الحية.

بالطبع يختلف الأمر إذا كانت حالتك مختلفة.

بعد تجربة ذلك، تغيرت نظرتي للأمور. الأمان ليس مطلقاً؛ بل يعني جعل الهجوم غير مجدٍ من حيث الجهد.

بالطبع يختلف الأمر إذا كانت حالتك مختلفة.

سأتحدث من الطرف الآخر، فأنا من جانب الموردين. القرار المتسرع يصبح قراراً يُصحح بعد ستة أشهر.

محاولة فعل هذا بمفردك هي أغلى الطرق. دعني أتركها كملاحظة، قد تكون مفيدة.