قضية إساءة استخدام

في أي قطاع صناعي، من المهم وصف سلوك النظام عند استجابته لطلب وارد من خارجه : وقد أصبحت  حالات الاستخدام ^{[ 5 ] شائعة في تحديد المتطلبات [ 1 ]} بين المهندسين بفضل ميزاتها، مثل تقنية النمذجة المرئية، فهي تصف النظام من وجهة نظر المستخدم، ويوضح تنسيقها أهداف كل مستخدم والتدفقات التي يجب على النظام تنفيذها لتحقيقها. ^{[ 6 ]}

يُعدّ نموذج حالة الاستخدام، بفضل مستوى التجريد الذي يوفره، نقطة انطلاق مناسبة لأنشطة التصميم، وذلك بفضل استخدام مخططات حالات الاستخدام في لغة النمذجة الموحدة (UML) ولغة المستخدم النهائي أو خبير المجال. ولكن في تحليلات أمن البرمجيات، ينبغي على المطورين الانتباه إلى السيناريوهات السلبية وفهمها. ولهذا السبب، ظهر مفهوم "معكوس حالة الاستخدام" في النرويج في تسعينيات القرن الماضي .

يكمن الفرق بين حالة سوء الاستخدام وحالة الاستخدام في الهدف: فحالة سوء الاستخدام تصف سلوكيات النظام المحتملة التي يعتبرها أصحاب المصلحة في النظام غير مقبولة، أو كما قال غوتورم سيندر وأندرياس ل. أوبدال، "وظيفة لا ينبغي للنظام السماح بها". ^{[ 1 ]} ويتجلى هذا الاختلاف أيضًا في السيناريوهات: فالسيناريو "الإيجابي" هو سلسلة من الإجراءات التي تؤدي إلى هدف يرغب فيه شخص أو مؤسسة، بينما السيناريو "السلبي" هو سيناريو لا ترغب المؤسسة المعنية في حدوث هدفه، أو يرغب فيه جهة معادية (ليست بالضرورة بشرية). ^{[ 7 ]}

وصف آخر للاختلاف هو ^{[ 8 ]} الذي يعرف حالة الاستخدام بأنها سلسلة كاملة من الإجراءات التي تعطي قيمة متزايدة للمستخدم، ويمكن تعريف حالة سوء الاستخدام بأنها سلسلة كاملة من الإجراءات التي تؤدي إلى خسارة للمنظمة أو لبعض أصحاب المصلحة المحددين.

بين الحالة "الجيدة" والحالة "السيئة"، تكون اللغة المستخدمة لتمثيل السيناريو مشتركة: حيث يتم تضمين مخططات حالات الاستخدام رسميًا في لغتي نمذجة محددتين من قبل OMG : لغة النمذجة الموحدة (UML) ولغة نمذجة الأنظمة (SysML)، ويساعد هذا الاستخدام لرسم العوامل وحالات سوء الاستخدام في السيناريو بشكل صريح على تركيز الانتباه عليه. ^{[ 9 ]}

تُستخدم حالات سوء الاستخدام بشكل شائع في مجال الأمن السيبراني. ^{[ 10 ]} ومع تزايد أهمية أنظمة تكنولوجيا المعلومات، أصبح من الضروري لكل شركة تطوير قدرتها على حماية بياناتها. ^{[ 11 ]}

لذا، على سبيل المثال، يمكن استخدام حالة إساءة استخدام لتحديد ما قد يرغب المخترق في فعله بالنظام وتحديد متطلباته. ويمكن للمطور أو المصمم بعد ذلك تحديد متطلبات المستخدم والمخترق في مخطط UML نفسه، مما يساعد بدوره في تحديد المخاطر الأمنية للنظام. ^{[ 12 ]}

يستفيد نموذج حالات سوء الاستخدام من أنواع العلاقات الموجودة في نموذج حالات الاستخدام؛ وهي: التضمين ، والتوسيع ، والتعميم ، والارتباط . بالإضافة إلى ذلك، يُقدّم النموذج علاقتين جديدتين لاستخدامهما في الرسم التخطيطي:

يخفف من

يمكن لحالة الاستخدام أن تقلل من احتمالية نجاح حالة سوء الاستخدام.

يهدد

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

تُعطي هذه المفاهيم الجديدة، بالإضافة إلى المفاهيم الموجودة من حالة الاستخدام، النموذج الفوقي التالي، والذي يوجد أيضًا في الشكل 2 في سيندر وأوبدال (2004). ^{[ 2 ]}

هناك طريقتان مختلفتان لوصف حالة سوء الاستخدام نصيًا؛ إحداهما مُضمنة في نموذج وصف حالة الاستخدام، حيث يُمكن إضافة حقل وصف إضافي يُسمى " التهديدات" . هذا هو الحقل الذي يُمكن فيه ملء خطوات حالة سوء الاستخدام (والخطوات البديلة). يُشار إلى هذه الطريقة بالأسلوب المُبسط لوصف حالة سوء الاستخدام.

