خطة تدريب Internship في الأمن السيبراني لـ 8 أو 12 أسبوعاً

لنفرض أن نورة تدير قسم الأمن السيبراني في شركة خدمات لوجستية فيها قرابة 400 موظف ومهندسا أمن فقط، وفي أول أسبوع بعد أن نشرت الشركة فرص التدريب الصيفي والتعاوني وصلها 90 طلباً، أغلبها من طلاب الحاسب ونظم المعلومات الذين يريدون «الأمن السيبراني» تحديداً. والمشكلة ليست في عدد الطلبات وحده، فالقسم يستطيع أن يقبل اثني عشر متدرباً على الأكثر، ووقت المهندسين الاثنين ممتلئ أصلاً بالتنبيهات والتحديثات وطلبات المدقق، وتجربة السنة الماضية كانت سيئة: ثلاثة متدربين جلسوا أسبوعين ينتظرون الحسابات، ثم قضوا بقية الصيف في قراءة عشوائية، وأحدهم فتح لوحة الـ SIEM الحقيقية من جهاز زميل وصور شاشتها ليسأل عنها في مجموعة على WhatsApp، وفيها أسماء موظفين وعناوين داخلية.

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

دليللماذا تحتاج شركتك برنامج تدريب Internship؟ماذا تستفيد الشركة من برنامج التدريب بالأرقام المنشورة، وأنواعه من الصيفي إلى تمهير، وما يقوله النظام في المملكة، ولماذا تفشل البرامج.دليلتخطيط برنامج التدريب Internship في 12 أسبوعاًكيف تحدد أهداف برنامج التدريب وميزانيته وتختار المشرفين والمشروع، مع خطة اثني عشر أسبوعاً وقوالب جاهزة للنسخ.دليلإدارة المتدربين Interns من الاستقطاب إلى قرار التوظيفكيف تستقطب المتدربين وتختارهم بعدل وتتابعهم أسبوعياً وتقيمهم بمعيار واضح حتى قرار التوظيف، مع القوالب والأدوات وأسعارها.

وسوف نناقش في هذا المقال ما يلي:

• الحسبة قبل الخطة: كم ساعة يملك المشرف فعلاً، ولماذا لا يعمل الإشراف الفردي مع اثني عشر متدرباً.
• قواعد السلامة Safety Rules التي توقع قبل أول يوم: المختبر، والبيانات مجهولة الهوية للقراءة فقط، ومنع الإنتاج والبيانات الشخصية، وما يقوله نظام حماية البيانات الشخصية والضوابط الأساسية للأمن السيبراني ECC عن ذلك.
• الفرز Screening بمهمة حقيقية لكل متقدم، والدفعات Cohorts، وقادة الأقران Peer Leads، والأسبوع النموذجي بساعة مراجعة واحدة.
• المختبر المشترك Shared Lab: ماذا يعمل على سيرفر واحد وماذا يعمل على جهاز المتدرب، بأرقام الذاكرة التي قسناها في مقالات المسار.
• خطة الأسابيع بالتفصيل في النسختين، مع المقالات والمختبرات والتسليم والتحقق لكل أسبوع.
• المشروع الختامي والعرض النهائي، ومعيار التقييم Rubric.
• تجربة عملية: نبني مهمة الفرز من سجل SSH حقيقي، ونصنع نسخة مختلفة لكل متقدم، ونصححها آلياً، ثم نجرب ماذا يحدث عندما ينسخ متقدم إجابات غيره.
• أخطاء شائعة، وقائمة تحقق قبل أن تفتح باب التقديم.

الحسبة قبل الخطة: كم ساعة يملك المشرف؟

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

ثم حسبت ما يحتاجه الإشراف الفردي One-to-one الذي يتخيله أغلب الناس عندما يسمعون كلمة تدريب، بافتراضات بسيطة نكتبها صراحة حتى تغيرها بأرقامك: اجتماع ساعة مع كل متدرب في الأسبوع، ونصف ساعة لقراءة تسليمه وتصحيحه. ومع اثني عشر متدرباً يصبح هذا 12 ساعة اجتماعات و6 ساعات تصحيح، أي 18 ساعة في الأسبوع، وهذا ستة أضعاف ما تملكه. والصورة التالية تقارن هذا بالنموذج الذي سوف نبنيه في بقية المقال:

والنموذج الثاني لا يقلل التعليم، وإنما يغير من يقوم بكل جزء منه:

• التصحيح الآلي Self-check: كل تمرين له إجابات قابلة للفحص، مثل عدد محاولات الدخول الفاشلة في سجل، أو عنوان المهاجم، أو رقم القاعدة التي أطلقت التنبيه، وسكربت صغير يقول للمتدرب PASS أو FAIL في ثوان، فلا ينتظر المشرف ليعرف أنه أخطأ في العد.
• قادة الأقران Peer Leads: ثلاثة من أقوى المتدربين، نختارهم بعد الأسبوع الثاني بالأدلة وليس بالانطباع، ويقود كل منهم مجموعة من أربعة، فيجيب عن الأسئلة المتكررة ويراجع التسليمات قبل أن تصل إلى المشرف.
• ساعة مراجعة واحدة للدفعة كلها: بدل اثني عشر اجتماعاً، والأسئلة المكتوبة في قناة واحدة تجيب عن السؤال مرة واحدة للجميع.
• قراءة عينة Sampling: يقرأ المشرف بعمق ثلاثة تسليمات في الأسبوع بالدور، فيرى كل متدرب في العمق مرة كل أربعة أسابيع، ويراه كل أسبوع في المراجعة.

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

ماذا يكون المتدرب في نهاية البرنامج؟

قبل أن تكتب أسبوعاً واحداً حدد المستوى الذي تستهدفه، وأوضح مرجع لذلك في المملكة هو الإطار السعودي لكوادر الأمن السيبراني SCyWF من الهيئة الوطنية للأمن السيبراني، وقد أعلنت الهيئة في 2026 تحديثه وإضافة ملحق للمسارات المهنية اسمه SCyWF Career Progression. ويصف الملحق المستوى الأول Level 1 بأنه دور مبتدئ لخريج بشهادة أو دبلوم، يعمل متدرباً أو داعماً للفريق أو عضواً مبتدئاً تحت إشراف قريب من ممارس، بينما يكتسب المهارات التي يحتاجها ليصبح ممارساً، ويطلب لهذا المستوى إتقاناً أساسياً Foundational، أي أداء المهام الروتينية تحت إشراف قريب. وهذا هو هدف البرنامج بالضبط: لا نريد محلل SOC مستقلاً بعد ثمانية أسابيع، وإنما شخصاً يستطيع أن يقوم بالمهام الأساسية في عدة أدوار وهو يعرف متى يسأل، وقد شرحنا الأدوار نفسها ومستوياتها في مقال أدوار الأمن السيبراني من نفس المرحلة.

دليلأدوار الأمن السيبراني Careers: ماذا يعمل كل دور، ومن أين تبدأ؟تسعة أدوار في الأمن السيبراني من المراجع الرسمية: اليوم العادي والمهارات والأدوات، ومن أي مستوى يبدأ كل دور.

قواعد السلامة Safety Rules قبل أول يوم

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

والقواعد كما كتبتها، مع سبب كل واحدة منها:

