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



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

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

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

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

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

سنقوم الآن بتعقيد المهمة والنظر في القواعد التي يوفرها خبراء خارجيون ، مثل SOCs التجارية أو شركات التكامل التي تنفذ SIEM أو مطورو حلول SIEM بأنفسهم. لا تتضمن هذه القواعد ميزات مكبرات الصوت الخاصة بك - سياق التنفيذ - فهي ليست مُحسَّنة لهم. هذه المشكلة هي حجر عثرة آخر في مفهوم قواعد الارتباط التي تعمل خارج الصندوق. قد يكون حلها أن SIEM داخل نفسه:

1. يبني نموذجًا للمتحدثين الملحوظين.
2. دائما يحافظ على هذا النموذج حتى الآن.
3. يسمح لك باستخدام هذا النموذج كسياق للتنفيذ في قواعد الارتباط.

السياق - نموذج النظام الآلي

أولاً ، نصف تكوين نموذج السماعة. إذا انتقلنا إلى التعريف الكلاسيكي لمصطلح من GOST 34.003-90 ، فإن AS عبارة عن "نظام يتكون من أفراد ومجموعة من أدوات التشغيل الآلي لأنشطتها التي تنفذ تكنولوجيا المعلومات لأداء وظائف ثابتة". من المهم أنه عند تطبيق تكنولوجيا المعلومات ، يعمل الموظفون (المستخدمون) وأدوات التشغيل الآلي على البيانات.

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

بعد ذلك ، سنصف كيف يبدو النموذج الذي تم إنشاؤه لكيانات مثل المستخدم ، ومجموعة من أدوات التشغيل الآلي (المشار إليها فيما يلي باسم أنظمة الشبكات والكمبيوتر) والبيانات.

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


نموذج المتحدث العام

علاوة على ذلك ، سننظر في كل كيان وسنتناول:

• تحديد فريد
• تكوين النموذج ؛
• العثور على البيانات اللازمة للنموذج ؛
• طبيعة التغيير في بيانات الكيان ؛
• تحديث البيانات في النموذج عندما تتغير.

نموذج المستخدم

تحديد الهوية

يجب أن يفهم مستخدم AS بأنه شخص محدد: موظف في شركة أو مقاول أو مستقل. من المهم أن يكون قد أذن الوصول إلى مكبرات الصوت.

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

1. مايكروسوفت دليل نشط ومايكروسوفت تبادل. من لهم يمكننا معرفة تسجيل الدخول المجال الرئيسي وعنوان البريد الإلكتروني.
2. يخزن محرك خدمات الهوية من Cisco (ISE) تسجيل الدخول الثاني للوصول عن بُعد عبر VPN.
3. قاعدة بيانات البوابة الداخلية تخزن تسجيل الدخول الثالث.
4. إذا كان المستخدم مسؤول قاعدة بيانات ، فسيتم تخزين تسجيل الدخول الرابع في نظام إدارة قواعد البيانات ، وربما لا يتم تخزينه.
5. قاعدة بيانات الموارد البشرية ، حيث يتم تخزين اسمه الكامل (في حال كان Active Directory كسولًا جدًا بحيث يتعذر على المستخدم وفقًا لجميع القواعد).

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

لتلخيص:

1. يتطلب SIEM معرف مستخدم واحد.
2. عندما تظهر حسابات المستخدمين في أي سجل ، وأي نظام ، يجب أن نحدده بشكل فريد ونلصق معرف المستخدم الفريد الخاص بنا.

تكوين النموذج

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

كحد أدنى ، يجب تضمين ما يلي في نموذج المستخدم العام:

• معرف مستخدم واحد في SIEM
• جميع معرفاتها من أنظمة مختلفة ، بما في ذلك:
  
  • عناوين البريد الإلكتروني الخارجية والداخلية ؛
  • الاسم الكامل
  • حساب نظام التشغيل المحلي
  • حساب المجال ؛
  • حساب VPN
  • حساب الوكيل
  • حسابات DBMS
  • حسابات في أنظمة التطبيق الأخرى.
• وحدة التنظيم في Microsoft Active Directory التي يكون المستخدم عضواً فيها ؛
• مجموعات Microsoft Active Directory التي يكون المستخدم عضواً فيها.

كحد أدنى ، يجب أن يشتمل نموذج السلوك لدى المستخدم على:

• نوع الاتصال المستخدم (محلي ، عن بعد) ونوع قناة الاتصال (سلكي ، لاسلكي) ؛
• الأجهزة المستخدمة للوصول إلى شبكة الشركة ؛
• التطبيقات المستخدمة ؛
• الربط الجغرافي ، خاصة للمستخدمين عن بُعد ؛
• موارد الشركة التي يتصل بها المستخدم ؛
• لمن وما نقل البيانات (تدفق المعلومات).

نموذج المستخدم

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

مصادر البيانات للنموذج

أين يمكن الحصول على البيانات اللازمة لبناء النموذج؟ النظر في المبدأين الرئيسيين للحصول على المعلومات المتاحة في معظم SIEMs - طرق فعالة وغير فعالة لجمع.

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

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

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

النظر في المصادر التي يمكن أن توفر البيانات لبناء النموذج وفي ما هي الطرق التي يمكنك الحصول على المعلومات اللازمة منها.

نموذج الشبكات وأنظمة الحوسبة

تحديد الهوية

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

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

1. استخدام على شبكة DHCP. تتغير عناوين IP للأصول.
2. تبديل العقد في تكوين كتلة. اعتمادًا على نوع التجميع ، يمكن تغيير MAC و IP.
3. استعادة نظام من نسخة احتياطية على خادم آخر بسبب فشل فادح. تغيير عناوين MAC ، وأحيانًا IP و FQDN واسم المضيف.
4. استبدال المخطط لها ، وتحديث المعدات أو أجزاء من مكبرات الصوت. تقريبا جميع المفاتيح يمكن أن تتغير.

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

نظرًا لأنه لا يمكنك الاعتماد على IP أو MAC أو FQDN أو Hostname بشكل منفصل لتحديد الأصل ، فيمكنك محاولة تحديد الأصل على الفور بواسطة جميع المعلمات الأربعة. نحن هنا نواجه مشكلة عالمية: تعمل SIEM في الأحداث ، وهي لا تحتوي أبدًا على جميع مفاتيح التعريف الأصلية في نفس الوقت.

كيف يمكن حلها؟ لنلقِ نظرة على بعض الخيارات:

1. طريقة نشطة باستخدام حلول مستوى قاعدة بيانات إدارة التكوين (CMDB) . يمكن الحصول على معلومات حول مفاتيح التعريف الأصلية من هناك. ولكن هل يحتوي CMDB على جميع مفاتيح مصدر الأصول اللازمة لتحديد الهوية؟ والأهم من ذلك ، هل يأخذ في الاعتبار التغييرات في المتكلمين المذكورة أعلاه؟ من المهم أيضًا مراعاة وقت تحديث البيانات في CMDB ، إذا تأخرت البيانات عشرات الدقائق أو الساعات عن الحالة الحقيقية للمتكلمين - على الأرجح ، لن يكون هذا الحل مناسبًا للاستخدام في ارتباط الدفق للأحداث في SIEM.
2. طريقة نشطة باستخدام حل إدارة الثغرات الأمنية . يمكنك تحميل تقاريرها إلى SIEM ، كما يفعل Micro ، على سبيل المثال ، من التركيز ArcSight. ولكن هل هناك ضمان بأن الماسح الضوئي لجهة خارجية سيجلب جميع البيانات اللازمة لتحديد الهوية؟ ما مدى صلة هذه المعلومات إذا أجريت عمليات المسح أكثر من مرة في الشهر (متوسط ​​للشركات الكبيرة) ، وبعيدًا عن تغطية البنية التحتية بالكامل.
3. طريقة سلبية . تحديد الأصول من الأحداث ، على الرغم من البيانات غير المكتملة وغير الدقيقة. لا تحتوي الأحداث على جميع المفاتيح ؛ حيث ترسل المصادر المختلفة مجموعات مختلفة من المفاتيح. ومع ذلك ، فهذه هي أسرع طريقة للحصول على معلومات حول التغييرات في السماعات. كقاعدة ، تُنشئ المصادر أحداثًا في جميع المواقف الموضحة أعلاه ، باستثناء عمليات الاستبدال المخططة للمعدات.
4. طريقة الهجين . الاستفادة من جميع النهج في وقت واحد:
   
   • تتيح المجموعة النشطة مع CMDB تعبئة أصول SIEM الأولية السريعة.
   • سيضيف التكامل مع إدارة الثغرات الأمنية المعلومات المفقودة.
   • سيتيح لك تحليل الأحداث تحديث النموذج بسرعة ، مع مراعاة تفاصيل كل مصدر على حدة.
   
   تتيح لك الطريقة الهجينة تسوية مشاكل الآخرين ، لكن من الصعب تنفيذها.

