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