ما هو SOC؟ كيف يعمل مركز العمليات الأمنية من التنبيه إلى الاستجابة للحوادث

Security Operations Center — SOC هو وظيفة أو فريق أمني مسؤول عن مراقبة البيئة التقنية للمؤسسة، واكتشاف النشاط المشبوه، والتحقيق فيه، ثم تنسيق الاستجابة عندما يتحول التنبيه إلى حادث أمني حقيقي.

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

ما هو SOC بالضبط؟

يشير اختصار SOC إلى Security Operations Center أو مركز العمليات الأمنية. وتدرج NIST المصطلح ضمن مراجعها الرسمية لعمليات الأمن والاستجابة للحوادث.

عمليًا، يمكن النظر إلى SOC باعتبارها الطبقة التشغيلية التي تجيب باستمرار عن أسئلة مثل:

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

وقد تعمل SOC على مدار الساعة في المؤسسات التي تحتاج تغطية 24/7، بينما قد تستخدم مؤسسات أخرى فريقًا داخليًا في أوقات محددة أو نموذجًا هجينًا مع مزود خارجي. لذلك، وجود SOC لا يعني تلقائيًا وجود محللين بشريين يعملون 24 ساعة يوميًا.

من أين تحصل SOC على البيانات؟

لا يستطيع محلل الأمن اكتشاف نشاط لا تصله عنه بيانات. لذلك تبدأ فعالية SOC قبل ظهور أي Alert، من تحديد مصادر Telemetry التي تحتاج المؤسسة إلى جمعها والاحتفاظ بها.

من أهم هذه المصادر:

EDR وأحداث أجهزة Endpoint.
أنظمة الهوية وتسجيلات الدخول والمصادقة.
Active Directory أو خدمات الهوية السحابية.
Firewall وIDS/IPS.
DNS وProxy وSecure Web Gateway.
البريد الإلكتروني.
الخدمات والتطبيقات السحابية.
الخوادم والتطبيقات وقواعد البيانات.
أجهزة الشبكة.
أنظمة SaaS المهمة للمؤسسة.

وجود آلاف المصادر لا يعني بالضرورة رؤية أفضل. إذا كانت السجلات المهمة غير مفعلة، أو التوقيت غير متزامن، أو البيانات لا تحتوي الحقول اللازمة للتحقيق، فإن SOC قد تمتلك كمية هائلة من Logs مع بقاء Blind Spots خطرة.

Event وAlert وIncident: ما الفرق؟

هذه المصطلحات ليست مترادفات، والتمييز بينها أساسي لفهم طريقة عمل مركز العمليات الأمنية.

Event

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

معظم Events طبيعية ولا تشير وحدها إلى هجوم.

Alert

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

على سبيل المثال، تسجيل دخول مستخدم ليس بالضرورة مشكلة، لكن تسجيل دخول من موقع غير معتاد متبوعًا بمحاولات للوصول إلى موارد حساسة قد يؤدي إلى Alert.

Incident

Incident هو حدث أمني تم تقييمه وأصبح يتطلب استجابة أو إدارة وفق إجراءات المؤسسة.

لهذا فإن 10,000 Alert لا تعني وقوع 10,000 Incident. جزء كبير من عمل SOC هو التمييز بين النشاط الطبيعي، والإيجابيات الكاذبة، والنشاط المشبوه، والحوادث المؤكدة.

إذا واجهتك مصطلحات مثل IOC وTTP وSIEM وXDR أثناء قراءة تقارير SOC، يجمع دليل مصطلحات الأمن السيبراني الأساسية تعريفاتها ضمن سياق واحد.

كيف ينتقل التنبيه داخل SOC؟

يمكن تبسيط دورة العمل إلى:

Telemetry → Detection → Alert → Triage → Investigation → Incident → Containment → Recovery → Improvement

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

1. Detection: كيف يظهر التنبيه أصلًا؟

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

هنا تظهر أهمية Detection Engineering. قاعدة الكشف الجيدة ليست مجرد Query تُكتب مرة واحدة وتُنسى، بل ينبغي التعامل معها كعنصر يحتاج إلى:

مالك واضح.
مصادر بيانات محددة.
اختبار قبل النشر.
Version Control عند الإمكان.
قياس الأداء.
Tuning مستمر.
مراجعة بعد الحوادث والتغييرات التقنية.

