معاييرُ اختبار الاختراق في تركيا: دليلٌ مؤسسيٌّ من سبع نقاط

اختبارُ الاختراق هو النظيرُ التقني لبند "تدقيق الأمن السيبراني" في العقد. يَدخل الفريقُ إلى أنظمة العميل كمهاجمٍ مُخوَّل، يُوثِّق المساراتِ التي قد يَسلكها خصمٌ حقيقي، ويُبلّغ عن المشاكل للإصلاح. نَضِجَ سوقُ pentest في تركيا بسرعةٍ خلال السنوات الخمس الماضية؛ لكنّ المعرفةَ العملية حول أيّ معيارٍ إلزاميٌّ لأيّ قطاع، كيف يُختار المُورّدُ الصحيح، وما يجب أن يَحتويه التقريرُ تَبقى مُبعثَرة.

يَستعرض هذا المقالُ دليلَ المؤسسات من سبع نقاط الذي تَحتاجه مؤسسةٌ في تركيا قبل تكليفِ اختبار اختراق. الإطارُ القانوني، المعاييرُ التقنية، اختيارُ المُورّد، وسيرورةُ ما بعد الاختبار في قطعةٍ واحدة. نُشارك النتائجَ العملية لفريق خدمات الأمن السيبراني لدينا من ٤٠+ مشروع pentest على مدى ٣٦ شهرًا الماضية.

١. الإطارُ التنظيمي — مَن يجب، مَن لا يجب

في تركيا، التزامُ إجراء pentest لا يُعرَّف بقانونٍ واحد بل في تَقاطع جهاتٍ تنظيميّةٍ متعدّدة. وضعُ قطاعكم في الفئة الصحيحة يُحدّد النطاقَ والميزانية معًا.

الكياناتُ تحت تنظيم BDDK (البنوك، مؤسساتُ الدفع/النقود الإلكترونية): وفق المادة ٣١ من لائحة نظم المعلومات BDDK + بلاغ التدقيق المستقل، pentest خارجيٌّ واحد على الأقل سنويًّا إلزامي. فريقُ الاختبار يجب أن يَكون من شركة تدقيقٍ مُعتمَدة من BDDK أو على الأقلّ مُتخصّصًا مستقلًّا مُعتمَدًا ISO 27001. التقريرُ يُحفَظ ٣ سنوات ويُقدَّم في تدقيقاتِ BDDK.

الكياناتُ تحت تنظيم EPDK (الطاقة): لائحةُ EPDK لأمن المعلومات ٢٠٢٤ تَتطلّب pentest سنوي + اختبارٌ خاصّ بـ SCADA/OT لشركاتِ توزيع الكهرباء والتوليد والغاز الطبيعي. اختباراتُ SCADA تَتطلّب خبرةً متخصّصة؛ فريقُ pentest IT قياسي لا يَكفي.

الكياناتُ التي تُعالج بياناتٍ شخصيةً ذات فئةٍ خاصّة تحت KVKK (الصحّة، القانون، مُشغّلو الأنظمة البيومترية): عبارةُ المادة ١٢ من KVKK "كلُّ تدبيرٍ تقني ضروري لأمن البيانات" تُفسَّر في آراء مجلس KVKK كـ pentest منتظم. الالتزامُ ليس صريحًا، لكنّ الإجابةَ بـ "لا" على "هل أَجريتم pentest سنويًّا؟" أثناء التدقيق تَرفع ماديًّا مخاطرَ العقوبات الإدارية.

TS 13638 (أمنُ المعلومات — منهجيّةُ اختبار الاختراق): معيارُ معهد المعايير التركي، يُستشهَد به كثيرًا في المناقصات الحكومية. يُعرّف اختباراتِ اختراقٍ من المستوى A/B/C — A الأكثرُ شمولًا (١٠+ أيّام مهندس)، C الأخفّ (١-٣ أيّام). إذا تَنافستم على مناقصات القطاع العام، يجب أن تَعرفوا هذه المستويات.

