الأمن السيبراني وأمن المعلومات

Severity مقابل الأولوية: كيف تصنف أحداث الأمن

6 دقيقة قراءةتاريخ النشر: 5 أغسطس 2026

تمثيل بصري احترافي لموضوع Severity مقابل الأولوية في أمن المعلومات في مجال SOC والعمليات

إجابة سريعة

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

في أنظمة SOC، تظهر أحيانًا عدة درجات في نفس الوقت: Alert Severity, Incident Severity, Risk Score, Magnitude أو Priority. عندما تستخدم الفرق هذه الدرجات وكأنها الشيء نفسه، تكون النتيجة قائمة عمل غير متناسقة: حدث 'مرتفع' قديم ومعزول يزيح نشاط 'متوسط' يحدث الآن على حساب مسؤول.

تصف Microsoft Severity كمقياس للتأثير المحتمل على الأصول، بينما تضيف قائمة الأحداث الموحدة آلية الأولوية التي تأخذ في الاعتبار أيضًا حرجية الأصل، ندرته، تقنيات MITRE، والتهديدات عالية الخطورة. في QRadar، يتم حساب Magnitude للاعتداء من خلال دمج Severity, Relevance و Credibility جنبًا إلى جنب مع عوامل أخرى. توضح الأمثلة أنه لا توجد درجة واحدة تناسب جميع القرارات.

الهدف ليس استبدال درجات الأدوات، بل إنشاء لغة تنظيمية تشرح لماذا يتم التعامل مع حدث ما الآن، من يعالجها، وما الذي سيؤدي إلى تغيير في التصنيف.

ما هي Severity

Severity تصف شدة النتيجة المحتملة أو الملحوظة: المساس بالسرية أو التكامل أو التوفر؛ عدد الأصول والمستخدمين؛ حرجية النظام؛ حساسية البيانات؛ ومستوى تحكم المهاجم. تجيب على السؤال: 'إذا كان السيناريو حقيقيًا، فكم هو خطير؟'

في معظم الأدوات، القيم هي Informational, Low, Medium و High، وأحيانًا Critical. من المهم فهم من حدد القيمة: مُصنِّع Detection، قاعدة محلية (Rule)، محرك تحليلي، أو محلل. يمكن توريث Alert Severity إلى Incident، ولكن بعد التحقيق، يُسمح بل وأحيانًا يُطلب تحديثها.

Severity ليست دليلًا على صحة الحادث. قاعدة 'High' ذات False Positive عالٍ لا تجعل كل تطابق حدثًا خطيرًا. لذلك يجب الفصل بين الشدة والثقة (Confidence).

ما هي Priority

Priority تحدد ترتيب المعالجة ومستوى الإلحاح. تجيب على السؤال: 'بماذا سنتعامل أولًا؟' بالإضافة إلى الشدة، تأخذ في الاعتبار الوقت، حالة الحدث، القدرة على الاحتواء، الموظفين المتاحين، SLA والسياق التجاري.

قد يحصل حدث Ransomware نشط على محطة واحدة على أولوية حرجة بسبب سرعة الانتشار، حتى قبل معرفة النطاق (Scope). على النقيض، قد يبقى تسرب تاريخي خطير تم احتواؤه بالفعل ذا Severity عالية ولكن Priority أقل للتحقيق الفوري، طالما لا يوجد تأثير نشط.

يجب أن تكون الأولوية ديناميكية. مع اكتشاف أصل إضافي، نجاح الاتصال، تغيير الامتياز (Privilege) أو فشل في الاحتواء (Containment) — تزداد. بعد العزل، الإلغاء (Revoke) والتأكد من عدم الانتشار — يمكن تقليل الإلحاح دون تغيير شدة الحدث بالضرورة.

لماذا يختلف المقياسان

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

يمكن إضافة Confidence أو Likelihood كمحور ثالث. على سبيل المثال: Severity عالية، Confidence منخفضة، Priority متوسطة حتى التأكيد؛ أو Severity متوسطة، Confidence عالية وحدث نشط — Priority عالية.

في QRadar، Magnitude هو مثال على درجة مدمجة: Severity, Relevance و Credibility جنبًا إلى جنب مع Asset Weight, عدد Events, عمر Offense ونقاط الضعف. إنه مفيد لتحديد الأولويات، ولكنه لا يزال يتطلب فهم السياق.

العوامل المؤثرة على Severity

التأثير على السرية، التكامل، والتوفر.
حرجية الأصل والخدمة التجارية.
حساسية المعلومات ونطاقها.
مستوى الوصول: User, Local Admin, Domain Admin أو Cloud Admin.
عدد الأصول، المستخدمين، والبيئات المعنية.
مرحلة الهجوم: Initial Access مقابل Exfiltration أو Impact.
القدرة على التعافي وما إذا كانت هناك نسخ احتياطية سليمة.

العوامل المؤثرة على Priority

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

مصفوفة تصنيف عملية

يمكن البدء بمصفوفة من Severity و Confidence، ثم تعديل Priority وفقًا لحالة النشاط والحرجية. لا توجد صيغة عالمية؛ يجب أن يكون النموذج شفافًا، موثقًا، ومختبرًا على أحداث حقيقية.