الهدف ليس إنشاء أكبر عدد من Alerts، بل كشف السلوك الذي يهم المؤسسة بأقل قدر ممكن من الضوضاء.

2. Triage: هل التنبيه يستحق التحقيق؟

عند وصول Alert، تبدأ مرحلة Triage. يحاول المحلل في وقت قصير جمع السياق الكافي لاتخاذ قرار أولي.

قد تشمل الأسئلة:

من المستخدم أو الحساب المرتبط بالنشاط؟
ما الجهاز أو الأصل المتأثر؟
متى بدأ النشاط؟
هل السلوك معتاد لهذا المستخدم؟
هل توجد Alerts أخرى مرتبطة؟
ما حساسية الأصل المتأثر؟
هل توجد Indicators أو TTPs معروفة؟
ما الأثر المحتمل على العمل؟

وقد ينتهي Triage إلى إغلاق التنبيه كـFalse Positive أو نشاط مشروع، أو تصعيده لمزيد من التحقيق.

3. Investigation: بناء قصة الحادث

التحقيق الأمني لا يعتمد على مشاهدة Alert منفردة، بل على إعادة بناء ما حدث زمنيًا وربط الأدلة من عدة مصادر.

قد يظهر Timeline مثلًا:

Initial Access → Execution → Credential Access → Lateral Movement → Impact

هذه ليست مراحل إلزامية لكل هجوم، وإنما مثال على كيفية ربط سلوكيات مختلفة. يستخدم المحللون في كثير من البيئات MITRE ATT&CK لوصف تكتيكات وتقنيات الخصوم استنادًا إلى سلوكيات لوحظت في هجمات حقيقية.

أثناء التحقيق قد يكتشف المحلل، على سبيل المثال، أن Alert بدأت على Endpoint واحد، لكن الحساب نفسه استُخدم لاحقًا على Server آخر. هنا يتغير نطاق التحقيق من جهاز واحد إلى حادث Identity أو Lateral Movement أوسع.

4. Containment: كيف توقف SOC الضرر؟

عندما تتوفر أدلة كافية، قد تحتاج SOC إلى احتواء النشاط قبل اكتمال كل تفاصيل التحقيق.

الإجراءات المحتملة تشمل:

عزل Endpoint عن الشبكة.
تعطيل حساب أو فرض إعادة تعيين بيانات الاعتماد.
إبطال Sessions أو Tokens.
حظر Domain أوIP أوIndicator محدد.
تقييد اتصال أو خدمة مؤقتًا.
عزل Workload سحابي.

لكن الاستجابة الآلية أو السريعة ليست دائمًا أفضل استجابة. عزل خادم إنتاج حرج بسبب Alert غير دقيقة قد يسبب ضررًا تشغيليًا أكبر من التهديد نفسه.

لهذا تحتاج SOC إلى Response Authority واضحة: من يستطيع عزل جهاز؟ من يستطيع تعطيل حساب مدير؟ متى تحتاج الموافقة؟ وما الأنظمة التي يمنع اتخاذ إجراء تلقائي عليها؟

5. الاستعادة والتعلم من الحادث

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

أصدر NIST في أبريل 2025 الإصدار النهائي من SP 800-61 Rev.3، الذي حل محل Rev.2 ويربط الاستجابة للحوادث بصورة أوضح بإدارة مخاطر الأمن السيبراني وCybersecurity Framework 2.0، بدل النظر إلى Incident Response كعملية منفصلة تبدأ فقط بعد وقوع الاختراق.

بعد الحادث قد تحتاج SOC إلى:

تحسين Detection Rule.
إضافة Telemetry كانت مفقودة.
تغيير Threshold أوCorrelation Logic.
إنشاء Playbook جديد.
تحديث إجراءات الاستجابة.
معالجة سبب جذري في الهوية أوالإعدادات أوالتقسيم الشبكي.
تحويل نتائج التحقيق إلى Threat Hunting Hypothesis.

ما دور SIEM داخل SOC؟

SIEM — Security Information and Event Management تساعد على تجميع السجلات والأحداث من مصادر متعددة، والبحث فيها، وربطها، وتشغيل Analytics وقواعد الكشف.

لكن SIEM ليست SOC.

يمكن لمؤسسة شراء منصة SIEM باهظة الثمن ثم الحصول على نتائج ضعيفة إذا كانت:

مصادر البيانات ناقصة.
القواعد لا تغطي التهديدات المهمة.
لا يوجد فريق يحقق في Alerts.
لا توجد Playbooks للاستجابة.
لا توجد صلاحيات لاتخاذ إجراءات الاحتواء.

الأداة توفر قدرات، بينما SOC هي المنظومة التشغيلية التي تحول تلك القدرات إلى قرارات واستجابة.

ما دور EDR وXDR؟

EDR يوفر رؤية عميقة لما يحدث على أجهزة Endpoint، مثل Processes والملفات والاتصالات والنشاط المرتبط بالمستخدم، وقد يسمح أيضًا بتنفيذ إجراءات استجابة مثل عزل الجهاز.

أما XDR فيهدف إلى ربط إشارات من أكثر من طبقة أمنية، مثل Endpoint والهوية والبريد والسحابة، حتى لا يضطر المحلل إلى تقييم كل Alert بمعزل عن السياق الآخر.

ومرة أخرى، امتلاك EDR أوXDR لا يلغي الحاجة إلى عملية تشغيلية تحدد من يراجع التنبيهات وكيف تُصنف وكيف يتم التصعيد والاستجابة.

أين تدخل SOAR والأتمتة؟

SOAR — Security Orchestration, Automation and Response تستخدم لأتمتة خطوات متكررة وربط الأدوات ضمن Playbooks.

يمكن للأتمتة مثلًا:

جمع معلومات إضافية عن IP أوDomain.
الاستعلام عن نشاط المستخدم.
إضافة Context إلى Incident.
إنشاء Ticket أوتحديثه.
إرسال إشعار إلى الفريق.
تنفيذ إجراء احتواء بعد تحقق شروط محددة.

القيمة الكبرى للأتمتة ليست فقط السرعة، بل إزالة الأعمال المتكررة حتى يركز المحلل على القرارات التي تحتاج فهمًا وسياقًا بشريًا.

أما الإجراءات عالية التأثير، فيجب تصميمها بعناية مع Approval Steps وRollback وخطط واضحة لما يحدث إذا كان Detection خاطئًا.

ما هو Threat Hunting داخل SOC؟

Threat Hunting يختلف عن انتظار Alert. يبدأ الباحث بفرضية ثم يبحث في Telemetry عن أدلة قد تشير إلى نشاط لم تكتشفه القواعد الحالية.

مثال دفاعي بسيط:

هل توجد حسابات شرعية تستخدم Remote Services بطريقة غير معتادة تتوافق مع TTPs نراقبها؟

إذا أثبت البحث وجود نمط مهم، فإن النتيجة الجيدة لا تنتهي بتقرير فقط. يمكن تحويل ما تم تعلمه إلى Detection جديدة أوتحسين Telemetry حتى لا يحتاج الفريق إلى البحث يدويًا عن السلوك نفسه كل مرة.

ما دور Threat Intelligence؟

استخبارات التهديدات ليست مجرد Feed يحتوي ملايين عناوين IP وHashes.

تكون أكثر فائدة عندما تساعد SOC على الإجابة عن أسئلة مثل:

ما الجهات أوالحملات ذات الصلة بقطاعنا؟
ما TTPs التي تستخدمها؟
هل لدينا Telemetry تكشف هذه السلوكيات؟
هل Detection الحالية تغطيها؟
هل توجد تقنيات يجب أن نبحث عنها استباقيًا؟

Indicator يمكن تغييره بسرعة، بينما فهم أسلوب المهاجم وسلوكه قد يعطي قيمة دفاعية أطول.

ما الفرق بين L1 وL2 وL3؟

تستخدم بعض مراكز العمليات نموذج المستويات:

L1: استقبال Alerts وتنفيذ Triage الأولي والتصعيد.
L2: تحقيق أعمق وربط الأدلة وتحديد النطاق.
L3: تحليل متقدم، Threat Hunting، Malware Analysis أوDetection Engineering حسب المؤسسة.

لكن هذا ليس Standard عالميًا ملزمًا. بعض SOC الحديثة تستخدم فرقًا متخصصة أوSquads وتوزع المسؤوليات بطريقة مختلفة بدل سلسلة تصعيد ثابتة من ثلاثة مستويات.

الأهم هو وضوح المسؤولية، وليس اسم المستوى.

SOC داخلية أم خدمة MDR؟

يمكن أن تدير المؤسسة عملياتها الأمنية داخليًا، أوتستعين بمزود خارجي، أوتستخدم نموذجًا هجينًا.

