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

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

دعونا ننتهز الفرصة ونحاول إيجاد حل للمشكلة.

قواعد SIEM خارج الصندوق


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

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

قد تهمك المقالة إذا:

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

عن ماذا ستكون المقالات


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

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

من أجل فهم أفضل لمجموعة كاملة من القضايا التي سيتم عرضها ، سأقدم الهيكل العام لسلسلة المقالات الكاملة:

  • المادة 1: هذه المادة. دعونا نتحدث عن بيان المشكلة ونحاول أن نفهم لماذا نحتاج بشكل عام إلى القواعد "قواعد الارتباط التي تعمل خارج الصندوق". ستكون المقالة إيديولوجية في طبيعتها ، وإذا أصبحت مملة تمامًا ، يمكنك تخطيها. ولكن ، لا أنصح بذلك ، لأن في المقالات المستقبلية سوف أشير إليها في أغلب الأحيان. هنا سنناقش المشاكل الرئيسية التي تقف في طريقنا ، وطرق حلها.
  • المادة 2: مرحى! هذا هو المكان الذي نصل فيه إلى التفاصيل الأولى للنهج المقترح لحل المشكلة. دعنا نصف كيف يجب أن "يرى" نظام معلومات SIEM الآمن الخاص بنا. لنتحدث عما يجب أن يكون مجموعة الحقول اللازمة لتطبيع الأحداث.
  • المادة 3: نصف دور تصنيف الأحداث وكيف تبنى منهجية تطبيع الأحداث على أساسها. نوضح كيف تختلف أحداث تكنولوجيا المعلومات عن أحداث نظم المعلومات ولماذا يجب أن يكون لديهم مبادئ مختلفة للتصنيف. نعطي أمثلة حية لعمل هذه المنهجية.
  • المادة 4: ألق نظرة عن كثب على الأصول التي يتكون منها نظامنا الآلي ونرى كيف تؤثر على أداء القواعد. سوف نتأكد من أنه ليس بهذه البساطة معهم أيضًا: يجب تحديدهم وتحديثهم باستمرار.
  • المادة 5: التي بدأ كل شيء من أجلها. نصف أسلوب كتابة قواعد الارتباط ، بناءً على كل ما ورد في المقالات السابقة.

بيان المشكلة وسبب أهميته


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

والآن ، دعونا نفترض أننا قمنا بالفعل بحل جميع المشاكل وأن مهمتنا قد اكتملت بالفعل. ماذا يعطينا هذا؟

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

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

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

بما فيه الكفاية من كلمات الأغاني ، سنتحدث بمزيد من التفصيل عن المشاكل التي تنشأ في حل مشكلتنا.

التحديات التي نواجهها


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

بشكل عام ، تنقسم المشاكل إلى الكتل الأربع الكبيرة التالية:

  1. فقدان البيانات أثناء التطبيع المرتبط بتحويل نماذج "العالم".
  2. عدم وجود قواعد واضحة ومقبولة عالمياً لتطبيع الأحداث.
  3. "التغيير" المستمر في موضوع الحماية - نظامنا الآلي.
  4. عدم وجود قواعد لكتابة قواعد الارتباط.


مشاكل الارتباط SIEM


دعونا الآن ندرس هذه القضايا بمزيد من التفصيل.

تحول النموذج العالمي


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

تحويل نموذج SIEM

في المثال الموصوف أعلاه ، نلاحظ مشكلة كلاسيكية ، حيث يتم تحويل "النموذج المفاهيمي" الأصلي ( Sovetov B. Ya. ، Yakovlev S. A. ، System Modeling ) عن طريق التبسيط إلى نموذج آخر مع فقد التفاصيل.
بالضبط نفس الشيء يحدث في عالم الأحداث الناتجة عن البرامج أو الأجهزة.

التفسير الذي يمكن تقديمه هنا هو مثل هذه الصورة المبسطة بالفعل من مجال الموضوع الخاص بنا:

  • التحول الأول للنموذج. تم تحميل ملف قابل للتنفيذ في ذاكرة الوصول العشوائي ، وبدأ نظام التشغيل في تنفيذ التعليمات الموضحة فيه. يقوم نظام التشغيل بتمرير بعض المعلومات حول هذه العملية إلى خدمة daemon / logging (auditd ، eventlog ، إلخ). إذا لم تقم بتمكين تدقيق موسع للإجراءات ، فإن بعض المعلومات لا تقع في هذا البرنامج الخفي. ولكن حتى في تدقيق موسع ، ستبقى بعض المعلومات مهملة ، لأنه قرر مطورو نظام التشغيل أن مثل هذا الحجم من المعلومات يكفي لفهم ما يحدث.
  • التحول الثاني للنموذج. والآن يقوم البرنامج الخفي بإنشاء حدث ، ويكتب المعلومات على القرص ، وهنا نتفهم أن طول سطر الحدث يمكن أن يكون محددًا بعدد معين من وحدات البايت. إذا كان الخفي / الخدمة يحتفظ بسجل منظم ، فإنه يحتوي على بعض مخطط الحدث مع حقول معينة. ماذا تفعل إذا كان هناك الكثير من المعلومات التي لا تتناسب مع مخطط "سلكي"؟ بشكل صحيح ، على الأرجح سيتم تجاهل هذه المعلومات ببساطة.

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


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

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

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

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

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

منهجية تطبيع الحدث


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

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

  1. ما هي مجالات الدائرة لما هو مطلوب.
  2. ما أنواع البيانات التي تتوافق مع الحقول.
  3. ما هي المعلومات المهمة بالنسبة لنا في إطار كل نوع من أنواع الأحداث.
  4. ما هي قواعد ملء الحقول.

نموذج وجوه الحماية وتغيرها


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

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

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

منهجية تطوير قواعد الارتباط


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

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

في النهاية


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

لحل المشكلة علينا مواجهة المشاكل التالية:

  1. فقدان البيانات أثناء تحويل نموذج "العالم" في مرحلة التطبيع.
  2. عدم وجود تعريف واضح لمنهجية التطبيع.
  3. طفرة دائمة في موضوع الحماية تحت تأثير الناس والعمليات.
  4. عدم وجود منهجية لكتابة قواعد الارتباط.

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

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



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

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

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

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

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

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

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

Source: https://habr.com/ru/post/ar423431/


All Articles