1. العمل في المختبر Lab فقط: كل تمرين في الخطة يعمل في Containers أو أجهزة افتراضية يبنيها المتدرب على جهازه أو على سيرفر المختبر المشترك، ولا يعمل شيء منها على شبكة الشركة. والسبب أن المختبر يسمح للمتدرب أن يخطئ ويعيد، وهذا نصف التعلم، بينما الخطأ على النظام الحقيقي له ضحية.
2. الأدوات الهجومية بإذن مكتوب ونطاق Scope: أدوات مثل Nmap وHydra وNuclei تعمل فقط على عناوين المختبر المكتوبة في ورقة الأسبوع، وفي شبكة Docker لا تصل إلى الإنترنت. وهذا ليس تفصيلاً إدارياً، فالفرق بين اختبار الاختراق والجريمة هو الإذن المكتوب، كما شرحنا في اختبار الاختراق المصرح به، والمتدرب الذي يجرب Nmap على موقع الجامعة «للتعلم» يعرض نفسه والشركة للمساءلة.
3. لا بيانات شخصية حقيقية: لا سجلات فيها أسماء موظفين أو عملاء، ولا رسائل بريد حقيقية، ولا لقطات من أنظمة الإنتاج. وكل البيانات في التمارين مولدة في المختبر أو عينات رسمية من مشاريع الأدوات نفسها.
4. البيانات مجهولة الهوية للقراءة فقط Read-only استثناء مكتوب: إذا أراد القسم أن يرى المتدرب شكل سجلات حقيقية في أسبوع المراقبة مثلاً، فالطريق نسخة مجهولة الهوية في مجلد للقراءة فقط على جهاز مخصص، باتفاقية موقعة، ومشرف مسمى بالاسم مسؤول عن النسخة وعن حذفها بعد الأسبوع.
5. لا وصول إلى الإنتاج Production: لا حسابات للمتدربين على السيرفرات الحقيقية ولا على الـ SIEM الحقيقي، والاستثناء الوحيد أن يشاهد المتدرب عمل المهندس بجانبه، وفي حضور مشرف مسمى، دون أن يلمس لوحة المفاتيح.
6. لا نسخ إلى أدوات خارجية: لا تلصق سجلات المختبر المشترك أو تسليمات الزملاء في محادثات عامة أو أدوات ذكاء اصطناعي خارجية دون إذن المشرف، والسبب أن العادة التي تبدأ في المختبر تنتقل إلى العمل.
7. الإبلاغ دون لوم: إذا وصل المتدرب إلى شيء حقيقي بالخطأ، مثل كلمة مرور في مستند أو عنوان سيرفر حقيقي، يبلغ المشرف فوراً ولا يجربه، ولا يعاقب على الإبلاغ، وإنما على الصمت.

متى تكون البيانات «مجهولة الهوية» فعلاً؟

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

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

وماذا تطلب الضوابط الأساسية للأمن السيبراني ECC؟

المتدرب في قسم الأمن السيبراني شخص يعمل داخل الجهة، حتى لو لم يكن موظفاً بعقد عمل عادي، لذلك يقرأ القسم عليه المكون الفرعي 1-9 «الأمن السيبراني المتعلق بالموارد البشرية» في وثيقة ECC-2:2024. وينص الضابط 1-9-3 على أن تشمل متطلبات ما قبل بدء العلاقة كحد أدنى إدراج بنود مسؤوليات الأمن السيبراني وبنود عدم الإفصاح في العقود، بما يشمل ما بعد انتهاء العلاقة، وإجراء المسح الأمني Screening or Vetting للعاملين في وظائف الأمن السيبراني والوظائف التقنية ذات الصلاحيات الحرجة والمميزة. وينص الضابط 1-9-4 على التوعية بالأمن السيبراني عند بداية العمل وخلاله، والضابط 1-9-5 على مراجعة الصلاحيات وإلغائها فور انتهاء العلاقة. ونحن هنا لا نقول إن الضوابط تخص المتدربين بالاسم، فهي تتكلم عن العاملين Personnel من موظفين ومتعاقدين، وإنما نقول إن تطبيق نفس المنطق عليهم أسهل طريق: بند عدم إفصاح في اتفاقية التدريب، وتوعية في اليوم الأول هي قواعد السلامة أعلاه، وحسابات المختبر تحذف في آخر يوم. وأما المسح الأمني فهو سبب إضافي لعدم إعطاء المتدرب أي صلاحية حرجة أو مميزة أصلاً، فلا يحتاجه.

الفرز Screening: مهمة حقيقية بدل السيرة الذاتية

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

وفي هذا التصميم عدة قرارات لها أسباب:

• مهمة تشبه العمل لا اختباراً للذاكرة: أسئلة مثل «ما الفرق بين IDS وIPS؟» يجيب عنها أي محرك بحث، بينما قراءة سجل حقيقي وعد الأسطر الصحيحة واستنتاج القصة منها هي بالضبط ما سيفعله المتدرب في أسبوع المراقبة، فتقيس الشيء الذي تريده.
• نسخة مختلفة لكل متقدم: إذا أرسلت نفس الملف للجميع فستجد الإجابات في مجموعة على Telegram في اليوم الثاني. لذلك نصنع من السجل الحقيقي نسخة لكل متقدم بعناوين وأسماء وأوقات مختلفة، والمفتاح يبقى عند القسم، وهذا ما بنيناه في التجربة العملية.
• الدرجة الآلية ترتب ولا تقرر: يقرأ الإنسان الفقرة المكتوبة لأعلى الدرجات فقط، ثم مكالمة قصيرة يشرح فيها المتقدم إجابته بصوته، وفي هذه المكالمة يظهر من نسخ إجابة لا يفهمها. والسبب أن الدرجة الآلية تقيس الدقة، ولا تقيس الفهم ولا طريقة الكتابة.
• 72 ساعة لا ساعتان: كثير من المتقدمين طلاب في فترة اختبارات أو يعملون، والمهمة تحتاج ساعة أو ساعتين من التركيز، فالمهلة القصيرة تقيس من كان متفرغاً ذلك اليوم لا من هو الأفضل.
• معيار مكتوب قبل قراءة أي ورقة: ماذا تعني الفقرة الممتازة والمقبولة والضعيفة، حتى لا يتغير الحكم بين الورقة الأولى والثلاثين، وهو نفس مبدأ الفرز العادل الذي شرحناه في نظام تتبع المتقدمين ATS.

ولاحظ أن نظام تتبع المتقدمين ATS هنا هو المكان الذي يحفظ الطلبات ويرسل المهمة ويسجل الدرجة، وليس هو من يصحح، فإذا كان لديك نظام مثل Frappe HR الذي جربناه في نظام توظيف على سيرفرك فالدرجة حقل في بطاقة المتقدم، والسكربت يعمل خارجه.

الدفعات Cohorts وقادة الأقران Peer Leads

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

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

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

والقائد يستفيد بقدر ما يعطي، فالشرح للآخرين أسرع طريقة لتعرف ما لا تفهمه، ويذكر ذلك في تقييمه النهائي كعمل قيادي فعلي. ولكن احذر أن يتحول القائد إلى مشرف مجاني: ساعتان في الأسبوع حد أعلى، وإذا زاد فالمشكلة في التمارين أو في الأسبوع نفسه وليست في المجموعة.

الأسبوع النموذجي: ساعة مراجعة واحدة

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

وساعة المراجعة يوم الخميس هي القلب الذي يجمع كل ذلك، ولها جدول ثابت حتى لا تتحول إلى محاضرة:

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

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

المختبر المشترك Shared Lab: ماذا يعمل وأين؟

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

وفي الجدول أعلاه لاحظ التالي:

• لو شغلت كل المنصات الثقيلة معاً طوال البرنامج لاحتجت أكثر من 12 GiB للمنصات وحدها، أما لو شغلت كل واحدة في أسبوعها فأثقل أسبوع هو أسبوع الاستجابة والتحقيق، حيث يعمل TheHive وTimesketch معاً بحوالي 9.5 GiB، وهذا يتسع له سيرفر بذاكرة 32 GB مع هامش لنظام التشغيل.
• كل منصة ثقيلة لها تشغيل أول طويل: TheHive احتاج قرابة خمس دقائق حتى ترد واجهته، وOpenVAS احتاج أكثر من ثلاث ساعات لبناء بيانات الثغرات في تجربتنا. لذلك يشغلها المشرف أو أحد القادة قبل الأسبوع بيوم، ولا يترك اثني عشر متدرباً ينتظرون صباح الأحد.
• OpenVAS ليس في الجدول عن قصد، فوقت تجهيزه وحجم بياناته أكبر من فائدته في أسبوع واحد، ويكفي المتدرب أن يقرأ تقريره في المقال ويشغل Nuclei بنفسه، وإذا أراد القسم أن يراه يعمل فيعرضه المشرف مرة واحدة.
• حساب لكل متدرب على السيرفر المشترك، لا حساب واحد للجميع، والسبب أن الحساب المشترك يجعل سجل من فعل ماذا بلا معنى، وهذا عكس ما نعلمه في أسبوع الهوية.
• لقطة Snapshot للسيرفر قبل كل أسبوع، فإذا عطل أحد المتدربين المنصة بتجربة خاطئة تعود في دقائق بدل أن يتوقف الجميع.

خطة الثمانية أسابيع أسبوعاً بأسبوع

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

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

الأسبوع الأول: الأساسيات وطريقة تفكير المهاجم

اليوم الأول ليس للمحتوى، وإنما لثلاثة أشياء: توقيع الاتفاقية وقواعد السلامة، وتشغيل Docker على جهاز كل متدرب والدخول إلى السيرفر المشترك بحسابه، ثم إعادة مهمة الفرز نفسها مع شرح الحل في ساعة المراجعة، لأن كل متدرب حلها وحده ويريد أن يعرف أين أخطأ. ثم يبدأ المحتوى باللغة المشتركة، فلا معنى لأسبوع المراقبة إذا كان المتدرب لا يفرق بين الحدث Event والتنبيه Alert والحادث Incident.

دليلمصطلحات الأمن السيبراني للمبتدئين: من CVE إلى Purple Teamماذا تعني الكلمات التي تتكرر في كل عرض أمني، من رقم الثغرة وخطورتها إلى أدوات المراقبة SOC والفرق الحمراء والزرقاء.دليلMITRE ATT&CK: كيف يفكر المهاجم خطوة بخطوةلغة موحدة لسلوك المهاجمين مبنية على حوادث موثقة، نقرأ بها هجوم فدية حقيقياً مرحلة بمرحلة ونربط كل خطوة بالدفاع المقابل.دليلنمذجة التهديدات Threat Modeling للمبتدئينكيف تسأل ما الذي قد يسوء في تصميم تطبيقك قبل أن تكتب الكود، وتقرر لكل تهديد هل تصلحه أو تقبله، مع قالب جاهز للنسخ.دليلأدوار الأمن السيبراني Careers: ماذا يعمل كل دور، ومن أين تبدأ؟تسعة أدوار في الأمن السيبراني من المراجع الرسمية: اليوم العادي والمهارات والأدوات، ومن أي مستوى يبدأ كل دور.

• الأهداف: يستخدم المتدرب المصطلحات بدقة، ويقرأ هجوماً حقيقياً موثقاً على مصفوفة ATT&CK، ويرسم نموذج تهديدات بسيطاً لتطبيق صغير.
• المختبرات: تجربة قراءة بيانات ATT&CK بنفسك في مقال MITRE ATT&CK، وتجربة pytm في مقال نمذجة التهديدات.
• التسليم: خريطة لحادثة مهمة الفرز على ATT&CK: ما التقنية في كل خطوة، ورقمها، ولماذا اخترتها، وماذا كان سيكشفها أو يمنعها.
• التحقق: سكربت يتحقق من أرقام التقنيات الأساسية، مثل تخمين كلمات المرور ثم الدخول بحساب صحيح، والقائد يقرأ التعليل، والمشرف يناقش خريطتين في ساعة المراجعة.

الأسبوع الثاني: الهوية والوصول Identity

أغلب الحوادث التي سيراها المتدرب لاحقاً تبدأ بحساب، كما رأى في مهمة الفرز نفسها، لذلك تأتي الهوية مبكراً.

دليلما هو الدخول الموحد SSO؟ المصطلحات التي تحتاجها أولاًخريطة لمصطلحات الدخول الموحد SSO مع تجربة حقيقية تبين كيف تفتح جلسة واحدة في مزود الهوية تطبيقين، وماذا يبقى بعد الخروج.دليلشرح OAuth وOpenID Connect للمبتدئينلماذا لا يجب أن يعرف أي تطبيق كلمة مرورك، وكيف يحل OAuth ذلك بتوكنات محدودة، وكيف يضيف OpenID Connect الدخول الموحد.دليلالدخول دون كلمة مرور: شرح Passkeys وWebAuthnلماذا لا تحميك رموز SMS وTOTP من التصيد الحديث، وكيف تحل Passkeys المشكلة بمفتاح خاص لا يغادر جهازك.دليلإدارة الهوية والوصول IAM والوصول المميز PAMمن يملك صلاحية root على سيرفراتك ومنذ متى، وكيف تضبط حسابات المديرين بصلاحيات مؤقتة وجلسات مسجلة.دليلدورة حياة حساب الموظف JML من أول يوم إلى آخر يومكيف تجعل الموارد البشرية مصدر كل حساب، فيجد الموظف ما يحتاجه في يومه الأول وتغلق كل أبوابه في يوم مغادرته.دليلوصول مؤقت عند الحاجة Just-in-Time وحساب الطوارئ Break-glassجربنا صلاحيات تنتهي وحدها بقاعدة sudo وشهادة SSH قصيرة العمر، ثم حساب طوارئ مختوماً بثلاثة أشخاص يرسل تنبيهاً عند كل استخدام.

• الأهداف: يفهم المتدرب أطراف الدخول الموحد SSO والجلسات الثلاث، ويمشي تدفق Authorization Code بنفسه، ويعرف لماذا تحتاج الحسابات المميزة إدارة خاصة.
• المختبرات: تجربة Dex وcurl في مقال OAuth، وشهادات SSH قصيرة العمر وتسجيل جلسات sudo في مقال IAM وPAM، وتجربة دورة حياة الحساب من ملف الموارد البشرية في مقال JML.
• التسليم: تقرير صفحة عن تجربة JML: ما الأبواب التي أغلقها السكربت عند مغادرة الموظف، وما الباب الذي بقي مفتوحاً لو نسيت خطوة، مع المخرج الحقيقي من جهازه.
• التحقق: المخرج نفسه دليل، فالقائد يتأكد أنه من تشغيل حقيقي وليس منسوخاً من المقال، لأن أسماء الـ Containers والأوقات تختلف، والمشرف يقرأ عينة.

وفي نهاية هذا الأسبوع يختار المشرف قادة الأقران الثلاثة كما شرحنا، ويعلن المجموعات قبل الأسبوع الثالث.

الأسبوع الثالث: حماية الأنظمة والشبكات وWi-Fi

هذا أسبوع القياس قبل الحماية وبعدها، وهو أكثر أسبوع يرى فيه المتدرب أثر عمله برقم.

دليلتقوية السيرفر Hardening وقياسها مع Lynis ومعايير CISيواجه مسؤول نظم طلب المستشفى بدليل تقوية، فيقيس خادمه بـ Lynis وCIS ويقويه ويعيد القياس، ويكشف مفاجأة تخفض الدرجة.دليلCrowdSec: اكتشاف هجمات التخمين وحظرها جماعياًتتعرض سيرفرات مسؤول النظم لتخمين دائم، فيبني مختبراً يرى فيه CrowdSec يكتشف الهجوم ويصدر قرار حظر ينفذه الجدار الناري.دليلتقسيم الشبكة Network Segmentation بال VLAN وال VPCلماذا تصل كاميرا مخترقة إلى قاعدة بياناتك، وكيف تمنع ذلك بتقسيم الشبكة إلى مناطق لا يمر بينها إلا ما تسمح به.دليلالنسخ الاحتياطي بقاعدة 3-2-1 واختبار الاستعادةكيف تحدد كم بيانات تقبل أن تخسر، وتبني نسخاً لا يستطيع المخترق حذفها، وتتأكد أنك تستطيع استعادتها فعلاً.دليلبوابة الدخول Captive Portal: شبكة الضيوف برمز تحققكيف تعمل بوابة الدخول في شبكة Wi-Fi الضيوف، وكيف تختار طريقة التحقق والأدوات المناسبة لمقهى أو فندق أو شركة.دليلWi-Fi للمؤسسات بحساب لكل موظف مع FreeRADIUSبنينا سيرفر FreeRADIUS واختبرنا دخول WPA2/3-Enterprise بأداة eapol_test، فرأينا الـ VLAN لكل موظف، وكيف أوقفت شهادة منتهية الدخول للجميع.

