كيف يعمل محرك كشف SIEM من الداخل؟

في المقال السابق خرج من Falco تنبيه بصيغة JSON عند فتح ملف حساس، لكن تنبيهاً واحداً من جهاز واحد لا يصنع دفاعاً، فالمؤسسة فيها مئات الأجهزة وعشرات الخدمات، كل منها يولد سجلات طوال اليوم، والمهاجم الذكي يوزع خطواته على عدة أجهزة حتى لا تلفت أي خطوة الانتباه وحدها. ومن هنا يأتي نظام إدارة المعلومات والأحداث الأمنية Security Information and Event Management واختصاراً SIEM: مكان واحد تتجمع فيه كل السجلات، فترى فيه الصورة الكاملة، وتطبق عليه قواعد تربط الخطوات المتفرقة في هجوم واحد. وقد يبدو من الوهلة الأولى أن SIEM مجرد قاعدة بيانات كبيرة للسجلات، لكن في الواقع فهو غير كذلك، فالصعوبة ليست في تخزين السجلات وإنما في توحيدها ثم فهمها ثم تحمل تكلفة ذلك دون أن تفلس أو تغرق فريقك بالتنبيهات. وسوف نرى في هذا المقال كيف يعمل محرك SIEM من الداخل، ونبني منه خط أنابيب مصغراً يعمل على جهازك ويطلق قاعدة كشف حقيقية على محاولات دخول فاشلة.

وهذا المقال من المرحلة المتقدمة كيف تبني منتجات الأمن السيبراني، وهو يكمل مقالين سابقين: مقال EDR الذي يولد الأحداث، ومقارنة حلول الأمن التي حسبت تكلفة SIEM التجاري:

دليلكيف يعمل وكيل EDR؟ من eBPF إلى قواعد الكشفكيف يرى وكيل EDR ما يجري داخل كل جهاز، ولماذا سائق النواة خطر، مع تشغيل Falco يكشف فعلاً مشبوهاً.دليلحلول الأمن التجارية وبدائلها مفتوحة المصدر: متى توفر فعلاً؟لكل فئة من حلول الأمن التجارية الشائعة في السعودية بديل مفتوح المصدر، وهنا تعرف متى يوفر عليك فعلاً ومتى يكون التجاري أفضل.

وسوف نناقش في هذا المقال ما يلي:

• مراحل خط الأنابيب: الاستقبال Ingestion والتفكيك Parsing والتوحيد Normalisation، ولماذا تحتاج مخططاً موحداً مثل ECS أو OCSF.
• التخزين والفهرسة وتكلفتهما، وقواعد الربط Correlation، وتحويل Sigma إلى استعلام المحرك، وإرهاق التنبيهات Alert Fatigue، وحساب تكلفة الاحتفاظ.
• البدائل المفتوحة: Wazuh وOpenSearch Security Analytics وGraylog وSecurity Onion، ورخصة كل منها، ونظرة سريعة على SIEM السحابي.
• تجربة عملية: خط أنابيب صغير Vector ثم Loki، وقاعدة Sigma يحولها pySigma فتطلق على محاولات SSH فاشلة مولدة.

خط الأنابيب: من سجل خام إلى تنبيه

لنمش مع سجل واحد من لحظة توليده إلى أن يصير تنبيهاً. والصورة التالية تبين المراحل:

وفيما يلي كل مرحلة:

