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



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

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

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

• تكون موحدة للأحداث من أي نوع والمصادر ؛
• صف بوضوح من تفاعل مع من وكيف ؛
• الحفاظ على جوهر وسياق التفاعل.

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

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

للعثور على الإجابة على هذه الأسئلة ، تحتاج إلى اللجوء إلى التحليلات ومحاولة تحليل أكبر عدد ممكن من قواعد التطبيع التي تم تطويرها بالفعل وتعمل في حلول SIEM قدر الإمكان لتحديد الأنماط الشائعة. كجزء من هذا العمل ، كان من الممكن تحليل أكثر من 3000 قاعدة تطبيع من أكثر من 100 مصدر مختلف من حلول مثل التقنيات الإيجابية MaxPatrol SIEM و Micro Focus ArcSight. أسفر التحليل عن الاستنتاجات التالية:

1. توجد مخططات التفاعل النموذجي.
2. في كل حدث فردي ، كقاعدة عامة ، هناك معلومات حول التفاعل على مستوى الشبكة وعلى مستوى التطبيق .
3. قد تختلف أنماط التفاعل النموذجية على مستويات مختلفة ، ويجب أخذ ذلك في الاعتبار.

مخططات اتصالات طبقة الشبكة والتطبيق

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

• الموضوع . كيان يؤثر على كائن. على سبيل المثال ، يقوم المستخدم بتغيير مفتاح التسجيل ، أو مضيف له IP 10.0.0.1 ، وإرسال حزمة إلى مضيف مع IP 20.0.0.1.
• كائن . الكيان المتأثر بالموضوع.
• المصدر كقاعدة ، المضيف الذي يسجل تفاعل الموضوع مع الكائن ويولد الحدث نفسه. على سبيل المثال ، سيكون المصدر جدار حماية يقوم بتسجيل إرسال الحزم من المضيف - الموضوع ذو IP 10.0.0.1 ، إلى المضيف - الكائن ذو IP 20.0.0.1.
• جهاز الإرسال هناك حالات عندما يتلقى SIEM الأحداث ليس مباشرة من المصدر ، ولكن من خادم وسيط تمر من خلاله هذه الأحداث. أبسط مثال هو خادم سجل متوسط. المثال أكثر تعقيدًا - عندما يكون جهاز الإرسال خادم إدارة ، على سبيل المثال ، Kaspersky Security Center. في هذه الحالة ، المصدر هو وكيل محدد لـ Kaspersky Endpoint Security.

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

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

مستوى الشبكة

المعرف الأساسي للكيانات على مستوى الشبكة هو عناوين IP. من المهم أن نفهم أنه قد يكون هناك معرفات أخرى ذات صلة - عناوين MAC على مستوى القناة ، FQDN - على مستوى التطبيق. السؤال الذي يطرح نفسه: هل يتحدثون عن نفس الكيان أو مختلف؟ هل يمكن لهذه المعرّفات أن تتغير بمرور الوقت مع نفس الكيان؟ سيتم تخصيص مقال منفصل لهذا الغرض ، فلننتقل الآن إلى حقيقة أن المعرف الرئيسي لنماذج التفاعل على مستوى الشبكة هو عنوان IP.

لذلك ، يمكن تقسيم مخططات التفاعل النموذجية لهذا المستوى إلى فئتين - أساسية ومتدهورة.

مخططات التفاعل الأساسية

مخطط 1. مخطط التفاعل الكامل

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

يلتقط الحدث أدناه دقة تفاعل الشبكة بين المضيفين بواسطة جدار الحماية Stonesoft (الآن Forcepoint) ، بينما لا يدخل الحدث نفسه SIEM مباشرة ، ولكن من خادم وسيسلوغ متوسط.



هنا:
40.0.0.1 - جهاز إرسال (خادم سجل نظام وسيط) ،
30.0.0.1 - المصدر (عقدة جدار الحماية) ،
10.0.0.1 - الموضوع (إرسال حزم UDP) ،
20.0.0.1 - كائن (استقبال حزم UDP).


الرسم التخطيطي 2: مخطط تجميع مباشر بدون جهاز إرسال