• الأهداف: يقيس المتدرب تقوية سيرفر قبل التعديل وبعده، ويرى هجوم تخمين يكشف ويحظر، ويفهم كيف يفصل الضيوف عن شبكة الشركة، وكيف يدخل كل موظف إلى Wi-Fi المؤسسة بحسابه.
• المختبرات: Lynis قبل التقوية وبعدها، وCrowdSec مع Container مهاجم، وتقسيم الشبكة بشبكات VLAN في Linux، واختبار FreeRADIUS بأداة eapol_test دون أي جهاز لاسلكي.
• التسليم: فرق مؤشر Lynis قبل التقوية وبعدها على سيرفر المختبر، مع قائمة التعديلات، وسبب كل واحد منها في سطر.
• التحقق: القائد يعيد تشغيل Lynis على Container المتدرب نفسه فيرى نفس الرقم، وهذا أبسط تحقق ممكن: الرقم يعاد إنتاجه أو لا يقبل.

ولاحظ أن مختبرات Wi-Fi في هذه الخطة لا تحتاج بطاقة لاسلكية، فالمصادقة 802.1X تختبر بين FreeRADIUS وeapol_test عبر الشبكة، وأما اكتشاف الأجهزة الدخيلة واختبار كلمة مرور الشبكة فهي في مقالات المرحلة القادمة، ولا يجربها المتدرب إلا على شبكة مختبر يملكها القسم وبإذن مكتوب.

الأسبوع الرابع: المراقبة SOC وفرز التنبيهات Triage

هنا يعمل Wazuh على السيرفر المشترك، ويضيف كل متدرب وكيلاً من Container على جهازه، فيرى تنبيهاته هو بين تنبيهات زملائه، وهذا قريب جداً من يوم المحلل الحقيقي.

دليلمراقبة السيرفرات مع Wazuh: من السجل Log إلى حظر المهاجمشغلنا Wazuh مع وكيل على سيرفر تجريبي، فكشف تخمين كلمات مرور SSH وحظر المهاجم تلقائياً، ونبه على ملف PHP دخيل خلال ثانية.دليلمراقبة الشبكة واكتشاف التسلل IDS مع Suricata وZeekمختبر حقيقي يقرأ الحركة نفسها بأداتين، فيكشف Suricata الهجمات المعروفة ويكتب Zeek سجلاً لكل اتصال، مع الضبط وفقد الحزم.دليليوم محلل SOC: فرز التنبيهات Alert Triage من التنبيه إلى القرارستة عشر تنبيهاً حقيقياً من Wazuh وSuricata نفرزها واحداً واحداً بالإثراء من Zeek حتى القرار والتصعيد.

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

الأسبوع الخامس: إدارة الثغرات Vulnerability Management

دليلإدارة الثغرات Vulnerability Management: هل سيرفرك متأثر؟كيف تعرف خلال ساعات أن ثغرة جديدة تمس سيرفراتك، ولماذا يخدعك رقم الإصدار، وكيف ترتب الإصلاح وتتأكد أنه تم فعلاً.دليلمختبر Lab: اكتشف السيرفرات المتأثرة بثغرة CVE جديدة وأصلحهافحصنا ثلاثة سيرفرات قديمة وسيرفراً محدثاً بأدوات Trivy وWazuh وسكربت تنبيه صغير، فظهر من يكتشف ثغرة الأسبوع ومن يفوته.دليلفحص الثغرات المعروفة Known Vulnerabilities مع Nucleiشغلنا Nuclei على خدمات قديمة في شبكة Docker معزولة، فأصاب في ثغرات Apache وGrafana وأعطى أربعة إنذارات خاطئة على Redis.دليلإدارة نتائج الفحص والثغرات مع DefectDojoاستوردنا نتائج Nuclei وOpenVAS الحقيقية إلى DefectDojo، فجمع التكرار وأغلق المصلح وحده، وكاد إعداد افتراضي واحد أن يفسد كل شيء.

• الأهداف: يعرف المتدرب لماذا يخدعه رقم الإصدار على التوزيعات، ويرتب الأولوية بـ CVSS وEPSS وقائمة KEV، ويفحص سيرفرات قديمة ويرى الفرق بعد الإصلاح.
• المختبرات: سيرفرات المختبر القديمة مع Trivy في مقال المختبر، وNuclei على أهدافه القديمة والمصلحة، واستيراد النتائج إلى DefectDojo على السيرفر المشترك.
• التسليم: قائمة أولويات لخمس ثغرات من فحصه، مع سبب الترتيب، ودليل إعادة الفحص بعد الإصلاح.
• التحقق: أرقام CVE والحزم المتأثرة يصححها السكربت من مخرج Trivy، والترتيب نفسه يناقش، لأن ترتيبين مختلفين قد يكونان صحيحين إذا اختلفت الافتراضات المكتوبة.

الأسبوع السادس: الاستجابة للحوادث والتحقيق الرقمي DFIR

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

دليلخطة الاستجابة للحوادث Incident Response وكتيبات التشغيل Playbooksخطة استجابة وكتيبا حساب مخترق وفدية على NIST SP 800-61r3، مع مختبر نستعيد فيه البيانات من نسخة restic.دليلالتحقيق الرقمي DFIR للمبتدئين: احفظ الأدلة قبل أن تنظف السيرفرماذا تفعل عندما تشك أن سيرفرك مخترق، ولماذا تمسح إعادة التشغيل والتنظيف الأدلة التي تحتاجها لتعرف ما حدث.دليلفحص سيرفر Linux مخترق دون أن تفسد الأدلةفحصنا سيرفراً مخترقاً في المختبر خطوة خطوة بالطريقة الصحيحة، فوجدنا برنامجاً من ملف محذوف وأمر ls مزروعاً ووقتاً مزوراً، دون أن نفسد دليلاً.دليلالخط الزمني للحادث Timeline مع Plaso وTimesketchبنينا خطاً زمنياً شاملاً لحادثة اختراق سيرفر بأداة Plaso، فأعاد الهجوم بالدقيقة، ثم رفعناه إلى Timesketch وشغلنا محلل تخمين كلمة المرور.دليلالاستجابة للحوادث Incident Response مع TheHiveحولنا تنبيهاً عن دخول مريب إلى حساب FTP إلى قضية في TheHive بمهام ومؤشرات وأسلوب ATT&CK، وقسنا ما تسمح به الرخصة فعلاً.

• الأهداف: يعرف المتدرب مراحل الاستجابة وأدوار الفريق، ويجمع الأدلة بالهاش وسلسلة الحيازة، ويبني خطاً زمنياً للحادثة، ويدير قضية في TheHive.
• المختبرات: فحص سيرفر Linux مخترق دون إفساد الأدلة، وPlaso على أدلة الحادثة في مقال الخط الزمني، وقضية في TheHive على السيرفر المشترك، ثم تمرين طاولة Tabletop لكتيب الاستجابة.
• التسليم: خط زمني من عشرة أحداث على الأكثر يروي ما حدث، مع هاش كل دليل جمعه، وقضية مغلقة في TheHive بحكمها.
• التحقق: الهاشات تقارن بالأصل آلياً، وأوقات الأحداث الرئيسية لها مفتاح، والقصة يقرؤها القائد، والمشرف يدير تمرين الطاولة بنفسه في ساعة المراجعة.