• الاستقبال Ingestion: جمع السجلات من كل مصدر بصيغه المختلفة، ولكل مصدر طريقته: syslog، وملفات، وواجهات برمجية، ووكلاء. وهذه مرحلة تبدو بسيطة لكنها تتعطل عند أول مصدر يرسل بصيغة غير متوقعة.
• التفكيك Parsing: كل سجل نص غير منظم، فسطر SSH شيء وسطر جدار الحماية شيء آخر، والتفكيك يستخرج منه الحقول: من فعل، ماذا، متى، من أي عنوان. وهذا هو أكثر ما يستهلك الوقت، لأن كل منتج يكتب سجلاته بشكله.
• التوحيد Normalisation: بعد التفكيك تريد أن تسمي الحقول بأسماء موحدة، فعنوان المصدر يسمى source.ip سواء جاء من جدار الحماية أو من الخادم، وإلا لم تستطع كتابة قاعدة واحدة تعمل على الجميع. وهنا تأتي المخططات الموحدة، وسنفصلها بعد قليل.
• التخزين والفهرسة Storage and Indexing: حفظ الأحداث بشكل يتيح البحث السريع، والفهرسة هي ما تجعل السؤال يرجع في ثوان لا ساعات، لكنها أيضاً أكبر بند تكلفة كما سنرى.
• الربط Correlation: تطبيق قواعد الكشف على الأحداث، إما حدثاً حدثاً، أو بربط عدة أحداث: مئة محاولة دخول فاشلة ثم نجاح واحد من نفس العنوان مثلاً، وهو نمط لا تراه إلا إذا نظرت إلى الأحداث مجتمعة.

لماذا تحتاج مخططاً موحداً: ECS وOCSF

وقد يتساءل البعض: لماذا لا نبحث في السجلات كما هي؟ والإجابة أن كل مصدر يسمي الشيء نفسه باسم مختلف، فعنوان المصدر src_ip هنا وclientIP هناك وremote_addr في ثالث، فلو كتبت قاعدة تبحث عن عنوان مشبوه لاحتجت أن تكتبها بعشر صيغ. والحل أن توحد الحقول في مخطط واحد عند الاستقبال، ثم تكتب القاعدة مرة. وهناك مخططان مفتوحان شائعان: المخطط المشترك من Elastic واسمه Elastic Common Schema واختصاراً ECS، والإطار المفتوح لمخطط الأمن السيبراني Open Cybersecurity Schema Framework واختصاراً OCSF الذي أطلقته AWS وSplunk وشركاء آخرون في أغسطس 2022 وانضم إلى مؤسسة Linux في نوفمبر 2024. ولاحظ تطوراً مهماً: أعلنت Elastic في أبريل 2023 عن المساهمة ب ECS في مشروع OpenTelemetry لتقارب المخططين في واحد، فالاتجاه نحو لغة مشتركة واحدة للأحداث.

قواعد الكشف: Sigma واستعلام المحرك

بعد أن توحدت الحقول، كيف تكتب قاعدة الكشف؟ المشكلة أن كل محرك SIEM له لغة استعلام مختلفة، فلو كتبت قواعدك بلغة محرك معين صرت أسيراً له. والحل صيغة Sigma، وهي صيغة عامة تصف حدث سجل مشبوهاً بشكل مستقل عن المنتج، ثم تحولها بأداة إلى لغة أي محرك. والصورة التالية تبين الفكرة:

والأداة المفتوحة لذلك هي مكتبة pySigma وأداة سطر الأوامر sigma-cli، وبها تحول القاعدة إلى LogQL ل Loki، أو إلى Lucene ل OpenSearch، أو إلى لغة Elasticsearch، أو إلى استعلام Splunk. وهذا ما سنفعله حرفياً في التجربة. ورخصة قواعد SigmaHQ هي رخصة قواعد الكشف Detection Rule License، وpySigma برخصة LGPL.

التكلفة: أين تذهب الفاتورة؟

هنا جوهر مشكلة SIEM، فالتكلفة لا تأتي من الكشف وإنما من التخزين. كل حدث يجب أن يخزن ويفهرس ويحفظ مدة طويلة، وضوابط الهيئة الوطنية للأمن السيبراني في المكون 2-12 تطلب الاحتفاظ بالسجلات مدة لا تقل عن اثني عشر شهراً كما رأينا في مقال ضوابط NCA ECC، وهذا يعني قرصاً كبيراً يكبر كل يوم. ولتقدير الحجم، تعطي وثائق Wazuh مثالاً محسوباً: بيئة فيها 80 محطة عمل و10 سيرفرات و10 أجهزة شبكة تحتاج قرابة 231 جيجابايت لتخزين تنبيهات 90 يوماً، فإذا مددتها إلى سنة كاملة تضاعف الرقم. والدرس العملي: كل مصدر جديد يضيفه إلى SIEM يزيد الفاتورة، ولذلك أول قرار هندسي ليس «ماذا أجمع؟» وإنما «ما الذي يستحق الحفظ، وكم أحتفظ به؟»، فالفرق بين جمع كل شيء وجمع ما يفيد قد يكون أضعافاً في التكلفة.

