كيف تبني منصة محاكاة الهجمات والتحقق من التعرض AEV؟

تشتري أغلب المؤسسات أدوات الحماية ثم تفترض أنها تعمل، فجدار الحماية مركب، وبرنامج الحماية على الأجهزة EDR منصب، وتصل السجلات إلى ال SIEM، ويبقى سؤال واحد بلا جواب حتى لحظة الهجوم الحقيقي: هل تكشف هذه الضوابط مجتمعة هجوماً فعلياً، أم أن فيها ثغرة لا يعرفها أحد؟ وقد كان الجواب التقليدي هو اختبار الاختراق المصرح به مرة في السنة، لكن مرة في السنة لا تكفي لبيئة تتغير كل أسبوع، ومن هنا ظهرت فئة من الأدوات تحاكي خطوات المهاجم بشكل آمن ومستمر لتثبت أي الضوابط يعمل وأيها لا، وهي ما تسميه Gartner اليوم محاكاة الهجمات والتحقق من التعرض Adversarial Exposure Validation واختصاراً AEV، وسوف نرى في هذا المقال كيف تعمل هذه المنصات من الداخل، وكيف يمكن بناء واحدة، ونشغل منها نموذجاً مفتوح المصدر على جهازك بسيناريو غير ضار.

وهذا المقال من المرحلة المتقدمة كيف تبني منتجات الأمن السيبراني في خارطة الطريق، وهو يبني على مقالين سابقين: مقارنة حلول الأمن التجارية ببدائلها المفتوحة التي تذكر أين توفر فعلاً، ومقال نمذجة التهديدات الذي شرح إطار MITRE ATT&CK ونظرة المهاجم خطوة خطوة، فلن نكرر شرح ATT&CK هنا:

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

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

• ما الذي تعنيه Gartner بمصطلح AEV، وكيف يختلف عن الفحص Scanning وعن اختبار الاختراق السنوي.
• مكونات المنصة من الداخل: مكتبة السيناريوهات المرتبطة ب ATT&CK، وال Executors وال Agents، والتنفيذ الآمن، وال Collectors التي تقيس النتيجة ضد الضوابط.
• البدائل مفتوحة المصدر: OpenAEV من Filigran (الاسم الجديد ل OpenBAS)، وApache Caldera، وAtomic Red Team، ورخصة كل منها.
• تجربة عملية: تشغيل Caldera على جهازك، ونشر Agent على حاوية هدف، وتشغيل سيناريو استطلاع غير ضار ومشاهدة النتائج الحقيقية.
• الجانب الهندسي والتجاري لبناء منتج كهذا: ما الصعب فيه، وقسم عن بنائه في منطقتنا، ومتى تشتري ومتى تبني.

ما هو AEV، ولماذا ظهر؟

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

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

وقد يتساءل البعض: أليس هذا هو ما كان يسمى محاكاة الاختراق والهجوم Breach and Attack Simulation واختصاراً BAS؟ والإجابة أن BAS هو الجيل الأول من هذه الأدوات، وقد وضعت Gartner في دليل السوق الأول Market Guide for Adversarial Exposure Validation الصادر في 11 مارس 2025 مصطلح AEV ليجمع تحته BAS واختبار الاختراق الآلي Automated Penetration Testing والفريق الأحمر المستمر في فئة واحدة، وتعرف الفئة بأنها التقنيات التي تقدم دليلاً متسقاً ومستمراً وآلياً على إمكانية نجاح الهجوم. وهذه الفئة بدورها جزء من إطار أوسع تسميه Gartner الإدارة المستمرة للتعرض للتهديدات Continuous Threat Exposure Management واختصاراً CTEM، فالفحص يكتشف، وAEV يتحقق Validation، وهي المرحلة التي كانت الحلقة الناقصة.

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

مكونات المنصة من الداخل

لو فتحت أي منصة AEV جادة لوجدت خمسة أجزاء تتكرر بأسماء مختلفة، والصورة التالية تبين كيف ترتبط:

وفيما يلي كل جزء بالتفصيل:

• مكتبة السيناريوهات Scenario Library: مجموعة من الهجمات الصغيرة، كل واحدة ترتبط بتقنية في إطار MITRE ATT&CK، مثل التقنية T1003 لسرقة بيانات الاعتماد أو T1059 لتنفيذ الأوامر. والربط ب ATT&CK مهم لأنه يعطيك لغة مشتركة: بدل أن تقول «اختبرنا هجوماً ما بشكل عام»، تقول «اختبرنا هذه التقنية بالذات وكشفها ضابطنا». ومكتبة جيدة تغطي سلسلة كاملة: دخول أولي، ثم ترسيخ، ثم استطلاع، ثم حركة جانبية، ثم سحب بيانات.
• المنصة Platform: العقل الذي يجدول السيناريوهات، ويقرر ما يشغله ومتى وعلى أي أجهزة، ويجمع النتائج في تقارير. وهذا هو الجزء الذي تنظر إليه كل يوم.
• المنفذون والوكلاء Executors and Agents: المنفذ هو الآلية التي تشغل الهجوم على الهدف، والوكيل Agent برنامج صغير يثبت على الجهاز ويطلب من المنصة تعليماته وينفذها ويعيد النتيجة. ومن أهم قرارات التصميم أن يبقى الوكيل محايداً: ينفذ أوامر محاكاة لا برمجيات ضارة حقيقية، حتى لا يصطدم ببرنامج الحماية نفسه الذي يختبره.
• الضوابط تحت الاختبار Controls under Test: هي دفاعاتك الحقيقية: EDR على الأجهزة، وSIEM الذي يجمع السجلات، وجدار الحماية، وبوابة البريد. المنصة لا تلمسها، وإنما تشغل الهجوم ثم تنظر ماذا فعلت.
• الجامعون والتوقعات Collectors and Expectations: بعد كل خطوة، يتصل الجامع Collector ب EDR أو SIEM ويسأله: هل رأيت هذا الحدث؟ هل منعته؟ ثم تقارن المنصة الواقع بالتوقع Expectation الذي حددته مسبقاً، فإن كان المتوقع «يجب أن يكشف EDR هذه الخطوة» ولم يكشفها، فهذه ثغرة في التغطية ظهرت بدليل لا بظن.

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

التنفيذ الآمن: محاكاة لا برمجية ضارة

وهنا المبدأ الذي يفرق منصة احترافية عن سكربت خطير: الاختبار الذري Atomic Testing. بدل أن تطلق برمجية فدية حقيقية لترى هل يكشفها EDR، تشغل الأمر الواحد الذي تبدأ به برمجية الفدية فعلاً، مثل أمر يعدد الملفات أو يحاول حذف النسخ الاحتياطية الظلية، دون أن يشفر ملفاً واحداً. فأنت تحاكي السلوك المرصود في ATT&CK بأقل أثر ممكن، وتنظف بعده. وهذا يعني أن قاعدة الذهب في أي منصة AEV هي: لا برمجيات ضارة حقيقية على بيئة الإنتاج أبداً، وكل خطوة لها أمر تنظيف يعيد الجهاز كما كان. والسبب أن الهدف إثبات التغطية لا إحداث ضرر، فإن أضررت بالإنتاج وأنت تختبر الدفاع فقد صرت أنت الحادثة.

البدائل مفتوحة المصدر

هذه الفئة ليست حكراً على المنتجات التجارية مثل Picus وCymulate وSafeBreach وAttackIQ وPentera، فهناك ثلاث أدوات مفتوحة تغطي أجزاء مختلفة منها:

