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