إرهاق التنبيهات Alert Fatigue

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

البدائل مفتوحة المصدر

فئة SIEM من أغنى الفئات ببدائل مفتوحة ناضجة:

• Wazuh: برخصة GPL-2.0، منصة كاملة تجمع الوكيل على الأجهزة والسيرفر الذي يطبق القواعد والفهرس ولوحة الإدارة، وتصف نفسها بأنها توحد قدرات XDR وSIEM، وهي أقرب خيار مفتوح إلى منتج SIEM جاهز دون جزء مدفوع.
• OpenSearch مع إضافة Security Analytics: برخصة Apache-2.0، والإضافة تطبق قواعد Sigma جاهزة وتنشئ التنبيهات، لكنها محرك بحث تبني فوقه أنت المحللات واللوحات.
• Graylog: انتبه للرخصة، فخادم Graylog برخصة SSPL وهي مصدر متاح Source-available وليست مفتوحة بتعريف OSI، ويكفيك هذا إن كنت تستخدمه داخلياً ولا تقدمه خدمة لغيرك، والنسخ المؤسسية والأمنية مدفوعة.
• Security Onion: توزيعة كاملة لمراقبة الشبكة والأجهزة تجمع Suricata وZeek وElastic، ورخصتها Elastic License 2.0، فهي أيضاً مصدر متاح.

أما SIEM السحابي مثل Microsoft Sentinel وGoogle Security Operations وSplunk (الذي أكملت Cisco شراءه في مارس 2024)، فيحل عنك مشكلة التشغيل والتوسع مقابل أن يرتبط السعر غالباً بحجم البيانات المدخلة، وهو ما يجعل الفاتورة تكبر مع كل مصدر، وقد فصلنا حساباً لثلاث سنوات بين Sentinel وبديل مفتوح في مقارنة حلول الأمن.

تجربة عملية: خط أنابيب يطلق قاعدة Sigma حقيقية

سوف نبني خط أنابيب SIEM مصغراً: نولد سجل دخول SSH فيه محاولات فاشلة، ونشحنه ب Vector إلى Loki، ثم نحول قاعدة Sigma ب pySigma إلى LogQL ونشغلها على Loki فتطابق المحاولات الفاشلة وتتجاهل الناجحة. والصورة التالية تبين التجربة:

أولاً نولد سجلاً واقعياً فيه أربعون محاولة دخول فاشلة وثلاث ناجحة، وهذا السجل من توليدنا لا من هجوم حقيقي:

Oct 09 14:00:00 vps sshd[1000]: Failed password for oracle from 203.0.113.7 port 46578 ssh2
Oct 09 14:00:03 vps sshd[1001]: Failed password for test from 203.0.113.90 port 42209 ssh2
...
Oct 09 14:03:25 vps sshd[2001]: Accepted password for ubuntu from 192.0.2.10 port 51515 ssh2

ثم نشغل Loki، ونشغل Vector ليقرأ الملف ويشحنه إلى Loki بصيغة logfmt مع حقل message:

docker network create lab-sec-siem
docker run -d --name lab-sec-loki --network lab-sec-siem -p 127.0.0.1:13100:3100 \
  --memory 512m -v "$PWD/loki.yaml":/etc/loki/local-config.yaml:ro \
  grafana/loki:3.3.0 -config.file=/etc/loki/local-config.yaml

docker run -d --name lab-sec-vector --network lab-sec-siem --memory 512m \
  -v "$PWD/vector.yaml":/etc/vector/vector.yaml:ro \
  -v "$PWD/auth.log":/data/auth.log:ro \
  timberio/vector:0.44.0-debian --config /etc/vector/vector.yaml

الآن الجزء الأهم: نحول قاعدة Sigma التي تصف محاولة الدخول الفاشلة إلى لغة Loki ب sigma-cli، والقاعدة نفسها بسيطة:

detection:
  selection:
    message|contains: 'Failed password'
  condition: selection

ونحولها بالأمر التالي:

sigma convert -t loki ssh_fail.yml

والمخرج سوف يكون استعلام LogQL جاهزاً:

{job=~".+"} | logfmt | message=~`(?i).*Failed\ password.*`

نشغل هذا الاستعلام على Loki عبر واجهته، والمخرج يبين أنه طابق أربعين سطراً بالضبط:

curl -s -G "http://127.0.0.1:13100/loki/api/v1/query_range" \
  --data-urlencode 'query={job=~".+"} | logfmt | message=~`(?i).*Failed\ password.*`' ...

matched: 40

ونحول القاعدة نفسها إلى صيغة قاعدة تنبيه Loki Ruler لتعمل باستمرار لا مرة واحدة:

sigma convert -t loki -f ruler ssh_fail.yml

expr: sum(count_over_time({job=~".+"} | logfmt | message=~`...Failed\ password...` [1m])) or vector(0) > 0

وعند تشغيل هذا على بياناتنا رجع الرقم 40. في المخرجات أعلاه لاحظ التالي:

• القاعدة طابقت الأربعين محاولة فاشلة بالضبط، وتجاهلت الثلاث الناجحة، وهذا هو جوهر الكشف: نمط واحد يفصل المشبوه عن العادي.
• كتبنا القاعدة مرة بصيغة Sigma، وحولناها آلياً إلى LogQL، ولو أردنا OpenSearch بدل Loki لغيرنا كلمة واحدة في الأمر، وهذا هو مكسب الصيغة المستقلة عن المنتج.
• الصيغة ruler تحول القاعدة من بحث يدوي إلى تنبيه مستمر، وهو الفرق بين التحقيق بعد الحادثة والكشف أثناءها.
• كل هذا جرى على جهاز واحد بأدوات مفتوحة، وهذا بالضبط نموذج SIEM المصغر الذي تبني عليه.

وأخيراً نحذف ما أنشأناه بأسمائه بالضبط:

docker rm -f lab-sec-vector lab-sec-loki
docker network rm lab-sec-siem

بناء منتج كهذا: أين الصعوبة الحقيقية؟

قد يبدو بناء SIEM مجرد تركيب محرك بحث فوقه قواعد، لكن الصعوبة في خمسة أمور:

• التفكيك والتوحيد Parsing: كل منتج يكتب سجلاته بشكله، وكتابة محلل Parser لكل مصدر وصيانته مع كل تحديث للمصدر هو أكثر العمل وأقله بريقاً وأكثره استمراراً.
• تكلفة التخزين Scale: حجم السجلات يكبر بلا توقف، وتصميم تخزين يوازن بين سرعة البحث وتكلفة القرص ومدة الاحتفاظ مسألة هندسية صعبة تقرر ربح المنتج أو خسارته.
• جودة القواعد Detection Quality: قاعدة تكشف الهجوم دون أن تطلق إنذارات كاذبة كثيرة تحتاج فهماً عميقاً للتهديدات وضبطاً مستمراً، وهي القيمة التي يدفع العميل ثمنها.
• التوسع في الإدخال: استقبال ملايين الأحداث في الثانية دون فقد ودون أن يتعطل المحرك عند ذروة هجوم، وهو وقت تزداد فيه الأحداث فجأة، يحتاج تصميماً يتحمل الضغط.
• الثقة والتكامل Trust: SIEM يرى كل شيء في المؤسسة، فهو هدف ثمين بذاته، ويجب أن يحمى بعناية، وأن يتكامل مع عشرات المصادر التي يملكها العميل بالفعل.

إذا أردت بناء واحدة في منطقتنا

كتابة محرك SIEM من الصفر منافسة مباشرة لمحركات بحث ناضجة مثل OpenSearch، وهذا نادراً ما يكون المدخل الأنسب. والمسار العملي أن تبني على المفتوح: Wazuh أو OpenSearch كمحرك، وVector أو ما يشبهه للاستقبال، وقواعد Sigma للكشف، ثم تصنع القيمة في الطبقة التي تحتاجها المؤسسات هنا: محللات Parsers جاهزة للخدمات الشائعة محلياً، وقواعد كشف مكتوبة لتهديدات تخص بيئاتنا، وربط التقارير بضوابط NCA ECC، وواجهة ولوحات بالعربية، ودعم قريب بالتوقيت نفسه. وهذه القيمة فوق محرك مفتوح، لا بناء المحرك نفسه، هي المدخل الواقعي، ونتجنب هنا أي أرقام عن حجم السوق لأنها تحتاج مصدراً موثقاً.

