حرب الطبقة الدلالية في بيانات الأمن: اقتصاديات الحوسبة وراء مواصفات بحث Google SecOps

وثيقة تعلّمك كيف توفّر المال، وتكشف تحولًا هيكليًا في الصناعة بأكملها

أصدرت Google Security Operations (المعروفة سابقًا باسم Chronicle) وثيقة حول أفضل ممارسات البحث في UDM. تُقرأ كوثيقة تقنية نموذجية لمورّد: تتحدث عن الحقول، والعوامل، وضبط الأداء، واستكشاف الأخطاء وإصلاحها.

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

تفتتح الوثيقة بتحذير — إذا بُني الاستعلام بشكل غير صحيح، فسيستهلك البحث قدرًا كبيرًا من الموارد الحسابية، وسيتغير الأداء أيضًا وفقًا لحجم البيانات وتعقيدها في المثيل. ثم تسرد، شبه بنبرة مستشار تكاليف، بندًا بندًا: «الحقول عالية الأداء» و«الحقول المستبعدة» و«كيفية تضييق النطاق الزمني».

هذا ليس تعليمًا نحويًا. هذه اقتصاديات الحوسبة. عندما تحتاج وثيقة رسمية لمنتج أمني إلى تخصيص مساحة كبيرة لتعليم المستخدمين كيف ينفقون أقل، ويحسبون أقل، ويمسحون بيانات أقل، فهذا يعني أن التناقض المحوري في العمليات الأمنية قد انتقل من «هل يمكننا رؤية الهجوم؟» إلى «هل نستطيع تحمّل كلفة رؤيته؟».

القائمة البيضاء للحقول: المخطط هو سلطة البنية التحتية

الجزء الأكثر إفادة في الوثيقة هو أنها تقدّم لكل فئة من سيناريوهات الاستعلام قائمة واضحة بـ«حقول UDM عالية الأداء». البيانات الوصفية، والكيان الرئيسي (principal)، والمصدر، والهدف، والشبكة، والنتائج الأمنية — ست فئات من الحقول تُسرد واحدة تلو الأخرى، مع توضيح صريح بأن هذه الحقول «مُحسّنة للاسترجاع السريع».

يعكس هذا حقيقة ناضجة لكن كثيرًا ما تُتجاهل: نموذج البيانات الموحّد ليس مجرد مواصفة بيانات، بل هو تعريف لحدود قدرات الاستعلام.

في عالم السجلات الخام، يمكن نظريًا البحث في أي حقل، لكن الثمن هو مسح الجدول كله. أما في عالم UDM، فبعض الحقول تُوصل بالفهرس ومسارات الاسترجاع، بينما تعيش حقول أخرى في النص الأصلي ولا تُحلّل إلا عند الضرورة. هذه الطبقات ليست تفصيلًا تقنيًا، بل رهان من مصممي المنتج على طريقة التحقيق الأمني في المستقبل — فهم يرون أن ما يستخدمه المحققون فعليًا وبوتيرة متكررة هو أسماء المضيفين، وعناوين IP، وتجزئات الملفات، ومعرّفات العمليات، ومعرّفات المستخدمين، وعناوين البريد الإلكتروني، وأساليب HTTP، وأسماء القواعد الأمنية.

هذه القائمة بحد ذاتها هي صورة جانبية لـ«سلوكيات التحقيق الأمني»: الوحدة الذرية لاصطياد التهديدات الحديثة هي معرّفات كيانات قابلة للربط، وليس نصًا حرًا.

بالنسبة للمنافسين، هذه القائمة هي أيضًا جدار. من يعرّف الحقول يعرّف طريقة كتابة قواعد الكشف، والنموذج الذهني للمحللين، وتكلفة الانتقال خارج هذه المنصة. المخطط (schema) لم يكن محايدًا قط؛ إنه الشكل الملموس لسلطة البنية التحتية.

الحقول المستبعدة عمدًا: زاوية مكشوفة من اقتصاديات الحوسبةيوجد في الوثائق قدر نادر من الصراحة: بعض الحقول مُستبعدة عمدًا من مرشحات البحث، بما في ذلك metadata.id وmetadata.product_log_id وجميع حقول *.timestamp. والسبب مذكور بشكل مباشر——فالقيم الفريدة في هذه الحقول تُنتج ارتفاعًا في التمايز (high cardinality)، ما يُدخل تباينًا إحصائيًا ويضر بأداء البحث.