الأسبوع السابع: الاختبار المصرح به وأمن التطبيقات والحوكمة

في نسخة الثمانية أسابيع يجمع هذا الأسبوع ثلاث مراحل، لذلك يختار المتدرب واحدة منها للتعمق حسب اهتمامه، ويقرأ المقالات الأساسية في الاثنتين الأخريين فقط:

دليلاختبار الاختراق المصرح به: المنهجية والإذن والتقريريواجه مسؤول نظم طلب المستشفى باختبار اختراق سنوي، فنرافقه وهو يفهم الإذن والنطاق وقواعد الاشتباك وبنية التقرير قبل أن يبدأ.دليلاستكشاف الشبكة والمنافذ والخدمات مع Nmapنشغل Nmap على مختبر من Containers نملكها بثلاث خدمات، ونمر على الاكتشاف وفحص المنافذ وكشف الإصدار ومحرك السكربتات NSE بمخرج حقيقي.دليلثغرات الويب بالتجربة: تطبيق نخترقه ثم نصلحهنرى أثر أشهر ثغرات الويب على متجر صغير على جهازك، ثم السطر المسؤول عن كل ثغرة، ثم الإصلاح والاختبار الذي يثبته.دليلOWASP Top 10 للمبتدئين: أخطر عشر مشكلات في تطبيقات الويبأخطر عشر مشكلات أمنية في تطبيقات الويب، كل واحدة بمثال ضعيف ثم مصلح، وكيف تمنعها في الكود وأين تكتشفها.دليلمصطلحات GRC للمبتدئين بمثال من شركة صغيرةما الذي يعنيه GRC فعلاً، وما الكلمات التي يستخدمها المدقق، وكيف تثبت له أن ضوابطك تعمل كما تقول.دليلالضوابط الأساسية للأمن السيبراني NCA ECC بلغة بسيطةكيف تقرأ الضوابط الأساسية ECC دون أن تضيع في أرقامها، وعلى من تنطبق، وما المطلوب من جهتك فعلاً في كل مكون.

• الأهداف: يعرف المتدرب أن الاختبار يبدأ بالإذن والنطاق، ويستكشف شبكة المختبر بـ Nmap، أو يستغل ثغرة ويب في تطبيق المختبر ثم يصلحها، أو يربط ضابطاً من ECC بدليل حقيقي.
• المختبرات: مختبر Nmap بأربع خدمات وجدار ناري، أو تطبيق ثغرات الويب مع Semgrep والاختبارات، أو تجربة ربط الضوابط بالأدوات.
• التسليم: إما تقرير اختبار قصير على نطاق المختبر بالمنهجية، وإما إصلاح ثغرة مع اختبار Test يفشل قبل الإصلاح وينجح بعده، وإما جدول ضابطين مع الدليل الآلي لكل منهما.
• التحقق: اختبار الإصلاح يشغله السكربت، ونتائج Nmap تعاد على نفس المختبر، وجدول الضوابط يقرؤه المشرف.

الأسبوع الثامن: المشروع الختامي Capstone والعرض

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

خطة الاثني عشر أسبوعاً: ماذا يضيف كل أسبوع إضافي؟

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

أسبوع Wi-Fi مستقل

في النسخة الطويلة يأخذ Wi-Fi أسبوعه كاملاً، والهدف فيه ليس الهجوم على الشبكات، وإنما أن يفهم المتدرب لماذا كلمة مرور واحدة للجميع مشكلة، وكيف يعمل 802.1X من الداخل، وما الفرق بين PEAP وEAP-TLS، ولماذا تظهر نقطة الوصول المزيفة Evil Twin. والتسليم إعداد FreeRADIUS بحساب لكل موظف، ودخول ناجح ودخول مرفوض موثقان بمخرج eapol_test. أما الأدوات التي تحتاج بطاقة لاسلكية بوضع المراقبة Monitor Mode فلا تجرب إلا على شبكة مختبر يملكها القسم، وبإذن مكتوب، وإذا لم يكن لدى القسم هذه البطاقة فيكفي ملف الحزم الرسمي من مشروع الأداة نفسه، كما تفعل مقالات هذه المرحلة.

دليلأمن الشبكات اللاسلكية: WPA3 وفصل الضيوف وإيقاف WPSدليل الإعدادات الدفاعية في أي راوتر: تشفير WPA3 وكلمة مرور قوية، وفصل شبكة الضيوف وأجهزة إنترنت الأشياء، وإيقاف ميزة WPS الخطرة.دليلWi-Fi للمؤسسات بحساب لكل موظف مع FreeRADIUSبنينا سيرفر FreeRADIUS واختبرنا دخول WPA2/3-Enterprise بأداة eapol_test، فرأينا الـ VLAN لكل موظف، وكيف أوقفت شهادة منتهية الدخول للجميع.دليلبوابة الدخول Captive Portal: شبكة الضيوف برمز تحققكيف تعمل بوابة الدخول في شبكة Wi-Fi الضيوف، وكيف تختار طريقة التحقق والأدوات المناسبة لمقهى أو فندق أو شركة.دليلاكتشاف الأجهزة اللاسلكية الدخيلة مع Kismetشغلنا Kismet على ملفات التقاط رسمية فصنف الأجهزة واستخرج المصنع واسم الشبكة، ورفع تنبيهاً أمنياً عن جهاز بلا حماية إطارات الإدارة.دليلاختبار أمان شبكتك اللاسلكية بإذن مع Aircrack-ngكسرنا كلمات مرور WPA وWEP على ملفات الالتقاط الرسمية لـ Aircrack-ng، فظهر لماذا الهجوم دون اتصال، ولماذا تسقط كلمة القاموس في ثوان.

مراجعة المنتصف Mid-point Review في الأسبوع السادس

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

أسبوع الاختبار المصرح به في مختبر معزول

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

دليلاختبار الاختراق المصرح به: المنهجية والإذن والتقريريواجه مسؤول نظم طلب المستشفى باختبار اختراق سنوي، فنرافقه وهو يفهم الإذن والنطاق وقواعد الاشتباك وبنية التقرير قبل أن يبدأ.دليلاستكشاف الشبكة والمنافذ والخدمات مع Nmapنشغل Nmap على مختبر من Containers نملكها بثلاث خدمات، ونمر على الاكتشاف وفحص المنافذ وكشف الإصدار ومحرك السكربتات NSE بمخرج حقيقي.دليلKali Linux في Docker وأدوات الفريق الأحمر الأساسيةنرافق مسؤول نظم وهو يبني محطة Kali في Docker ويوجه أدواتها إلى مختبر يملكه، فيكشف gobuster مجلدات مخفية وتجد hydra كلمة مرور ضعيفة.

أسبوعا أمن التطبيقات والحوكمة

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

دليلثغرات الويب بالتجربة: تطبيق نخترقه ثم نصلحهنرى أثر أشهر ثغرات الويب على متجر صغير على جهازك، ثم السطر المسؤول عن كل ثغرة، ثم الإصلاح والاختبار الذي يثبته.دليلالبرمجة الآمنة Secure Coding بأمثلة من أربع لغاتكيف تكتب الكود الذي يتعامل مع مدخلات المستخدم والملفات والأخطاء بحيث لا يحتاج إصلاحاً أمنياً لاحقاً، بأمثلة في أربع لغات.دليلOWASP Top 10 للمبتدئين: أخطر عشر مشكلات في تطبيقات الويبأخطر عشر مشكلات أمنية في تطبيقات الويب، كل واحدة بمثال ضعيف ثم مصلح، وكيف تمنعها في الكود وأين تكتشفها.دليلسياسات الأمن السيبراني Policies: كيف تكتب سياسة تطبق فعلاً؟من أين تبدأ بقوالب السياسات العربية الرسمية، وكيف تحولها إلى صفحة يقرؤها الناس ويفحصها Git آلياً قبل أن يكتشف المدقق خاناتها الفارغة.دليلجمع أدلة الامتثال Evidence تلقائياً بدل لقطات الشاشةنبني جامع أدلة صغيراً يقرأ إعدادات السيرفرات عبر SSH ويحفظها بالهاش، ثم نجربه على تغيير مفاجئ ودليل معدل وجامع فقد صلاحيته بصمت.دليلالضوابط الأساسية للأمن السيبراني NCA ECC بلغة بسيطةكيف تقرأ الضوابط الأساسية ECC دون أن تضيع في أرقامها، وعلى من تنطبق، وما المطلوب من جهتك فعلاً في كل مكون.