ليس دائما في مخطط التفاعل هو جهاز إرسال. كقاعدة ، يكون موجودًا عند استخدام خادم وسيط (على سبيل المثال ، خادم سجل نظام) لإرسال الأحداث ، أو عندما يكون الحل الذي يتم من خلاله تجميع الأحداث يحتوي على نظام إدارة مركزي - على سبيل المثال ، Kaspersky Security Center أو Check Point Smart Console أو Cisco Prime. بموجب هذا المخطط ، تقع الأحداث في SIEM مباشرة من المصدر. يتم وصف معظم الأحداث من خلال هذا المخطط بالذات. بالمناسبة ، يمكن رؤية مثال لمثل هذا الحدث في الشكل 1 ، إذا لم يكن هناك خادم سجل نظام وسيط فيه وتلقينا الأحداث مباشرة من جدار الحماية.



هنا:
30.0.0.1 - المصدر (عقدة جدار الحماية) ،
10.0.0.1 - الموضوع (إرسال حزم UDP) ،
20.0.0.1 - كائن (استقبال حزم UDP).


مخطط 3. التفاعل مع العديد من الكائنات

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

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

يوضح المثال التالي حدثًا من خادم IGMP Relay يتم من خلاله بث طلب عضوية الإرسال المتعدد.



هنا:
30.0.0.1 - المصدر (خادم ترحيل IGMP) ،
10.0.0.1 - الموضوع (طلب عضوية في مجموعة) ،
224.0.0.252 - الكائن (عنوان الإرسال المتعدد).

مخططات منحطة

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


مخطط 4. التفاعل بدون كائن

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

يوضح المثال كيف يستشعر خادم Symantec Management Server أن وكيل Symantec Endpoint Protection الذي يديره قد اكتشف ملفًا ضارًا على موقعه.



هنا:
30.0.0.1 - المصدر (خادم إدارة Symantec) ،
10.0.0.1 - الموضوع (Symantec Endpoint Protection Agent).


مخطط 5. الجمع بين دور الموضوع والشيء في المصدر

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

في هذا المثال ، يُبلغ المحول المستند إلى Cisco IOS أن واجهته انتقلت إلى حالة UP.



هنا 30.0.0.1 هو المصدر (التبديل).

مستوى التطبيق

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

تتضمن معظم أنواع الأحداث التفاعلات في وقت واحد على مستوى الشبكة ومستوى التطبيق. ومع ذلك ، نلاحظ أن الأحداث التي تم إنشاؤها مباشرةً بواسطة برنامج التطبيق ، على سبيل المثال ، 1C: Enterprise أو Microsoft SQL Server أو Oracle Database ، يمكن أن تحتوي على تفاعلات على مستوى التطبيق حصريًا.

بالإضافة إلى ذلك ، يظهر كيان موارد إضافي على مستوى التطبيق.

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

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

ضع في اعتبارك أنماط تفاعل إضافية خاصة بمستوى التطبيق.


الشكل 6. تفاعل الموارد

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

يوضح المثال إدخالاً من قاعدة بيانات تدقيق قاعدة بيانات أوراكل. يعمل على إصلاح عملية إلغاء دور من المستخدم.



هنا:
"ALEX" - الموضوع (اسم المستخدم الذي يسحب الدور) ،
"BOB" - الكائن (اسم المستخدم الذي تم إبطاله) ،
"ROLE" - المورد (اسم الدور الذي تم إبطاله).


الشكل 7: التفاعل مع العديد من الموارد

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

في المثال ، حل حماية البيئات الافتراضية vGate Security Code يلتقط إضافة سياسات جديدة للمجموعة.



هنا:
"Admin @ VGATE" - الموضوع (اسم المستخدم يغير مجموعة السياسات)
"Base" - الكائن (مجموعة من السياسات)
"تثبيت والحفاظ على سلامة نظام الملفات" ، "التحقق من إعدادات وكيل SNMP" ، "تعطيل التثبيت التلقائي لأدوات VMware" - الموارد (أسماء السياسات المضافة)

نموذج قناة التفاعل بين الموضوع والشيء

في جميع المخططات ، قمنا بتمييز الكيانات المختلفة (الموضوعات ، والأشياء ، والموارد ، والمصادر ، وأجهزة الإرسال) ولاحظنا ما يسمى بقناة التفاعل فيما بينها. دعونا نتناول بمزيد من التفاصيل عن المكون قبل الأخير من النموذج الكبير "للعالم" الذي يجب أن تعمل معه SIEM - على نماذج قناة التفاعل بين الموضوع والشيء. تذكر أن المكون الأخير هو سياق التفاعل (سيتم تخصيص المقالة التالية لهذا).

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


