ماذا يفعل محلل SOC من الدرجة الأولى طوال اليوم فعلاً؟

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

طابور التذاكر لا يفرغ فعلاً

تبدأ مناوبتك وهناك طابور من التذاكر، عادة ما ينتج عن SIEM مثل Splunk أو Microsoft Sentinel أو QRadar. كل تذكرة هي تنبيه واحد: تسجيل دخول من دولة غير عادية، قفزة في حركة المرور الصادرة، ملف يطابق قاعدة YARA، حساب مستخدم مقفل خمس مرات في عشر دقائق. يولد SOC مشغول مئات هذه يومياً، ومعظمها مشكلة Tier 1 أولاً.

تفتح تذكرة. تعطيك طابع زمني وعنوان IP مصدر وربما اسم مستخدم والقاعدة التي تفعلت. وظيفتك الإجابة على سؤال واحد: هل هذا شيء أم لا شيء؟ هذا كل شيء. أنت لا تصلح أي شيء بعد — أنت تقرر ما إذا كان هذا يستحق اهتماماً أكثر.

الفحص هو 90% جمع السياق

قل أن التنبيه هو "السفر المستحيل": سجل مستخدم دخول من شيكاغو وبعد ذلك، بعد 20 دقيقة، من فرانكفورت. قبل أن تقرر أي شيء تسحب السياق:

• تحقق من نمط تسجيل الدخول الطبيعي للمستخدم في SIEM — هل يسافرون للعمل، يستخدمون VPN، لديهم جهاز محمول يبلغ عن الموقع الجغرافي بشكل خاطئ؟
• تحقق مما إذا تم تحقيق MFA على كلا تسجيلات الدخول، أم أن الثانية استخدمت رمز مخزن مؤقتاً.
• ابحث عن عنوان IP المصدر في شيء مثل VirusTotal أو AbuseIPDB — هل هي عقدة خروج Tor معروفة، موفر VPN، ISP سكني؟
• تحقق مع المستخدم مباشرة إذا سمحت به عملية SOC الخاصة بك — رسالة Slack مثل "مرحباً، هل كنت تسجل دخول من ألمانيا حول الساعة الثانية ظهراً؟" تحل نصف هذه التذاكر في رد واحد.

في معظم الحالات إنه عميل VPN يبدل الخوادم أو هاتف يتزامن عبر LTE في موقع غريب. تكتب ما وجدته، تضعها كإيجابية خاطئة، وتغلق التذكرة. هذه هي الوظيفة، مكررة 30-60 مرة في المناوبة اعتماداً على حجم SOC الخاص بك وسرعتك.

معرفة متى يتم التصعيد — وكتابته بحيث لا تضطر Tier 2 إلى إعادة عملك

المهارة الحقيقية ليست كشف البرامج الضارة. إنها معرفة متى لا يكون شيء ما متسقاً بما يكفي للتصعيد، وكتابة التصعيد بحيث يمكن لـ Tier 2 التقاطه بدون إعادة فحصك من الصفر. تصعيد سيء يقول "تسجيل دخول مريب، يرجى التحقيق." تصعيد جيد يقول:

User: jsmith@company.com
Alert: Impossible travel (Chicago -> Frankfurt, 22 min apart)
MFA: Satisfied on both logins via push notification
Source IP (Frankfurt): 185.220.101.x — matches known Tor exit node list (AbuseIPDB score 94)
User response: Denies traveling or using VPN; reports no MFA prompt received for second login (possible push fatigue?)
Recommendation: Escalate — possible account compromise via MFA push spam. Recommend forced password reset and session revocation.

استغرقت هذه الكتابة ربما ثماني دقائق لكنها توفر Tier 2 عشرين. تذاكر مثل هذه — حيث ينكر المستخدم النشاط وعنوان IP مضروب — هي الوحيدة التي تهم حقاً، وهي ربما 5% من طابورك.

الأدوات التي ستلمسها كل مناوبة

بعيداً عن SIEM، توقع البقاء في حفنة من الأدوات يومياً: وحدة تحكم EDR (CrowdStrike Falcon أو SentinelOne أو Defender for Endpoint) للتحقق من أشجار العمليات وعزل المضيفات إذا طلب منك، نظام تذاكر (ServiceNow أو Jira) لتتبع عملك، بحوث التهديدات (VirusTotal أو AbuseIPDB أو urlscan.io) للفحوصات السريعة للمؤشرات، وغالباً وثيقة runbook أو playbook تخبرك بالضبط بخطوات المتابعة لكل نوع تنبيه. عمل Tier 1 مدفوع بكثافة بالـ playbooks عن قصد — الاتساق يهم أكثر من الارتجال على هذا المستوى.

لماذا التكرار هو التدريب فعلاً

السبب في وجود Tier 1 كدور مميز، بدلاً من إرسال كل تنبيه مباشرة إلى محللين أكبر سناً، هو التعرف على الأنماط من خلال الحجم. بعد مئات تذاكر السفر المستحيل تبدأ في التعرف على شكل تذكرة حقيقية مقابل تبديل VPN روتيني قبل أن تنهي حتى سحب السياق. هذا الحدس لا يأتي من دورة — يأتي من فعل نسخة ممله من الوظيفة طويلة بما يكفي بحيث يظهر الحادث الحقيقي النادر فعلاً.

إذا كنت ترسم مساراً في عمل الفريق الأزرق، فإن Korra Studio لديها أجزاء حول أساسيات استعلام SIEM وأسلاف تصفية رسائل البريد الإلكتروني المزيفة وما يفصل مسؤوليات Tier 1 عن Tier 2 في الممارسة.