الكياناتُ خارج القطاعات المنظَّمة: لا التزام لكنّ ضغطٌ حقيقي. بوليصاتُ التأمين السيبراني تَتطلّب pentest سنويًّا، عملاءُ المؤسسات الكبيرة يَسألون "تاريخ آخر pentest" في استبيانات المُورّدين، وأَصبحت Due Diligence للمستثمرين معياريّةً.

٢. اختيارُ المعيار — PTES، OWASP، NIST: أيّها؟

ثلاثةُ معاييرَ أساسية لـ pentest موجودة؛ تَسميةُ الإطار الصحيح في طلب العروض أو عقد المُورّد هي الخطوةُ الأولى التي تُغلق النطاقَ بوضوح.

PTES (Penetration Testing Execution Standard): منهجيّةُ pentest عامّة محايدة قطاعيًّا. سبعُ مراحل: pre-engagement، intelligence gathering، threat modeling، vulnerability analysis، exploitation، post-exploitation، reporting. مناسبةٌ لاختبارات الشبكة والتطبيقات معًا. معظمُ شركات pentest التركية تَستخدم PTES افتراضيًّا.

OWASP (Open Web Application Security Project): مُركَّزٌ على تطبيقات الويب. OWASP Top 10 (الفئاتُ العشر الأكثر شيوعًا من ثغرات الويب) + OWASP Testing Guide (٣٠٠+ سيناريو اختبار) + OWASP ASVS (Application Security Verification Standard، ١٤ قسم × المستوى ١/٢/٣). أعمقُ من PTES لاختبارات الويب/API.

NIST SP 800-115 (Technical Guide to Information Security Testing): معيارٌ فدرالي أمريكي؛ أكثرُ ملاءمةً للشبكات الكبيرة والبنية المؤسسية. مطلوبٌ أقلّ في تركيا لكنّه مفيدٌ للمؤسسات ذات قاعدةِ عملاءٍ دولية.

التركيبُ العملي: توصيتُنا للعملاء المؤسسيين هي إطار PTES + اختبارات محتوى OWASP. أجزاءُ الويب/API تَجري وفق OWASP ASVS Level 2، أجزاءُ الشبكة/البنية وفق PTES. هذا النهجُ يُوفّر العمقَ والاتساع معًا.

المعيارُ المُستخدَم يجب أن يَكون مكتوبًا في العقد. "ستُطبَّق أفضلُ الممارسات" غيرُ كافٍ — في التدقيق، السؤالُ "مَن عَرَّف أفضلَ الممارسات؟" صعبُ الجواب.

٣. الأسود مقابل الرمادي مقابل الأبيض — متى أيّ منها

الأنواعُ الثلاثة تَخدم أغراضًا مختلفة؛ اختيارُ الصحيح يَقود إلى النتيجة الصحيحة.

الصندوق الأسود: لا تُعطى للفريق معلوماتٌ مسبقة. فقط قائمةُ URLs/IPs الهدف. محاكاةُ مهاجمٍ خارجي — واقعيٌّ لكنّه سطحي. يَكتمل الاستطلاعُ في ٢-٣ أيّام مهندس؛ معظمُ الاكتشافات تأتي من مرحلة الاكتشاف، بينما تُتجاوز العيوبُ المعماريّةُ العميقة.

الصندوق الرمادي: تُمنَح صلاحياتُ مستخدمٍ قياسي، يُقدَّم ملخّصُ المعماريّة، لكن لا وصولَ للكود. الخيارُ B2B الأكثر شيوعًا. نموذجُ تهديدٍ داخليّ+خارجيّ مدمج — يَختبر ما يمكن لمهاجمٍ حقيقي فعلُه باعتمادات مستخدمٍ مُسرَّبة. ٥-١٠ أيّام مهندس.

الصندوق الأبيض: يُقدَّم الكودُ المصدري + مخطّطُ المعماريّة + حسابُ admin. مراجعةٌ متعمّقة — يَجد ٣-٥× أكثر من المشاكل من الصندوق الأسود. ١٠-٢٠ يوم مهندس. الأكثرُ ملاءمةً لتحضير تدقيق KVKK، أوّل pentest للبنية الحرجة، due diligence تقنية M&A.