• OpenAEV من Filigran: وهو الاسم الجديد لمشروع OpenBAS، وقد أعلنت Filigran عن التسمية الجديدة في 29 أكتوبر 2025، وتوثق صفحة إعادة التسمية أن الاسم حذف رسمياً في الإصدار OpenAEV 2.0.0. والنسخة المجتمعية Community Edition برخصة Apache-2.0 كما في ملف الرخصة، مع نسخة مؤسسية Enterprise Edition ببعض المزايا تحت رخصة خاصة. وبنيته هي الأجزاء الخمسة نفسها: المنصة، والمنفذون Executors ومنهم Agent خاص مكتوب بلغة Rust يبقى محايداً تجاه برامج الحماية وأيضاً دعم Agent من Caldera، والحاقنون Injectors، والجامعون Collectors الذين يتصلون ب SIEM وXDR وEDR، والتوقعات Expectations على مستويات المنع والكشف والثغرة والاستجابة البشرية. وهو من عائلة منتجات Filigran نفسها التي منها OpenCTI لاستخبارات التهديدات.
• Apache Caldera: منصة محاكاة خصم من MITRE، وقد انتقلت إلى مؤسسة Apache فصارت تسمى Apache Caldera وهي قيد الحضانة Incubating، ورخصتها Apache-2.0 كما في مستودعها، وآخر إصدار 5.3.0. وتتكون من خادم قيادة وتحكم Command and Control واختصاراً C2 فيه REST API وواجهة ويب، ووكيل افتراضي اسمه Sandcat، وقدرات Abilities كل واحدة تنفذ تقنية ATT&CK، وملفات خصم Adversary Profiles تجمع عدة قدرات، وعمليات Operations تشغل الملف على مجموعة وكلاء، وإضافات منها stockpile لمخزون التقنيات وatomic الذي يجلب تقنيات Atomic Red Team. وهذه هي الأداة التي سنشغلها في التجربة لأنها أخف من OpenAEV الذي يحتاج PostgreSQL وElasticsearch وRabbitMQ وتخزين S3 وذاكرة كبيرة.
• Atomic Red Team من Red Canary: ليست منصة وإنما مكتبة اختبارات ذرية برخصة MIT، كل اختبار أمر صغير مرتبط بتقنية ATT&CK وله أمر تنظيف، وتضم اليوم قرابة 1878 اختباراً تغطي 344 تقنية وتقنية فرعية. وتستطيع تشغيلها يدوياً أو عبر وحدة PowerShell باسم Invoke-AtomicRedTeam، وهي المرجع الذي تبني فوقه كثير من المنصات مكتبة سيناريوهاتها.

ولاحظ التمييز المهم: Caldera وOpenAEV منصتان كاملتان بجدولة وتقارير، أما Atomic Red Team فمكتبة محتوى تحتاج أن تشغلها بنفسك، ولذلك كثير من الفرق تبدأ ب Atomic Red Team لتتعلم، ثم تنتقل إلى منصة عندما تريد الجدولة والقياس المستمر.

تجربة عملية: Caldera على جهازك بسيناريو غير ضار

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

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

docker network create lab-sec-net
docker network create --internal lab-sec-int

docker run -d --name lab-sec-caldera --network lab-sec-net \
  -p 127.0.0.1:18888:8888 --memory 2g ghcr.io/mitre/caldera:5.2.0
docker network connect lab-sec-int lab-sec-caldera

وعند أول تشغيل ينشئ Caldera مفاتيح وكلمات مرور عشوائية ويكتبها في ملف إعداده، والمخرج سوف يبين كلمة مرور المستخدم red ومفتاح الواجهة البرمجية api_key_red، نقرؤهما كما يلي:

docker exec lab-sec-caldera sh -c "grep -E 'api_key_red|red:' conf/local.yml"

والمخرج سوف يكون كما يلي، وهذه القيم من تشغيلنا نحن وتختلف عندك في كل مرة:

api_key_red: a2QK8-ru7AWM-CWyJIkClPV4pjqXlqU8AKVgpjFNDHw
  red:
    red: ZtBdWbYBDL2dcPnaHOY6SVxsrXCIX2gDNrhxUExIO3I

الآن نشغل حاوية هدف بسيطة على الشبكة الداخلية، وننزل عليها وكيل Sandcat من الخادم ونشغله ليتصل ويطلب تعليماته:

docker run -d --name lab-sec-target --network lab-sec-int --memory 256m \
  debian:13.4-slim sleep infinity

docker exec lab-sec-target sh -c '
  apt-get update -q && apt-get install -y -q curl procps
  curl -s -X POST -H "file:sandcat.go" -H "platform:linux" \
    http://lab-sec-caldera:8888/file/download -o agent
  chmod +x agent
  nohup ./agent -server http://lab-sec-caldera:8888 -group red -v > agent.log 2>&1 &'

وعند تشغيل الوكيل سوف تجد في سجله أنه اتصل وبدأ يطلب التعليمات كما يلي:

beacon channel=HTTP
[+] Beacon (HTTP): ALIVE
[*] Running instruction ...

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

KEY=a2QK8-ru7AWM-CWyJIkClPV4pjqXlqU8AKVgpjFNDHw
curl -s -H "KEY: $KEY" http://127.0.0.1:18888/api/v2/agents

والمخرج يبين وكيلاً واحداً سجل نفسه على الحاوية الهدف باسم المستخدم app ضمن المجموعة red:

paw=hiqwus  host=cf1e85bdc099  platform=linux  username=app  group=red

الآن نصنع ملف خصم Adversary Profile من أربع قدرات استطلاع غير ضارة فقط: التعرف على المستخدم الحالي، وعرض العمليات، وتعداد المستخدمين المحليين، وعرض الملفات، وكل واحدة مرتبطة بتقنية ATT&CK، ثم نشغل عملية عليه:

KEY=a2QK8-ru7AWM-CWyJIkClPV4pjqXlqU8AKVgpjFNDHw
U=http://127.0.0.1:18888/api/v2

# ملف خصم من 4 قدرات استطلاع غير ضارة
curl -s -H "KEY: $KEY" -H 'Content-Type: application/json' -X POST $U/adversaries \
  -d '{"name":"ArabRoot Harmless Discovery","atomic_ordering":[
    "c0da588f-79f0-4263-8998-7496b1a40596",
    "5a39d7ed-45c9-4a79-b581-e5fb99e24f65",
    "c1cd6388-3ced-48c7-a511-0434c6ba8f48",
    "52177cc1-b9ab-4411-ac21-2eadc4b5d3b8"]}'

# تشغيل العملية على المجموعة red
curl -s -H "KEY: $KEY" -H 'Content-Type: application/json' -X POST $U/operations \
  -d '{"name":"arabroot-discovery","adversary":{"adversary_id":"<ID>"},
       "group":"red","state":"running"}'

وبعد ثوان نجلب تقرير العملية ونرى نتيجة كل خطوة الحقيقية، وهي الأمر المحاكى ثم مخرجه ثم رمز الخروج exit_code، كما يلي:

### T1033 Identify active user   ->  whoami
stdout: app                      exit_code: 0

### T1057 System processes       ->  ps aux
stdout: USER PID ... sleep infinity / ./agent -server ...   exit_code: 0

### T1087.001 Find local users    ->  cut -d: -f1 /etc/passwd | grep -v '_'
stdout: root daemon bin sys ... nobody app   exit_code: 0

### T1083 List Directory         ->  ls
stdout: agent  agent.log         exit_code: 0

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

• كل خطوة نفذها الوكيل على الهدف وأعادت مخرجاً حقيقياً برمز خروج 0، وهذا هو جوهر عمل المنصة: أمر محاكى ينفذ ونتيجة ترجع.
• كل خطوة موسومة برقم تقنية ATT&CK، فالاستطلاع هنا هو التكتيك Discovery، وهذا الوسم هو ما يتيح لاحقاً مطابقة ما نفذناه بما كشفه EDR.
• لا شيء من هذه الأوامر يضر الهدف، فهي أوامر قراءة فقط، وهذا هو المقصود بالتنفيذ الآمن.

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

docker rm -f lab-sec-target lab-sec-caldera
docker network rm lab-sec-int lab-sec-net

بناء منتج كهذا: أين الصعوبة الحقيقية؟

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

