نختتم سلسلة من المقالات المكرسة لقواعد الارتباط العمل خارج الصندوق. لقد وضعنا هدفًا لصياغة نهج من شأنه أن يسمح لنا بإنشاء قواعد ارتباط يمكن أن تعمل "خارج الصندوق" مع الحد الأدنى من الإيجابيات الخاطئة.
الصورة: تسويق البرمجياتجميع النقاط الرئيسية للمقالة متاحة في
الخاتمة ، وفي نفس المكان يتم تقديم هذه المنهجية في شكل رسم
بياني .
باختصار حول ما حدث في المقالات السابقة: وصفوا كيف ينبغي أن تبدو مجموعة من الحقول لحدث طبيعي -
رسم تخطيطي ؛ أي نظام
تصنيف الحدث لاستخدامه ؛ كيف ، باستخدام نظام تصنيف ومخطط ، لتوحيد
عملية تطبيع الأحداث. درسنا أيضًا
سياق تنفيذ قواعد الارتباط وفحصنا ما يجب على SIEM معرفته عن النظام الآلي (AS) الذي يراقبه ولماذا.
جميع الأساليب المذكورة أعلاه والمنطق هي الكتل التي تم بناء منهجية تطوير قواعد الارتباط. لقد حان الوقت لوضعها معًا وإلقاء نظرة على الصورة كاملة.
المنهجية الكاملة لتطوير قواعد الارتباط تتكون من أربع كتل:
- إعداد المصادر والمناطق المحيطة بها ؛
- تطبيع الأحداث وإثرائها ؛
- تكييف قواعد الارتباط مع سياق AS ؛
- تشكيل اتفاق على الإيجابيات.
إعداد المصادر والبيئات
قواعد الارتباط تعمل على الأحداث التي تولد مصادر. في هذا الصدد ، من المهم للغاية أن تكون المصادر المطلوبة لقواعد الارتباط موجودة في السماعات وأن تكون مكوّنة بشكل صحيح.
إعداد المصادر والبيئاتالخطوة 1 :
فكر في المنطق العام للقاعدة وفهم ما هي مصادر الحدث المطلوبة. إذا كنت تتطور من نقطة الصفر أو تأخذ
قاعدة ارتباط
Sigma جاهزة ، فيجب أن تفهم استنادًا إلى الأحداث التي تعمل من خلالها المصادر.
الخطوة 2 :
تأكد من أن جميع المصادر اللازمة موجودة في الشركة ويمكن جمعها. يكون الموقف ممكنًا عندما تعمل قاعدة على سلسلة من الأحداث من عدة مصادر للنموذج (الحدث A من المصدر 1) - (الحدث B من المصدر 2) - (الحدث C من المصدر 3) لمدة 5 دقائق. إذا لم يكن لشركتك مصدر واحد على الأقل ، فإن مثل هذه القاعدة تصبح عديمة الفائدة ، لأنها لن تنجح أبدًا. عليك أن تفهم ما إذا كان من الممكن ، من حيث المبدأ ، جمع الأحداث من المصادر الضرورية وما إذا كان بإمكان SIEM توفيرها. على سبيل المثال ، يكتب المصدر الأحداث إلى ملف ، ولكن يتم تشفير الملف ، أو يتم استخدام قاعدة بيانات غير قياسية على المصدر للتخزين ، لا يمكن الوصول إلى الوصول إليها من خلال برنامج تشغيل ODBC / JDBC القياسي.
الخطوة 3 :
توصيل المصادر إلى SIEM. لا يهم كيف قد يبدو مبتذلاً ، ولكن في هذه الخطوة ، من الضروري تطبيق مجموعة الأحداث. غالبا ما يكون هناك العديد من المشاكل. على سبيل المثال ، المشكلات التنظيمية ، عندما تحظر إدارة تكنولوجيا المعلومات بشكل قاطع التوصيل بالأنظمة المهمة للمهام. أو تقنية ، عندما لا يكون هناك إعدادات إضافية ، يقوم وكيل SIEM (SmartConnector ، Universal Forwarder) ، عند جمع الأحداث ، ببساطة "بقتل" المصدر ، مما يؤدي إلى رفض الخدمة. يمكن ملاحظة ذلك غالبًا عند توصيل نظم إدارة قواعد البيانات المحملة للغاية بـ SIEM.
الخطوة 4 :
تأكد من أن التدقيق على المصادر قد تم تكوينه بشكل صحيح ، يتم استلام الأحداث اللازمة للارتباط في SIEM. تتوقع قواعد الارتباط أنواعًا معينة من الأحداث. يجب أن يتم إنشاؤها بواسطة المصدر. غالبًا ما يحدث أنه من أجل توليد الأحداث اللازمة للقواعد ، يجب تكوين المصدر بشكل إضافي: يتم تمكين التدقيق المتقدم وتهيئة إخراج السجل بتنسيق معين.
غالبًا ما يؤثر تمكين التدقيق المطول على مقدار تدفق الأحداث (EPS) الذي يتم تلقيه في SIEM من المصدر. نظرًا لحقيقة أن المصدر نفسه و SIEM في مجال مسؤولية الإدارات المختلفة ، هناك دائمًا خطر تعطيل المراجعة الموسعة ، ونتيجة لذلك ، ستتوقف الأنواع الضرورية من الأحداث عن الحضور إلى SIEM. يمكن اكتشاف هذه المشكلة جزئيًا عن طريق مراقبة تدفق الأحداث لكل مصدر ، أو بالأحرى مراقبة التغييرات في الأحداث في الثانية (EPS).
الخطوة 5 :
تحقق من أن الأحداث جارية وتكوين مراقبة المصدر. في أي بنية تحتية ، عاجلاً أم آجلاً ، تظهر الأعطال في الشبكة أو المصدر نفسه. في هذه المرحلة ، يفقد SIEM الاتصال بالمصدر ولا يمكنه تلقي الأحداث. إذا كان المصدر خاملًا وكتب سجلاته إلى ملف أو قاعدة بيانات ، فلن تضيع الأحداث في حالة حدوث عطل ، وسيكون بإمكان SIEM استقبالها عند استعادة الاتصال. إذا كان المصدر نشطًا ويرسل الأحداث إلى SIEM ، على سبيل المثال ، عبر syslog ، دون حفظها بشكل إضافي في أي مكان ، عندها ستفقد الأحداث ، ولن تعمل قاعدة الارتباط الخاصة بك ، لأن الحدث المطلوب لن ينتظر. الحفر أعمق ، يمكنك أن ترى ذلك ، حتى عند العمل مع مصدر سلبي ، عند استعادة الاتصال بعد الفشل ، لا يوجد ضمان بأن قواعد الارتباط ستعمل ، خاصة تلك التي تعمل مع نوافذ زمنية. خذ بعين الاعتبار مثال القاعدة الموضح أعلاه: (الحدث A من المصدر 1) - (الحدث B من المصدر 2) - (الحدث C من المصدر 3) لمدة 5 دقائق. في حالة حدوث عطل بعد الحدث B واستعادة الاتصال خلال ساعة ، فلن يعمل الارتباط ، لأن الحدث C لن يصل خلال 5 دقائق المتوقعة.
مع مراعاة هذه الميزات ، يجب عليك تهيئة مراقبة المصادر التي يتم جمع الأحداث منها. يجب أن يراقب هذا الرصد مدى توفر المصادر ، وتوقيت وصول الأحداث منها ، وقوة تدفق الأحداث المجمعة (EPS).
إن إطلاق نظام المراقبة هو أول جرس يتحدث عن ظهور عامل سلبي يؤثر على أداء قواعد الارتباط بكاملها أو جزء منها.
تطبيع الأحداث وإثرائها
جمع الأحداث اللازمة للعلاقة ليست كافية. يجب تطبيع الأحداث التي تصل إلى SIEM بدقة وفقًا للقواعد المقبولة. لقد كتبنا عن مشاكل التطبيع وتشكيل منهجية التطبيع في
مقال منفصل. بشكل عام ، يمكن وصف هذه الكتلة بأنها معركة ضد القمامة في
الداخل ، ومخلفات النفايات (
GIGO ).
تطبيع وإثراء الأحداثالخطوة 6 والخطوة 7 :
تصنيف الأحداث وتطبيع الأحداث وفقًا للفئة ، استنادًا إلى المنهجية. لن نتطرق إليها بالتفصيل ، لأننا نظرنا في هذه الخطوات بالتفصيل في مقال
"منهجية تطبيع الأحداث" .
الخطوة 8 :
إثراء الأحداث مع المعلومات المفقودة والإضافية ، وفقا للفئة. في كثير من الأحيان ، لا تحتوي الأحداث الواردة دائمًا على معلومات بالقدر اللازم لتشغيل قواعد الارتباط. على سبيل المثال ، يحتوي الحدث على عنوان IP الخاص بالمضيف فقط ، ولكن لا توجد معلومات حول FQDN أو اسم المضيف الخاص به. مثال آخر: يحتوي الحدث على معرف مستخدم ، ولكن لا يوجد اسم مستخدم في الحدث. في هذه الحالة ، يجب استخراج المعلومات الضرورية من مصادر خارجية - قواعد البيانات أو وحدات تحكم المجال أو الدلائل الأخرى وإضافتها إلى الحدث.
من المهم أن نلاحظ أن تصنيف الأحداث يحدث في البداية - قبل التطبيع. بالإضافة إلى حقيقة أن الفئة تحدد قواعد تطبيع الحدث ، فإنها تحدد أيضًا قائمة البيانات التي يجب البحث عنها في مصادر خارجية إذا لم تكن موجودة في الحدث نفسه.
تكييف قواعد الارتباط مع السياق
بعد أن تقوم بإعداد بيانات الإدخال (الأحداث) ومتابعة تطوير قواعد الارتباط ، من الضروري أن تأخذ في الاعتبار تفاصيل الأحداث القادمة ، AS نفسها وتغيرها. كان المزيد حول هذا الموضوع في مقال
"نموذج النظام كسياق لقواعد الارتباط" .
تكييف قواعد الارتباط مع السياقالخطوة 9 :
فهم تواتر الأحداث من كل مصدر ، حدد نافذة الوقت للارتباط. في كثير من الأحيان ، تستخدم قواعد الارتباط نوافذ زمنية عندما يكون من الضروري توقع وصول حدث معين خلال فترة زمنية محددة. عند تطوير هذه القواعد ، من المهم مراعاة التأخير في تلقي الأحداث. وعادة ما يكون سببها عاملان.
أولاً ، لا يجوز للمصدر نفسه أن يكتب الأحداث على الفور إلى قاعدة البيانات أو إلى ملف أو يرسلها عبر syslog. يجب تقدير وقت هذا التأخير ومراعاته في القاعدة.
ثانياً ، هناك تأخير في تسليم الأحداث إلى SIEM. على سبيل المثال ، يتم تكوين مجموعة الأحداث من قاعدة البيانات بحيث يتم تنفيذ طلب الأحداث مرة واحدة كل 10 دقائق ، بطبيعة الحال ، أن إطار الارتباط لمدة 5 دقائق ليس هو الحل الأفضل في هذا الموقف.
تتفاقم المشكلة عندما يكون من الضروري تطوير قاعدة الارتباط التي تعمل مع الأحداث من عدة مصادر في وقت واحد. في هذه الحالة ، من المهم أن نفهم أنه قد يكون لديهم أوقات تسليم مختلفة. في أسوأ الحالات ، ستأتي الأحداث بترتيب عشوائي مع انتهاك التسلسل الزمني. في مثل هذه الحالة ، يحتاج مطور قواعد الارتباط إلى فهم واضح في الوقت الذي يدرك فيه SIEM الارتباط (في وقت الحدث أو عند وصول الحدث إلى SIEM). ألاحظ أن الارتباط في وقت وصول الأحداث هو الخيار الأكثر شيوعًا من الناحية الفنية والأكثر شيوعًا لمعالجة الأحداث في وضع الوقت الفعلي الزائف. ومع ذلك ، فإن هذا الخيار لا يؤدي إلا إلى تفاقم المشاكل المذكورة أعلاه ، ولا يحلها.
إذا كان SIEM يوفر ارتباطًا في وقت الحدث ، فمن المرجح أن هناك آليات لإعادة ترتيب الأحداث التي يمكنها استعادة التسلسل الزمني الفعلي للأحداث.
في حالة فهمك أن نافذة الوقت أكبر من أن تفعل الارتباط على الدفق ، يجب عليك استخدام آلية الارتباط القديمة ، والتي يتم فيها تحديد الأحداث المحفوظة بالفعل من قاعدة بيانات SIEM وفقًا للجدول الزمني ويتم تشغيلها عبر قواعد الارتباط.
الخطوة 10 :
إنشاء آلية استثناء. في العالم الواقعي ، سيكون هناك دائمًا كائن ذو سلوك خاص لا ينبغي التعامل معه بواسطة قاعدة ارتباط محددة ، لأن هذا يؤدي إلى إيجابية خاطئة. لذلك ، في مرحلة تطوير القواعد ، يجب وضع آليات لإضافة هذه الأشياء إلى الاستثناءات. على سبيل المثال ، إذا كانت قاعدتك تعمل مع عناوين IP الخاصة بالأجهزة ، فأنت بحاجة إلى قائمة جدول حيث يمكنك إضافة عناوين لا تعمل القاعدة عليها. وبالمثل ، إذا كانت قاعدة ما تعمل مع تسجيلات دخول المستخدم أو أسماء العمليات ، فمن الضروري العمل بشكل مبدئي مع قوائم استبعاد الجدول في منطق القاعدة.
سيتيح لك هذا الأسلوب إضافة كائنات تلقائيًا أو يدويًا إلى استثناءات دون الحاجة إلى إعادة كتابة نص القاعدة.
الخطوة 11 :
تحديد الحدود المادية والمنطقية للتطبيق لقاعدة الارتباط. عند تطوير قاعدة الارتباط ، من المهم أن نفهم في البداية حدود قابلية التطبيق (نطاق) القاعدة ، وما إذا كانت موجودة على الإطلاق. عند اختبار المنطق وتصحيح القاعدة ، من الضروري التركيز على تفاصيل هذا المجال. إذا بدأت قاعدة العمل مع البيانات التي تتجاوز نطاق هذا المجال ، فإن احتمال وجود إيجابيات كاذبة يزداد.
يمكن تمييز نوعين من النطاقات: المادية والمنطقية. النطاق الفعلي هو شبكات الشركة والشبكات المجاورة لها ، والمنطقة المنطقية هي أجزاء من AS أو تطبيقات الأعمال أو العمليات التجارية. أمثلة على المجال المادي: شريحة DMZ والشبكات الفرعية الداخلية والخارجية وشبكات الوصول عن بُعد. أمثلة على النطاق المنطقي للقواعد: التحكم في العمليات ، أو المحاسبة ، أو قطاع PCI DSS ، أو قطعة PD ، أو مجرد أدوار معدات محددة - وحدات تحكم المجال ، ومفاتيح الوصول ، وأجهزة التوجيه الأساسية.
يمكنك تعيين نطاقات لقواعد الارتباط من خلال قوائم الجدول. يمكن ملؤها إما يدويا أو تلقائيا. إذا وجدت وقتًا في شركتك لإدارة الأصول (إدارة الأصول) ، فقد تكون جميع البيانات الضرورية موجودة بالفعل في نموذج AS الذي تم إنشاؤه في SIEM. يتيح لك الإنشاء التلقائي لقوائم الجداول هذه أن تدرج ديناميكيًا في النطاق أصول جديدة تظهر في الشركة. على سبيل المثال ، إذا كان لديك قاعدة عملت حصريًا مع وحدات التحكم بالمجال ، فستتم إضافة وحدة تحكم جديدة إلى مجموعة المجال في النموذج وستقع في نطاق القاعدة.
بشكل عام ، يمكن اعتبار قوائم الجدول المستخدمة في الاستثناءات قوائم سوداء ، والقوائم المسؤولة عن نطاق القواعد كقوائم بيضاء.
الخطوة 12 :
استخدم نموذج السماعة لتوضيح السياق. في عملية تطوير قاعدة الارتباط التي تحدد الأعمال الضارة ، من المهم التأكد من إمكانية تنفيذها بالفعل. إذا لم يؤخذ ذلك في الاعتبار ، فإن تشغيل القاعدة التي كشفت عن هجوم محتمل سوف يكون خاطئًا ، لأن هذا النوع من الهجوم قد لا ينطبق ببساطة على البنية الأساسية الخاصة بك. سأشرح مع مثال:
- افترض أن لدينا قاعدة ارتباط بالكشف عن اتصالات RDP عن بعد بالخوادم.
- يعرض جدار الحماية محاولة للاتصال بمنفذ خادم myserver.local TCP 3389.
- حرائق القاعدة ، وتبدأ في تحليل حادث محتمل مع أولوية عالية.
أثناء التحقيق ، اكتشفت بسرعة أنه على myserver.local 3389 ، تم إغلاقه ولم يتم فتحه من قبل أي خدمة ولينوكس موجود. هذه إيجابية كاذبة استغرقت وقتًا للتحقيق.
مثال آخر: يرسل IPS حدثًا مثيرًا للتوقيع عند إجراء محاولة لاستغلال الثغرة الأمنية CVE-2017-0144 ، ومع ذلك ، أثناء التحقيق ، اتضح أن التصحيح المقابل مثبت على الجهاز الذي تمت مهاجمته ولا توجد حاجة للرد على مثل هذا الحادث ذي الأولوية العليا.
سيساعد استخدام البيانات من نموذج السماعة في تسوية هذه المشكلة.
الخطوة 13 :
استخدام معرفات الكيانات ، وليس مفاتيح المصدر الخاصة بهم. كما هو موضح سابقًا في مقال
"نموذج النظام كسياق لقواعد الارتباط" ، يمكن أن يتغير عنوان IP و FQDN وحتى MAC للأصل. وبالتالي ، إذا استخدمت معرفات مصدر الأصل في قاعدة الارتباط أو قائمة الجدول ، فبعد فترة من الوقت توجد فرصة كبيرة لتلقي إيجابيات كاذبة لسبب عادي تمامًا ، على سبيل المثال ، أصدر خادم DHCP هذا IP ببساطة إلى جهاز آخر.
إذا كان لدى SIEM آلية لتحديد الأصول ، وتتبع تغييراتها والسماح لك بالعمل مع معرفاتها ، فيجب عليك استخدام المعرفات ، وليس مفاتيح مصدر الأصل.
تشكيل اتفاق إيجابي
عند الاقتراب من الكتلة النهائية لإنشاء قاعدة الارتباط ، نذكر أن نتيجة القاعدة هي حادثة نشأت في SIEM. يجب أن يستجيب المهنيون المسؤولون لمثل هذا الحادث. على الرغم من أن الغرض من هذه السلسلة من المقالات لا يشمل النظر في عملية الاستجابة للحوادث ، تجدر الإشارة إلى أن جزءًا من المعلومات حول الحادث تم إنشاؤه بالفعل في مرحلة إنشاء قاعدة الارتباط المقابلة.
بعد ذلك ، نأخذ بعين الاعتبار النقاط الأساسية التي يجب مراعاتها عند تكوين المعلمات لإطلاق قاعدة الارتباط وإنشاء حادث.
تشكيل اتفاق إيجابيالخطوة 14 :
تحديد شروط التجميع والإغلاق في حالة وجود عدد كبير من الإيجابيات الخاطئة. في مرحلة تصحيح الأخطاء ، وفي أثناء عملها ، إذا لم تلتزم بهذه التقنية :) ، فقد تحدث إنذارات خاطئة للقواعد. من الجيد أن تكون هناك رحلة واحدة أو رحلتان في اليوم ، ولكن ماذا لو كانت هناك قاعدة واحدة تحتوي على آلاف أو عشرات الآلاف من الرحلات؟ بالطبع ، هذا يشير إلى أن القاعدة تحتاج إلى مزيد من التطوير. ومع ذلك ، من الضروري التأكد من أنه في مثل هذه الحالات ، تكون هذه النتيجة إيجابية كاذبة:
- لم يؤثر على أداء SIEM.
- بين كتلة الإيجابيات الخاطئة ، لم تضيع الأحداث المهمة حقًا. حتى أن هناك نوعًا منفصلاً من الهجمات يهدف إلى إخفاء النشاط الضار الرئيسي وراء العديد من الأنشطة الخاطئة.
يمكن حل المشكلات من هذا النوع إذا ، عند إنشاء قاعدة ارتباط على مستوى النظام بأكمله ككل أو لكل قاعدة على حدة ، يمكن تعيين شروط لتجميع الحوادث وشروط إيقاف الطوارئ للقاعدة.
لن تسمح آلية تجميع الحوادث بإحداث ملايين من الحوادث المتطابقة ، ولكن "لإلصاق" الحوادث الجديدة بحادث واحد ، شريطة أن تكون متطابقة. في الحالات القصوى ، عندما يعطي تجميع الحوادث عبئًا كبيرًا ، يوصى بتعيين قاعدة الارتباط لإيقافها تلقائيًا عند تجاوز عدد العمليات المحدد لكل وحدة (دقيقة ، ساعة ، يوم).
الخطوة 15 :
تحديد قواعد لتوليد اسم الحادث. غالبًا ما يتم إهمال هذا العنصر ، خاصةً إذا كانت لا تقوم بتطوير قواعد لشركتها ، على سبيل المثال ، إذا كانت شركة خارجية مسؤولة عن تنفيذ SIEM وتطوير القواعد. يجب أن يكون اسم قاعدة الارتباط ، بالإضافة إلى الحادث الذي تم إنشاؤه ، قصيرًا ويعكس بوضوح جوهر قاعدة معينة.
إذا كان أكثر من شخص يعمل مع حوادث وقواعد الارتباط في شركتك ، فمن المستحسن أن تقوم بتطوير قواعد التسمية. يجب فهمهم وقبولهم من قبل الفريق بأكمله الذي يعمل مع SIEM.
الخطوة 16 :
تحديد قواعد لتشكيل أهمية الحادث. تتيح لك معظم حلول SIEM في المرحلة الأخيرة من إنشاء حادث تحديد أهميتها وأهميتها. تقوم بعض القرارات بحساب الأهمية تلقائيًا ، استنادًا إلى سياق الحادث والأشياء التي ينطوي عليها.
في حالة عمل حساب SIEM الخاص بك على الحساب التلقائي الحصري لأهمية الحوادث ، يجدر بنا أن نتعرف على أساس ما وحسب الصيغة التي يتم حسابها. على سبيل المثال ، إذا تم حساب الأهمية على أساس أهمية الأصول المتورطة في الحادث ، فعليك أن تأخذ على محمل الجد قضايا إدارة الأصول في الشركة مسبقًا.
إذا قمت بتعيين أهمية الحادث يدويًا ، فمن المستحسن أن تقوم بتطوير صيغة حساب تأخذ في الاعتبار ما يلي على الأقل:
- أهمية النطاق الذي تعمل فيه القاعدة. على سبيل المثال ، قد يكون أي حادث يقع في منطقة الأنظمة الحيوية للبعثة أكثر أهمية مما لو حدث نفس الحادث بالضبط في منطقة الأنظمة الحيوية للأعمال.
- أهمية الأصول وحسابات المستخدمين المتورطين في الحادث.
- تكرار هذا الحادث في الشركة.
أيضًا ، كما هو الحال في حوادث التسمية ، من المهم أن تفهم جميع الأطراف المعنية بوضوح وبشكل متساو القواعد التي تتشكل بها أهمية الحادث.
النتائج
بتلخيص نتائج سلسلة مقالاتنا ، ألاحظ أنه من الممكن ، في رأيي ، إنشاء قواعد ارتباط تنجح. قد يكون الحل مزيجًا من الأساليب التنظيمية والتقنية. يجب أن يكون SIEM نفسه قادرًا على القيام بشيء ما ، ولكن يجب على المتخصصين الذين يقومون بتشغيله معرفة شيء ما.
لتلخيص:
- تتكون الطريقة من الكتل التالية:
- إعداد المصادر والبيئات.
- تطبيع الأحداث وإثرائها.
- تكييف قواعد الارتباط مع السياق.
- تشكيل اتفاق على الإيجابيات.
- كل وحدة لديها مكونات التنظيمية والتقنية.
- من الناحية الفنية ، تؤثر الكتل الموصوفة على جميع وظائف SIEM الأساسية تقريبًا ، بدءًا من مجموعة الأحداث وحتى إنشاء الحادث.
- يمكن توفير المكون التقني بأكمله من هذه المنهجية تقريبًا عن طريق حلول SIEM الأجنبية ، وكذلك بعض الحلول المحلية.
- تم تقديم دراسة أكثر تفصيلًا وتبرير لخطوات هذه المنهجية في المقالات السابقة من الدورة. وترد روابط لهم في نهاية المقال.
منهجية تطوير قواعد الارتباط التي تعمل "خارج الصندوق" ،شكرًا جزيلاً لكل من أتقن سلسلة المقالات بأكملها ، أو على الأقل قرأها في هذه السطور. إذا كان لديك أي أسئلة ، فاكتب بشكل شخصي أو قم بطرحها في التعليقات. سأكون سعيدا لمناقشة.
سلسلة من المقالات:أعماق SIEM: الارتباطات خارج الصندوق. الجزء 1: التسويق النقي أو مشكلة غير قابلة للحل؟أعماق SIEM: الارتباطات خارج الصندوق. الجزء 2. مخطط البيانات باعتباره انعكاسا لنموذج "العالم" منعمق SIEM: الارتباطات "خارج الصندوق". الجزء 3.1. تصنيف أحداثSIEM العمق: الارتباطات خارج الصندوق. الجزء 3.2. منهجية تطبيع أحداثعمق SIEM: الارتباطات خارج الصندوق. الجزء 4. نموذج النظام كسياق لقواعد الارتباط بعمق SIEM: الارتباطاتخارج الصندوق. الجزء 5. منهجية تطوير قواعد الارتباط ( هذه المقالة )