تستحق هذه الجملة أن تُقرأ مرارًا.

في مجال بيانات الرصد والأمان، ظل ارتفاع التمايز (high cardinality) الخصم الأكثر عنادًا في بنية التكاليف. فحقل يحتوي على ملايين أو حتى مليارات القيم الفريدة يكاد يكون من المستحيل فهرسته بكفاءة. أمام المورّد خياران لا ثالث لهما: إما أن يتحمّل العبء ويحوّل التكلفة إلى المستخدم، وإما أن يحجبه عن طبقة البحث السريع، فيدفع المستخدم تكلفة أعلى عند الحاجة.

اختارت Google الخيار الثاني، وكتبت ذلك في وثائق عامة. وهذا يعني أنها اعترفت بأمر واحد: في منصات بيانات الأمان، ليست كل البيانات خُلقت متساوية.

والأكثر إثارة للانتباه أن الطوابع الزمنية صُنفت ضمن هذه الفئة. كان ينبغي أن يكون الوقت البعد الأول في التحقيق الأمني، لكن لأن قيم الوقت شبه لا نهائية، فإنه لا يصلح كشرط مطابقة دقيق عالي الفعالية من حيث التكلفة. البديل الذي تقدّمه الوثائق هو استخدام ثواني Unix epoch للمقارنة، أو استدعاء دوال الوقت في YARA-L لتحويل التواريخ——وبعبارة أخرى، ترجمة «الوقت القابل للقراءة البشرية» إلى «أعداد صحيحة قابلة للفهرسة آليًا»، مع تحميل المستخدم تكلفة هذه الترجمة.

هذا تنازل هندسي نموذجي، وخيار نموذجي في نموذج العمل.

ساعتان: الانفصال بين وقت الحدث ووقت الاستيعاب

وثمة تفصيل آخر في الوثائق يسهل تجاهله لكنه عميق الدلالة، يتعلق ببيان «البيانات المستوعبة حديثًا لكن طوابعها الزمنية أقدم»: يعتمد النطاق الزمني للبحث على الطابع الزمني للحدث بعد التحليل، وليس على الطابع الزمني لاستيعاب السجل الأصلي.

بل إنها تقدّم حتى حلًا مضادًا——إذا أردت البحث في طوابع أحداث قديمة عن سجلات مستوعبة حديثًا، فيجب استخدام خيار All time، والاستعلام بدلًا من ذلك عن metadata.ingested_timestamp.

وخلف هذا تكرار لمشكلة قديمة في مجال معالجة التدفقات في السياق الأمني: الفصل بين وقت الحدث (event time) ووقت المعالجة (processing time). في الأنظمة الموزعة، يؤدي تأخر السجلات، وانحراف الساعات، والتخزين المؤقت للوكلاء، وإعادة رفع البيانات من الأجهزة غير المتصلة، إلى فصل وقت وصول البيانات عن وقت وقوع الحدث.

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

انفصال الكيانات عن الأحداث: التعامل مع البيانات السياقية بشكل منفصل

يوضح المستند صراحة: إذا استُخدم metadata.log_type = "..." للبحث في أنواع سجلات مثل AZURE_AD_CONTEXT، WORKSPACE_USERS من الكيانات أو السياق، فسيعيد نتائج فارغة — لأن بحث UDM لا يستعلم إلا عن سجلات أحداث UDM. وللوصول إلى هذه البيانات، لا بد من استخدام صيغة graph، عبر مسارات مثل graph.metadata.event_metadata.log_type أو graph.entity.user.email_addresses.

هذه التفصيلة تكشف عن تفرع في معمارية البيانات الأمنية: الأحداث (events) والكيانات (entities) يجري تخزينها والاستعلام عنها بشكل منفصل.

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

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

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

الحقول المكررة وفخ الصمت في any