قاعدةُ الاختيار العملية:

خدمتنا لمحاكاة Red Team تَختلف عن pentest الكلاسيكي بتَوجّهها نحو هدفٍ محدّد (مثلًا تَسريبُ بيانات العملاء)؛ تَستخدم كلَّ مسارٍ بما فيه الهندسةُ الاجتماعية. pentest الكلاسيكي يَجد المشاكل؛ Red Team يَختبر قدرتكم الدفاعية. كلاهما يَخدم غرضًا مختلفًا، لا يَحلّ أحدهما محلَّ الآخر.

٤. تعريفُ النطاق — مرحلةُ pre-engagement

الجزءُ الأكثر مناقشةً في مشروع pentest هو تعريفُ النطاق. نطاقٌ غيرُ كافٍ → تَبقى المشاكلُ الحرجة غيرَ مرئيّة لأنّها خارج النطاق؛ نطاقٌ مُفرِط → يَتمدّد الاختبار، تَنفجر الأسعار.

أدنى مستندٍ لتعريف النطاق يجب أن يَحتوي ستّةَ أقسام:

١. الأصولُ المختبَرة: قائمةُ URLs/IPs، نقاطُ نهاية API، إصداراتُ التطبيق الجوّال. قائمةٌ صريحة، ليس wildcard ("*.example.com"). ٢. الأصولُ غير المختبَرة (الاستثناءات): SaaS من طرفٍ ثالث (Google Workspace، Microsoft 365)، CRM إنتاج، خوادمُ النسخ الاحتياطي. الاختبارُ العَرَضي يَحمل مخاطرَ استمراريّةِ العمل. ٣. نوافذُ الاختبار: نطاقُ الوقت (مثلًا ٠٢:٠٠-٠٦:٠٠ خارج ساعات العمل) + أيّام الأسبوع. لتقليل التأثير على حركةِ مرور الإنتاج. ٤. Payloads غير المختبَرة: Denial of Service (DoS)، تَسريبُ بيانات المستخدم، محاكاةُ هجومٍ فيزيائي. ممنوعٌ صراحةً في العقد. ٥. بروتوكولُ الطوارئ: مَن يُتَّصل عند انقطاعٍ في prod أثناء الاختبار، على أيّ خطّ، معاييرُ إيقاف الاختبار. ٦. قنواتُ التواصل: تقاريرُ حالةٍ يومية، خطُّ إخطار طوارئ للاكتشافات الحرجة (عادةً خلال ٤ ساعات).

هذا المستندُ يجب توقيعُه من الجانبين قبل بدء الاختبار. التغييراتُ اللاحقة تَمرّ بعمليّةِ change request؛ الاتّفاقاتُ الشفهية غيرُ صالحة.

٥. تنسيقُ التقرير — سلسلةُ الأدلّة والقابليّةُ للتكرار

السمةُ المشتركة لتقرير pentest جيّد هي أنّ الاكتشافاتِ قابلةٌ للتكرار. "يوجد SQL injection في URL X" غيرُ كافٍ؛ يجب أن يَستطيع المطوّرُ إرسالَ نفس الطلب ومراقبةَ نفس النتيجة.

الأقسامُ الخمسة الرئيسية لتقرير pentest قياسي:

القسم ١ — ملخّصٌ تنفيذي (١-٢ صفحة). بلغةٍ غير تقنية: كم اكتشاف، كم critical/high/medium/low، رسمٌ ملخّصٌ للنتيجة، تعليقٌ على أثر العمل. تَقرأها الإدارةُ العليا، تُقرّر.

القسم ٢ — النطاقُ والمنهجيّة. أيُّ الأنظمة اختُبِرَت، أيُّ معيارٍ استُخدِم (PTES + OWASP Level 2 إلخ)، أيُّ الأدوات (Burp Suite، Nmap، Metasploit، سكربتاتٌ مخصّصة)، نوافذُ الاختبار. للقابليّة للتكرار.

القسم ٣ — جدولُ الاكتشافات (مرتَّبٌ بسعرِ CVSS 3.1). لكلّ اكتشاف: المعرّفُ + العنوانُ + مستوى المخاطر + الأصلُ المتأثّر + سعرُ CVSS. يُظهر كلَّ الاكتشافات في لمحةٍ واحدة.