تشتري أم تبني؟

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

أخطاء شائعة

• جمع كل شيء ظناً أن الأكثر أفضل؛ فكل مصدر يزيد الفاتورة، والصحيح جمع ما يفيد الكشف والتحقيق فقط.
• البحث في السجلات دون توحيد الحقول؛ فتضطر لكتابة كل قاعدة بعشر صيغ، والصحيح التوحيد إلى مخطط مثل ECS أو OCSF عند الاستقبال.
• كتابة القواعد بلغة محرك واحد؛ فتصير أسيراً له، والصحيح صيغة Sigma ثم التحويل.
• تشغيل قواعد كثيرة متحمسة؛ فيغرق المحلل في إنذارات كاذبة حتى يتجاهل الحقيقي.
• نسيان مدة الاحتفاظ المطلوبة نظاماً؛ فتكتشف متأخراً أنك تحتاج تخزين سنة كاملة لا أسبوع.

الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

• SIEM يجمع سجلات المؤسسة في مكان واحد ليرى الصورة الكاملة ويربط خطوات الهجوم المتفرقة، والصعوبة في التوحيد والفهم والتكلفة لا في التخزين وحده.
• خط الأنابيب: استقبال، تفكيك، توحيد إلى مخطط مثل ECS أو OCSF، تخزين وفهرسة، ثم ربط ينتج التنبيه.
• تكتب القاعدة مرة بصيغة Sigma المستقلة عن المنتج، وتحولها ب pySigma إلى لغة أي محرك.
• التكلفة تأتي من التخزين والفهرسة ومدة الاحتفاظ، وجودة القواعد تقاس بدقتها لا بعددها حتى لا تغرق المحلل.
• البدائل المفتوحة: Wazuh (GPL-2.0) الأقرب لمنتج جاهز، وOpenSearch (Apache-2.0)، وGraylog (SSPL) وSecurity Onion (Elastic License 2.0) وهما مصدر متاح لا مفتوح.
• بنينا خط أنابيب Vector ثم Loki، وحولنا قاعدة Sigma ب pySigma إلى LogQL فطابقت أربعين محاولة فاشلة وتجاهلت الناجحة.

وفي المقالين التاليين نكمل الصورة: من أين يأتي السياق الذي يحول حدثاً عادياً إلى تنبيه خطير، أي منصة استخبارات التهديدات، ثم كيف تعمل بوابة أمن البريد:

دليلكيف تبني منصة استخبارات التهديدات؟ STIX وTAXIIكيف تجمع منصات التهديدات المؤشرات وتثريها وتشاركها، مع تجربة تطابق مغذي C2 حقيقياً بمؤشرات STIX.دليلكيف تعمل بوابة أمن البريد وتكشف التصيد؟كيف تفحص بوابة أمن البريد كل رسالة وتكشف التصيد والانتحال، مع تشغيل Rspamd وClamAV على رسائل اختبار.دليلكيف تبني منصة محاكاة الهجمات والتحقق من التعرض AEV؟كيف تعمل منصات AEV من الداخل لتثبت أي الهجمات ينجح خلف ضوابطك، مع تشغيل Caldera بسيناريو آمن.دليلكيف يعمل وكيل EDR؟ من eBPF إلى قواعد الكشفكيف يرى وكيل EDR ما يجري داخل كل جهاز، ولماذا سائق النواة خطر، مع تشغيل Falco يكشف فعلاً مشبوهاً.

سجل التحديثات

• أكتوبر 2026: كتابة المقال، وتنفيذ التجربة العملية على Docker Engine 29.8.0 مع Vector 0.44.0 وLoki 3.3.0 وsigma-cli 3.1.0، بتحويل قاعدة Sigma إلى LogQL ومطابقتها أربعين محاولة SSH فاشلة مولدة.