• جودة الكشف Detection Quality: منتجك لا قيمة له إن لم يقرأ نتيجة الضوابط بدقة، وهذا يعني كتابة Collectors لكل EDR وSIEM في السوق، وكل واحد له واجهة برمجية مختلفة وصيغة أحداث مختلفة، وهذا هو أصعب جزء وأكثره عملاً مستمراً.
• الإنذارات الكاذبة False Positives: إن قالت منصتك «هذا الهجوم لم يكشف» وكان في الحقيقة مكشوفاً لكن Collector لم يقرأ التنبيه، فقد أفقدت العميل ثقته. والعكس أسوأ: أن تقول «محمي» وهو ليس كذلك.
• التوسع Scale: تشغيل سيناريو على جهاز واحد سهل، أما على عشرة آلاف جهاز بجدولة لا تثقل الشبكة ولا تطلق آلاف التنبيهات دفعة واحدة، فهذه مسألة تصميم أنظمة، وقد شرحنا مبادئها في مدخل إلى تصميم الأنظمة.
• التحديثات Updates: المهاجمون لا يقفون، وكل تقنية جديدة في ATT&CK تحتاج سيناريو جديداً مختبراً، فمنتجك يحتاج فريق محتوى يلاحق التهديدات باستمرار، تماماً كما يحتاج مضاد الفيروسات تحديث توقيعاته.
• الثقة Trust: أنت تطلب من العميل أن يشغل برنامجاً ينفذ أوامر تحاكي هجوماً على أجهزة الإنتاج، وهذا يتطلب أن يكون الوكيل مفتوحاً للتدقيق، وأن يكون كل أمر محاكاة موثقاً، وأن يكون التنظيف مضموناً، وأن يكون الوكيل محايداً لا يصطدم ببرامج الحماية. وبلا هذه الثقة لن يثبت أحد منتجك على أجهزته.

إذا أردت بناء واحدة في منطقتنا

بناء منصة AEV كاملة تنافس المنتجات التجارية مشروع كبير يحتاج فريق محتوى تهديدات دائماً، وهو أمر واقعي لكنه ليس نقطة البداية الأنسب لفريق صغير. والمسار العملي أن تبدأ من المحتوى المفتوح الموجود: شغل Caldera أو OpenAEV داخلياً، واستفد من مكتبة Atomic Red Team، ثم ابن فوقهما القيمة التي تحتاجها المؤسسات هنا ولا توفرها الأداة الأجنبية جاهزة، مثل ربط نتائج الاختبار بضوابط الهيئة الوطنية للأمن السيبراني، فقد رأينا في مقال ضوابط NCA ECC أن المكون الفرعي 2-11 يطلب اختبار الاختراق الدوري، والمكون 2-12 يطلب سجلات ومراقبة، وتقرير AEV يصلح دليلاً عملياً على أن هذه الضوابط تعمل فعلاً لا على الورق. وهذا النوع من القيمة المحلية، لا بناء المحرك من الصفر، هو المدخل الواقعي، وهو نفس المنطق الذي ناقشناه في من المختبر إلى المنتج. ونتجنب هنا أي أرقام عن حجم السوق لأنها تحتاج مصدراً موثقاً، والمهم أن المدخل هندسي وواضح.

تشتري أم تبني؟

القاعدة البسيطة: ابن ما يميزك، واشتر أو استخدم المفتوح فيما هو سلعة. ومحرك المحاكاة ومكتبة التقنيات أقرب إلى السلعة، فهي موجودة ومفتوحة وناضجة في Caldera وOpenAEV وAtomic Red Team، ولا معنى لإعادة كتابتها. أما ما يستحق أن تبنيه فهو الطبقة التي فوقها: التقارير بلغة مديرك، والربط بالضوابط التنظيمية عندك، والتكامل مع EDR وSIEM الذي تملكه بالفعل. وإذا كنت مؤسسة تريد النتيجة فقط لا المنتج، فالمقارنة الصحيحة ليست «مفتوح ضد تجاري» وإنما «ماذا يكلفني تشغيل المفتوح بفريق، مقابل اشتراك تجاري يأتي بفريق محتوى جاهز»، وهي نفس الموازنة التي فصلناها في مقارنة حلول الأمن التجارية ببدائلها المفتوحة.