القسم ٤ — صفحةُ تفصيلٍ لكلّ اكتشاف:

• الوصف (فقرةٌ واحدة، بلغةٍ تقنية)
• الأثر: ماذا يَحدث إذا استُغِلَّ هذا الاكتشاف؟ تَسريبُ بيانات؟ استيلاءٌ على حساب؟ وصولٌ نظام؟
• خطواتُ التكرار: URL كامل + طريقةُ HTTP + رؤوس + payload + استجابةٌ متوقَّعة
• PoC (Proof of Concept): لقطةُ شاشة، حركةُ HTTP (تصديرُ Burp)، تسجيلُ فيديو
• الإصلاحُ الموصى به: محدّد. ليس "أَجرِ التحقّقَ من المُدخَلات" — "استَخدِم هذه المكتبة في هذه الوظيفة بهذه الطريقة".
• المراجع: رقمُ OWASP/CWE/CVE

القسم ٥ — نتائجُ إعادة الاختبار. نتيجةُ إعادة الاختبار بعد المعالجة. أيُّ الاكتشافات أُغلِقَت، أيّها أُغلِقَ جزئيًّا، أيّها بَقي مفتوحًا. يجب أن يُقدّم مُورّدُ pentest إعادةَ اختبارٍ مجّانية خلال ٣٠ يومًا.

تقريرٌ لا يَتوافق مع هذه البنية يَجعل من الصعب على فريق الاستجابة للحوادث لدينا استخدامَه كمرجعٍ بعد خرقٍ مستقبلي. جودةُ التقرير تَؤثّر مباشرةً على سرعة العمل الجنائي بعد الخرق.

٦. معاييرُ اختيار المُورّد — ٧ نقاط

سبعةُ معاييرَ ملموسة لتَثقيل الكِفّة عند اختيار مُورّد pentest:

١. شهاداتُ الفريق: OSCP (Offensive Security Certified Professional) الحدُّ الأدنى، OSCE/OSEP/OSWE المستوى الأعلى، eMAPT للجوّال، شهاداتُ GIAC. اطلبوا السيرةَ الذاتية للمهندس الذي سيَختبر فعلًا — شهادةُ مدير المشروع غيرُ كافية. ٢. خبرةٌ قطاعية: شركةٌ تَفعل اختباراتِ المصارف ليست دائمًا مناسبةً لـ SCADA. اسألوا كم اختبارًا أَجرى المُورّدُ في قطاعكم في الـ ١٢ شهرًا الماضية. ٣. توثيقُ المنهجيّة: هل توجد منهجيّةُ pentest مكتوبة؟ مَبنيّة على PTES أم OWASP؟ مُحدَّثة على مدى السنوات؟ ٤. جردُ الأدوات: Burp Suite Professional + Nessus + Metasploit Framework + Cobalt Strike (لـ red team) + سكربتاتٌ مخصّصة — قائمةٌ صريحة للأدوات يجب أن تَكون متاحة. ٥. التأمين + NDA: تأمينُ المسؤولية المهنية (تَغطيةٌ دنياها ١ مليون ليرة) + NDA صارم + بندُ مسؤوليةٍ لحوادث البيانات أثناء الاختبار. ٦. سياسةُ إعادة الاختبار: مجّانية خلال ٣٠ يومًا؟ ٦٠؟ مَن يُعرّف نطاقَ إعادة الاختبار؟ ٧. فحوصاتُ المراجع: مراجعٌ قابلةٌ للتحقّق من آخر ٣ عملاء؛ مثاليًّا مثالُ تقرير pentest مُجهَّل الهوية.

قليلٌ من المُورّدين يَحصلون على أخضرَ في السبعة جميعًا؛ يمكنكم العملُ مع ٥ أخضر + ٢ أصفر على الأقل. ما إذا كانت المناطقُ الصفراء حرجةً لمشروعكم تُقدِّرونه أنتم.

٧. بعد pentest — حلقةُ المعالجة و SLA

