تصميم أدلة الإجراءات

دليل الإجراءات هو سير عمل استجابة مُقنّن: مجموعة مرتبة ومتفرعة من الخطوات تنفذها منصة SOAR عند تشغيلها. وهو النسخة القابلة للتنفيذ من دليل تشغيل كان موجودًا سابقًا في ويكي.

فبينما يقول دليل التشغيل تحقق من سمعة عنوان IP، يستدعي دليل الإجراءات فعليًا واجهة API الخاصة بالسمعة، ويحلل النتيجة، ويتفرع بناءً على الدرجة. ويُعد تصميم أدلة الإجراءات جيدًا المهارة الأساسية لهندسة الأتمتة في مركز العمليات الأمنية.

لا تصمموا دليل إجراءات في فراغ. ابدؤوا بتوثيق كيفية تعامل المحللين فعليًا مع التنبيه اليوم، خطوةً بخطوة، بما في ذلك القرارات التي يتخذونها والبيانات التي يتحققون منها.

صنّفوا كل خطوة ضمن واحدة من الفئات الثلاث التالية:

• إجراء حتمي — تؤدي المدخلات نفسها دائمًا إلى المخرجات نفسها (آمن للأتمتة).
• إثراء — جمع البيانات دون آثار جانبية (آمن للأتمتة).
• حكم — يتطلب سياقًا أو مساءلة (يُبقى ضمن الحلقة البشرية).

يحتاج كل دليل إجراءات إلى مشغّل دقيق. فإذا كان واسعًا جدًا، فسيُشغَّل بسبب الضجيج؛ وإذا كان ضيقًا جدًا، فسيفوّت الحالات الحقيقية.

ترتبط المشغلات عادةً بقاعدة ارتباط في SIEM، أو بفئة كشف في EDR، أو بحكم صادر عن بوابة البريد الإلكتروني. حدّدوا شرط الدخول بوضوح.

يعمل دليل الإجراءات على الآثار: المؤشرات المستخرجة من الحدث الذي شغّله، مثل عناوين IP، وتجزئات الملفات، وحسابات المستخدمين، وعناوين URL، وأسماء المضيفين.

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

• استخرجوا الآثار مرة واحدة في البداية.
• تحققوا من الأنواع (هل هذا عنوان IPv4 صالح فعلًا؟).
• مرّروا سياقًا مشتركًا عبر التدفق بأكمله.

تتفرع مسارات العمل الحقيقية. بعد إثراء البيانات، تقررون المسار استنادًا إلى الأدلة. أبقوا الفروع واضحة وشاملة حتى لا يمر أي حدث دون معالجة.

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

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

• تعطيل الحسابات: يحتاج إلى بوابة.
• حظر الشبكات الفرعية الكبيرة: يحتاج إلى بوابة.
• إثراء مؤشر: لا يحتاج إلى بوابة.

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

أدرجوا ما يلي:

• إعادة المحاولة مع التراجع التدريجي للأخطاء المؤقتة (HTTP 429 و503).
• إعدادات افتراضية آمنة عند الفشل — إذا فشلت عملية الإثراء، فليكن التصعيد إلى محلل بشري هو الإجراء الافتراضي، لا الإغلاق التلقائي.
• معالجة الرسائل غير القابلة للتسليم — وجّهوا الأحداث غير القابلة للمعالجة إلى قائمة انتظار يراجعها أحد المحللين.

قد يُشغَّل كتيب الإجراءات مرتين للحدث نفسه بسبب التنبيهات المكررة أو عمليات إعادة المحاولة. يجب أن تكون الإجراءات قابلة للتكرار: إذ إن تشغيلها مرتين يجب ألا يسبب ضررًا مضاعفًا.

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

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

وهذا يحاكي التصميم الجيد للبرمجيات. فعندما يُستدعى مكوّن قابل لإعادة الاستخدام لإثراء عناوين IP من كتيبات إجراءات التصيد الاحتيالي والقوة الغاشمة وC2، يصبح إصلاحه عند تغيّر واجهة API الخاصة بذكاء التهديدات أمرًا ممكنًا من مكان واحد.

شغّلوا كتيبات الإجراءات الجديدة أولًا في وضع التشغيل التجريبي / المحاكاة: نفّذوا الإثراء والتسجيل، لكن عطّلوا الإجراءات المدمّرة واستبدلوها بدوال وهمية. وقارنوا الإجراء المقترح من كتيب الإجراءات بما كان المحللون سيفعلونه في الحالات السابقة.

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

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

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

ويتحول كتيب الإجراءات غير الموثّق الذي لا يفهمه أحد إلى عبء بمجرد أن يعمل بشكل خاطئ.

طبّقوا مبادئ تصميم كتيبات الإجراءات على سيناريو فشل.

أساسيات تصميم كتيبات الإجراءات:

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