نموذج قناة البيانات

بناءً على هذا النموذج ، قد يحتوي كل حدث تتلقاه SIEM على معلومات تصف:

• معلمات القناة نفسها هي "الأنابيب" ،
• البيانات المرسلة عبر هذا "الأنبوب".

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

فكر في مثال لحدث يحتوي على بيانات حول قناة التفاعل. في ما يلي حدث من Cisco Identity Services Engine (ISE) ، وهو نظام إدارة العمليات لتحديد الدخول والتحكم فيه ، والذي يسجل جلسة شبكة المستخدم كجزء من الإجراء المحاسبي (المحاسبة).




هنا:
"Acct-Session-Id = 1A346216" ، "Acct-Session-Time = 50" ، "Service-Type = Framed" ، "Framed-Protocol = PPP" - معلمات قناة الاتصال ،
"Acct-Input-Octets = 43525" ، "Acct-Output-Octets = 122215" ، "Acct-Input-Packets = 234" ، "Acct-Output-Packets = 466" - معلمات البيانات المرسلة عبر القناة.

مثال على نماذج تفاعل الكيانات والقناة في حدث واحد

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

هنا نرى حدثًا من جدار الحماية - جهاز Cisco Adaptive Security Appliance (ASA) ، حيث يتم إصلاح اتصال TCP الصادر.



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

هنا:
30.0.0.1 - المصدر (Cisco ASA) ،
10.0.0.1 - الموضوع (عنوان الشخص الذي يتصل) ،
20.0.0.1 - كائن (عنوان الشخص الذي يتصل به).

على مستوى التطبيق ، مخطط بسيط لا يوجد فيه سوى الموضوع والكائن:
"ALEX" - الموضوع (اسم المستخدم الذي يتصل) ،
"BOB" - الكائن (اسم المستخدم الذي يتصل به).

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

الاستنتاجات

كيف يمكن لمخططات التفاعل النموذجية التي أبرزناها أن تساعد؟

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

وبالتالي ، يجب أن يحتوي نموذج "العالم" ، الذي بني في SIEM ويمثله مجموعة من الحقول (مخطط) ، على أقسام لوصف:

1. على مستوى الشبكة :
   
   • الموضوع ؛
   • الكائن ؛
   • المصدر ؛
   • جهاز الإرسال
   • قناة التفاعل
   • البيانات المرسلة عبر القناة.
   
   
2. على مستوى التطبيق :
   
   • الموضوع ؛
   • كائن أو مجموعة من الأشياء ؛
   • مورد أو موارد متعددة.
   
   

لكل كيان ، من الضروري تحديد مجموعة من الخصائص التي تحددها بشكل فريد. على مستوى الشبكة ، يتم تحديد الكيانات بواسطة IP أو MAC أو FQDN. على مستوى التطبيق ، بالاسم أو الهوية. يجب أن يحتوي المخطط على حقول مخصصة لتخزين هذه المعرفات.

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

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

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

ونتيجة لذلك ، يبدو المخطط العام القادر على وصف مجموعة كاملة من التفاعلات النموذجية كما يلي:


مخطط ميداني موجه للتفاعل

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

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

---

سلسلة المقالات:

أعماق SIEM: الارتباطات خارج الصندوق. الجزء 1: تسويق محض أم مشكلة غير قابلة للحل؟

أعماق SIEM: الارتباطات خارج الصندوق. الجزء 2. مخطط البيانات باعتباره انعكاسا لنموذج "العالم" ( هذه المقالة )

أعماق SIEM: الارتباطات خارج الصندوق. الجزء 3.1. تصنيف أحداث

عمق SIEM: الارتباطات خارج الصندوق. الجزء 3.2.

SIEM Depth Events منهجية التطبيع : الارتباطات خارج الصندوق. الجزء 4. نموذج النظام كسياق لقواعد ارتباط العمق SIEM: الارتباطات

خارج الصندوق. الجزء 5. منهجية لتطوير قواعد الارتباط