المشروع الختامي Capstone والعرض النهائي

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

• حزمة قواعد كشف Detection Rules: ثلاث قواعد Wazuh أو Suricata لسيناريوهات القسم، مع سجل اختبار لكل قاعدة يثبت أنها تطلق التنبيه، وسجل آخر يثبت أنها لا تطلق على العمل العادي.
• دليل تقوية Hardening لنوع سيرفر يستخدمه القسم: سكربت يطبق التعديلات، وفرق Lynis قبل وبعد، وقائمة ما لم يطبق ولماذا.
• كتيب استجابة Playbook لحادثة واحدة: مثل حساب مخترق، مع تمرين طاولة يديره المتدرب بنفسه لزملائه، ومحضر التمرين وما تغير في الكتيب بعده.
• مواد توعية: ثلاث رسائل قصيرة وصفحة واحدة لموضوع اختاره القسم، مبنية على حادثة الفرز أو على تنبيهات أسبوع المراقبة، مع خطة قياس بسيطة.
• جدول ضوابط بأدلة آلية: خمسة ضوابط من ECC مع سكربت يجمع الدليل لكل منها من سيرفرات المختبر.

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

معيار التقييم Rubric

التقييم النهائي على خمسة معايير، بأربعة مستويات لكل منها، وهو نفس المعيار في مراجعة المنتصف والعرض النهائي، والجدول التالي يصف المستويين الطرفيين وما بينهما:

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

تجربة عملية: مهمة فرز من سجل SSH حقيقي لكل متقدم

الآن نبني مهمة الفرز التي وصفناها، على جهاز واحد بـ Docker: سيرفر SSH حقيقي في Container، وجهازان في نفس الشبكة الداخلية، الأول يخمن كلمات المرور على عدة أسماء ثم يدخل بحساب صحيح، والثاني موظفة أخطأت في كلمة مرورها مرة ثم دخلت. ثم نصنع من السجل نسخة مختلفة لكل متقدم، ونصحح ثلاث أوراق إجابة. وكل شيء في شبكة Docker خاصة لا تصل إلى أي جهاز خارجها، ولا ينشر أي منفذ على الجهاز.

الـ Docker Image والسجل الأصلي

نبدأ بـ Docker Image واحدة فيها خادم SSH وعميله وأداة sshpass التي تمرر كلمة المرور من سطر الأوامر، وهي مناسبة للمختبر فقط، ومعها مستخدمان بكلمات مرور تجريبية:

FROM debian:trixie-20261005-slim
RUN apt-get update && apt-get install -y --no-install-recommends openssh-server openssh-client sshpass python3 ca-certificates \
 && rm -rf /var/lib/apt/lists/* && mkdir -p /run/sshd
RUN useradd -m -s /bin/bash deploy && echo 'deploy:Lab-Only-2026!' | chpasswd \
 && useradd -m -s /bin/bash mona && echo 'mona:Another-Lab-Pass-9' | chpasswd

ثم سكربت gen.sh الذي ينشئ الشبكة والسيرفر ويشغل الجهازين:

#!/bin/sh
# Generates the screening log: real sshd on sci-intern-target, two lab clients.
set -e
docker network create --subnet 10.251.15.0/24 sci-intern-net >/dev/null
docker run -d --name sci-intern-target --network sci-intern-net --ip 10.251.15.10 sci-intern-lab:1 \
  /usr/sbin/sshd -D -e -o PasswordAuthentication=yes -o LogLevel=INFO >/dev/null
sleep 2
# client A (10.251.15.21): guesses, then a valid login as deploy
docker run --rm --network sci-intern-net --ip 10.251.15.21 sci-intern-lab:1 sh -c '
  T=10.251.15.10; O="-o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o ConnectTimeout=5 -o NumberOfPasswordPrompts=1"
  for u in root root root admin admin test oracle deploy deploy; do
    sshpass -p "guess-$u-$RANDOM" ssh $O $u@$T true 2>/dev/null || true; sleep 1; done
  sshpass -p "Lab-Only-2026!" ssh $O deploy@$T "id; uname -n" 2>/dev/null'
# client B (10.251.15.22): an employee who mistyped once, then logged in
docker run --rm --network sci-intern-net --ip 10.251.15.22 sci-intern-lab:1 sh -c '
  T=10.251.15.10; O="-o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o ConnectTimeout=5 -o NumberOfPasswordPrompts=1"
  sshpass -p "another-lab-pass-9" ssh $O mona@$T true 2>/dev/null || true; sleep 1
  sshpass -p "Another-Lab-Pass-9" ssh $O mona@$T true 2>/dev/null'
docker logs -t sci-intern-target > auth.log 2>&1

في السكربت أعلاه لاحظ التالي:

• كل الأسماء تبدأ بالبادئة sci-intern، والعناوين ثابتة بالخيار --ip حتى نعرف من فعل ماذا عندما نقرأ السجل، وهذه عادة جيدة في أي مختبر تبنيه للمتدربين.
• NumberOfPasswordPrompts=1 يجعل كل اتصال محاولة واحدة، فيصبح عدد الأسطر في السجل مساوياً لعدد المحاولات، وهذا يجعل السؤال الأول له إجابة واحدة واضحة.
• الخيار -e يرسل سجل sshd إلى الخطأ القياسي stderr بدل syslog، ثم نقرؤه بالأمر docker logs -t الذي يضيف وقتاً لكل سطر.

وفي المحاولة الأولى استخدمنا الخيار -E /var/log/auth.log الذي يكتب السجل إلى ملف مباشرة، فخرج السجل بلا أي وقت، مثل السطر Failed password for root from 10.251.15.21 port 45416 ssh2 وحده، والسبب أن الأوقات في السجل العادي يضيفها syslog أو journald وليس sshd نفسه، ولا يوجد أي منهما في الـ Container. وسجل بلا أوقات لا يصلح لمهمة فرز، فالسؤال «متى دخل المهاجم؟» من أهم الأسئلة، لذلك انتقلنا إلى -e مع أوقات Docker. ونشغل السكربت، ثم نقرأ السجل:

docker build -q -t sci-intern-lab:1 .
MSYS_NO_PATHCONV=1 ./gen.sh
wc -l auth.log

والمخرج سوف يكون كما يلي:

uid=1000(deploy) gid=1000(deploy) groups=1000(deploy)
9be6c56dca99
32 auth.log

السطران الأولان هما مخرج الأمرين id وuname -n اللذين نفذهما الجهاز الأول بعد دخوله بحساب deploy، أي أن الدخول نجح فعلاً ونفذ أوامر على السيرفر. والمتغير MSYS_NO_PATHCONV=1 نحتاجه في Git Bash على Windows فقط، حتى لا يحول المسارات التي تبدأ بشرطة مائلة مثل /usr/sbin/sshd إلى مسارات Windows. وهذا جزء من السجل الناتج:

2026-10-26T13:37:04.477770056Z Failed password for root from 10.251.15.21 port 38060 ssh2
2026-10-26T13:37:04.542796490Z Connection closed by authenticating user root 10.251.15.21 port 38060 [preauth]
2026-10-26T13:37:12.231254525Z Invalid user admin from 10.251.15.21 port 34174
2026-10-26T13:37:15.007568576Z Failed password for invalid user admin from 10.251.15.21 port 34174 ssh2
2026-10-26T13:37:16.565237446Z Connection closed by invalid user admin 10.251.15.21 port 34174 [preauth]
2026-10-26T13:37:35.161659147Z Failed password for deploy from 10.251.15.21 port 53750 ssh2
2026-10-26T13:37:36.404993737Z Connection closed by authenticating user deploy 10.251.15.21 port 53750 [preauth]
2026-10-26T13:37:37.536109625Z Accepted password for deploy from 10.251.15.21 port 53766 ssh2
2026-10-26T13:37:37.549698205Z Received disconnect from 10.251.15.21 port 53766:11: disconnected by user
2026-10-26T13:37:40.240668300Z Failed password for mona from 10.251.15.22 port 45146 ssh2
2026-10-26T13:37:41.757584860Z Accepted password for mona from 10.251.15.22 port 45298 ssh2

في المخرج أعلاه لاحظ التالي، وهو بالضبط ما نريد أن يلاحظه المتقدم:

• المستخدم الموجود مثل root يظهر له سطر Failed password for root، أما الاسم غير الموجود مثل admin فيظهر له سطران: Invalid user admin ثم Failed password for invalid user admin. ومن يعد كل سطر فيه كلمة فشل أو اسم غير صحيح سيعد المحاولة الواحدة مرتين، وهذا هو الفخ في السؤال الأول.
• بعد تسع محاولات فاشلة من نفس العنوان جاء Accepted password for deploy من نفس العنوان بعد ثانيتين فقط من آخر فشل، وهذا هو التسلسل الذي يجعل الحادثة حادثة: تخمين ثم دخول ناجح.
• العنوان الثاني فشل مرة واحدة ثم نجح بعد ثانية ونصف، وهذا شكل موظف أخطأ في الكتابة، والسؤال السادس يسأل عنه تحديداً حتى نعرف هل يفرق المتقدم بين الاثنين، أم يحظر كل من فشل مرة.

نسخة مختلفة لكل متقدم

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

"""Builds one screening task per applicant from the real lab log.
   python make_task.py <applicant-id>  ->  out/<id>/auth.log (to send) and out/<id>/key.json (kept by the department)
   Each applicant gets different addresses, a different compromised account name and a shifted clock,
   so answers cannot be copied between applicants."""
import hashlib, json, random, re, sys
from datetime import datetime, timedelta
from pathlib import Path

app_id = sys.argv[1]
rnd = random.Random(hashlib.sha256(app_id.encode()).digest())   # same id -> same task, every time
src = Path("auth.log").read_text().splitlines()

net = f"10.{rnd.randint(20, 250)}.{rnd.randint(0, 255)}"
ip_map = {"10.251.15.21": f"{net}.{rnd.randint(30, 99)}", "10.251.15.22": f"{net}.{rnd.randint(100, 199)}"}
victim = rnd.choice(["deploy", "backup", "webadmin", "jenkins", "svc-app"])
guesses = dict(zip(["admin", "test", "oracle"], rnd.sample(["admin", "test", "oracle", "ubuntu", "pi", "git", "ftpuser", "postgres"], 3)))
shift = timedelta(days=rnd.randint(-40, -5), minutes=rnd.randint(0, 600))

out = []
for line in src:
    ts, msg = line.split(" ", 1)
    t = datetime.fromisoformat(ts[:26]) + shift                  # keep microseconds, drop the extra digits
    for a, b in ip_map.items():
        msg = msg.replace(a, b)
    msg = re.sub(r"\bdeploy\b", victim, msg)
    msg = re.sub(r"user (admin|test|oracle)\b", lambda m: "user " + guesses[m.group(1)], msg)
    out.append(f"{t.isoformat()}Z {msg}")

text = "\n".join(out) + "\n"
failed = [l for l in out if "Failed password" in l]
ok = [l for l in out if "Accepted password" in l and victim in l][0]
answers = {
    "q1_failed_total": str(len(failed)),
    "q2_source_ip": ip_map["10.251.15.21"],
    "q3_account": victim,
    "q4_login_time": ok.split(".")[0] + "Z",
    "q5_invalid_users": ",".join(sorted(set(re.findall(r"Invalid user (\S+)", text)))),
    "q6_second_ip_verdict": "benign",
}
d = Path("out") / app_id
d.mkdir(parents=True, exist_ok=True)
(d / "auth.log").write_text(text)
(d / "key.json").write_text(json.dumps(answers, indent=1))
print(app_id, ip_map["10.251.15.21"], victim, answers["q4_login_time"])

في الكود أعلاه لاحظ التالي:

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

نصنع مهمتين لمتقدمين، ونقرأ المفتاحين:

MSYS_NO_PATHCONV=1 docker run --rm -v "$(pwd -W):/w" -w /w python:3.13.17-slim sh -c '
  python make_task.py A-0417; python make_task.py A-0418
  cat out/A-0417/key.json; cat out/A-0418/key.json'

والمخرج سوف يكون كما يلي:

A-0417 10.57.11.87 backup 2026-10-09T23:29:37Z
A-0418 10.168.193.67 backup 2026-10-04T19:24:37Z
{
 "q1_failed_total": "10",
 "q2_source_ip": "10.57.11.87",
 "q3_account": "backup",
 "q4_login_time": "2026-10-09T23:29:37Z",
 "q5_invalid_users": "git,pi,postgres",
 "q6_second_ip_verdict": "benign"
}
{
 "q1_failed_total": "10",
 "q2_source_ip": "10.168.193.67",
 "q3_account": "backup",
 "q4_login_time": "2026-10-04T19:24:37Z",
 "q5_invalid_users": "admin,git,oracle",
 "q6_second_ip_verdict": "benign"
}

لاحظ أن المتقدمين حصلا على عنوانين مختلفين ووقتين مختلفين وأسماء مخمنة مختلفة، لكن الحساب المخترق جاء backup في الاثنين بالصدفة، لأنه واحد من خمسة أسماء فقط، وسوف نرى أثر ذلك في التصحيح. وأما عدد المحاولات الفاشلة فهو 10 للجميع، لأن القصة نفسها لم تتغير، وهذا مقصود: المهمة تقيس طريقة القراءة، ولا نريد أن تختلف صعوبتها من متقدم لآخر. وفي نسخة أولى من السكربت كنا نغير العناوين والحساب فقط، فبقيت أسماء المستخدمين المخمنة admin,oracle,test في كل النسخ، أي أن إجابة السؤال الخامس كانت واحدة للجميع ويمكن تداولها، فأضفنا السطر الذي يختار ثلاثة أسماء من ثمانية لكل متقدم.

التصحيح الآلي check.py

السكربت check.py يقرأ المفتاح وورقة الإجابة، ويوحد الكتابة قبل المقارنة، أي يحول إلى حروف صغيرة ويحذف المسافات، حتى لا يخسر المتقدم درجة لأنه كتب git, pi, postgres بمسافات:

"""Grades the automatic part of a screening answer sheet.
   python check.py out/<id>/key.json answers/<id>.txt   (answer lines: q1_failed_total=10 ...)"""
import json, sys

key = json.load(open(sys.argv[1]))
given = {}
for line in open(sys.argv[2], encoding="utf-8"):
    if "=" in line:
        k, v = line.split("=", 1)
        given[k.strip()] = v.strip().lower().replace(" ", "")
score = 0
for q, right in key.items():
    ok = given.get(q, "") == right.lower().replace(" ", "")
    score += ok
    print(f"{q:22} {'PASS' if ok else 'FAIL'}   given={given.get(q, '-')}")
print(f"score {score}/{len(key)}  (q7, the written explanation, is read by a person)")

ولدينا ثلاث أوراق: المتقدم A-0417 حل مهمته بنفسه، والمتقدم A-0418 صديقه وأخذ إجاباته كما هي، والمتقدم A-0419 حل مهمته بنفسه ولكنه وقع في فخين. وهذه ورقة الثالث:

q1_failed_total=14
q2_source_ip=10.193.92.64
q3_account=deploy
q4_login_time=2026-09-17T18:11:37Z
q5_invalid_users=pi,postgres,ubuntu
q6_second_ip_verdict=suspicious
q7=The first address guessed passwords and then entered as deploy. The second address also failed, so I would block it as well.

نصحح الأوراق الثلاث:

MSYS_NO_PATHCONV=1 docker run --rm -v "$(pwd -W):/w" -w /w python:3.13.17-slim sh -c '
  for a in A-0417 A-0418 A-0419; do echo "== $a"; python check.py out/$a/key.json answers/$a.txt; done'

والمخرج سوف يكون كما يلي:

== A-0417
q1_failed_total        PASS   given=10
q2_source_ip           PASS   given=10.57.11.87
q3_account             PASS   given=backup
q4_login_time          PASS   given=2026-10-09t23:29:37z
q5_invalid_users       PASS   given=git,pi,postgres
q6_second_ip_verdict   PASS   given=benign
score 6/6  (q7, the written explanation, is read by a person)
== A-0418
q1_failed_total        PASS   given=10
q2_source_ip           FAIL   given=10.57.11.87
q3_account             PASS   given=backup
q4_login_time          FAIL   given=2026-10-09t23:29:37z
q5_invalid_users       FAIL   given=git,pi,postgres
q6_second_ip_verdict   PASS   given=benign
score 3/6  (q7, the written explanation, is read by a person)
== A-0419
q1_failed_total        FAIL   given=14
q2_source_ip           PASS   given=10.193.92.64
q3_account             PASS   given=deploy
q4_login_time          PASS   given=2026-09-17t18:11:37z
q5_invalid_users       PASS   given=pi,postgres,ubuntu
q6_second_ip_verdict   FAIL   given=suspicious
score 4/6  (q7, the written explanation, is read by a person)

في المخرج أعلاه لاحظ التالي:

• المتقدم الأول حصل على ست من ست، وفقرته المكتوبة تقول ما حدث وما سيفعله، فهو في أعلى الطابور لقراءة الإنسان.
• المتقدم الثاني نسخ الإجابات، فسقط في العنوان والوقت والأسماء المخمنة لأنها تخص مهمة صديقه، ونجح في الأسئلة التي إجابتها واحدة للجميع، مثل عدد المحاولات وحكم العنوان الثاني، ونجح في الحساب المخترق بالصدفة لأن المهمتين حصلتا على backup. وثلاث من ست بهذا النمط بالذات، أي خطأ في كل ما يخص مهمته وصواب فيما يشترك فيه الجميع، علامة يراها من يقرأ التقرير، ويؤكدها سؤال واحد في المكالمة: «من أين جاء هذا العنوان في سجلك؟».
• المتقدم الثالث كتب 14 في السؤال الأول، وهو عدد الأسطر التي فيها Failed password أو Invalid user معاً، أي أنه عد المحاولة على الاسم غير الموجود مرتين. ووقع في الفخ الثاني فحكم على الموظفة التي أخطأت مرة بأنها مشبوهة، وهذا خطأ مفهوم من مبتدئ، ويصلح في الأسبوع الرابع، ولكنه يقول للمشرف ما يجب أن يركز عليه معه.

ونتحقق من سبب الرقم 14 بأنفسنا من سجل المتقدم الثالث:

grep -c "Failed password" out/A-0419/auth.log
grep -cE "Failed password|Invalid user" out/A-0419/auth.log

والمخرج سوف يكون كما يلي:

10
14

ماذا يحدث مع مئة متقدم؟

السؤال الذي يهم قسماً يستقبل طلبات كثيرة: هل يتحمل هذا الأسلوب مئة متقدم، وهل تبقى النسخ مختلفة فعلاً؟ لذلك صنعنا مئة مهمة دفعة واحدة، ثم عددنا كم قيمة مختلفة ظهرت لكل سؤال:

MSYS_NO_PATHCONV=1 docker run --rm -v "$(pwd -W):/w" -w /w python:3.13.17-slim bash -c '
  time (for i in $(seq 1000 1099); do python make_task.py A-$i >/dev/null; done)
  cat out/A-1*/key.json | grep q3 | sort | uniq -c
  cat out/A-1*/key.json | grep q2 | sort -u | wc -l
  cat out/A-1*/key.json | grep q5 | sort -u | wc -l'