الفريق الداخلي يمتلك عادة سياقًا أعمق حول الأعمال والأنظمة والحسابات الحساسة، بينما قد يساعد مزود خارجي على توفير مراقبة مستمرة أوخبرات يصعب توظيفها داخليًا.

أما Managed Detection and Response — MDR فهي خدمة تشغيلية تجمع عادة تقنيات الكشف مع محللين يقومون بالمراقبة والتحقيق والمساعدة في الاستجابة نيابة عن العميل أوإلى جانبه. لذلك لا ينبغي استخدام SOC وMDR وEDR وXDR كمصطلحات مترادفة.

كيف تعرف أن SOC فعالة؟

عدد Alerts المغلقة ليس مقياسًا كافيًا. ويمكن لفريق إغلاق آلاف التنبيهات دون اكتشاف هجوم واحد مهم.

من المقاييس الأكثر فائدة حسب بيئة المؤسسة:

Detection coverage: ما السلوكيات المهمة التي نستطيع اكتشافها فعليًا؟
Time to triage: كم يستغرق تقييم Alert ذات أولوية؟
Time to investigate: كم يستغرق الوصول إلى قرار موثوق؟
Time to contain: كم يستغرق الحد من الضرر بعد تأكيد الحادث؟
False positive rate: كم من Alerts لا تقدم قيمة فعلية؟
Telemetry gaps: ما أجزاء البيئة التي لا نملك عنها رؤية كافية؟
Repeat incidents: هل تتكرر المشكلة نفسها لأن السبب الجذري لم يُعالج؟
Detection quality: هل التنبيه يقدم للمحلل Context يسمح له بالتحقيق أم مجرد رسالة غامضة؟

وتوجد مؤشرات شائعة مثل MTTD وMTTR، لكن من المهم أن تحدد المؤسسة بدقة كيف تحسب بداية ونهاية كل مقياس؛ لأن اختصار MTTR نفسه قد يُستخدم أحيانًا بمعانٍ مختلفة مثل Mean Time to Respond أوRemediate أوRecover.

هل الذكاء الاصطناعي سيستبدل محللي SOC؟

الذكاء الاصطناعي أصبح جزءًا متزايدًا من منصات Security Operations، ويمكن استخدامه في تلخيص Incidents، وربط الأحداث، والمساعدة في كتابة Queries، وإثراء التنبيهات، واقتراح خطوات التحقيق.

لكن استخدام AI لا يعالج تلقائيًا مشاكل مثل Telemetry المفقودة، أوصلاحيات الاستجابة غير الواضحة، أوDetection ضعيفة، أوبيانات غير موثوقة.

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

ما الذي تحتاجه SOC قبل شراء المزيد من الأدوات؟

قبل إضافة منصة جديدة، يجب أن تستطيع المؤسسة الإجابة بوضوح عن:

ما الأصول والحسابات الأكثر أهمية؟
ما التهديدات التي نحاول اكتشافها؟
ما Telemetry اللازمة لذلك؟
من يراجع Alerts؟
ما شروط تحويل Alert إلى Incident؟
من يملك صلاحية الاحتواء؟
ما Playbooks الموجودة للحوادث المهمة؟
كيف نقيس Detection وResponse؟
كيف تتحول نتائج الحوادث إلى تحسينات جديدة؟

إذا كانت هذه الأسئلة بلا إجابة، فإن إضافة SIEM أوXDR أوأداة AI جديدة قد تزيد كمية البيانات والتنبيهات دون تحسين قدرة المؤسسة على اتخاذ القرار.

الخلاصة

SOC الناجحة ليست مجموعة شاشات أوأسماء منتجات، بل قدرة تشغيلية مستمرة تحول Telemetry إلى قرار أمني صحيح: هل النشاط يمثل حادثًا حقيقيًا؟ ما نطاقه؟ وما أسرع طريقة لاحتوائه دون فقد الأدلة أوتعطيل الأعمال بلا داعٍ؟

كلما تحسنت جودة البيانات وDetection Engineering وعمليات Triage والتحقيق والاستجابة والتعلم بعد الحوادث، أصبحت SOC أكثر فاعلية. أما كثرة الأدوات أوAlerts وحدها فلا تثبت أن المؤسسة ترى التهديدات المهمة أوتستطيع التعامل معها عندما تتحول إلى حادث فعلي.