هناك طريقة أخرى لوصف حالة سوء الاستخدام، وهي استخدام قالب منفصل لهذا الغرض فقط. يُقترح استعارة بعض الحقول من وصف حالة الاستخدام ( الاسم ، الملخص ، المؤلف ، والتاريخ ). كما يُعدّل هذا القالب حقلي " المسار الأساسي" و "المسار البديل" ليصفا مسارات حالات سوء الاستخدام بدلاً من حالات الاستخدام نفسها. إضافةً إلى ذلك، يُقترح استخدام عدة حقول أخرى أيضاً.

• اسم قضية سوء الاستخدام
• ملخص
• مؤلف
• تاريخ
• المسار الأساسي
• مسارات بديلة
• نقاط التخفيف
• نقاط التمديد
• المحفزات
• الشروط المسبقة
• الافتراضات
• ضمان التخفيف
• قواعد العمل ذات الصلة
• ملف تعريف المستخدم الذي قد يسيء استخدامه
• أصحاب المصلحة والتهديدات
• المصطلحات والتفسيرات
• نِطَاق
• مستوى التجريد
• مستوى دقيق

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

يقترح سيندر وأوبدال الخطوات الخمس التالية لاستخدام حالات سوء الاستخدام لتحديد متطلبات الأمان:

1. تحديد الأصول الحيوية في النظام
2. حدد أهداف الأمان لكل أصل
3. حدد التهديدات التي تواجه كل هدف من أهداف الأمن هذه، وذلك من خلال تحديد الجهات المعنية التي قد ترغب في إلحاق الضرر بالنظام.
4. تحديد وتحليل المخاطر المتعلقة بالتهديدات، باستخدام تقنيات مثل تقييم المخاطر
5. حدد متطلبات الأمان للمخاطر.

يُقترح استخدام مستودع لحالات سوء الاستخدام القابلة لإعادة الاستخدام كدعم في هذه العملية المكونة من 5 خطوات.

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

تركز أبحاث أخرى على تحسين حالة سوء الاستخدام لتحقيق هدفها النهائي: ففي ^{[ 13 ]} "هناك قصور في عملية التطبيق، والنتائج عامة للغاية وقد تؤدي إلى عدم دقة تعريف المفاهيم أو سوء فهمها". ويقترحون كذلك "النظر إلى حالة سوء الاستخدام في ضوء نموذج مرجعي لإدارة مخاطر أمن نظم المعلومات (ISSRM)" للحصول على عملية لإدارة مخاطر الأمن.

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

كما يقترح سيندر وأوبدال (مبتكرا مفهوم حالات سوء الاستخدام): "يتمثل أحد الأهداف المهمة الأخرى لمزيد من العمل في تسهيل تبني حالات سوء الاستخدام على نطاق أوسع في القطاع الصناعي". ^{[ 2 ]} ويقترحان، في المقالة نفسها، دمج حالة سوء الاستخدام في أداة نمذجة حالات الاستخدام، وإنشاء "قاعدة بيانات" لحالات سوء الاستخدام القياسية لمساعدة مهندسي البرمجيات. ينبغي على أصحاب المصلحة في النظام إنشاء مخططات حالات سوء الاستخدام الخاصة بهم للمتطلبات المحددة لمجالات مشاكلهم. وبمجرد تطويرها، يمكن لقاعدة بيانات المعرفة أن تقلل من عدد الثغرات الأمنية القياسية التي يستغلها مخترقو لامدا.

ركزت أبحاث أخرى على الحلول الملموسة المفقودة المحتملة لحالات إساءة الاستخدام: كما ذكر ^{[ 14 ]} : "مع أن هذا النهج قد يساعد في استخلاص متطلبات الأمان على مستوى عالٍ، إلا أنه لا يوضح كيفية ربط حالات إساءة الاستخدام بالسلوك المشروع والأصول الملموسة؛ لذا، ليس من الواضح ما هي حالة إساءة الاستخدام التي ينبغي أخذها في الاعتبار، ولا في أي سياق". ويمكن معالجة هذه الانتقادات من خلال الاقتراحات والتحسينات الواردة في قسم السوابق.

قد يُتيح توحيد حالة سوء الاستخدام كجزء من تدوين UML إمكانية جعلها جزءًا إلزاميًا من تطوير المشروع. "قد يكون من المفيد إنشاء تدوين خاص بوظائف الأمان، أو التدابير المضادة التي أُضيفت للتخفيف من الثغرات الأمنية والتهديدات." ^{[ 15 ]}