أخطاء شائعة

• تشغيل برمجية ضارة حقيقية على بيئة الإنتاج لاختبار الدفاع، فتصبح أنت الحادثة؛ والصحيح المحاكاة الذرية مع تنظيف مضمون.
• قياس «هل نفذ الأمر» بدل «هل كشف الأمر»؛ فنجاح تنفيذ الخطوة على الهدف لا يعني شيئاً، المهم ماذا فعل الضابط.
• اختبار مرة واحدة ثم الاطمئنان؛ والبيئة تتغير كل أسبوع، فالقيمة في الحلقة المستمرة لا في اللقطة الواحدة.
• نشر منفذ المنصة على كل الواجهات بلا داع؛ وخادم C2 يجب أن يكون محمياً ومحدوداً، فهو نفسه هدف ثمين.
• الاعتماد على تغطية ATT&CK كرقم للتفاخر؛ تغطية 100% من التقنيات لا تعني حماية، إن كانت الاختبارات لا تطابق تهديداتك الحقيقية.

الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

• AEV مصطلح Gartner لفئة تجمع BAS واختبار الاختراق الآلي، وهدفها إثبات أي الهجمات ينجح فعلاً خلف ضوابطك، بشكل آمن ومستمر، بين اختبارات الاختراق السنوية.
• المنصة خمسة أجزاء: مكتبة سيناريوهات مرتبطة ب ATT&CK، ومنصة تجدول، ووكلاء ينفذون محاكاة آمنة، وضوابط تحت الاختبار، وجامعون يقيسون النتيجة على مستويات المنع والكشف والاستجابة.
• البدائل المفتوحة: OpenAEV من Filigran (الاسم الجديد ل OpenBAS برخصة Apache-2.0)، وApache Caldera (Apache-2.0)، وAtomic Red Team (MIT) كمكتبة محتوى.
• شغلنا Caldera فعلاً بوكيل على حاوية معزولة، ونفذنا أربع تقنيات استطلاع غير ضارة ورأينا نتائجها الحقيقية برمز خروج 0 وكلها موسومة بتقنيات ATT&CK.
• الصعوبة الهندسية في جودة الكشف وقراءة الضوابط لا في تنفيذ الأمر، والمدخل الواقعي محلياً هو البناء فوق المفتوح وربطه بضوابط NCA لا كتابة المحرك من الصفر.
• ابن طبقة التقارير والربط التنظيمي والتكامل، واستخدم المفتوح للمحرك والمكتبة.

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

دليلكيف يعمل وكيل EDR؟ من eBPF إلى قواعد الكشفكيف يرى وكيل EDR ما يجري داخل كل جهاز، ولماذا سائق النواة خطر، مع تشغيل Falco يكشف فعلاً مشبوهاً.دليلكيف يعمل محرك كشف SIEM من الداخل؟كيف يجمع SIEM ملايين السجلات ويوحدها ويطبق قواعد الكشف، مع خط أنابيب Vector وLoki وقاعدة Sigma تطلق فعلاً.دليلكيف تبني منصة استخبارات التهديدات؟ STIX وTAXIIكيف تجمع منصات التهديدات المؤشرات وتثريها وتشاركها، مع تجربة تطابق مغذي C2 حقيقياً بمؤشرات STIX.دليلكيف تعمل بوابة أمن البريد وتكشف التصيد؟كيف تفحص بوابة أمن البريد كل رسالة وتكشف التصيد والانتحال، مع تشغيل Rspamd وClamAV على رسائل اختبار.

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

• أكتوبر 2026: كتابة المقال، وتنفيذ التجربة العملية على Docker Engine 29.8.0 مع Caldera 5.2.0، بتشغيل عملية استطلاع من أربع تقنيات ATT&CK على وكيل Sandcat في حاوية معزولة.