في الوقت الحالي ، عملت فقط مع حلين حيث كان لدى الشركات المصنّعة الخبرة اللازمة لتنفيذ هذا النهج - IBM QRadar (الوصف العام حسب المرجع وتفاصيل الخوارزمية مغلقة) وإيجابي تكنولوجيز ماكسباترول سيم (تفاصيل الخوارزمية مغلقة). في الوقت الحالي ، تواصل الشركتان استخدام وتحسين النهج المختلط بدقة.

لذلك:

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

تكوين النموذج

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

تمامًا مثل طراز المستخدم ، يتكون نموذج الشبكة وأنظمة الحوسبة من جزء شائع وسلوكي.

يجب أن يتضمن تكوين النموذج العام للشبكات وأنظمة الحوسبة على الأقل:

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

يجب أن يتضمن تكوين النموذج السلوكي للشبكات وأنظمة الحوسبة على الأقل:

• تفاعلات شبكة L3 و L4 (مع ما يتفاعل ووفقًا لبروتوكولات) ؛
• متوسط ​​كمية البيانات المنقولة في الأسبوع ؛
• المستخدمين الذين يستخدمون ؛
• من العقد التي يتم فيها التحكم عن بعد ؛
• إحصائيات تشغيل ميزات الأمان لهذا المضيف (الشبكة والمحلية).

نموذج الشبكات وأنظمة الحوسبة

مصادر البيانات للنموذج

يمكن جمع المعلومات لهذا النموذج بطريقتين: نشط وسلبي.

النظر في النموذج العام:

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

تحديد الهوية

دعنا ننتقل إلى العنصر الأخير من السياق - نموذج البيانات المحمية.

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

يتم تنفيذ تحديد المعلومات السرية بواسطة محرك بحث لبصمات الأصابع في حل DLP نفسه. لا تسمح خصوصية الآلية بتنفيذها داخل SIEM. وبالتالي ، من حيث تحديد البيانات المحمية ، من الممكن استخدام تكامل محكم فقط مع حلول فئة DLP.

تكوين النموذج

نظرًا لحقيقة أن DLP تنفذ معظم مراقبة وحماية المعلومات السرية ، فإن تركيب النموذج في SIEM مضغوط تمامًا.

كحد أدنى ، يجب تضمين ما يلي في النموذج العام للبيانات المحمية:

• ما هي الأصول المعلومات السرية المخزنة على ؛
• المستخدمين الذين لديهم حق الوصول إلى المعلومات السرية.

يجب تضمين ما يلي على الأقل في النموذج السلوكي للبيانات المحمية:

• بين الأصول التي هي معلومات سرية تنتقل ؛
• بين المستخدمين التي يتم نقل المعلومات السرية.

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

مصادر البيانات للنموذج

لإنشاء نموذج للبيانات المحمية ، تتوفر أيضًا طريقتان للحصول على المعلومات - النشطة وغير الفعالة.

النظر في النموذج العام:

آليات التنفيذ النموذجية في SIEM

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

1. كيفية تنفيذ جمع البيانات النشطة والسلبية.
2. أين وفي أي شكل لتخزين النموذج.

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

يتم جمع السلبي من خلال تحليل الأحداث التي تمر عبر SIEM.

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

في الحالة العامة ، تحتوي جميع حلول SIEM الحديثة على جميع العناصر اللازمة لإنشاء وتعبئة بيانات نموذج التيار المتردد الموصوف.

تاريخ النموذج

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

الاستنتاج من كل هذا هو: يجب أن يكون للواحد الذي يتم بناؤه داخل SIEM محفوظات يمكن الوصول إليها في أي وقت.


تغيير النموذج مع مرور الوقت

الاستنتاجات

لتلخيص:

1. لكي تعمل قواعد الارتباط مع أقل عدد ممكن من الإيجابيات الخاطئة ، يجب أن تأخذ في الاعتبار السياق الذي تعمل فيه.
2. .
3. SIEM .
4. :
   
   • ;
   • , ;
   • .
5. , , :
   
   • ;
   • .
6. , . .
7. .
8. , , , .
9. SIEM .

---

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

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

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

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

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

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

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