في المستند فقرة عن "الحقول المكررة"، نبرتها هادئة، لكن عواقبها ليست بالقليلة. حقول مثل principal.ip، target.file.md5 يمكنها تخزين قيم متعددة في حدث واحد. وبشكل افتراضي، تُقيَّم باستخدام المعامل any: فبمجرد أن تستوفي أي قيمة واحدة في الحقل الشرط، يصبح المُسند بأكمله صحيحًا.المثال الوارد في الوثيقة نموذجي للغاية: عند البحث عن principal.ip != "1.2.3.4"، إذا كان حدث ما يحتوي في الوقت نفسه على 1.2.3.4 و5.6.7.8، فسيظل هذا الحدث مطابقًا. لأن 5.6.7.8 استوفى شرط «لا يساوي».

بالنسبة للمحلل البشري، هذا يكاد يكون منافيًا للحدس. وبالنسبة للمهندس الذي يبني قواعد كشف آلية، فهذا فخ يمكن أن يؤدي مباشرة إلى إيجابيات كاذبة وسلبيات كاذبة.

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

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

الشروط المسبقة لوكيل التحقيق بالذكاء الاصطناعي مكتوبة في هذه الوثيقة

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

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

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

الشرط الثالث: يجب أن تكون الواجهة مُهيكلة. توصي الوثيقة باستخدام قوائم مرجعية (reference lists) بدل مطابقة القيم على نطاق واسع، واستخدام Unix epoch بدل سلاسل الوقت البشرية، ومسارات حقول واضحة بدل البحث النصي الحر — وكل هذا يحوّل «التحقيق» من نشاط بشري غامض إلى مجموعة خطوات محددة قابلة للاستدعاء برمجيًا.

بعبارة أخرى، مفهوم مثل agentic SOC لا يقوم على وجود وكيل أولًا ثم تكييف المنصة معه. بل الترتيب الحقيقي هو العكس تمامًا: تُنظّم المنصة أولًا نموذج البيانات ودلالات الاستعلام وحدود التكلفة في شكل قابل للاستخدام الآلي، وعندها يجد الوكيل موضع قدم. هذه الوثيقة جزء من هذا التحضير، رغم أنها لا تقول ذلك عن نفسها.

توحيد المخططات: منافسة هادئة لكن حاسمة## توحيد المخططات: منافسة هادئة لكنها حاسمة

إذا أخذنا خطوة إلى الوراء، فإن الساحة التي تقف فيها هذه الوثيقة هي المنافسة على توحيد مخططات بيانات الأمن (schema).

على جانب واحد توجد مخططات المورّدين الخاصة، مثل UDM من Google. ميزتها أنها مُحسّنة بعمق، ومتكاملة بإحكام مع محرك البحث والكشف الخاص بها؛ والثمن هو تكلفة الانتقال وانغلاق المنظومة. وعلى الجانب الآخر يوجد اتجاه المخططات المفتوحة الذي تدفع إليه الصناعة بشكل جماعي، وهدفه أن تحصل السجلات من مصادر مختلفة على دلالات حقول متسقة، وتقليل عوائق التعاون بين المنصات.

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

لكن هذه التفاصيل تحدد واقع الجيل القادم: هل يمكن إعادة استخدام قواعد الكشف عبر المنصات، وهل يمكن تبادل استخبارات التهديدات بين المؤسسات، وهل يستطيع وكلاء الذكاء الاصطناعي فهم البيانات الواردة من مورّدين مختلفين، وكم تبقى لفرق الأمن من مساحة تفاوض قبل أن يتم قفلهم داخل منصة واحدة.

الخاتمة: العمليات الأمنية تتحول من تجارة التخزين إلى تجارة الطبقة الدلالية

على مدى العقدين الماضيين، كانت السردية الأساسية لـ SIEM هي "تجميع السجلات مركزيًا". كان التخزين تكلفة، والاسترجاع وظيفة.

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

لا تكمن قيمة وثيقة Google SecOps هذه فيما تعلّمه من تراكيب، بل في أنها تكشف بصدق قواعد اللعبة الجديدة: الحقول ذات مراتب، والوقت ملتبس، وللاستعلام ثمن، وللدلالة حدود.

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

---

مصدر المعلومات: Search best practices | Google Security Operations