تقريرُ pentest بدايةٌ، ليس نهاية. الهندسةُ الفعلية تَحدث في المعالجة. SLAs المعالجة المعياريّة:

التخفيف ≠ الإصلاح. التخفيفُ تقليلُ مخاطرَ قصيرُ الأمد (قاعدةُ WAF، حظرُ IP، إيقافُ ميزةٍ مؤقّت)؛ الإصلاحُ تَغييرٌ دائم في الكود/التَّكوين. كلاهما مطلوبٌ لاكتشافٍ حرج.

حفظُ العملية الداخلية حاسمٌ أثناء المعالجة. افتَحوا تذكرةً لكلّ اكتشاف، عَيِّنوا مسؤولًا، اضبطوا deadline، عرِّفوا مَن يُؤكّد الإصلاح. توصيتُنا: على مُورّد pentest أن يُقدّم جلسةَ استشارةٍ تقنيّة مجّانية لمدّةِ ٣٠ دقيقة لخطّة المعالجة؛ للإجابة على سؤال فريق المطوّرين "كيف نُصلح هذا في الكود".

إعادةُ الاختبار تُؤخَذ خلال ٣٠ يومًا، مجّانًا، من نفس المُورّد. تقريرُ إعادة الاختبار مُرفَقٌ بالأصل؛ ثلاثُ أعمدة — "الاكتشافاتُ المُغلَقة" + "ما زال مفتوحًا" + "حديثُ الاكتشاف" (إعادةُ الاختبار أحيانًا تَكشف مشاكلَ جديدة).

بعد اكتمال المعالجة، يُعيّن فريقُ SOC لدينا إشاراتِ مراقبة — أيُّ محاولةِ هجومٍ مُعادة على الثغرة المُغلَقة تُكتَشف فورًا. هذه هي الحلقةُ التي تَربط دورةَ pentest بعمليّات الأمن المستمرّة.

مصفوفةُ القرار: بأيّ تَواترٍ نَختبر

تَواترُ pentest يَعتمد على القطاع، التنظيم، وملفّ المخاطر:

قرارُ إجراء pentest ليس ميزانيّة بل سؤالُ مخاطر. متوسّطُ تكلفة خرقٍ حرج (غرامةُ KVKK + فقدُ العملاء + ضررُ السمعة) هو ٢٠-٥٠× تكلفةَ pentest السنوية. مع هذه الحساب يَكون pentest ليس "ترفًا" بل "تأمينًا منخفضَ التكلفة". أَجروا الحسابَ لمؤسستكم وقَدِّموه للإدارة العليا في هذا الإطار — نِسبُ القبول تَرتفع ملحوظًا.

الخطوةُ التالية

إذا كنتم تُخطّطون لـ pentest لمؤسستكم — لروتينٍ سنوي، أو متطلَّبٍ تنظيمي، أو إطلاقِ منتجٍ جديد — قَيِّموا النقاطَ السبع أعلاه مقابلَ سيناريوكم. أيُّ معيارٍ يُلائم، أيُّ نوع (أسود/رمادي/أبيض) يَأخذ الأولوية، أيُّ معيارِ مُورّدٍ حرجٌ لكم — تُجاب هذه end-to-end معًا مع الفريق.

يمكنكم طلبُ مكالمةٍ تمهيدية لـ pentest عبر صفحة الاتصال؛ في مكالمةٍ مجّانية لـ ٤٥ دقيقة نُشارك مسوّدةَ نطاق + نطاقَ ميزانية + توصيةَ معيار. بعد المكالمة، تُقرّرون إجراءَ pentest والمُورّد؛ توصيتُنا مجرّدُ نقطة مرجع.

ستُعلَن المنشوراتُ التالية التي تَستمرّ في هذه السلسلة على مدوّنتنا: "دليلٌ عمليٌّ لمحاكاة Red Team" و "نَشرُ SOC — خريطةُ طريقٍ ٩٠ يومًا". إن كان موضوعٌ من أولويّاتكم، فإنّ ذكرَه في طلبكم يَسمح لنا بمشاركة المادّة التقنية ذات الصلة.