الدليل الميداني للاستجابة للحوادث

1المقدمة

يُحسم معظم الحوادث في الساعة الأولى. يحتوي المستجيبون المتمرسون المهاجم دون إتلاف الأدلة ودون تنبيهه ودون تحميل العمل تكلفة أكبر من اللازم. هذا الدليل نسخة مختصرة من طريقة إدارتنا لتلك الساعة وكل ما بعدها. وهو يتبع دورة الحياة التي يصفها NIST في SP 800-61، والتي تربط الاستجابة للحوادث الآن بوظائف Detect وRespond وRecover في Cybersecurity Framework 2.0.

2الجاهزية: تُقرَّر قبل الحادثة

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

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

3الساعة الأولى

1. أعلن الحادثة وعيّن قائدًا واحدًا لها. ينسق القائد ويقرر، ولا يقوم بالتحليل بنفسه.
2. انقل الاستجابة إلى القناة خارج النطاق، واجعل الدائرة مقصورة على من يحتاج إلى المعرفة.
3. ابدأ فورًا جدولًا زمنيًا بتوقيت UTC: كل ملاحظة وإجراء وشخص ووقت. سيصبح تقريرك وسجلك القانوني ودروسك المستفادة.
4. حدد النطاق قبل لمس أي شيء: ما الهويات والأجهزة والبيئات والبيانات المعنية، وهل النشاط ما زال جاريًا؟
5. احفظ الأدلة المتطايرة من أهم الأنظمة قبل تغيير حالتها.
6. اختر استراتيجية الاحتواء عن قصد (كما في الأقسام التالية)، ثم حدد وتيرة للتحديثات، مثل كل 60 دقيقة لحادثة SEV-1.

4الفرز والخطورة

تحدد الخطورة عدد الفريق والتواصل وصلاحية الإنفاق، لذلك عرّفها بلغة الأعمال لا بلغة التقنية.

• SEV-1: مهاجم نشط بصلاحيات عالية، أو تسريب بيانات مؤكد، أو تشغيل برنامج فدية، أو انقطاع يراه العملاء. تعبئة كاملة، واتصال مع الإدارة العليا، وإشراك القانونيين.
• SEV-2: اختراق مؤكد ومحصور في نطاق محدود (جهاز واحد أو حساب واحد)، دون دليل على حركة جانبية حتى الآن. مستجيبون مخصصون وتحديث يومي للإدارة.
• SEV-3: نشاط مشبوه أو مخالفة سياسة دون اختراق مؤكد. يُعالج في قائمة الأمن المعتادة.

5الأدلة: الأكثر تطايرًا أولًا

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

date -u                                        # anchor the timeline in UTC
uptime; who -a; last -Faiwx | head -50         # sessions and logins
ss -tunap                                      # live connections with owning processes
ps auxwwf                                      # full process tree and arguments
ls -l /proc/*/exe 2>/dev/null | grep deleted   # binaries deleted while running
find / -xdev -type f -mtime -2 2>/dev/null     # files changed in the last 48h
sha256sum triage-*.txt > triage.sha256

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

6الاحتواء دون تنبيه المهاجم

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

• اعزل الأجهزة باحتواء الشبكة عبر EDR بدل إطفائها، فالذاكرة دليل.
• أعد تعيين بيانات الاعتماد في عملية واحدة منسقة بعد تحديد النطاق: المستخدمون المتأثرون والمسؤولون وحسابات الخدمة ومفاتيح API والرموز. فالإعادة المتفرقة تتيح للمهاجم المراقبة والتكيف.
• في Active Directory، أعد تعيين حساب KRBTGT مرتين مع السماح بالنسخ المتماثل بينهما، لإبطال تذاكر Kerberos المزورة.
• في البيئات السحابية، ألغِ الجلسات ورموز التحديث، وبدّل مفاتيح الوصول، وابحث عن استمرار المهاجم: مستخدمون أو أدوار IAM جديدة، وتغييرات الثقة الاتحادية، وموافقات تطبيقات OAuth، وقواعد تحويل البريد.
• احظر بنية القيادة والتحكم المعروفة عند الخروج، وتوقع أن لدى المهاجم بديلًا لها.

7الإزالة والتعافي

تنتهي الإزالة عندما تستطيع شرح الوصول الأولي وتكون قد أزلت كل آليات الاستمرار، لا عندما تتوقف التنبيهات. ابحث عن المهام المجدولة ومهام cron والخدمات الجديدة ومفاتيح التشغيل وإدخالات SSH authorized_keys وweb shells وحسابات المسؤول غير المصرح بها وبيانات اعتماد CI/CD الملغومة.

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

8التواصل تحت الضغط

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

9ما بعد الحادثة

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

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

10الخاتمة

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