الأمن السيبراني

    تأسيس مركز عمليات الأمن (SOC) المؤسسي؛ هندسة SIEM وSOAR وخطّ الاستخبارات السيبرانية

    سبعة قرارات عملية لبناء SOC بجودة إنتاج من الصفر؛ جمع السجلّات، اختيار SIEM (Wazuh/ELK/Splunk)، تخطيط MITRE ATT&CK، أتمتة SOAR، اعتدادٌ مع KVKK. دروسٌ من مشاريع الأمن المؤسسية. ملاحظةٌ هندسية من eCloud Tech.

    نُشر: ٢٥ مايو ٢٠٢٦14 د قراءة
    socsiemsoarmitre-attack

    شهد الأمنُ السيبراني المؤسسي تحوّلًا جوهريًا في السنوات الخمس الماضية. لقد دخلنا حقبةً لم يَعد فيها نموذجُ دفاع المحيط (firewall + antivirus + IPS) كافيًا، وأصبح فيها نموذجُ zero-trust + المراقبة المستمرّة + الاستجابة السريعة مهيمنًا. والمركزُ التشغيلي لهذا التحوّل هو SOC (Security Operations Center)؛ وظيفةُ أمنٍ تعمل على مدار الساعة، تَجمع البيانات الـtelemetry، وتَكتشف الشذوذ، وتَستجيب للحوادث، وتنضج باستمرار. وفي تركيا، يُموضِع قانونُ KVKK لحماية البيانات الشخصية ولائحةُ نظم معلومات BDDK ولوائحُ EPDK وعقودُ التأمين السيبراني الـSOC اليوم لا بصفته جيّدًا لو وُجد، بل لا بدّ منه.

    في إطار خدماتنا في هندسة تأسيس عمليات SOC وخدمات الاستجابة للحوادث وخدمات استخبارات التهديدات، أنجزنا خلال الأربع والعشرين شهرًا الماضية 11 مشروع SOC مؤسسي في قطاعات المالية والصحة والطاقة والتجارة الإلكترونية. في هذا المقال نَستعرض في سبع خطواتٍ عملية كيفية بناء معمارية SOC مؤسسية من الصفر؛ تعريف النطاق، جمع السجلّات، اختيار SIEM، تخطيط MITRE ATT&CK، خطّ استخبارات التهديدات، أتمتة SOAR، وعمليةُ النضج المستمرّ.

    1. القرار الاستراتيجي؛ النطاق والنموذج وهدف النضج

    السؤالُ الأول ليس Splunk أم Wazuh؟؛ بل ينبغي أن يكون ما الذي نحميه، وضدّ مَن، وبأيِّ مستوى نضجٍ؟. ثلاثةُ أبعادٍ جوهرية:

    النطاق؛ أيُّ الأصول تحت مراقبة SOC؟ الطبقاتُ النموذجية؛ (1) الـendpoint (أجهزةُ المستخدمين، الخوادم)، (2) الشبكة (firewall، router، switch، IDS/IPS)، (3) الـcloud (مستوى التحكّم وأعباء العمل في AWS/Azure/GCP)، (4) الهوية (Active Directory، Azure AD، MFA)، (5) التطبيق (تطبيقاتُ الويب، API gateway)، (6) الـSaaS (Microsoft 365، Google Workspace، Slack). تَتطلّب كلُّ طبقةٍ مصادرَ سجلٍّ خاصّة وقواعدَ كشفٍ خاصّة وضبطًا خاصًا. ومنهج لِنرصد كلَّ شيء مدمِّر؛ ركّز في البداية على الطبقتين أو الثلاث الأكثر حرجًا، ووسِّع مع النضج.

    النموذج (داخلي / MSSP / هجين):

    • داخلي؛ تحكّمٌ كامل، خصوصيّةٌ قصوى، لكنّه للورديّات على مدار الساعة يحتاج 6-8 محلّلين على الأقل (سنويًا 4-7 مليون ليرة موظفين)، ومرحلةَ صعودٍ طويلة. إلزاميٌّ للقطاعات الحسّاسة (الدفاع، البنية التحتية الحرجة، المالية الكبرى).
    • MSSP؛ بدايةٌ سريعة (4-8 أسابيع)، ورديّةٌ جاهزة على مدار الساعة، سنويًا 1,5-3,5 مليون ليرة. عيب؛ تَتدفّق السجلّات إلى مؤسسةٍ خارجية — لـ KVKK يجب إدراج DPA + موقع السجلّات في العقد. ويُفضَّل MSSP محلّي.
    • هجين؛ MSSP لـ L1 (فرز التنبيهات) + L2 (تحقيقٌ أوّلي)، وداخلي لـ L3 (تحقيقٌ عميق) + استجابة للحوادث + صيد التهديدات. النموذجُ المهيمن للشركات المتوسطة-الكبيرة — أفضلُ توازنٍ بين الكلفة والنطاق.

    هدفُ النضج؛ يتطوّر نضجُ SOC على مدى سنوات. ويُعرّف نموذجُ نضج SANS لـ SOC خمسةَ مستويات:

    المستوىالتعريفعتبةُ المؤسسة
    Level 1عشوائي، غيرُ موثَّقالأشهرُ الستّة الأولى
    Level 2قابلٌ للتكرار، مؤشّراتٌ أساسية6-18 شهرًا
    Level 3عمليّةٌ معرّفة، مخطَّطٌ مع MITRE ATT&CK، استخبارات تهديدات18-36 شهرًا
    Level 4مَقيسٌ ويتحسّن باستمرار، صيدُ تهديدات نشط3-5 سنوات
    Level 5مُحسَّن، كشفٌ معزَّز بالذكاء الاصطناعي، استباقي5+ سنوات

    هدفٌ عملي؛ في الاثني عشر شهرًا الأولى بين Level 2-3؛ خلال 24-36 شهرًا بين Level 3-4. لا تُلتفَت إلى ادّعاءات تسويق Level 5 — مراكزُ Level 5 الحقيقية موجودةٌ في عددٍ قليلٍ جدًا من المؤسسات (شركات التقنية الكبرى، الدفاع السيبراني الحكومي).

    2. جمع السجلّات؛ جودة الـtelemetry تُحدّد كلَّ شيء

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

    سجلّاتُ الـendpoint (EDR)؛ إنشاءُ العمليات، تعديلُ الملفات، تغييرُ الـregistry، اتصالُ الشبكة، تنفيذُ PowerShell. وWindows Defender for Endpoint وCrowdStrike Falcon وSentinelOne ووكيلُ Wazuh هي الخياراتُ المؤسسية. وSysmon (Microsoft) بديلٌ مجاني؛ مع sysmon-config صحيح (مثلًا SwiftOnSecurity) يُعطي 80 بالمئة من قيمة EDR.

    سجلّاتُ الشبكة؛ Firewall (deny/allow مع المصدر/الوجهة)، Proxy (طلب HTTP، User-Agent)، DNS (سجلُّ الاستعلام — حرجٌ لكشف تسريب البيانات عبر DNS)، NetFlow/IPFIX (خطُّ أساس حركة المرور). وعادةً تُتجاوَز سجلّاتُ DNS، لكنّها المصدرُ الأكثر قيمةً لكشف الحركة الجانبية ورد اتصال C2.

    سجلّاتُ الهوية؛ سجلُّ أحداث Active Directory (4624 تسجيلُ دخول، 4625 تسجيلُ دخولٍ فاشل، 4688 عملية، 4720 إنشاءُ مستخدم)، وسجلُّ تسجيل الدخول إلى Azure AD، وتحدّي MFA، والوصولُ المميَّز. هنا تُكتشَف هجماتُ Pass-the-Hash وGolden Ticket وKerberoasting.

    سجلّاتُ الـcloud؛ AWS CloudTrail (سجلُّ استدعاءات API)، Azure Activity Log، GCP Audit Log — مَن فعل ماذا في أيِّ موردٍ ومتى. وتظهر هنا أحداثٌ مثل جعل S3 bucket عامًا، وتغييرات IAM policy، وتغييرات VPC.

    سجلّاتُ التطبيقات؛ Access logs لتطبيقات الويب، API gateway (انتهاكُ rate limit، فشلُ المصادقة)، قاعدةُ البيانات (Query audit)، SaaS (Microsoft 365 unified audit log، Google Workspace admin log).

    معماريّةُ جمع السجلّات؛ النمطُ القياسي:

    [المصدرُ السجلّي]
        ↓ (syslog، agent، API)
    [شاحنُ السجلّ؛ Fluent Bit / Logstash / Wazuh agent]
        ↓ (تطبيع، إثراء)
    [الـbuffer؛ Kafka / Redis] (للحجم العالي)
        ↓
    [SIEM؛ Wazuh / ELK / Splunk / Sentinel]
        ↓
    [أرشيفٌ طويل الأجل؛ S3 / Azure Blob / MinIO]
    

    من منظور KVKK نقطتان حرجتان: (1) إن احتوت السجلّاتُ بياناتٍ شخصية (اسمُ المستخدم، IP، البريد الإلكتروني)، فعليك بصفتك مسؤولًا عن البيانات أن تُوضّح غرضَ المعالجة (المراقبةُ الأمنية) في سياسةٍ مكتوبة وأن تُعرّف فترةَ الاحتفاظ (عادةً 6-12 شهرًا hot، 12-24 شهرًا أرشيف). (2) ينبغي أن يبقى موقعُ السجلّات داخل تركيا أو ضمن حدود الاتحاد الأوروبي؛ وإن استُخدمت خدماتُ سحابةٍ أمريكية فـ DPA + Standard Contractual Clauses إلزاميان.

    البنيةُ التحتية لهندسة البيانات كثيرًا ما تكون حرجة لـpipeline سجلّات SOC — لا يمكن بناء SOC مستدام دون معرفةٍ بـ Kafka cluster وETL jobs وسياسة الأرشيف.

    3. اختيار SIEM؛ مصفوفةُ قرار Wazuh وELK وSplunk وSentinel

    SIEM (Security Information and Event Management) هو دماغُ SOC؛ يُمرّر السجلّات عبر قواعد الترابط ويُنتج التنبيهات. والاختيارُ الخاطئ لـ SIEM يُنتج مشروعَ هجرةٍ خلال 1-2 سنة؛ والاختيارُ الصحيح يَعيش 5-7 سنوات.

    Wazuh (مفتوحُ المصدر، مجاني):

    • المزايا؛ مجاني، on-prem ومتوافق مع KVKK، جمعٌ agent-based قوي، تخطيطُ قواعد MITRE ATT&CK مُضمَّن، FIM (مراقبةُ سلامة الملفات) + SCA (تقييمُ تكوين الأمن) + كشفُ الثغرات في حزمةٍ واحدة.
    • العيوب؛ واجهةٌ خام (Wazuh Dashboard قابلةٌ للاستخدام لكنّها ليست بمستوى Splunk)، التوسّعُ فوق 5 آلاف EPS (events per second) يَتطلّب ضبطَ Elasticsearch، يحتاج الفريقُ إلى خبرة Linux + Elasticsearch.
    • الأنسب؛ للمؤسسات الصغيرة والمتوسطة (200-2.000 مستخدم)، القطاعاتُ الحرجة لـ KVKK، فلسفةُ المصدر المفتوح.

    ELK Stack / OpenSearch:

    • المزايا؛ تحليلاتُ السجلّات قويةٌ جدًا، لوحاتٌ مخصّصة، توسّعٌ جيّد.
    • العيوب؛ ليس SIEM بمفرده — يجب كتابةُ قواعد الترابط يدويًا؛ ميزاتُ Elastic Security (X-Pack) مدفوعة (~125 دولار/host سنويًا).
    • الأنسب؛ المؤسسات التي تستخدم ELK أصلًا، أو ذات حاجةٍ عالية لتحليلاتٍ مخصّصة.

    Splunk Enterprise Security:

    • المزايا؛ الواجهةُ ولغةُ البحث (SPL) معيارُ القطاع، متجرُ تطبيقاتٍ واسع (1.500+ تكامل)، إضافةُ Enterprise Security المتقدّمة (ترابط، استخبارات تهديدات، إطارُ أصول).
    • العيوب؛ الترخيصُ مكلف — perpetual أو term-based، سنويًا 500-2.000 دولار/GB-يوم؛ لـ10TB/يوم سنويًا 1,8-7,3 مليون دولار. بسبب التسعير المعتمد على الـingestion يبقى بعيدًا عن متناول الشركات الصغيرة والمتوسطة.
    • الأنسب؛ المؤسسات الكبرى في المالية والاتصالات والتجزئة (5.000+ مستخدم) بميزانياتٍ أمنية بملايين الدولارات.

    Microsoft Sentinel (cloud-native، Azure):

    • المزايا؛ تكاملٌ مع منظومة Azure، KQL (Kusto Query Language) قوية، UEBA + Fusion correlation مع ذكاءٍ اصطناعي، pay-per-ingestion (~2-5 دولار/GB)، تكاملٌ أصيل مع Microsoft 365 / Defender.
    • العيوب؛ مرتبطٌ بـ Azure؛ لـ KVKK يجب اختيار منطقةِ الاتحاد الأوروبي (West Europe / North Europe) وتوقيع DPA. غيرُ ملائمٍ للمؤسسات on-prem-only.
    • الأنسب؛ المؤسسات الثقيلة في Microsoft 365 / Azure، استراتيجياتُ cloud-first، الحجمُ المتوسط إلى الكبير.

    مصفوفةُ القرار:

    المعيارWazuhELKSplunkSentinel
    الكلفةُ السنوية (2 آلاف مستخدم)500 ألف-2 مليون ليرة1-3 مليون ليرة250 ألف-1 مليون دولار+150-600 ألف دولار
    KVKK on-premكاملكاملكاملمنطقةُ الاتحاد الأوروبي + DPA
    مدّةُ التأسيس8-12 أسبوعًا8-14 أسبوعًا16-24 أسبوعًا4-8 أسابيع
    دعمُ MITRE ATT&CKأصلييدويأصلي (ES)أصلي
    تقاريرُ الامتثالمتوسطيدويقويقوي
    مهاراتُ الفريق المطلوبةLinux+ElasticElastic+LuceneSPL+adminKQL+Azure

    التوصيةُ العملية؛ الشركاتُ الصغيرة والمتوسطة = Wazuh؛ منظومةُ Microsoft = Sentinel؛ المؤسساتُ الكبرى = Splunk أو Sentinel. والمنعكسُ الخطأ؛ القول Splunk هو الأفضل — Splunk هو الأقوى مع الفريق والميزانية المناسبَين، لكنّه للفِرق الصغيرة يَنوء تحت الكلفة وعبء التشغيل.

    4. تخطيطُ MITRE ATT&CK؛ لغةٌ مشتركة وتغطيةُ الكشف

    إطارُ MITRE ATT&CK هو اللغةُ الأمنية المشتركة التي تُصنّف سلوكَ المهاجمين الواقعي بصورةٍ بنيوية. 14 تكتيكًا (Reconnaissance، Resource Development، Initial Access، Execution، Persistence، Privilege Escalation، Defence Evasion، Credential Access، Discovery، Lateral Movement، Collection، Command and Control، Exfiltration، Impact) × 200+ تقنية + 600+ تقنيةً فرعية. ينبغي لـ SOC إنتاجي أن يستخدم هذا الإطار لثلاثة أغراضٍ رئيسة:

    خريطةُ تغطية الكشف؛ تُربَط قواعدُ SIEM لديكم بمعرّفات تقنيات ATT&CK، فترون ما الذي يُرصَد وما هي البقاعُ العمياء. مثالٌ على التخطيط:

    قاعدةُ كشفتقنيةُ ATT&CK
    تنفيذُ أمرٍ مُرمَّز في PowerShellT1059.001
    توقيعُ Mimikatz على القرصT1003.001
    الوصولُ إلى ذاكرة عملية LSASST1003.001
    إنشاءُ خدمةٍ جديدة على host بعيدT1543.003
    استعلامُ DNS مريب (نمط DGA)T1071.004
    تشفيرٌ جماعي للملفات (ransomware)T1486

    يُجسّد ATT&CK Navigator (أداةُ ويبٍ مجانية) هذا التخطيط؛ الأخضرُ = مغطًّى، الأصفرُ = جزئي، الأحمرُ = غيرُ مغطًّى. لـ SOC إنتاجي ينبغي أن تستهدف التغطيةُ 60 بالمئة على الأقل (المؤسساتُ الناضجة 75-85 بالمئة). و100 بالمئة مستحيلٌ وغيرُ ضروري؛ بعضُ التقنيات (تهديدٌ من الداخل بصلاحياتٍ مشروعة) لا تُلتقَط بالكشف القائم على التواقيع، بل تُحلّ بـ behaviour analytics + DLP.

    تمرينُ الفريق الأرجواني؛ يحاكي الفريقُ الأحمر تقنياتِ ATT&CK محدّدة (Atomic Red Team، Caldera، Cobalt Strike)، ويتحقّق الفريقُ الأزرق من الكشف. دورةٌ شهرية؛ الأحمرُ يُخطّط ← يُنفّذ ← الأزرقُ يتحقّق ← بقعةٌ عمياء ← قاعدةٌ جديدة ← اختبارٌ مجدّد. وتُجري خدمتنا لمحاكاة الفريق الأحمر هذه الدورةَ بوصفها فريقًا خارجيًا؛ ويكتسب الفريقُ الداخلي تحقّقًا.

    تخطيطُ استخبارات التهديدات؛ أيُّ التقنيات تستخدمها جهةُ تهديدٍ محدّدة (APT29، FIN7، Conti، Lazarus، MuddyWater) — يُسحَب ملفُّ TTPs من صفحة ATT&CK Groups، وتُكتَب قواعدُ كشفٍ خاصّة بالمؤسسة. مثال؛ تستخدم APT29 كثيرًا سلسلةَ T1078 (Valid Accounts) + T1098 (Account Manipulation) + T1059.001 (PowerShell)؛ وتُكتَب قاعدةُ ترابطٍ تَلتقط تركيبَ هذه التقنيات الثلاث.

    أداةُ تقييم نضج ATT&CK؛ DeTT&CT (مفتوحُ المصدر) يُؤتمِت تحليلَ الفجوات في التغطية ويَرصد نقصَ مصادر السجلّات. والمؤسسات التي تُجري تقييمًا سنويًا تَنتقل خلال 18-24 شهرًا من تغطية 35-40 بالمئة إلى 70-75 بالمئة.

    5. خطُّ استخبارات التهديدات؛ تحويلُ الاستخبارات الخارجية إلى كشف

    استخباراتُ التهديدات (TI) هي تحويلُ المعرفة الخارجية بـمَن وما وكيف يُهاجم إلى كشفٍ ومنعٍ واستجابة. ثلاثُ مستوياتٍ من الجودة:

    TI استراتيجي؛ مشهدُ التهديدات القطاعي للإدارة — اتجاهاتُ APT، دوافعُ الهجمات على مستوى الدول، اقتصادُ الدارك ويب. صيغةُ تقريرٍ سنوي. Microsoft Digital Defense Report، CrowdStrike Global Threat Report، ENISA Threat Landscape، تقاريرُ BTK USOM.

    TI تشغيلي؛ معلوماتُ الحملات النشطة لمحلّلي SOC — أيُّ مجموعة APT تستهدف حاليًا أيَّ قطاع، وأيُّ initial access vector يُستخدم، وأيُّ malware family ناشط. Recorded Future، Mandiant Advantage، CrowdStrike Falcon Intelligence، STIX/TAXII feeds المفتوحة (AlienVault OTX، MISP)، نشراتُ USOM للتهديدات السيبرانية لتركيا.

    TI تكتيكي / IoC (مؤشّراتُ التسوية)؛ تستهلكه SIEM مباشرة — عناوينُ IP خبيثة، malware hashes، نطاقاتٌ خبيثة، أنماطُ URL، بصمةُ JA3، Yara rule. معيارُ STIX 2.1، بروتوكولُ نقل TAXII 2.1. أمثلةُ الـfeeds:

    Feedالنوعالكلفة
    AlienVault OTXمجتمعي، واسعمجاني
    Abuse.ch URLhaus / Feodo / SSL BLC2 للبرمجيات الخبيثة، ransomwareمجاني
    Spamhausbotnet، spamمجاني / مدفوع
    MISP community sharingقطاعيمجاني
    Recorded Futurepremium مؤسسي50-300 ألف دولار/سنة
    Mandiant AdvantageAPT، عميق100-500 ألف دولار/سنة
    USOM Türkiyeتهديدٌ محليمجاني (تسجيلٌ مؤسسي)

    معماريّةُ الـpipeline:

    [TI feeds؛ STIX/TAXII، JSON، CSV]
        ↓
    [منصةُ TI؛ MISP / OpenCTI / ThreatConnect]
        ↓ (إزالة التكرار، scoring، tagging)
    [إثراءُ SIEM؛ سياقٌ عند مطابقة IoC للتنبيه]
        ↓
    [SOAR playbook؛ block آلي / quarantine / تصعيدُ تنبيه]
    

    ممارسةٌ مهمّة؛ تُقاس جودةُ IoC بـعمرها + مصدرها + التحقّق منها. ودفعُ feed غيرُ متحقَّق منه مباشرةً إلى SIEM يُحدث انفجارَ false positive — يَرتفع عبءُ المحلّل لساعات بينما تَفوت تهديداتٌ حقيقية. وScoring (high confidence / medium / low) وTTL (مثلًا انتهاء بعد 30 يومًا) على IoC انضباطٌ إلزامي.

    MISP (Malware Information Sharing Platform، مفتوحُ المصدر) شائعٌ في SOC التركية — مجتمعاتُ التشارك القطاعية (MISP المغلق لمصارف BDDK الأعضاء، التنسيقُ بين TÜBİTAK BİLGEM وUSOM) تُنظّم تبادلَ IoC.

    تُوفّر خدمتنا لاستخبارات التهديدات طبقةَ الاستشارة التي تُثري هذا الـpipeline بتحليل TTPs خاصٍ بالمؤسسة.

    6. أتمتةُ SOAR؛ playbooks وخفضُ MTTR

    SOAR (Security Orchestration, Automation and Response) هو ذاكرةُ العضلات في SOC — يُؤتمِت خطواتِ الاستجابة المتكرّرة عبر playbooks، ويخفض MTTR (Mean Time To Respond)، ويُخفّف عبءَ محلّلي L1.

    أمثلةُ playbook نموذجية:

    الاستجابةُ لبريد التصيّد:

    1. تَهبط رسالةُ تصيّد مُبلَّغة من المستخدم إلى Inbox
    2. آليًا؛ فحصُ الروابط في sandbox (URLscan، VirusTotal، ANY.RUN)
    3. التحقّقُ من hash المرفقات في MISP/VT
    4. عند الخباثة؛ حذفُ الرسالة من جميع صناديق بريد المستخدمين (Microsoft 365 Compliance API)
    5. حظرُ نطاق المرسِل في email gateway
    6. إخطارُ المستخدمين
    7. إغلاقُ التذكرة كـresolved، تحديثُ مؤشّرات اللوحة
    8. يدويًا؛ 30 دقيقة. SOAR؛ 2-3 دقائق.

    كشفُ برمجيةٍ خبيثة على endpoint:

    1. تنبيهُ EDR ← ترابطُ SIEM
    2. آليًا؛ عزلُ host الـendpoint عن الشبكة (CrowdStrike/Defender API)
    3. سحبُ شجرة العمليات + hash الملف
    4. استعلامُ VirusTotal + Hybrid Analysis
    5. إخطارُ مدير المستخدم
    6. تعيينُ تذكرةٍ لمحلّل L2 (مع المرفقات)
    7. تجهيزُ ملاحظةِ تواصل مع المستخدم

    تدفّقُ تسجيل دخولٍ فاشل (Brute Force):

    1. كشفُ SIEM؛ 50+ تسجيلَ دخولٍ فاشلًا لنفس المستخدم خلال 10 دقائق
    2. آليًا؛ حظرٌ مؤقّت لـsource IP لمدة ساعة (firewall API)
    3. قفلٌ مؤقّت للحساب (AD API) — فقط إن كان المصدرُ من الداخل
    4. فرضُ تحدّي MFA
    5. إخطارٌ بـ SMS إلى المستخدم
    6. تذكرةٌ لمحلّل L1 — مراجعةٌ يدوية

    منصّاتُ SOAR الشائعة:

    المنصةالنوعالترخيص
    Cortex XSOAR (Palo Alto)مؤسسي، رائدُ السوق100-500 ألف دولار/سنة
    Splunk SOARمنظومةُ Splunk60-300 ألف دولار/سنة
    Microsoft Sentinel playbooksأصيلٌ في Azure، Logic Appspay-per-execution
    Tinesحديث، no-code20-100 ألف دولار/سنة
    Shuffleمفتوحُ المصدرمجاني
    n8n + customworkflow عاممجاني / مُستضاف

    تحذيرٌ حرج — تصميمُ playbook يَتطلّب انضباطًا:

    • playbook حظر IP المشتبه به تلقائيًا المُصمَّم بصورةٍ خاطئة قد يَحظر VPN الشركة أو IP عميل في الإنتاج. ويُسمَّى هذا automation self-DoS.
    • النمط؛ في الأشهر الستّة الأولى يَعمل لـدعم القرار — تُشغَّل خطواتُ playbook آليًا، وتَتعلّق الخطوةُ الأخيرة بـبوّابة موافقة محلّل L2. وتُزال البوّاباتُ تدريجيًا مع تراكم الثقة.
    • يحتاج كلُّ playbook مسارَ تراجع؛ ما فعلته يجب أن تستطيع إلغاءَه (مثلًا استعادةُ ملفٍ أُحيلَ سهوًا إلى الـquarantine).
    • سجلُّ تدقيق إلزامي؛ أيُّ playbook اتّخذ أيَّ إجراءٍ ومتى — من أجل KVKK + الفحص الجنائي.

    تُنضّج خدمتنا للاستجابة للحوادث قدرةَ الاستجابة في SOC من خلال مكتبة playbooks وتمارين tabletop وحلقاتِ مراجعة ما بعد الحادث.

    7. النضجُ المستمر؛ مؤشّرات، صيدُ تهديدات، تدريب

    SOC ليس مشروعًا ينتهي يومَ الإطلاق؛ بل انضباطٌ حيّ. ويبدأ العملُ الحقيقي بعد الأشهر الستّة الأولى. ثلاثةُ تدفّقاتٍ متوازية:

    المؤشّراتُ وKPI؛ مؤشّراتٌ عددية لصحّة SOC. الحدُّ الأدنى:

    المؤشّرالهدفالمعنى
    MTTD (Mean Time To Detect)<30 دقيقة P1، <4 ساعات P2في كم من الوقت يُكتشَف التهديد
    MTTR (Mean Time To Respond)<2 ساعة P1، <8 ساعات P2في كم من الوقت تَكتمل الاستجابة
    حجمُ التنبيهات / يوممتابعةُ الاتجاهاتالانفجاراتُ تُشير إلى ضبطٍ ضروري
    معدّلُ false positive<15 بالمئةالمعدّلُ العالي يَستوجب ضبطَ القواعد
    معدّلُ التنبيهات التي لمسها محلّل70 بالمئة+إنتاجيّةُ L1
    تغطيةُ ATT&CK60 بالمئة+نضجُ الكشف
    SLA التذاكرِ المغلقة90 بالمئة+الانضباطُ التشغيلي
    ساعاتُ صيد التهديدات / أسبوع8-20 ساعةالسعةُ الاستباقية

    اللوحة؛ تصويرُ مؤشّرات SIEM على Grafana + اجتماعُ مراجعة عمليات أسبوعي.

    صيدُ التهديدات؛ بحثٌ عن تهديدٍ استباقيٌّ غير مدفوعٍ بالتنبيهات. قائمٌ على الفرضيات؛ لو كانت APT29 في بيئتنا فأيُّ أنماط سجلٍّ ستتركها؟ ← مسحُ السجلّات يدويًا ← التحقّقُ من الاكتشاف ← كتابةُ قاعدة كشفٍ جديدة. تخصيصُ 8-20 ساعةً أسبوعيًا، يقوم به محلّلٌ Senior (L3). صيدُ التهديدات + تحليلُ فجوات تغطية ATT&CK أسرعُ طريقٍ لرفع النضج.

    التدريب؛ التطويرُ المستمر لفريق SOC. tabletop داخليٌّ شهري (حادثٌ خيالي، تمثيلُ أدوار، قرارات)، هدفُ شهادة كلَّ ستة أشهر (SC-200 لـ Sentinel، Splunk Power User، SANS GCIH/GCFA، Wazuh Certified Security Analyst)، حضورُ مؤتمراتٍ سنوية (Black Hat، BSides İstanbul، SOC Forum Türkiye).

    مراجعةُ ما بعد الحادث؛ بعد كل حادث P1/P2 يُجرى استرجاعٌ بلا لومٍ — ما الذي أمسكناه، وما الذي تأخّرنا في رؤيته، وما الذي فاتنا، وأيُّ كشفٍ يجب إضافته. تُكتَب ملاحظاتُ الاسترجاع في wiki، ويُجرى تحليلُ اتجاهاتٍ كلَّ ثلاثة أشهر.

    ملخّصٌ عملي؛ قائمةُ بداية

    الترتيبُ الصحيح لأوّل SOC إنتاجي لكم:

    1. تعريفُ النطاق؛ أيُّ الطبقتين أو الثلاث أولًا، وأيُّها مرحلةٌ ثانية.
    2. قرارُ النموذج؛ تحت 500 مستخدم = MSSP؛ بين 500-2.000 = هجين؛ 2.000+ حسّاس = داخلي.
    3. معماريّةُ جمع السجلّات؛ shipper + buffer + SIEM + أرشيف. سياسةُ احتفاظٍ مكتوبةٌ لـ KVKK.
    4. اختيارُ SIEM؛ الصغيرة والمتوسطة = Wazuh؛ Microsoft الثقيلة = Sentinel؛ المؤسساتُ الكبرى = Splunk/Sentinel.
    5. Endpoint EDR؛ Defender / CrowdStrike / SentinelOne / Wazuh agent. تكوينُ Sysmon (SwiftOnSecurity).
    6. تخطيطُ MITRE ATT&CK؛ الهدفُ الأول 50 بالمئة، و70 بالمئة+ خلال 12 شهرًا. ATT&CK Navigator + DeTT&CT.
    7. خطُّ استخبارات التهديدات؛ ابدأ بالـfeeds المجانية (OTX، Abuse.ch، USOM)، انشر MISP، انضباطُ scoring + TTL.
    8. SOAR؛ أوّلُ 5-10 playbooks في وضع دعم القرار، ثم الأتمتةُ الكاملة بعد ستة أشهر.
    9. لوحةُ المؤشّرات؛ Grafana + مراجعةُ عملياتٍ أسبوعية؛ تقريرُ KPI شهري إلى الإدارة.
    10. النضجُ المستمر؛ صيدُ تهديدات (أسبوعي)، فريقٌ أرجواني (شهري)، tabletop (شهري)، شهادات (كلَّ ستة أشهر)، مراجعةُ ما بعد الحادث (بعد كل P1/P2).

    هذه القائمةُ هي الحدُّ الأدنى للانضباط. ثم تُضاف فوقها إضافاتٌ قطاعية (تقاريرُ إضافية للائحة نظم معلومات BDDK، دمجُ عمليةِ بلاغ خرق KVKK خلال 72 ساعة، EWCS — Early Warning Cyber System لبنية تحتية حرجة EPDK). وقيمةُ SOC ليست في كونه قائمًا، بل في إمكانية قياس نضجه كلَّ أسبوع — القدرةُ على إعطاء إجاباتٍ موثَّقة عن لماذا تَنخفض المؤشّرات وأيُّ عمليةٍ نَجحت حين تَرتفع.

    شَيّد فريقُنا في شانلي أورفا قرة كوبرو خطوطَ SOC في قطاعات المالية والصحة والطاقة والتجارة الإلكترونية عبر هندسة تأسيس عمليات SOC وخدمات الاستجابة للحوادث. ولأجل تجربة SOC مؤسسية، أو استشارة اختيار SIEM، أو تقييم نضج SOC قائم، يمكنكم التواصل عبر نموذج الاتصال؛ والمكالمةُ الأولى للتقييم مجانية.


    eCloud Tech — فريقٌ مقرّه شانلي أورفا في تركيا، يعمل في البرمجيات المؤسسية والذكاء الاصطناعي والبلوكتشين والأمن السيبراني. Building Tomorrow.

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

    يستند القرار إلى ثلاثة متغيّرات. (1) حسّاسية البيانات ونطاق KVKK؛ للمؤسسات التي تُعالج بياناتٍ شخصية ذات فئة خاصّة (صحية، حيوية، مالية)، كثيرًا ما يخلق خروج السجلّات إلى الخارج مشكلةَ امتثال؛ فيصبح SOC داخليٌّ أو MSSP محلّيٌّ إلزاميًا. (2) ميزانية القدرة على مدار الساعة؛ يحتاج SOC الداخلي إلى ما لا يقلّ عن 6-8 محلّلين (3 ورديّات × 2 + قائد)، بكلفة سنوية 4-7 مليون ليرة تركية رواتب فضلًا عن البنية التحتية. ويُقدّم MSSP النطاقَ نفسه بكلفة 1,5-3,5 مليون ليرة سنويًا. (3) متطلَّبُ SLA للاستجابة للحوادث؛ يطلب العملاء الحرجون لـ P1 وقت MTTD/MTTR بـ15 دقيقة؛ وهذا صعبٌ حتى في الداخل، وينبغي كتابته في عقد MSSP. توصيةٌ عملية؛ تحت 500 مستخدم MSSP مُدار؛ بين 500-2.000 هجين (MSSP لـ L1/L2، وداخلي L3 + استجابة للحوادث)؛ 2.000+ في قطاعٍ حسّاس SOC داخلي مع استشاراتٍ مختصّة في استخبارات التهديدات.

    مقالات ذات صلة