والمخرج سوف يكون كما يلي:

real	0m8.034s
user	0m4.288s
sys	0m1.354s
     13  "q3_account": "backup",
     18  "q3_account": "deploy",
     25  "q3_account": "jenkins",
     22  "q3_account": "svc-app",
     22  "q3_account": "webadmin",
100
46

في المخرج أعلاه لاحظ التالي:

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

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

دليلعشرات طلبات التدريب كل يوم: كيف تدير برنامجاً كبيراً بوقت قليل؟برنامج تدريب يستقبل عشرات الطلبات يومياً بوقت مدير قليل: فرز آلي، ودفعات، وقادة أقران، وتمارين ذاتية التصحيح على CTFd.

حذف التجربة Cleanup

بعد الانتهاء احذف السيرفر والشبكة والـ Docker Image التي بنيناها، والمهام المولدة:

docker rm -f sci-intern-target 2>/dev/null
docker network rm sci-intern-net 2>/dev/null
docker image rm sci-intern-lab:1
rm -rf out/A-1*

أخطاء شائعة

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

قائمة تحقق قبل أن تفتح باب التقديم

الخلاصة

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

وهذه المقالات الأقرب إلى هذا الموضوع، ومنها تبدأ المرحلة التالية في المسار:

دليلأدوار الأمن السيبراني Careers: ماذا يعمل كل دور، ومن أين تبدأ؟تسعة أدوار في الأمن السيبراني من المراجع الرسمية: اليوم العادي والمهارات والأدوات، ومن أي مستوى يبدأ كل دور.دليلعشرات طلبات التدريب كل يوم: كيف تدير برنامجاً كبيراً بوقت قليل؟برنامج تدريب يستقبل عشرات الطلبات يومياً بوقت مدير قليل: فرز آلي، ودفعات، وقادة أقران، وتمارين ذاتية التصحيح على CTFd.دليلتخطيط برنامج التدريب Internship في 12 أسبوعاًكيف تحدد أهداف برنامج التدريب وميزانيته وتختار المشرفين والمشروع، مع خطة اثني عشر أسبوعاً وقوالب جاهزة للنسخ.دليليوم محلل SOC: فرز التنبيهات Alert Triage من التنبيه إلى القرارستة عشر تنبيهاً حقيقياً من Wazuh وSuricata نفرزها واحداً واحداً بالإثراء من Zeek حتى القرار والتصعيد.دليلخطة الاستجابة للحوادث Incident Response وكتيبات التشغيل Playbooksخطة استجابة وكتيبا حساب مخترق وفدية على NIST SP 800-61r3، مع مختبر نستعيد فيه البيانات من نسخة restic.دليلنظام تتبع المتقدمين ATS: من إعلان الوظيفة إلى العرضكيف تكتب إعلاناً واضحاً وتفرز المتقدمين بعدل وتقيس مسار التوظيف، وكيف تتعامل مع بياناتهم وفق نظام حماية البيانات الشخصية.

سجل التحديثات

• أكتوبر 2026: كتابة المقال، وتنفيذ تجربة مهمة الفرز على Docker Engine 29.8.0 مع Debian 13 (debian:trixie-20261005-slim) وOpenSSH 10.0p2 من مستودعات Debian وPython 3.13.17.