كيفية تطبيع الحدث بشكل صحيح؟ كيف تطبيع الأحداث المماثلة من مصادر مختلفة دون أن تنسى أو تربك أي شيء؟ ولكن ماذا لو فعل خبيران هذا بشكل مستقل؟ في هذه المقالة ، سوف نشارك منهجية التطبيع الشائعة التي يمكن أن تساعد في حل هذه المشكلة.
الصورة: Martinoflynn.comفي معظم الأحيان ، تستند قواعد الارتباط إلى أحداث طبيعية. وبالتالي ، فإن تطبيع الأحداث ومدى تنفيذها بشكل صحيح يؤثر بشكل مباشر على دقة قواعد الارتباط.
تمت صياغة المشكلات الناشئة عن تطبيع الأحداث في المادة الأولى (
هنا ) ، وتم اقتراح الحلول في المقالات التالية (
هنا وهنا ). نحن الآن نلخص ما سبق وصفه ونشكل مقاربة عامة لتطبيع الأحداث.
بادئ ذي بدء ، نذكر الأدوات التي على مستوى التطبيع قمنا بتطويرها:
- مخطط الحقل العام المطلوب لتخزين البيانات المستردة من الأحداث. معالمه:
- يأخذ في الاعتبار وجود الكيانات في الحدث: الموضوع ، الكائن ، المصدر والارسال للأحداث ، وكذلك المورد.
- يوفر التطبيع الصحيح في الحالات التي يحتوي فيها الحدث على كيانات من مستويات الشبكة والتطبيقات ، وعندما يكون لديه أكثر من موضوع و / أو كائن واحد.
- يتيح لك تحديد بنية عملية التفاعل بين الموضوع والكائن والحفاظ عليها صراحة
- نظام تصنيف الأحداث قادر على عكس دلالات حدث IT أو IB.
منهجية تطبيع الأحداث
تتكون المنهجية الكاملة لتطبيع الأحداث من ثلاث خطوات:
- تقييم الخبراء لهذا الحدث.
- تعريف مخطط التفاعل.
- تعريف فئة الحدث.
لتسهيل فهم كيفية عمل الأداة ، سنختار حدثًا وسننظر بالتفصيل في جميع خطوات التطبيع وفقًا لمنهجيتنا.
افترض أن لدينا مصدرًا - DBMS Oracle Database مع معالجة الشبكة التالية:
- IP : 10.0.0.1 ؛
- اسم المضيف : myoracle؛
- FQDN : myoracle.local.
من هذا المصدر ، يقوم وكيل SIEM بتفريغ الحدث التالي:
الخطوة 1. تقييم الخبراء لهذا الحدث
في بداية عملية تطبيع حدث ما ، من المهم أن نفهم معنى هذا الحدث. يكفي أن تقول جوهرها لنفسك. إذا كان الخبير ، من الحدث الأولي ، ولم يتم تطبيعه بعد ، لا يفهم العمليات التي تحدث في المصدر ، فنحن نتحدث عنها ، مع احتمال كبير أنه سيعيدها بشكل غير صحيح. ثم ما نوع التشغيل الصحيح لقواعد الارتباط التي يمكن أن نتحدث عنها؟
المشكلة في مدى دقة الخبير في تفسير الحدث بشكل صحيح. على سبيل المثال ، هل يمكن للخبير أن يفهم معنى الحدث التالي؟
إذا كان في المثال الأصلي يمكن اكتشاف الجوهر من نص الحدث نفسه ، فأنت بحاجة في هذه الحالة إلى أن تفهم جيدًا ما هو المصدر الذي تعمل به وفي الحالات التي يولد فيها حدثًا مماثلاً. في بعض الأحيان ، يتعين عليك حتى أن تنشر موقفا منفصلا مع مصدر من أجل إعادة إنتاج الموقف الذي يرسل فيه حدث معقد وصعب التفسير إلى SIEM.
دعنا نعود إلى
المثال الأصلي مع حدث من قاعدة بيانات Oracle. في هذه المرحلة ، يجب على الخبير التفكير في هذا:
"
كخبير ، أعتقد أن الحدث الأولي يصف عملية إبطال دور مستخدم من قبل مستخدم آخر في قاعدة بيانات Oracle ".
الخطوة 2. تحديد مخطط التفاعل
تتيح لنا الخطوة السابقة التأكد من أننا قادرون على فهم المعنى العام للحدث على الأقل. الآن سوف نحلل بالتفصيل كيفية التمييز بين الكيانات وتحديد مخطط تفاعلها.
وفقًا لهذه المنهجية ، لكل
مخطط تفاعل ، من الضروري وصف قواعد توزيع معرّفات الكيانات الرئيسية في حقول حدث عادي. في الوقت نفسه ، يتم تعريف القواعد من أجل:
- كيانات مستوى الشبكة
- كيانات مستوى التطبيق.
من المهم أن نتذكر أن هناك مخططات يكون فيها الموضوع مساويا للكائن ويساوي المصدر. بالنسبة لمثل هذه المخططات ، من الضروري تحديد قواعد ملء حقول الكيانات الثلاثة بوضوح. إذا لم يتم ذلك ، عند مستوى قواعد الارتباط أو البحث عن الأحداث ، ستبدأ المشاكل وسيظهر منطق إضافي للتفسير الصحيح للحقول الفارغة. حول هذا - في المقال المكرس
لخطط التفاعل .
دعونا نرى كيف تعمل هذه الخطوة في المنهجية على
المثال الأولي:
- مخطط تفاعل على مستوى الشبكة : مخطط تجميع مباشر كامل ، بدون جهاز إرسال.
- مخطط التفاعل على مستوى التطبيق : التفاعل من خلال مورد.
بالنسبة لهذه المخططات ، يمكن تعريف قواعد التطبيع التالية:
- كيانات طبقة الشبكة:
- الموضوع :
- الحقل: src.ip = <empty>
- الحقل: src.hostname = alex_host
- الحقل: src.fqdn = <empty>
- كائن
- الحقل: dst.ip = 10.0.0.1
- الحقل: dst.hostname = عضل عضلي
- الحقل: dst.fqdn = myoracle.local
- المصدر (يطابق الكائن) :
- الحقل: event_source.ip = 10.0.0.1
- الحقل: event_source.hostname = myoracle
- الحقل: event_source.fqdn = myoracle.local
- الارسال :
- الحقل: forwarder.ip = <empty>
- الحقل: forwarder.hostname = <empty>
- الحقل: forwarder.fqdn = <empty>
- قناة التفاعل :
- الحقل: تفاعل. id = 2342594
- كيانات مستوى التطبيق (مجموعة العناصر):
- الموضوع :
- الحقل: topic [1] .name = "Alex"
- الحقل: الموضوع [1]. النوع = "الحساب"
- كائن
- الحقل: كائن [1] .name = "بوب"
- الحقل: كائن [1]. النوع = "حساب"
- المصدر :
- الحقل: مورد [1] .name = "MYROLE"
- الحقل: مورد [1]. النوع = "دور"
الخطوة 3. تحديد فئة الحدث
بعد تحديد جميع العناصر الرئيسية للحدث ، من الضروري وصف جوهر العملية المنعكسة في الحدث ونقله إلى لغة التطبيع. لهذه الأغراض ، يتم استخدام نظام لتصنيف الأحداث. تمت مناقشة نظام تصنيف الأحداث بالتفصيل في
مقالة منفصلة ، والآن لنرى كيف يعمل في الممارسة العملية.
من أجل توحيد التطبيع ، يحدد نظام التصنيف القواعد التالية:
- لكل فئة من كل مستوى من مستويات تكنولوجيا المعلومات وأحداث أمن المعلومات ، يقوم خبير بتكوين دليل يتضمن قائمة بالمعلومات التي يجب العثور عليها في الحدث الأولي وتطبيعها.
- إذا تم تخصيص حدث لأي فئة ، فإن الخبير ، وفقًا للدليل ، ملزم بإيجاد المعلومات المطلوبة وتطبيعها.
- تعرّف كل فئة مجموعة من حقول مخطط الأحداث التي تمت تسويتها والتي يجب ملؤها.
وبالتالي ، فإن الفئة المختارة لهذا الحدث تنشئ مراسلات مباشرة بين:
- دلالات الحدث.
- معلومات مهمة يتم استخراجها من الحدث ، وفقًا للفئة الملصقة ؛
- مجموعة من المجالات لمخطط الحدث الذي يجب أن يتم "وضع" هذه المعلومات فيه.
يتيح لك هذا النهج أن تفهم بوضوح من فئة أي حدث البيانات الموجودة في أي حقول للحدث المعتاد.
إذا تبين ، بدعم من مصادر جديدة ، أن بعض المعلومات المهمة تحتاج إلى استخراج إضافي من أحداث فئة معينة ، يتم إدخالها في الدليل. في هذه الحالة ، تحتاج إلى:
- تحديد قواعد لملء حقول مخطط الحدث
- إجراء مراجعة لتطبيع الأحداث في هذه الفئة لجميع المصادر المدعومة سابقًا ؛
- إضافة معلومات جديدة إلى الأحداث التي سبق تطبيعها.
بهذه الطريقة ، يتم الحفاظ على تناسق التغييرات التي تم إجراؤها. النظر في المثال الأصلي.
وفقًا لنظام التصنيف ، يحتوي هذا الحدث على الفئات التالية:
- نظام التصنيف : أحداث تكنولوجيا المعلومات
- المستوى الأول الفئة (المستوى 1) : المستخدم والحقوق
- المستوى الثاني الفئة (المستوى 2) : المستخدم
- المستوى الثالث الفئة (المستوى 3) : التلاعب
دليل هذه الفئة يبدو كالتالي:
- عند تطبيع الأحداث في فئة المستخدم والحقوق ، من المهم فهم:
- إذا تم استخدام تصعيد الامتياز ، فسيتم تنفيذ العملية نيابةً عنه.
- الحقل: الموضوع [i] .assign
- هل كانت الإجراءات ناجحة.
- ما هو كود الإرجاع؟
- الحقل: result.status.code
- عند تطبيع أحداث فئة المستخدم ، من المهم فهم:
- هل هناك أي معلومات حول عنوان IP أو اسم المضيف أو fqdn لجهاز المستخدم.
- الحقول: src.ip ، src.hostname ، src.fqdn
- الحقول: dst.ip ، dst.hostname ، dst.fqdn
- تحت أي حساب المستخدم متصل.
- الحقول: الموضوع [i] .name ، الكائن [i] .name
- هل هناك أي معلومات حول حسابه في نظام التشغيل.
- الحقول: الموضوع [i] .osname ، الكائن [i] .osname
- هل هناك أي معلومات حساب المجال؟
- الحقول: الموضوع [i] .domain ، الكائن [i] .domain
- هل هناك أي معلومات حول تطبيق المستخدم.
- الحقول: الموضوع [i] .التطبيق ، الكائن [i] .application
- عند تطبيع الأحداث في فئة المعالجة ، من المهم فهم:
- نوع العملية.
- ما الذي تغير.
- الحقل: الكائن [i] .name ، الكائن [i]. النوع - عند تغيير الحسابات
- الحقل: مورد [i] .name ، مورد [i]. نوع - عند التغيير في الموارد
- ما الذي تغير.
- الحقل: كائن [i]. تعديل
- الحقل: مورد [i]. تعديل
- إذا كانت العملية على مورد ، فمن هو صاحبها.
لقد قدمنا هذا الدليل لإظهار مبدأ تشكيله ، وبالتالي فإنه لا يدعي أنه دقيق وكامل.
نتيجة لذلك ، فإن الحدث الذي تم تطبيعه بواسطة هذه المنهجية يبدو كما يلي:
مثال لحدث طبيعي في الخطوة الثالثة من المنهجية.الاستنتاجات
تُظهر التجربة أنه غالبًا ما تكون أخطاء التطبيع وعدم وجود قواعد موحدة للتطبيع هي التي تؤدي غالبًا إلى إيجابيات خاطئة لقواعد الارتباط. الآن لدينا نهج يسمح ، إن لم يكن التخلص ، ثم على الأقل يقلل من تأثير المشكلة.
لتلخيص - يتضمن النهج ثلاث خطوات:
- الخطوة 1 يحاول الخبير فهم الجوهر العام للظاهرة الموصوفة في الحدث الأولي.
- الخطوة 2 يحدد الخبير الكيانات الرئيسية للشبكة ومستوى التطبيق في الحدث: الموضوع ، الكائن ، المصدر ، المرسل ، المورد ، قناة التفاعل. إنه يعزلهم في الحدث ويحدد نمط تفاعل هذه الكيانات. ينشئ كل مخطط قواعد لوضع هذه الكيانات في حقول حدث عادي - مخطط. تم وصف ذلك بالتفصيل في مقال مخصص لخطط تفاعل الكيان.
- الخطوة 3 يحدد الخبير فئة المستويات الأولى والثانية والثالثة. لكل فئة ، فإنه ينشئ دليلًا يتضمن وصفًا للبيانات المهمة التي يجب العثور عليها في الحدث أثناء تطبيعها ، معلومات حول ميادين حقول الحدث الذي تم تطبيعه من الضروري "وضع" البيانات الموجودة.
الآن ، من بناء قواعد الارتباط لـ "العمل خارج الصندوق" ، نحن منفصلون فقط عن طريق مشكلة التغييرات المستمرة في الكيانات نفسها - الأصول. تغيير عناوينهم ، والأصول الجديدة التي تم إدخالها ، والبيانات القديمة التي تم إيقاف تشغيلها ، وتبديل العقد العنقودية ، والانتقال من الأجهزة الظاهرية من مركز بيانات إلى آخر ، وأحيانًا حتى مع تغيير العنوان. كيفية التغلب على هذه المشكلات ، سنتحدث في المقال التالي من الدورة.
سلسلة من المقالات:أعماق SIEM: الارتباطات خارج الصندوق. الجزء 1: التسويق النقي أو مشكلة غير قابلة للحل؟أعماق SIEM: الارتباطات خارج الصندوق. الجزء 2. مخطط البيانات بمثابة انعكاس لنموذج "العالم"أعماق SIEM: الارتباطات خارج الصندوق. الجزء 3.1. تصنيف الحدثأعماق SIEM: الارتباطات خارج الصندوق. الجزء 3.2. منهجية تطبيع الأحداث (
هذه المقالة )
أعماق SIEM: الارتباطات خارج الصندوق. الجزء 4. نموذج النظام كسياق لقواعد الارتباطأعماق SIEM: الارتباطات خارج الصندوق. الجزء 5. منهجية لتطوير قواعد الارتباط