> ## Content Index > Fetch the complete content index at: https://arabroot.io/llms.txt > Use this file to discover other available public pages before exploring further. # خطة الاستجابة للحوادث Incident Response وكتيبات التشغيل Playbooks - URL: https://arabroot.io/articles/خطة-الاستجابة-للحوادث-incident-response-وكتيبات-التشغيل/ - Published: 2026-10-26T22:27:33.000Z - Updated: 2026-10-27T08:22:04.000Z - Description: خطة استجابة وكتيبا حساب مخترق وفدية على NIST SP 800-61r3، مع مختبر نستعيد فيه البيانات من نسخة restic. - Author: فريق عرب رووت - Tags: الأدلة التقنية, الأمن السيبراني, لينكس والسيرفرات, الاستضافة الذاتية في الثامنة صباح الأحد وصل إلى فريق تقنية المعلومات في شركة التوزيع الصغيرة، وهو شخصان، ما فرزته محللة الأمن في [مقال فرز التنبيهات](https://arabroot.io/articles/%D9%8A%D9%88%D9%85-%D9%85%D8%AD%D9%84%D9%84-soc-%D9%81%D8%B1%D8%B2-%D8%A7%D9%84%D8%AA%D9%86%D8%A8%D9%8A%D9%87%D8%A7%D8%AA-%D9%85%D9%86-%D8%A7%D9%84%D8%AA%D9%86%D8%A8%D9%8A%D9%87-%D8%A7%D9%84%D9%89-%D8%A7%D9%84%D9%82%D8%B1%D8%A7%D8%B1/): قضية على سيرفر web01 فيها تخمين كلمات مرور، ثم ملفات PHP ومفتاح SSH ظهرت دون دخول ناجح ظاهر. والآن السؤال ليس «هل هذه حادثة؟»، فهذا حسم في الفرز، وإنما «ماذا نفعل الآن، بأي ترتيب، ومن يقرر ماذا، ومن نبلغ، ومتى؟». وفي هذه اللحظة بالضبط يفرق الاستعداد بين حادثة تنتهي في ساعات وحادثة تمتد أسابيع: الفريق الذي لديه خطة استجابة Incident Response Plan وكتيبات تشغيل Playbooks مكتوبة يفتح الكتيب ويمشي، والفريق الذي لا يملكها يرتجل تحت الضغط، فيعيد تشغيل السيرفر «لينظف» فيمحو الأدلة، أو يتأخر في التبليغ النظامي حتى يفوت موعده. هذا المقال خطة استجابة كاملة وكتيبان عمليان، مبنيان على الوثيقة الرسمية [NIST SP 800-61 Rev. 3](https://csrc.nist.gov/pubs/sp/800/61/r3/final?ref=arabroot.io) الصادرة في أبريل 2025، وعلى [اللائحة التنفيذية لنظام حماية البيانات الشخصية](https://sdaia.gov.sa/en/SDAIA/about/Documents/ImplementingRegulationPersonalDataProtectionLaw.pdf?ref=arabroot.io) من سدايا و[الضوابط الأساسية للأمن السيبراني ECC](https://cdn.nca.gov.sa/api/files/public/upload/86e09090-44e4-481f-bc28-355673607654%5FECC--2024-EN.pdf?ref=arabroot.io) من الهيئة الوطنية للأمن السيبراني، وكل رقم ضابط أو مادة فيه راجعناه في نصه الرسمي قبل ذكره. وبنينا مختبراً صغيراً مثلنا فيه حادثتين بأمان: حساب موظف مخترق على سيرفر، وبرنامج فدية على سيرفر قاعدة بيانات، ثم استعدنا البيانات من نسخة احتياطية حقيقية، وكل الأوامر والمخرجات من هذا المختبر. وهذا المقال هو المدخل إلى مرحلة [الاستجابة للحوادث والتحقيق الرقمي DFIR](https://arabroot.io/start/#stage-ir) في المسار، والأدوات التي تنفذ به مثل منصة الحالات والخط الزمني وفحص السيرفر المخترق لها مقالاتها المستقلة، فلن نكررها هنا: [![](https://arabroot.io/content/images/2026/10/dfir-basics-cover-cover.webp)دليلالتحقيق الرقمي DFIR للمبتدئين: احفظ الأدلة قبل أن تنظف السيرفرماذا تفعل عندما تشك أن سيرفرك مخترق، ولماذا تمسح إعادة التشغيل والتنظيف الأدلة التي تحتاجها لتعرف ما حدث.](https://arabroot.io/articles/%D8%A7%D9%84%D8%AA%D8%AD%D9%82%D9%8A%D9%82-%D8%A7%D9%84%D8%B1%D9%82%D9%85%D9%8A-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-dfir/)[![](https://arabroot.io/content/images/2026/10/thehive-lab-cover-cover.webp)دليلالاستجابة للحوادث Incident Response مع TheHiveحولنا تنبيهاً عن دخول مريب إلى حساب FTP إلى قضية في TheHive بمهام ومؤشرات وأسلوب ATT&CK، وقسنا ما تسمح به الرخصة فعلاً.](https://arabroot.io/articles/%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%AC%D8%A7%D8%A8%D8%A9-%D9%84%D9%84%D8%AD%D9%88%D8%A7%D8%AF%D8%AB-incident-response-%D9%85%D8%B9-thehive/)[![](https://arabroot.io/content/images/2026/10/compromised-linux-cover-cover.webp)دليلفحص سيرفر Linux مخترق دون أن تفسد الأدلةفحصنا سيرفراً مخترقاً في المختبر خطوة خطوة بالطريقة الصحيحة، فوجدنا برنامجاً من ملف محذوف وأمر ls مزروعاً ووقتاً مزوراً، دون أن نفسد دليلاً.](https://arabroot.io/articles/%D9%81%D8%AD%D8%B5-%D8%B3%D9%8A%D8%B1%D9%81%D8%B1-linux-%D9%85%D8%AE%D8%AA%D8%B1%D9%82-%D8%AF%D9%88%D9%86-%D8%A7%D9%86-%D8%AA%D9%81%D8%B3%D8%AF-%D8%A7%D9%84%D8%A7%D8%AF%D9%84%D8%A9/)[![](https://arabroot.io/content/images/2026/10/timeline-plaso-cover-cover.webp)دليلالخط الزمني للحادث Timeline مع Plaso وTimesketchبنينا خطاً زمنياً شاملاً لحادثة اختراق سيرفر بأداة Plaso، فأعاد الهجوم بالدقيقة، ثم رفعناه إلى Timesketch وشغلنا محلل تخمين كلمة المرور.](https://arabroot.io/articles/%D8%A7%D9%84%D8%AE%D8%B7-%D8%A7%D9%84%D8%B2%D9%85%D9%86%D9%8A-%D9%84%D9%84%D8%AD%D8%A7%D8%AF%D8%AB-timeline-%D9%85%D8%B9-plaso-%D9%88-timesketch/) وسوف نناقش في هذا المقال ما يلي: - دورة حياة الاستجابة في NIST SP 800-61r3، ولماذا تغيرت عن الإصدار الثاني، وبنيت على وظائف إطار CSF 2.0 الست. - الأدوار والمسؤوليات: من قائد الحادثة إلى القانوني ومالك الأصل، وكيف تجمعها شركة صغيرة. - الفرق بين الخطة والسياسة والإجراء والكتيب Playbook، وما الذي يكتب في كل منها. - الأدلة وسلسلة الحيازة Chain of Custody، والتواصل أثناء الحادثة. - التبليغ النظامي: المادة 24 من اللائحة التنفيذية لـ PDPL ومهلة 72 ساعة، والضابط 2-13 من ECC، من النص الرسمي فقط. - كتيب حساب موظف مخترق، وكتيب برنامج الفدية على سيرفر، خطوة بخطوة. - تجربة عملية: نمثل الحادثتين في مختبر، ونجمع الأدلة بالهاش، ونستعيد البيانات من نسخة restic جربناها فعلاً. - تمرين الطاولة Tabletop Exercise الذي يختبر الخطة قبل الحادثة، وأخطاء شائعة، وقائمة تحقق. ## دورة حياة الاستجابة: ماذا تغير في NIST SP 800-61r3؟ أشهر مرجع للاستجابة للحوادث في العالم هو وثيقة NIST SP 800-61، وقد صدر إصدارها الثالث في أبريل 2025، و[يحل محل الإصدار الثاني](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r3.pdf?ref=arabroot.io) الذي كان من 2012\. والإصدار الثاني كان يصف دورة حياة من أربع مراحل في حلقة دائرية: الاستعداد، ثم الكشف والتحليل، ثم الاحتواء والإزالة والتعافي، ثم ما بعد الحادثة، وكانت الدروس تجمع في آخر مرحلة وتعود إلى الاستعداد. وتشرح الوثيقة الجديدة لماذا لم يعد هذا يكفي: في ذلك الوقت كانت الحوادث نادرة ونطاقها محدوداً وتنتهي في يوم أو يومين، أما اليوم فالحوادث متكررة وأشد ضرراً، والتعافي منها يأخذ أسابيع أو أشهراً، والدروس يجب أن تشارك فور اكتشافها لا بعد انتهاء التعافي. لذلك بنى الإصدار الثالث الدورة على الوظائف الست لإطار الأمن السيبراني [NIST CSF 2.0](https://www.nist.gov/cyberframework?ref=arabroot.io)، كما في الصورة التالية: ![دورة حياة الاستجابة على ثلاثة مستويات: المستوى الأعلى الاستجابة نفسها فيه الكشف والتحليل Detect والاستجابة Respond والتعافي Recover، والمستوى الأوسط التحسين المستمر Improvement بفئة ID.IM حيث تغذي الدروس من كل الوظائف فئة التحسين وتعود لتصحح السياسات في كل وقت لا بعد التعافي فقط، والمستوى الأساس الاستعداد Preparation وليس جزءاً من الاستجابة نفسها وفيه الحوكمة Govern والتعريف Identify والحماية Protect، وملاحظة أن الجدول 1 يربط مراحل الإصدار الثاني بهذه الوظائف الست](https://arabroot.io/content/images/2026/10/ir-playbooks-01-lifecycle.webp) الاستجابة نفسها ثلاث وظائف، والاستعداد أساس أوسع منها، والتحسين يجري في كل وقت والوظائف الست كما تعرفها الوثيقة: - **الحوكمة Govern:** وضع استراتيجية إدارة المخاطر وسياستها ومتابعتها. - **التعريف Identify:** فهم المخاطر والأصول الحالية. - **الحماية Protect:** الضوابط التي تقلل المخاطر. - **الكشف Detect:** اكتشاف الهجمات المحتملة وتحليلها. - **الاستجابة Respond:** اتخاذ الإجراءات على الحادثة المكتشفة. - **التعافي Recover:** إعادة الأصول والعمليات المتأثرة. والفكرة التي تغيرت جوهرياً أن الوثيقة تضع الحوكمة والتعريف والحماية في «المستوى الأساس»، وتقول صراحة إنها ليست جزءاً من الاستجابة نفسها، وإنما أنشطة إدارة مخاطر أوسع تدعمها، بينما الاستجابة نفسها هي الكشف والاستجابة والتعافي في «المستوى الأعلى». والتحسين المستمر في المنتصف يعمل في كل وقت، لا في نهاية الحادثة فقط. والجدول 1 في الوثيقة يربط مراحل الإصدار الثاني الأربع بهذه الوظائف، فمن تعود على المراحل القديمة لا يحتاج أن ينسى شيئاً، وإنما أن يراها موزعة على الوظائف. ونحن في هذا المقال نستخدم لغة الوظائف، ونذكر رمز كل مخرج فرعي Subcategory من CSF مثل RS.MA-02، لأن الكتيبين مبنيان عليها، وهذا يربط عملك مباشرة بإطار معترف به إذا طلب المدقق ذلك. ## الأدوار والمسؤوليات: من يشارك في الاستجابة؟ في الإصدار الثاني كانت الاستجابة عمل فريق واحد تقريباً، وفي الإصدار الثالث يقول القسم 2.2 إن نجاح الاستجابة اليوم يعتمد على مشاركة أطراف داخلية وخارجية كثيرة بأدوار متنوعة. والصورة التالية تجمع الأدوار كما تعددها الوثيقة، مكيفة لشركة صغيرة: ![ثمانية أدوار: قائد الحادثة من الإدارة يقرر الإجراءات عالية الأثر، ومعالجو الحوادث يتحققون ويجمعون الأدلة ويحتوون داخليون أو عبر MSSP، ومختصو التقنية مديرو الأنظمة والشبكات والمطورون، والقانوني يراجع الخطط والعقود ويوجه عند التبعات، والعلاقات العامة متى يبلغ الإعلام، والموارد البشرية إذا كان الموظف مشتبهاً، ومالكو الأصول أولويات التعافي، والأطراف الخارجية مزود السحابة والإنترنت بمسؤولية مشتركة في العقد](https://arabroot.io/content/images/2026/10/ir-playbooks-02-roles.webp) في شركة صغيرة يجمع شخص عدة أدوار، والمهم أن يكون لكل دور مسمى قبل الحادثة وفي شركة التوزيع التي فيها شخصان، يأخذ مدير تقنية المعلومات دوري قائد الحادثة ومعالج الحوادث، ويأخذ زميله دور مختص التقنية، أما القانوني والعلاقات العامة فهما المدير العام الذي يرجع إلى مستشار قانوني خارجي عند الحاجة. والمهم في هذا ليس عدد الأشخاص، وإنما أن يكون مكتوباً قبل الحادثة من يقرر إيقاف خدمة الإنتاج، ومن يتصل بالهيئة، ومن يتحدث للإعلام، لأن الوقت الذي تقضيه في الحادثة وأنت تسأل «من يقرر هذا؟» هو وقت يستغله المهاجم. والوثيقة تذكر أيضاً دور معالجي الحوادث بالتفصيل: يتحققون أن حادثة وقعت فعلاً، ويجمعون البيانات والأدلة ويحللونها، ويرتبون أولويات الاستجابة، ويتصرفون للحد من الضرر وإيجاد السبب الجذري وإعادة التشغيل، وقد يكونون داخليين أو على عقد مع مزود خدمة أمنية مدارة أو متاحين عند الحاجة من جهة أم أو شريك أو جهة إنفاذ نظام. والمؤسسة الكبيرة قد يكون لها عدة فرق استجابة لكل قطاع، على أن تكون جزءاً من كيان منسق واحد حتى تبقى الإجراءات والتدريب متسقة وتتشارك المعلومات. ونقطة مهمة في الوثيقة عن الأطراف الخارجية: إذا استعنت بمزود خدمة أمنية مدارة MSSP أو بمزود سحابة، فهذه مسؤولية مشتركة Shared Responsibility يجب أن تحدد في العقد: ماذا يفعل المزود، وما حدود صلاحيته، مثل هل يستطيع أن يوقف خدمة لاحتواء حادثة دون الرجوع إليك؟ وهل يستطيع أن يشارك معلومات حادثتك المجهولة مع عملاء آخرين؟ والمزود قد يكتشف الهجوم أسرع منك لأنه يرى عدة عملاء، لكنه يملك أيضاً وصولاً مميزاً إلى أنظمتك، فاتفاقية عدم الإفصاح وبنود العقد جزء من الاستعداد لا من الحادثة. ## الخطة والسياسة والإجراء والكتيب: ما الفرق؟ قبل الحادثة بوقت طويل تكتب أربع وثائق مختلفة، وخلط أدوارها سبب شائع للفوضى وقت الحادثة. وقد شرحنا الفرق العام بينها في [مصطلحات GRC](https://arabroot.io/articles/%D9%85%D8%B5%D8%B7%D9%84%D8%AD%D8%A7%D8%AA-grc-%D8%A7%D9%84%D8%AD%D9%88%D9%83%D9%85%D8%A9-%D9%88%D8%A7%D9%84%D9%85%D8%AE%D8%A7%D8%B7%D8%B1-%D9%88%D8%A7%D9%84%D8%A7%D9%85%D8%AA%D8%AB%D8%A7%D9%84/)، وهنا نطبقها على الاستجابة كما يصفها القسم 2.3 من الوثيقة: | الوثيقة | تجيب عن | مثال من الاستجابة | | ----------------- | --------------------------------- | ----------------------------------------------------------------------------------------------- | | السياسة Policy | لماذا، ومن يملك الصلاحية | التزام الإدارة، ونطاق التطبيق، وتعريف الحادثة، ومن يملك صلاحية فصل أو إيقاف أصل، ومقاييس الأداء | | الخطة Plan | كيف ننظم الاستجابة ككل | الأدوار، والتواصل، ومستويات التصنيف، والتصعيد، والموارد، والتمارين | | الإجراء Procedure | كيف ننفذ عملية تقنية بالتفصيل | كيف تأخذ صورة قرص، كيف تعزل سيرفر، كيف تعيد نشر منصة الهوية | | الكتيب Playbook | خطوات قابلة للتنفيذ لسيناريو محدد | ماذا تفعل خطوة بخطوة عند حساب مخترق، أو عند فدية | والوثيقة تذكر أن كثيراً من المؤسسات تكتب إجراءاتها على شكل كتيبات Playbooks لأن ذلك يحسن قابلية استخدامها، وتحيل إلى [كتيبات CISA](https://www.cisa.gov/sites/default/files/2024-08/Federal%5FGovernment%5FCybersecurity%5FIncident%5Fand%5FVulnerability%5FResponse%5FPlaybooks%5F508C.pdf?ref=arabroot.io) كأمثلة. والسياسة تذكر أيضاً أن بعض الإجراءات يجب أن تجرب بانتظام، وأن تكتب إجراءات للعمليات المهمة التي قد تحتاجها عاجلاً في الطوارئ، مثل إعادة نشر منصة المصادقة الأساسية. وهذا سبب إضافي للتمرين الذي سنتناوله في آخر المقال: الإجراء الذي لم يجرب لن يعمل يوم تحتاجه. والعناصر التي تذكر الوثيقة أن أغلب سياسات الاستجابة تشترك فيها: بيان التزام الإدارة، والغرض والأهداف، والنطاق، وتعريف الأحداث والحوادث والتحقيقات، والأدوار والصلاحيات (مثل من يملك صلاحية المصادرة أو الفصل أو الإيقاف)، وإرشادات ترتيب أولوية الحوادث وتقدير خطورتها، ومقاييس الأداء. وقد شرحنا كيف تكتب سياسة يطبقها الناس في [سياسات الأمن السيبراني](https://arabroot.io/articles/%D8%B3%D9%8A%D8%A7%D8%B3%D8%A7%D8%AA-%D8%A7%D9%84%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%B3%D9%8A%D8%A8%D8%B1%D8%A7%D9%86%D9%8A-%D9%82%D9%88%D8%A7%D9%84%D8%A8-%D9%88%D9%83%D9%8A%D9%81-%D8%AA%D9%83%D8%AA%D8%A8-%D8%B3%D9%8A%D8%A7%D8%B3%D8%A9-%D8%AA%D8%B7%D8%A8%D9%82/). ولماذا نكتب كتيباً منفصلاً لكل سيناريو بدل إجراء عام واحد؟ لأن الحادثة تحت الضغط ليست وقت القراءة الطويلة، والكتيب الجيد يقرأ في دقائق ويمشى عليه خطوة خطوة. ولأن كل نوع حادثة يحتاج ترتيباً مختلفاً: الحساب المخترق عمله تحقيق قبل إزالة، والفدية عملها عزل سريع قبل أي شيء، ولو خلطت الاثنين في إجراء واحد عام لم ينفع أياً منهما. والوثيقة تنصح بأن تكتب كتيبات لأكثر أنواع الحوادث شيوعاً عندك، لا لكل احتمال، فالكتيب الذي لن يستخدم يستهلك وقتاً في كتابته وصيانته دون فائدة. وفي شركة صغيرة تبدأ بكتيبين أو ثلاثة: الحساب المخترق، والفدية، والتصيد الناجح، لأنها أكثر ما يقع، ثم تضيف مع الوقت. والكتيب ليس ثابتاً، وإنما يتغير بعد كل حادثة وكل تمرين، وهذا هو التحسين المستمر Improvement في دورة الحياة. فإذا كشفت حادثة حقيقية أن خطوة في الكتيب كانت غامضة أو ناقصة، تعدلها فوراً، وإذا أظهر تمرين طاولة أن الفريق لا يعرف من يملك صلاحية إيقاف خدمة، تضيف ذلك إلى الكتيب والخطة. والمخرج الفرعي ID.IM في CSF 2.0 هو هذا بالضبط: الدروس المستفادة من كل الأنشطة تحلل وترتب وتستخدم لتصحيح السياسات والإجراءات، وليس بعد التعافي فقط كما في الإصدار الثاني، وإنما في أي وقت تظهر فيه، مثل لحظة اكتشاف تهديد جديد. ## الأدلة وسلسلة الحيازة، والتبليغ النظامي قبل الكتيبين، قاعدتان تحكمان كل حادثة: كيف تحفظ الأدلة، ومتى تبلغ. والصورة التالية تجمعهما: ![لوحتان: الدليل وسلسلة الحيازة Chain of Custody احفظ الدليل بالهاش قبل أي تغيير مثل هاش سجل web01 d4c03725 وسجل من جمعه ومتى ومن أين وفئة البيانات ونوعها، وCSF 2.0 RS.AN-06 و07 تسجل إجراءات التحقيق وتحفظ سلامة الأدلة ومصدرها ولا تعمل على الأصل وإنما على نسخة، ولوحة تبليغ تسرب البيانات الشخصية بالمادة 24 من اللائحة التنفيذية PDPL بخط زمني من العلم بالحادثة إلى إشعار الهيئة المختصة خلال 72 ساعة مع عناصر الإشعار الخمسة وأن تعذر الاكتمال يقدم لاحقاً مع المبررات والفقرة 4 لا يخل بما تطلبه الهيئة الوطنية](https://arabroot.io/content/images/2026/10/ir-playbooks-05-notification.webp) التحقيق الدقيق هو ما يجعلك قادراً على التبليغ الصحيح في الوقت المطلوب ### سلسلة الحيازة Chain of Custody الدليل الذي لا تستطيع أن تثبت أنه لم يتغير منذ جمعته لا قيمة له أمام مدقق ولا محقق. لذلك يضع إطار CSF 2.0 مخرجين فرعيين في وظيفة الاستجابة: **RS.AN-06** أن تسجل الإجراءات التي أجريت أثناء التحقيق وتحفظ سلامة السجلات ومصدرها، و**RS.AN-07** أن تجمع بيانات الحادثة وبياناتها الوصفية وتحفظ سلامتها ومصدرها. وعملياً يعني هذا ثلاثة أشياء: احفظ الدليل بالهاش فور جمعه، فإذا تغير بايت واحد تغير الهاش، وسجل من جمعه ومتى ومن أي جهاز، ولا تعمل على الأصل أبداً وإنما على نسخة، كما شرحنا في [التحقيق الرقمي DFIR للمبتدئين](https://arabroot.io/articles/%D8%A7%D9%84%D8%AA%D8%AD%D9%82%D9%8A%D9%82-%D8%A7%D9%84%D8%B1%D9%82%D9%85%D9%8A-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-dfir/). وسوف نرى هذا بالهاش في التجربة العملية. ### التبليغ: المادة 24 من اللائحة التنفيذية لـ PDPL إذا مست الحادثة بيانات شخصية، يضاف إلى العمل التقني التزام نظامي بموعد صارم. فالمادة العشرون من [نظام حماية البيانات الشخصية](https://laws.boe.gov.sa/BoeLaws/Laws/LawDetails/b7cfae89-828e-4994-b167-adaa00e37188/1?ref=arabroot.io) تلزم جهة التحكم بإشعار الجهة المختصة عند علمها بأي تسرب أو تلف أو وصول غير مشروع للبيانات الشخصية، و**المادة الرابعة والعشرون** من اللائحة التنفيذية تحدد المهلة والمحتوى، وقد راجعنا نصها الرسمي: - **المهلة 72 ساعة من العلم بالحادثة**، لا من وقوعها، إن كان من شأن الحادثة الإضرار بالبيانات أو بصاحبها أو التعارض مع حقوقه ومصالحه. - الإشعار يتضمن خمسة عناصر: وصف الحادثة ووقتها وتاريخها وكيفية وقوعها ووقت العلم بها، وفئات أصحاب البيانات وأعدادهم الفعلية أو التقريبية ونوع البيانات، ووصف المخاطر والتدابير المتخذة والمستقبلية، وبيان هل أشعر أصحاب البيانات، وبيانات التواصل لجهة التحكم أو مسؤول حماية البيانات. - إن تعذر تقديم أي من المعلومات خلال 72 ساعة، تقدم في أقرب وقت مع مبررات التأخير، وتحتفظ جهة التحكم بنسخة من التقارير وتوثق التدابير التصحيحية. - الفقرة الرابعة تنص صراحة على أن هذا لا يخل بما يطلبه نظام الهيئة الوطنية للأمن السيبراني أو غيره من بلاغات، أي قد تحتاج بلاغين لجهتين. - والمادة تلزم أيضاً بإشعار صاحب البيانات دون تأخير إذا كان من شأن الحادثة الإضرار به، بلغة بسيطة وواضحة. والسؤال التقني الذي يحدد قدرتك على الوفاء بالمهلة: هل تستطيع أن تجيب خلال يومين عن «ما البيانات التي مست، ولكم شخص؟». وهذا لا يمكن إلا بتحقيق دقيق وسجل أنشطة معالجة وسجل تدقيق، كما شرحنا في [حماية البيانات الشخصية PDPL](https://arabroot.io/articles/%D8%AD%D9%85%D8%A7%D9%8A%D8%A9-%D8%A7%D9%84%D8%A8%D9%8A%D8%A7%D9%86%D8%A7%D8%AA-%D8%A7%D9%84%D8%B4%D8%AE%D8%B5%D9%8A%D8%A9-pdpl-%D9%84%D9%84%D8%AE%D8%AF%D9%85%D8%A7%D8%AA-%D8%A7%D9%84%D9%85%D8%B3%D8%AA%D8%B6%D8%A7%D9%81%D8%A9/) و[سجل التدقيق](https://arabroot.io/articles/%D8%B3%D8%AC%D9%84-%D8%A7%D9%84%D8%AA%D8%AF%D9%82%D9%8A%D9%82-audit-trail-%D9%85%D9%86-%D9%81%D8%B9%D9%84-%D9%85%D8%A7%D8%B0%D8%A7-%D9%88%D9%85%D8%AA%D9%89/). ومن أعاد التشغيل ومحا الأدلة لن يعرف متى بدأت الحادثة ولا ماذا مست، فلا يستطيع أن يبلغ بلاغاً صحيحاً. ولاحظ أن المهلة تبدأ من العلم بالحادثة، لا من وقوعها، وهذا سيف ذو حدين: فهو يعطيك وقتاً بعد الاكتشاف، لكنه يعني أيضاً أن ساعة الاكتشاف تبدأ العد، فلا يصح أن تؤجل الاكتشاف أو تتجاهل التنبيهات لتؤخر المهلة، فالنظام يفترض أنك تراقب فعلاً. والشرط أن يكون من شأن الحادثة الإضرار، فليست كل حادثة تقنية تسرباً لبيانات شخصية، ومحاولة فاشلة لا تمس بيانات ليست موجبة للتبليغ، وهنا تظهر أهمية التحقيق الدقيق مرة أخرى: فهو ما يفرق بين محاولة لم تصل إلى البيانات وتسريب فعلي، وبين حادثة على سيرفر لا يحمل بيانات شخصية وأخرى على سيرفر العملاء. والقرار النهائي في «هل هذه الحادثة موجبة للتبليغ؟» ليس قراراً تقنياً بحتاً، وإنما يشارك فيه القانوني ومسؤول حماية البيانات إن وجد، والمعالج التقني يوفر لهم الحقائق: ما الأصل، وما البيانات عليه، وما الذي وصل إليه المهاجم، ومتى. ### وضابط ECC: إدارة الحوادث والتهديدات وإذا كانت الجهة ملزمة بالضوابط الأساسية للأمن السيبراني، فالمكون الفرعي 2-13 لإدارة حوادث وتهديدات الأمن السيبراني يضع في الضابط 2-13-3 حداً أدنى راجعناه في النص الرسمي: خطط الاستجابة للحوادث وإجراءات التصعيد، وتصنيف الحوادث، والتبليغ عن الحوادث للهيئة الوطنية للأمن السيبراني، ومشاركة الإشعارات ومؤشرات الاختراق وتقارير الحوادث معها، وجمع ومعالجة تغذية معلومات التهديدات. وهذا بالضبط ما تبنيه خطة الاستجابة والكتيبات في هذا المقال، وقد شرحنا الضوابط ومن يلزم بها في [الضوابط الأساسية بلغة بسيطة](https://arabroot.io/articles/%D8%A7%D9%84%D8%B6%D9%88%D8%A7%D8%A8%D8%B7-%D8%A7%D9%84%D8%A7%D8%B3%D8%A7%D8%B3%D9%8A%D8%A9-%D9%84%D9%84%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%B3%D9%8A%D8%A8%D8%B1%D8%A7%D9%86%D9%8A-nca-ecc-%D8%A8%D9%84%D8%BA%D8%A9-%D8%A8%D8%B3%D9%8A%D8%B7%D8%A9/). ⚠️ أرقام الضوابط والمواد أعلاه من الوثائق الرسمية للهيئة الوطنية للأمن السيبراني وسدايا كما هي عند كتابة المقال، وهي مرجعك الأصل، والمقال يشرح ولا يحل محل الوثيقة ولا يغني عن المختص النظامي. راجع دائماً النص الرسمي والنسخة السارية قبل أن تبني عليها إجراء. ## تصنيف الحادثة وخطورتها: ما ترتبه الخطة أولاً قبل أن يفتح الفريق أي كتيب، يحتاج أن يصنف الحادثة ويقدر خطورتها، وهذا ما يسميه إطار CSF 2.0 المخرج الفرعي RS.MA-03، أي أن الحوادث تصنف وترتب أولوياتها. والسبب أن فريق الشركة الصغير لا يستطيع أن يتعامل مع كل حادثة بنفس الطاقة، فحادثة تمس سيرفر المتجر الذي يحمل بيانات العملاء ليست كحادثة على طابعة في المكتب، وحادثة فدية تشفر قاعدة البيانات ليست كمحاولة تخمين فشلت. والخطة الجيدة تحدد مستويات خطورة واضحة قبل الحادثة، حتى لا يتجادل الفريق تحت الضغط هل هذه حادثة كبيرة أم صغيرة. وأبسط تصنيف عملي لشركة صغيرة يقوم على سؤالين: ما الأصل المتأثر وما أهميته من قائمة الأصول، وما مدى تقدم المهاجم، أي هل هي محاولة، أم دخول، أم تحكم، أم تسريب أو تشفير للبيانات. ومن تقاطع السؤالين تخرج ثلاثة مستويات: منخفض يتعامل معه الفريق في وقته العادي ويوثقه، ومتوسط يستدعي معالجاً متفرغاً ويبلغ القائد، وعال يفعل الخطة كاملة ويستدعي كل الأدوار وقد يستوجب التبليغ النظامي. وحادثة web01 في مثالنا عالية، لأنها جمعت أصلاً حساساً مع تحكم المهاجم وبقائه، واحتمال مساس بيانات العملاء. والخطة أيضاً تحدد معايير بدء التعافي، وهو المخرج الفرعي RS.MA-05، أي متى ننتقل من الاحتواء والإزالة إلى إعادة الخدمة، حتى لا نعيدها مبكراً فيعود المهاجم، ولا نتأخر فيها فنخسر العمل. ## التواصل أثناء الحادثة: من يبلغ من؟ أكثر ما يفشل في الحوادث الحقيقية ليس الجانب التقني، وإنما التواصل: معالج يعزل سيرفراً دون أن يخبر مالكه فيتوقف الطلب في وقت الذروة، أو قائد يعرف بالحادثة من عميل غاضب لا من فريقه. ولذلك يضع إطار CSF 2.0 وظيفة كاملة للتواصل، فالمخرج الفرعي RS.CO-02 ينص على إشعار أصحاب المصلحة الداخليين والخارجيين بالحوادث، وRS.CO-03 على مشاركة المعلومات مع الجهات المحددة. والخطة الجيدة تحول هذا إلى جدول تواصل Communication Plan يكتب قبل الحادثة، فيه لكل مستوى خطورة: من يبلغ، وبماذا، ومتى، وبأي قناة. وفي شركة التوزيع يعني هذا أن أي حادثة متوسطة أو عالية تبلغ القائد خلال خمس عشرة دقيقة من تأكيدها، وأن مالك أي أصل يخبر قبل أن يعزل أو يوقف، وأن المستشار القانوني يستشار قبل أي تبليغ خارجي أو أي قرار قد يكون له أثر قانوني. والقاعدة المهمة أن قنوات التواصل أثناء الحادثة قد تكون نفسها مخترقة، فإذا كان البريد أو المحادثة الداخلية على نفس النظام المصاب، فلا تناقش الحادثة فيه، لأن المهاجم قد يقرأ، وهذا سبب أن تكون في الخطة قناة تواصل بديلة معروفة مسبقاً، مثل مجموعة على هواتف الفريق، تفعل عند الحوادث الكبيرة فقط. وأما التواصل مع العملاء والجمهور فهو دور العلاقات العامة والقانوني، ولا يتحدث المعالج التقني للإعلام، فالمعلومة غير الدقيقة في بداية الحادثة قد تضر أكثر من الصمت. ومخرج فرعي ثالث يهم الشركات الصغيرة التي تعتمد على موردين: RS.AN-08 تقدير حجم الحادثة والتحقق منه، وRS.CO يشمل التنسيق مع الأطراف الخارجية. فإذا كان سيرفر المحاسبة يديره مورد، فالخطة تحدد من يتصل بالمورد، وما المعلومة التي يطلبها، وما صلاحية المورد في التصرف، وكل هذا مكتوب في العقد قبل الحادثة لا يتفاوض عليه أثناءها. ## كتيب: حساب موظف مخترق Account Compromise الكتيب الجيد لا يشرح، وإنما يأمر: خطوات مرقمة يمشي عليها الفريق تحت الضغط. وهذا كتيب الحساب المخترق، وهو السيناريو الذي مثلناه في المختبر، والصورة التالية تبين خطواته مربوطة بمخرجات CSF الفرعية: ![خمس خطوات لكتيب الحساب المخترق: تحقق Triage هل الدخول حقيقي بمقارنة العنوان والوقت والجهاز RS.MA-02، ثم احتو Contain عطل الحساب أو أعد ضبط كلمته واقطع جلساته واحظر العنوان ولا تحذف شيئاً بعد RS.MI-01، ثم حقق Analyze ماذا فعل الحساب وابحث عن authorized_keys جديد ومهام cron RS.AN-03، ثم أزل Eradicate احذف المفتاح الدخيل وغير الأسرار RS.MI-02، ثم تعاف وبلغ Recover أعد الوصول السليم وراقب وبلغ إن مست بيانات شخصية RC.RP و RS.CO](https://arabroot.io/content/images/2026/10/ir-playbooks-03-account.webp) لا تحذف شيئاً قبل الحقق: الحذف المبكر يمحو الدليل على كيف دخل المهاجم 1. **تحقق Triage (RS.MA-02):** هل الدخول حقيقي أم إنذار خاطئ؟ قارن العنوان والوقت والجهاز بسلوك الحساب المعتاد. في حالتنا دخول من عنوان غير معروف بعد خمس محاولات فاشلة، فهو حقيقي. 2. **احتو Contain (RS.MI-01):** عطل الحساب أو أعد ضبط كلمة مروره، واقطع جلساته النشطة، واحظر العنوان المصدر. والمهم هنا: احتو دون أن تحذف، فإلغاء الحساب يوقف المهاجم، وحذف ما تركه يمحو الدليل على ما فعله. 3. **حقق Analyze (RS.AN-03):** ماذا فعل الحساب بعد الدخول؟ ابحث عما يضمن للمهاجم العودة Persistence: مفتاح جديد في `authorized_keys`، مهمة cron، مستخدم جديد، تغيير صلاحية. واحفظ كل دليل بالهاش قبل أن تلمسه. 4. **أزل Eradicate (RS.MI-02):** احذف ما تركه المهاجم من بقاء، وغير أسرار الحساب، وافحص إن كان الحساب استخدم للوصول إلى أنظمة أخرى، فالحساب المخترق كثيراً ما يكون أول خطوة لا آخرها. 5. **تعاف وبلغ Recover (RC.RP, RS.CO):** أعد الوصول السليم للموظف، وراقب عودة المهاجم أسابيع، وبلغ إن مست الحادثة بيانات شخصية بحسب المادة 24. وأخطر سؤال في هذا الكتيب هو الذي لا يجيب عنه الكتيب نفسه: كيف وصل المهاجم؟ ففي حالتنا نجح التخمين على كلمة مرور ضعيفة، وفي حالات أخرى يكون الحساب نفسه سليماً والدخول عبر جلسة مسروقة أو ثغرة، لذلك لا تغلق الحادثة لمجرد أنك عطلت الحساب، حتى تعرف الطريق الذي دخل منه وتغلقه. ولماذا نرتب الخطوات هكذا بالضبط؟ لأن كل ترتيب آخر يضر. فلو بدأنا بالإزالة قبل الحقق، لحذفنا المفتاح الدخيل قبل أن نعرف أنه موجود أصلاً، فلا نعرف أن المهاجم ضمن لنفسه العودة، ونظن أن تعطيل الحساب كفى. ولو بدأنا بالحقق قبل الاحتواء، لبقي المهاجم يعمل أثناء تحقيقنا، فربما وسع سيطرته بينما نحن نقرأ سجلاته. والاحتواء قبل الحقق مع حفظ الأدلة هو التوازن الصحيح: توقف المهاجم، ثم تفهم ما فعله، ثم تزيله. وهذا الترتيب يظهر أهمية أن يكون الكتيب مكتوباً ومجرباً، فتحت الضغط يميل الإنسان إلى أن «ينظف» أولاً، وهو أسوأ ما يفعله. ولاحظ أن الاستعداد Preparation من المستوى الأساس في دورة الحياة هو ما يجعل هذا الكتيب ممكناً أصلاً. فالتحقق في الخطوة الأولى يحتاج أن تعرف ما سلوك الحساب المعتاد، وهذا من قائمة الأصول ومن سجلات الدخول التي فعلتها مسبقاً. والاحتواء يحتاج أن تملك صلاحية تعطيل الحساب بسرعة، وهذا من إدارة الهوية التي بنيتها قبل الحادثة كما في [دورة حياة حساب الموظف](https://arabroot.io/articles/%D8%AF%D9%88%D8%B1%D8%A9-%D8%AD%D9%8A%D8%A7%D8%A9-%D8%AD%D8%B3%D8%A7%D8%A8-%D8%A7%D9%84%D9%85%D9%88%D8%B8%D9%81-jml/). ومنع هذه الحادثة أصلاً كان ممكناً بكلمة مرور قوية ومصادقة ثنائية، وهو ما تقوله وظيفة الحماية Protect، فالاستجابة الجيدة تبدأ قبل الحادثة بوقت طويل. ## كتيب: برنامج الفدية Ransomware على سيرفر برنامج الفدية Ransomware يشفر ملفات السيرفر ويطلب فدية لفك التشفير، وهو من أكثر الحوادث التي تحتاج ترتيباً صحيحاً، لأن الإجراء الخاطئ فيه يضاعف الضرر. وترتيب الخطوات في الصورة التالية مبني على قائمة الاستجابة في [دليل CISA StopRansomware](https://www.cisa.gov/stopransomware/ransomware-guide?ref=arabroot.io) (سبتمبر 2023)، والتعافي على نسخة restic جربناها في المختبر: ![خمس خطوات لكتيب الفدية: اعزل Isolate حدد الأنظمة المتأثرة واعزلها فوراً وإن تعذر فافصلها عن الشبكة ولا تطفئها إلا إذا تعذر الفصل حتى لا تفقد الذاكرة RS.MI-01، ثم رتب للتعافي Triage بحسب الأهمية وافحص أنظمة الكشف والسجلات RS.MA-03، ثم احفظ الأدلة صورة للقرص والذاكرة ومذكرة الفدية قبل إعادة البناء RS.AN-06 و07، ثم تحقق من النسخة Verify تأكد من سلامتها وابحث عن البرنامج المسقط حتى لا تعيد العدوى RC.RP-03، ثم استعد وأكد Restore إلى بيئة نظيفة لا فوق المصاب ثم أعلن نهاية التعافي RC.RP-02 و05، ولوحة قرار الدفع ليس تقنياً ويشمل الإدارة والقانوني](https://arabroot.io/content/images/2026/10/ir-playbooks-04-ransomware.webp) افصل عن الشبكة قبل أن تطفئ، واستعد إلى بيئة نظيفة لا فوق المصاب 1. **اعزل Isolate (RS.MI-01):** حدد الأنظمة المتأثرة واعزلها فوراً، وإن ظهر أن عدة أنظمة أو شبكات فرعية متأثرة فافصل الشبكة على مستوى السويتش، كما تنص قائمة CISA. والترتيب مهم: افصل عن الشبكة قبل أن تطفئ، لأن إطفاء السيرفر يفقدك الذاكرة التي قد تحمل مفتاح التشفير أو أثر العملية، ولا تطفئ إلا إذا تعذر الفصل بطريقة أخرى. 2. **رتب للتعافي Triage (RS.MA-03):** رتب الأنظمة المتأثرة للاستعادة بحسب أهميتها، وافحص أنظمة الكشف والسجلات والمضاد الفيروسي لتبني فهماً أولياً موثقاً لما حدث، كما في قائمة CISA. 3. **احفظ الأدلة (RS.AN-06, RS.AN-07):** صورة للقرص والذاكرة، ومذكرة الفدية، وعينة من الملفات المشفرة، قبل إعادة البناء، فقد تحتاجها للتبليغ النظامي وللتحقيق ولمعرفة إن كان هناك تسريب للبيانات لا تشفير فقط. 4. **تحقق من النسخة Verify (RC.RP-03):** تأكد من سلامة النسخة الاحتياطية قبل أن تستخدمها، وابحث عن البرنامج المسقط Dropper حتى لا تعيد العدوى من النسخة نفسها، وهذا ما تحذر منه قائمة CISA صراحة. 5. **استعد وأكد Restore (RC.RP-02, RC.RP-05):** استعد إلى بيئة نظيفة، لا فوق السيرفر المصاب، وأكد سلامة ما استعدت وأن الخدمة عادت للوضع الطبيعي، ثم أعلن نهاية التعافي (RC.RP-06). وأما قرار الدفع فليس قراراً تقنياً، ويشمل الإدارة والقانوني، وقد يكون للدفع تبعات نظامية، فحدد في الخطة قبل الحادثة من يقرره، ولا يتخذه المحلل وحده. ولاحظ أن الدفع لا يضمن استعادة البيانات ولا يمنع تسريبها، والأصل أن نسخة احتياطية مجربة تغنيك عن السؤال كله، وهذا ما نثبته في التجربة العملية. وقد شرحنا النسخ الاحتياطي الذي يقاوم الفدية في [النسخ الاحتياطي بقاعدة 3-2-1](https://arabroot.io/articles/%D8%A7%D9%84%D9%86%D8%B3%D8%AE-%D8%A7%D9%84%D8%A7%D8%AD%D8%AA%D9%8A%D8%A7%D8%B7%D9%8A-%D8%A8%D9%82%D8%A7%D8%B9%D8%AF%D8%A9-3-2-1-%D9%88%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1-%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%B9%D8%A7%D8%AF%D8%A9/). ونقطة تغفل عنها كثير من الفرق: الفدية الحديثة لا تشفر فقط، وإنما تسرق البيانات أولاً ثم تشفرها، وتهدد بنشرها إن لم تدفع، وهذا ما يسمى الابتزاز المزدوج Double Extortion. وأثر ذلك على الكتيب أن سؤال «هل سربت بيانات؟» لا يقل أهمية عن «كيف نستعيد؟»، لأن التسريب هو ما يوجب التزام التبليغ النظامي في المادة 24\. ولهذا كانت الخطوة الثالثة في الكتيب، أي حفظ الأدلة قبل إعادة البناء، مهمة حتى لو كانت لديك نسخة احتياطية ممتازة: فالنسخة تعيد الملفات، ولكنها لا تجيب عن سؤال ماذا خرج من الشبكة، وهذا السؤال يجاب من سجلات الشبكة وحركة البيانات الخارجة التي رأيناها في [مراقبة الشبكة مع Suricata وZeek](https://arabroot.io/articles/%D8%A7%D9%83%D8%AA%D8%B4%D8%A7%D9%81-%D8%A7%D9%84%D8%AA%D8%B3%D9%84%D9%84-%D9%81%D9%8A-%D8%A7%D9%84%D8%B4%D8%A8%D9%83%D8%A9-ids-%D9%85%D8%B9-suricata-%D9%88-zeek/)، لا من الملفات المشفرة. وأسلوب التشفير لمنع التعافي له رمز في ATT&CK هو [Data Encrypted for Impact T1486](https://attack.mitre.org/techniques/T1486/?ref=arabroot.io)، وكثير من عائلات الفدية تحذف أيضاً النسخ الاحتياطية ونسخ الظل Shadow Copies قبل التشفير، وهو أسلوب [Inhibit System Recovery T1490](https://attack.mitre.org/techniques/T1490/?ref=arabroot.io)، ولهذا يجب أن تكون نسختك الاحتياطية في مكان لا يصل إليه السيرفر المصاب، كما تقول قاعدة 3-2-1. ## تجربة عملية: نمثل الحادثتين ونستعيد البيانات الآن نبني المختبر ونمثل فيه الحادثتين بأمان على جهاز واحد بـ Docker: سيرفر web01 عليه موظفة اسمها sara بكلمة مرور ضعيفة ومئتا ملف، وسيرفر قاعدة بيانات db01، وجهاز مهاجم، كلهم على شبكة Docker خاصة لا تخرج إلى أي مكان. ونأخذ نسخة احتياطية بـ restic قبل الحادثتين، ثم نمثل تخمين كلمات المرور وبقاء المهاجم، ثم نمثل الفدية (محاكاة فقط، بلا برنامج خبيث حقيقي)، ثم نستعيد. 🛑 كل الهجمات في هذا المختبر من Container إلى Container داخل شبكة Docker أنشأناها لهذا الغرض، ومحاكاة الفدية سكربت يشفر نسخاً في المختبر ويسقط مذكرة نصية، وليست برنامجاً خبيثاً. لا تجرب أي هجوم على سيرفر لا تملكه أو لا تملك إذناً مكتوباً به، ولا تشغل أي برنامج فدية حقيقي مهما كان «للتجربة». ### السيرفرات والنسخة الاحتياطية قبل الحادثة ملف Dockerfile يبني Image فيها خادم SSH وموظفة بكلمة مرور ضعيفة ومئتا ملف فواتير تمثل بيانات السيرفر: ```dockerfile FROM debian:trixie-20261005-slim RUN apt-get update && apt-get install -y --no-install-recommends openssh-server openssh-client sshpass procps ca-certificates \ && rm -rf /var/lib/apt/lists/* && mkdir -p /run/sshd /srv/data RUN useradd -m -s /bin/bash sara && echo 'sara:Lab-Weak-Pass1' | chpasswd \ && for i in $(seq 1 200); do printf 'invoice %04d\nlab data only\n' $i > /srv/data/invoice-$i.txt; done CMD ["/usr/sbin/sshd", "-D", "-e"] ``` ```bash docker build -t sci-ir-lab:1 . docker network create --subnet 10.252.20.0/24 sci-ir-net docker run -d --name sci-ir-web --hostname web01 --network sci-ir-net --ip 10.252.20.10 sci-ir-lab:1 ``` ثم نأخذ النسخة الاحتياطية بـ [restic](https://restic.readthedocs.io/en/stable/?ref=arabroot.io)، وهي أداة نسخ احتياطي مفتوحة المصدر تشفر وتزيل التكرار Deduplication، شرحناها في مقال النسخ الاحتياطي. ننشئ المستودع، ثم ننسخ بيانات السيرفر إليه قبل أي حادثة، فهذه هي النسخة التي سوف تنقذنا: ```bash docker cp sci-ir-web:/srv/data ./srv-data MSYS_NO_PATHCONV=1 docker run --rm -e RESTIC_PASSWORD=lab-restic-pass -e RESTIC_REPOSITORY=/repo \ -v "$(pwd -W)/repo:/repo" restic/restic:0.18.1 init MSYS_NO_PATHCONV=1 docker run --rm -e RESTIC_PASSWORD=lab-restic-pass -e RESTIC_REPOSITORY=/repo \ -v "$(pwd -W)/repo:/repo" -v "$(pwd -W)/srv-data:/srv/data:ro" restic/restic:0.18.1 backup /srv/data --tag pre-incident ``` ```text Files: 200 new, 0 changed, 0 unmodified Added to the repository: 71.453 KiB (30.905 KiB stored) processed 200 files, 5.273 KiB in 0:02 snapshot fde164a0 saved ``` مئتا ملف محفوظة في نسخة مؤرخة، وهذا هو الاستعداد Preparation من المستوى الأساس في دورة الحياة: لا نبنيه أثناء الحادثة، وإنما قبلها. ### الحادثة الأولى: الحساب المخترق يخمن المهاجم من جهازه خمس كلمات مرور شائعة على الحساب sara، ثم يدخل بالكلمة الضعيفة الحقيقية، ويضيف مفتاحه إلى `authorized_keys` ليعود متى شاء: ```bash docker run -d --name sci-ir-attacker --network sci-ir-net --ip 10.252.20.66 sci-ir-lab:1 sleep infinity docker exec sci-ir-attacker sh -c ' T=web01; O="-o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o ConnectTimeout=5 -o LogLevel=ERROR -o NumberOfPasswordPrompts=1" for p in 123456 password sara123 letmein Summer2026; do sshpass -p "$p" ssh $O sara@$T true 2>/dev/null; sleep 1; done sshpass -p "Lab-Weak-Pass1" ssh $O sara@$T "mkdir -p ~/.ssh; echo \"ssh-ed25519 AAAA...attacker@lab\" >> ~/.ssh/authorized_keys; whoami; hostname" 2>/dev/null' ``` الآن يبدأ المعالج عمله بالكتيب. الخطوة الأولى بعد الاحتواء هي حفظ الأدلة بالهاش قبل لمس أي شيء، وهذا هو مخرج CSF الفرعي RS.AN-07، فنحفظ سجل SSH ونحسب هاشه: ```bash docker logs sci-ir-web > evidence/web01-sshd.log 2>&1 echo "failed: $(grep -c 'Failed password for sara' evidence/web01-sshd.log), accepted: $(grep -c 'Accepted password for sara' evidence/web01-sshd.log)" sha256sum evidence/web01-sshd.log docker exec sci-ir-web sh -c 'date -u +%FT%TZ; cat /home/sara/.ssh/authorized_keys; sha256sum /home/sara/.ssh/authorized_keys' ``` ```text failed: 5, accepted: 1 d4c0372551a0a239235343f6930d3fdf5d942225992c5bcbb3a1ad1168562744 *evidence/web01-sshd.log 2026-10-26T23:10:23Z ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILabIRPersistKey00000000000000000000000000 attacker@lab 34c68a12da309575241943ed4a012a57f306c953e356aa1c50d7a5ed7dc469f0 /home/sara/.ssh/authorized_keys ``` في المخرج أعلاه لاحظ التالي، وهو خلاصة التحقيق: - السجل يثبت القصة: خمس محاولات فاشلة لحساب sara من العنوان `10.252.20.66`، ثم دخول ناجح واحد، وهذا هو أسلوب [Valid Accounts T1078](https://attack.mitre.org/techniques/T1078/?ref=arabroot.io) بعد تخمين، والفرق المهم عن تنبيه الفرز أن هنا دخولاً ناجحاً بعد التخمين، لا محاولة فاشلة. - المفتاح الدخيل في `authorized_keys` هو بقاء المهاجم Persistence، أسلوب [T1098.004](https://attack.mitre.org/techniques/T1098/004/?ref=arabroot.io)، ولو حذفه الفريق قبل أن يحسب هاشه ويحفظه لضاع الدليل على أن المهاجم ضمن لنفسه العودة. - هاش السجل وهاش المفتاح هما سلسلة الحيازة في أبسط صورها: أي تعديل لاحق على الملفين سيغير الهاش، فتستطيع أن تثبت أن ما قدمته للمدقق أو للجهة هو ما جمعته. وبعد الحفظ تأتي الإزالة: حذف المفتاح، وتعطيل الحساب أو تغيير كلمته إلى كلمة قوية، والبحث عن أي أثر آخر. وفي الحادثة الحقيقية يكمل المعالج من هنا بأدوات التحقيق في [فحص سيرفر Linux مخترق](https://arabroot.io/articles/%D9%81%D8%AD%D8%B5-%D8%B3%D9%8A%D8%B1%D9%81%D8%B1-linux-%D9%85%D8%AE%D8%AA%D8%B1%D9%82-%D8%AF%D9%88%D9%86-%D8%A7%D9%86-%D8%AA%D9%81%D8%B3%D8%AF-%D8%A7%D9%84%D8%A7%D8%AF%D9%84%D8%A9/)، ويبني الخط الزمني في [Plaso وTimesketch](https://arabroot.io/articles/%D8%A7%D9%84%D8%AE%D8%B7-%D8%A7%D9%84%D8%B2%D9%85%D9%86%D9%8A-%D9%84%D9%84%D8%AD%D8%A7%D8%AF%D8%AB-timeline-%D9%85%D8%B9-plaso-%D9%88-timesketch/). ### الحادثة الثانية: الفدية والاستعادة على سيرفر قاعدة البيانات db01 نضع 150 ملف عملاء، ونأخذ نسخة احتياطية أولاً، ثم نمثل الفدية بسكربت يشفر النسخ الموجودة في المختبر بـ openssl ويسقط مذكرة، وهذه محاكاة فقط لرؤية أثر الفدية على الملفات دون أي برنامج خبيث: ```bash # backup BEFORE: 150 customer files MSYS_NO_PATHCONV=1 docker run --rm -e RESTIC_PASSWORD=lab-restic-pass -e RESTIC_REPOSITORY=/repo \ -v "$(pwd -W)/repo:/repo" -v "$(pwd -W)/srv-db:/srv/db:ro" restic/restic:0.18.1 backup /srv/db --tag db-nightly # lab ransomware simulation: encrypt the copies and drop a note (no real malware) docker exec sci-ir-db sh -c ' cd /srv/db for f in *.csv; do openssl enc -aes-256-cbc -pbkdf2 -k "lab-ransom-key-not-real" -in "$f" -out "$f.locked" && rm "$f"; done printf "YOUR FILES ARE ENCRYPTED (LAB SIMULATION).\n" > READ_ME_LAB.txt echo "locked: $(ls *.locked | wc -l), note: $(test -f READ_ME_LAB.txt && echo yes)"' ``` ```text processed 150 files, 4.073 KiB in 0:03 snapshot 72d0ef91 saved locked: 150, note: yes ``` مئة وخمسون ملفاً صارت `.locked` ومعها مذكرة، وهذا ما يجده الفريق صباحاً. والآن التعافي بالترتيب الصحيح من الكتيب، والمهم فيه أن نتحقق من النسخة قبل أن نثق بها، ونستعيد إلى مكان نظيف: ```bash # RC.RP-03: verify repository integrity before trusting it MSYS_NO_PATHCONV=1 docker run --rm -e RESTIC_PASSWORD=lab-restic-pass -e RESTIC_REPOSITORY=/repo \ -v "$(pwd -W)/repo:/repo" restic/restic:0.18.1 check # restore the db-nightly snapshot to a CLEAN directory, not over the infected server MSYS_NO_PATHCONV=1 docker run --rm -e RESTIC_PASSWORD=lab-restic-pass -e RESTIC_REPOSITORY=/repo \ -v "$(pwd -W)/repo:/repo" -v "$(pwd -W)/restore:/restore" restic/restic:0.18.1 restore 72d0ef91 --target /restore ls restore/srv/db | grep -c csv; ls restore/srv/db | grep -c locked; head -1 restore/srv/db/cust-1.csv ``` ```text check snapshots, trees and blobs [0:00] 100.00% 2 / 2 snapshots no errors were found Summary: Restored 152 files/dirs (4.073 KiB) in 0:03 150 0 customer 0001, balance 37 ``` في المخرج أعلاه لاحظ التالي: - `restic check` قال `no errors were found`، وهذا هو المخرج الفرعي RC.RP-03: لا تستعيد من نسخة قبل أن تتأكد أنها سليمة، فالنسخة التالفة تحول الحادثة إلى كارثة. - الاستعادة كانت إلى مجلد `restore` منفصل، لا فوق db01 المصاب، لأن إعادة الكتابة فوق الأصل تمحو الأدلة وقد تعيد العدوى إن بقي البرنامج المسقط. - بعد الاستعادة 150 ملف CSV سليم وصفر ملف `.locked`، وأول ملف فيه بياناته الأصلية، وهذا هو المخرج الفرعي RC.RP-05: تأكيد سلامة ما استعدت. وبهذا لم نحتج أن نسأل أصلاً عن دفع الفدية، لأن النسخة المجربة أغنت عنها. ولاحظ الفرق بين الحادثتين في العمل: الحساب المخترق عمله تحقيق وإزالة، والفدية عملها احتواء واستعادة، ولكن كليهما يبدأ بحفظ الأدلة بالهاش، وكلاهما لا يعمل فوق الأصل المصاب. وهذا المختبر مبسط عن الواقع في أمور يجب أن تعرفها: فنحن أخذنا النسخة الاحتياطية إلى مجلد على نفس الجهاز، وفي الواقع يجب أن تكون النسخة في مكان لا يصل إليه السيرفر المصاب، وأفضلها نسخة غير قابلة للحذف Immutable كما شرحنا في مقال النسخ الاحتياطي، وإلا حذفها برنامج الفدية مع الملفات. ومحاكاة الفدية لدينا شفرت الملفات بأداة نظام عادية، بينما الفدية الحقيقية تنتشر بين السيرفرات وتسرق البيانات وتحذف النسخ، ولا نشغلها أبداً للتجربة. والتحقيق الحقيقي في الحادثتين أوسع مما فعلنا: صورة كاملة للقرص والذاكرة، وبحث عن كل آثار المهاجم، وخط زمني يجمع كل الأحداث، وهذا ما تفعله أدوات مرحلة [DFIR](https://arabroot.io/start/#stage-ir) التي بنينا مختبراتها في مقالاتها. والهدف من مختبرنا أن ترى منطق الكتيب يعمل: حفظ الأدلة قبل اللمس، والاستعادة من نسخة محققة إلى مكان نظيف، لا أن يكون بديلاً عن تلك الأدوات. ### حذف المختبر Cleanup ```bash docker rm -f sci-ir-web sci-ir-db sci-ir-attacker docker network rm sci-ir-net docker image rm sci-ir-lab:1 restic/restic:0.18.1 rm -rf srv-data srv-db restore repo ``` ## تمرين الطاولة Tabletop Exercise: اختبر الخطة قبل الحادثة الخطة والكتيبات التي لم تجرب لا تعمل يوم تحتاجها، وأرخص طريقة لتجربتها تمرين الطاولة Tabletop Exercise: جلسة نقاشية يجلس فيها الفريق حول طاولة ويمشي على سيناريو، دون لمس أي نظام حقيقي، فتظهر الثغرات في الورق لا في الحادثة. والصورة التالية تبين بنيته: ![أربع مراحل لتمرين الطاولة: الإعداد باختيار سيناريو واقعي ودعوة الأدوار القائد والمعالج والتقنية والقانوني والعلاقات العامة، ثم الحقن Injects حيث يعطي المنسق معلومة جديدة كل مرحلة وصل تنبيه تخمين ثم دخول ناجح ثم مفتاح SSH جديد ثم البيانات فيها عملاء، ثم القرارات عند كل حقنة يقرر الفريق من يفعل ماذا ومن يبلغ ومتى يعزل، ثم الدروس بمحضر بما نجح وما تعثر وتعديلات على الكتيب، ولوحة أسئلة تكشف الثغرات من يملك صلاحية إيقاف خدمة الإنتاج وأين قائمة التواصل خارج ساعات العمل وكم ساعة للتبليغ النظامي وأين آخر نسخة ومتى جربنا استعادتها](https://arabroot.io/content/images/2026/10/ir-playbooks-06-tabletop.webp) الثغرة التي تكتشفها في التمرين تكلفك ساعة، والتي تكتشفها في الحادثة تكلفك أياماً وهذا تمرين جاهز لشركة التوزيع، مبني على حادثة الحساب المخترق في المختبر، يديره المنسق بأربع حقن Injects: 1. **الحقنة الأولى:** «الساعة 8:00، وصل تنبيه تخمين كلمات مرور على web01 من عنوان غير معروف». السؤال: من يفرز؟ وما الخطوة التالية؟ 2. **الحقنة الثانية:** «الساعة 8:10، التحقيق يظهر دخولاً ناجحاً لحساب sara من نفس العنوان». السؤال: من يملك صلاحية تعطيل الحساب؟ ومتى نعزل السيرفر؟ ومن يبلغ القائد؟ 3. **الحقنة الثالثة:** «الساعة 8:25، وجدنا مفتاح SSH دخيلاً وملفين جديدين». السؤال: كيف نحفظ الأدلة؟ ومن يقرر إعادة البناء؟ 4. **الحقنة الرابعة:** «الساعة 9:00، الملفات على السيرفر فيها بيانات عملاء». السؤال: هل هذا تسرب يستوجب التبليغ؟ وكم ساعة أمامنا؟ ومن يتصل بالهيئة؟ ومن يتحدث للعملاء؟ وعند كل حقنة يقرر الفريق بصوت عال، فتظهر الأسئلة التي لا جواب لها: من يملك صلاحية إيقاف خدمة الإنتاج؟ أين قائمة التواصل خارج ساعات العمل؟ كم ساعة لدينا للتبليغ النظامي، وهل نعرف أنها 72 ساعة من العلم؟ أين آخر نسخة احتياطية، ومتى جربنا استعادتها آخر مرة؟ ثم يكتب محضر بما نجح وما تعثر، وتعديلات على الكتيب، وموعد التمرين القادم. وينشر CISA حزم تمارين جاهزة في [CISA Tabletop Exercise Packages](https://www.cisa.gov/resources-tools/services/cisa-tabletop-exercise-packages?ref=arabroot.io) تستطيع أن تبدأ منها. والأدوات التي تدير الحالة فعلاً، مثل TheHive، تساعد في التمرين وفي الحادثة الحقيقية بأن تحفظ من فعل ماذا ومتى، كما جربنا في [مقال TheHive](https://arabroot.io/articles/%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%AC%D8%A7%D8%A8%D8%A9-%D9%84%D9%84%D8%AD%D9%88%D8%A7%D8%AF%D8%AB-incident-response-%D9%85%D8%B9-thehive/). [![](https://arabroot.io/content/images/2026/10/thehive-lab-cover-cover.webp)دليلالاستجابة للحوادث Incident Response مع TheHiveحولنا تنبيهاً عن دخول مريب إلى حساب FTP إلى قضية في TheHive بمهام ومؤشرات وأسلوب ATT&CK، وقسنا ما تسمح به الرخصة فعلاً.](https://arabroot.io/articles/%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%AC%D8%A7%D8%A8%D8%A9-%D9%84%D9%84%D8%AD%D9%88%D8%A7%D8%AF%D8%AB-incident-response-%D9%85%D8%B9-thehive/)[![](https://arabroot.io/content/images/2026/10/backup-321-cover-cover.webp)دليلالنسخ الاحتياطي بقاعدة 3-2-1 واختبار الاستعادةكيف تحدد كم بيانات تقبل أن تخسر، وتبني نسخاً لا يستطيع المخترق حذفها، وتتأكد أنك تستطيع استعادتها فعلاً.](https://arabroot.io/articles/%D8%A7%D9%84%D9%86%D8%B3%D8%AE-%D8%A7%D9%84%D8%A7%D8%AD%D8%AA%D9%8A%D8%A7%D8%B7%D9%8A-%D8%A8%D9%82%D8%A7%D8%B9%D8%AF%D8%A9-3-2-1-%D9%88%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1-%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%B9%D8%A7%D8%AF%D8%A9/)[![](https://arabroot.io/content/images/2026/10/dfir-basics-cover-cover.webp)دليلالتحقيق الرقمي DFIR للمبتدئين: احفظ الأدلة قبل أن تنظف السيرفرماذا تفعل عندما تشك أن سيرفرك مخترق، ولماذا تمسح إعادة التشغيل والتنظيف الأدلة التي تحتاجها لتعرف ما حدث.](https://arabroot.io/articles/%D8%A7%D9%84%D8%AA%D8%AD%D9%82%D9%8A%D9%82-%D8%A7%D9%84%D8%B1%D9%82%D9%85%D9%8A-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-dfir/) ## أخطاء شائعة - **إعادة تشغيل السيرفر «لينظف»:** يمحو الذاكرة والأدلة على كيف دخل المهاجم، ويجعل التبليغ الصحيح مستحيلاً. - **حذف ما تركه المهاجم قبل حفظه:** المفتاح الدخيل والملفات أدلة، احفظها بالهاش قبل الإزالة. - **الاستعادة فوق السيرفر المصاب:** يمحو الأدلة وقد يعيد العدوى، استعد إلى بيئة نظيفة. - **الثقة بالنسخة دون تحققها:** النسخة التالفة تكتشف وقت الاستعادة، فتحقق منها أولاً، واختبر الاستعادة دورياً لا وقت الحادثة. - **إغلاق الحادثة عند تعطيل الحساب:** دون معرفة الطريق الذي دخل منه المهاجم، فيعود من نفس الباب. - **تأخير التبليغ حتى اكتمال التحقيق:** المهلة 72 ساعة من العلم، وإن لم تكتمل المعلومات تقدم لاحقاً مع المبررات. - **عدم تحديد الأدوار قبل الحادثة:** فيضيع الوقت في السؤال «من يقرر هذا؟» تحت الضغط. - **كتابة الخطة وعدم تجربتها:** الإجراء الذي لم يجرب في تمرين طاولة لن يعمل في حادثة حقيقية. - **اتخاذ المحلل قرار دفع الفدية:** قرار إداري وقانوني، لا تقني، والدفع لا يضمن شيئاً. ## قائمة تحقق للاستعداد | البند | الوظيفة في CSF | جاهز؟ | | ------------------------------------------------------------------- | ------------------- | ----- | | سياسة استجابة معتمدة من الإدارة، فيها من يملك صلاحية الفصل والإيقاف | Govern | ☐ | | خطة استجابة بالأدوار والتصنيف والتصعيد والتواصل | Govern | ☐ | | قائمة أصول محدثة بمالك وأهمية كل أصل | Identify | ☐ | | كتيبان على الأقل: الحساب المخترق والفدية | Respond | ☐ | | نسخ احتياطية مجربة، واختبار استعادة دوري موثق | Recover | ☐ | | قائمة تواصل داخل وخارج ساعات العمل، وجهة اتصال الهيئة | Respond (RS.CO) | ☐ | | معرفة مهلة التبليغ: 72 ساعة من العلم بتسرب البيانات الشخصية | Respond (RS.CO) | ☐ | | طريقة حفظ الأدلة بالهاش وسلسلة الحيازة | Respond (RS.AN) | ☐ | | تمرين طاولة مرة في السنة على الأقل، بمحضر وتعديلات | Improvement (ID.IM) | ☐ | | عقد مزود الخدمة الخارجي فيه حدود الصلاحية والمسؤولية المشتركة | Govern | ☐ | ## الخلاصة - دورة حياة الاستجابة في NIST SP 800-61r3 بنيت على وظائف CSF 2.0 الست: الاستجابة نفسها هي الكشف والاستجابة والتعافي، والاستعداد (الحوكمة والتعريف والحماية) أساس أوسع منها، والتحسين يجري في كل وقت. - حدد الأدوار قبل الحادثة: قائد الحادثة والمعالج والتقنية والقانوني ومالك الأصل، ولو جمعها شخص واحد في شركة صغيرة. - السياسة لماذا، والخطة كيف ننظم، والإجراء كيف ننفذ، والكتيب خطوات سيناريو محدد. - احفظ الأدلة بالهاش قبل أي تغيير، ولا تعمل على الأصل، فهذا ما يثبت سلسلة الحيازة ويمكنك من التبليغ الصحيح. - التبليغ عند تسرب البيانات الشخصية خلال 72 ساعة من العلم بحسب المادة 24 من اللائحة التنفيذية، ولا يخل ذلك بما تطلبه الهيئة الوطنية للأمن السيبراني. - كتيب الحساب المخترق: تحقق، احتو، حقق، أزل، تعاف، دون حذف قبل الحفظ. وكتيب الفدية: اعزل قبل أن تطفئ، احفظ الأدلة، تحقق من النسخة، استعد إلى بيئة نظيفة. - النسخة الاحتياطية المجربة أغنتنا في المختبر عن سؤال دفع الفدية، واستعدنا 150 ملفاً بعد التحقق من سلامة النسخة. - تمرين الطاولة يكشف ثغرات الخطة في الورق لا في الحادثة، فاختبرها مرة في السنة على الأقل. وأقرب المقالات إلى هذا الموضوع في مرحلة الاستجابة والتحقيق: [![](https://arabroot.io/content/images/2026/10/thehive-lab-cover-cover.webp)دليلالاستجابة للحوادث Incident Response مع TheHiveحولنا تنبيهاً عن دخول مريب إلى حساب FTP إلى قضية في TheHive بمهام ومؤشرات وأسلوب ATT&CK، وقسنا ما تسمح به الرخصة فعلاً.](https://arabroot.io/articles/%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%AC%D8%A7%D8%A8%D8%A9-%D9%84%D9%84%D8%AD%D9%88%D8%A7%D8%AF%D8%AB-incident-response-%D9%85%D8%B9-thehive/)[![](https://arabroot.io/content/images/2026/10/dfir-basics-cover-cover.webp)دليلالتحقيق الرقمي DFIR للمبتدئين: احفظ الأدلة قبل أن تنظف السيرفرماذا تفعل عندما تشك أن سيرفرك مخترق، ولماذا تمسح إعادة التشغيل والتنظيف الأدلة التي تحتاجها لتعرف ما حدث.](https://arabroot.io/articles/%D8%A7%D9%84%D8%AA%D8%AD%D9%82%D9%8A%D9%82-%D8%A7%D9%84%D8%B1%D9%82%D9%85%D9%8A-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-dfir/)[![](https://arabroot.io/content/images/2026/10/compromised-linux-cover-cover.webp)دليلفحص سيرفر Linux مخترق دون أن تفسد الأدلةفحصنا سيرفراً مخترقاً في المختبر خطوة خطوة بالطريقة الصحيحة، فوجدنا برنامجاً من ملف محذوف وأمر ls مزروعاً ووقتاً مزوراً، دون أن نفسد دليلاً.](https://arabroot.io/articles/%D9%81%D8%AD%D8%B5-%D8%B3%D9%8A%D8%B1%D9%81%D8%B1-linux-%D9%85%D8%AE%D8%AA%D8%B1%D9%82-%D8%AF%D9%88%D9%86-%D8%A7%D9%86-%D8%AA%D9%81%D8%B3%D8%AF-%D8%A7%D9%84%D8%A7%D8%AF%D9%84%D8%A9/)[![](https://arabroot.io/content/images/2026/10/timeline-plaso-cover-cover.webp)دليلالخط الزمني للحادث Timeline مع Plaso وTimesketchبنينا خطاً زمنياً شاملاً لحادثة اختراق سيرفر بأداة Plaso، فأعاد الهجوم بالدقيقة، ثم رفعناه إلى Timesketch وشغلنا محلل تخمين كلمة المرور.](https://arabroot.io/articles/%D8%A7%D9%84%D8%AE%D8%B7-%D8%A7%D9%84%D8%B2%D9%85%D9%86%D9%8A-%D9%84%D9%84%D8%AD%D8%A7%D8%AF%D8%AB-timeline-%D9%85%D8%B9-plaso-%D9%88-timesketch/)[![](https://arabroot.io/content/images/2026/10/forensics-tools-cover-cover.webp)دليلأدوات التحقيق الرقمي مفتوحة المصدر وكيف تستخدمهاالأدوات المفتوحة التي تحتاجها في كل مرحلة من التحقيق الرقمي، من نسخ القرص واسترجاع ملف محذوف إلى بناء خط زمني لما حدث.](https://arabroot.io/articles/%D8%A7%D8%AF%D9%88%D8%A7%D8%AA-%D8%A7%D9%84%D8%AA%D8%AD%D9%82%D9%8A%D9%82-%D8%A7%D9%84%D8%B1%D9%82%D9%85%D9%8A-%D9%85%D9%81%D8%AA%D9%88%D8%AD%D8%A9-%D8%A7%D9%84%D9%85%D8%B5%D8%AF%D8%B1/)[![](https://arabroot.io/content/images/2026/10/soc-triage-cover-cover.webp)دليليوم محلل SOC: فرز التنبيهات Alert Triage من التنبيه إلى القرارستة عشر تنبيهاً حقيقياً من Wazuh وSuricata نفرزها واحداً واحداً بالإثراء من Zeek حتى القرار والتصعيد.](https://arabroot.io/articles/%D9%8A%D9%88%D9%85-%D9%85%D8%AD%D9%84%D9%84-soc-%D9%81%D8%B1%D8%B2-%D8%A7%D9%84%D8%AA%D9%86%D8%A8%D9%8A%D9%87%D8%A7%D8%AA-%D9%85%D9%86-%D8%A7%D9%84%D8%AA%D9%86%D8%A8%D9%8A%D9%87-%D8%A7%D9%84%D9%89-%D8%A7%D9%84%D9%82%D8%B1%D8%A7%D8%B1/) ## سجل التحديثات - أكتوبر 2026: كتابة المقال، وتنفيذ التجربة يوم 26 أكتوبر 2026 على Docker Engine 29.8.0 مع Debian 13 وrestic 0.18.1: تمثيل حساب مخترق (5 محاولات فاشلة ثم دخول ناجح ومفتاح SSH للبقاء) ومحاكاة فدية على 150 ملفاً، واستعادة من نسخة restic بعد التحقق من سلامتها، مبنياً على NIST SP 800-61r3 (أبريل 2025) وCSF 2.0 والمادة 24 من اللائحة التنفيذية لـ PDPL.