يوصى بإضافة سطر السبب (Reason) لكل قرار. 'الأولوية عالية - جلسة نشطة على هوية مميزة؛ الاحتواء لم يكتمل' أوضح من الدرجة وحدها.

Severity	Confidence	الحالة	الأولوية النموذجية
عالية	عالية	نشط/لم يتم احتواؤه	حرجة
عالية	متوسط	محتوى مؤقتًا	عالية
عالية	منخفضة	لا يوجد دليل تكميلي	متوسطة حتى التأكيد
متوسطة	عالية	أصل حرج أو انتشار	عالية
متوسطة	متوسط	النشاط انتهى	متوسطة
منخفضة	عالية	حجم كبير أو تأثير تشغيلي	متوسطة
منخفضة	منخفضة	حالة واحدة بدون تأثير	منخفضة

أمثلة من SOC

السيناريو	Severity	Priority	التبرير
برمجيات خبيثة قديمة موجودة في ملف Archive معزول	عالية	منخفضة-متوسطة	احتمال خطير، ولكن لا يوجد تنفيذ نشط
هجوم Password Spray نشط بدون نجاح	متوسطة	عالية	نافذة احتواء قصيرة ونطاق المستخدمين
تسجيل دخول لـ Global Admin من دولة جديدة	عالية	حرجة	هوية حساسة وجلسة نشطة محتملة
خادم Production لا يرسل سجلات	متوسطة	عالية	فقدان الرؤية في أصل حرج
Adware في محطة معمل غير متصلة	منخفضة	منخفضة	تأثير محدود واحتواء موجود

كيفية تحديث التصنيف أثناء التحقيق

حدد نقاط مراجعة (Review): بعد الفرز (Triage)، بعد النطاق الأولي (Initial Scope)، بعد الإجراء الأول وقبل الإغلاق. في كل نقطة اسأل ما الذي تغير في التأثير (Impact)، الثقة (Confidence) وحالة النشاط. يجب أن يتضمن تحديث الدرجة Timestamp, Owner وتبريرًا.

لا تقلل Severity فقط للامتثال لـ SLA. إذا كان الحدث خطيرًا ولكنه محتوى، يمكن الإبقاء على Severity عالية وتقليل Priority. بهذه الطريقة يتم الحفاظ على الصورة التاريخية للمخاطر ولا يكون التقرير مضللًا.

في مقاييس الفريق، قم بتحليل إعادة التصنيف (Reclassification) أيضًا: كم عدد الأحداث التي ارتفعت أو انخفضت في الدرجة، وما الذي أدى إلى ذلك. التغيير المستمر يمكن أن يشير إلى قاعدة (Rule) مصنفة بشكل خاطئ أو إلى Asset Criticality غير محدثة.

قائمة تحقق عملية

هل من الواضح من حدد Severity الأولية؟
هل قدرت التأثير (Impact) وليس فقط اسم الكشف (Detection)؟
هل الثقة (Confidence) موثقة بشكل منفصل؟
هل الحدث نشط أم محتوى؟
هل يتضمن أصول/هويات حرجة؟
هل تتضمن الأولوية (Priority) تبريرًا تشغيليًا؟
هل تم تحديد نقطة المراجعة (Review) التالية؟
هل تم حفظ تغيير الدرجة في سجل التدقيق (Audit Trail)؟

أخطاء شائعة

وضع علامة على كل تنبيه 'High' كحدث 'Critical'.
استخدام Severity و Priority كمرادفات.
عدم تحديث التصنيف بعد العزل أو توسيع النطاق (Scope).
تجاهل حرجية الأصل وحساسية المعلومات.
بناء صيغة معقدة لا يفهمها أحد.
قياس SLA بطريقة تشجع على خفض Severity بشكل مصطنع.

الخلاصة والدعوة لاتخاذ إجراء

قم ببناء مصفوفة لخمسة سيناريوهات من المختبر وأعط كل منها Severity, Confidence و Priority مع جملة تبرير. قارن النتيجة بالمقال حول Triage ومعايير التصعيد. في دورة Cybersecurity & AI من HPI، يتم التدرب على اتخاذ القرارات بناءً على السياق وليس فقط قراءة درجة من النظام.

الأسئلة الشائعة

هل Severity من المُصنِّع ملزمة للمؤسسة؟

لا. إنها نقطة بداية. يجب تكييفها مع البيئة، الأصل، النطاق (Scope)، والسياسة المحلية.

هل يمكن أن تكون الأولوية (Priority) أعلى من الشدة (Severity)؟

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

متى يتم تغيير Severity؟

عندما تغير الأدلة تقييم التأثير (Impact) أو النطاق (Scope). يجب توثيق التغيير مع تبرير.

ما هو Magnitude في QRadar؟

درجة تساعد في تحديد أولويات Offenses وتحسب، من بين أمور أخرى، بناءً على Severity, Relevance, Credibility, الأصول والأحداث. إنها ليست مطابقة لـ Severity وحدها.

هل نحتاج إلى Critical فوق High؟

فقط إذا كانت المؤسسة قادرة على تحديد معايير وإجراءات مختلفة. كثرة الفئات تخلق عدم اتساق.