رسم الخدمات وسياق المخاطر

لا يبدأ تحليل المخاطر بقائمة برمجيات. يبدأ بالسؤال: أي وعد تقدمه المؤسسة للعميل، وما الذي ينبغي أن يستمر لتفي به؟ لنفترض أن شركة توصيل تعد بإظهار حالة الطرد خلال ساعة. تعتمد هذه الخدمة على تطبيق العميل، وواجهة ربط مع شركة النقل، وقاعدة طلبات، ومزود رسائل. تعطل الرسائل قد يؤخر الإشعار لكنه لا يوقف تسليم الطرد؛ فساد قاعدة الطلبات قد يربك توجيه الشحنة نفسه. لذلك لا تكفي عبارة «النظام حرج»؛ اكتب مسار الخدمة وحدد أين يختلف أثر فقد التوافر عن أثر فقد سلامة البيانات أو سريتها.

في بداية الورشة، اطلب من مالك الخدمة وصف نتيجة العمل التي يهمه حمايتها، لا أسماء الخوادم فقط. ارسم تدفقًا بسيطًا: طلب العميل ← قاعدة الطلبات ← واجهة الناقل ← تحديث الحالة ← إشعار العميل. ضع عند كل وصلة مالكها وطريقة التحقق منها ومصدرًا بديلاً إن وجد. اسأل أين تعبر البيانات حدود مؤسسة أخرى، ومن يملك صلاحية تغييرها، وأي اعتماد مشترك يجعل عدة خدمات تتعطل معًا. هذه الخريطة نموذج قرار مؤقت؛ لا تزعم أنها جرد أصول كامل. وظيفة Identify في NIST CSF 2.0 تساعد على فهم الأصول والمخاطر، بينما Govern يربط هذا الفهم بالأهداف والأدوار واستراتيجية المخاطر.

اتفق على معايير أثر قبل رؤية ألوان مصفوفة الخطر. مثال افتراضي: أثر مرتفع إذا تعذر توجيه أكثر من 20% من شحنات يوم العمل أو فقدت سلامة عناوين التسليم؛ أثر متوسط إذا تأخر إشعار الحالة أكثر من ساعتين دون ضياع البيانات؛ وأثر منخفض إذا تأخر تقرير داخلي يمكن استعادته في اليوم التالي. هذه عتبات اختارتها المؤسسة في الحالة، وليست عتبات NIST أو معيارًا عامًا. وثّق مصدرها: حجم العمليات، التزامات الخدمة، خبرة مالك الخدمة، وحدود الموازنة. وإذا اختلف التسويق والعمليات حول أثر التأخير، دوّن الاختلاف بدل إخفائه في رقم متوسط.

المخرَج خريطة خدمة من صفوف مترابطة: «تحديث الحالة» يعتمد على واجهة الناقل وقاعدة الطلبات؛ «تعديل الموعد» يعتمد على إشعار العميل وقناة الرد؛ «تأكيد التسليم» يعتمد على بيانات السائق وواجهة الناقل. لكل صف أثر فقد التوافر، وأثر فقد السلامة، ودليل الاعتمادية، ومالك يؤكد التفسير. يترك المستشار خانة «فاعلية البديل» غير محسومة إلى أن يظهر اختبار حديث. إن نجح اختبار التحويل واستطاع العملاء تعديل الموعد عبر البريد بمعدل مقبول، تنخفض أولوية الاستثمار في مزود رسائل ثانٍ. إن فشل التحويل، تصبح تلك الأولوية أعلى. أما خطر فساد العنوان في قاعدة الطلبات فلا يتغير بسبب نجاح البريد؛ فصل السيناريوهات يمنع علاج المشكلة الخطأ.

لا تخلط بين «خريطة يعتمد عليها التحليل» و«حقيقة دائمة». بعد إطلاق ميزة جديدة أو تغيير واجهة الناقل، قد تتغير الاعتماديات. حدد صاحب مراجعة الخريطة وحدثها عند تغير معماري مؤثر، لا كلما تحرك رمز في رسم. عند مقابلة الفرق، ابدأ بإثبات المسار الأساسي ثم اختبر الحالات التي يكسر فيها افتراض واحد: ماذا يحدث إذا تعذر إرسال الإشعار لكن بقيت الطلبات سليمة؟ ماذا يحدث إذا وصل إشعار صحيح إلى عنوان خاطئ؟ هذا التفكير يكشف أن السرية والسلامة والتوافر ليست درجات متبادلة، بل نتائج مختلفة تتطلب قرارات مختلفة.

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