مخطط انسيابي للاستجابة لحوادث التصيد الاحتيالي (بلاغ بريد إلكتروني)

ما هي مخطط انسيابي للاستجابة لحوادث التصيد الاحتيالي (بلاغ بريد إلكتروني)؟

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

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

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

ما الذي يغطيه هذا المخطط

في هذا القالب

• خمسة مسارات (الموظف / المُبلِّغ، مكتب الخدمة، محلل مركز عمليات الأمن، تقنية المعلومات / فريق الهوية، وإدارة الأمن) عبر ست مراحل: الإبلاغ والاستلام، الفرز والقرار، تحديد نطاق الحملة، الاحتواء والاستئصال، التعافي والتواصل، والإغلاق والتحسين
• مساران للاستلام يغذّيان طابوراً واحداً: ضغطة زر الإبلاغ التي تُرسل العينة مباشرة إلى فريق الأمن، وتذكرة مكتب الخدمة لمن يتصل بدلاً من ذلك، تُسجَّل مع إرفاق الرسالة الأصلية لا وصفها
• قرار الفرز 'هل الرسالة المُبلَّغ عنها ضارة؟'، الذي يجيب فرعه غير الضار المُبلِّغ، ويضبط مرشح البريد، ويغلق البلاغ باعتباره غير ضار بدل إسقاطه بصمت، لأن الرد هو ما يبقي الناس على الإبلاغ
• تحديد النطاق قبل الحذف بـ'ابحث في المستأجر عن نسخ أخرى' و'هل نقر أحد أو ردّ؟'، ثم جولة احتواء تحذف كل نسخة، وتحظر المرسل والروابط وبصمات الملفات، وتتكرر عند 'هل ما زالت تصل نسخ أخرى؟' ما دامت الحملة لا تزال تصل
• فرع ثلاثي 'ما الذي فعله المستخدم المتأثر؟': إدخال بيانات الاعتماد يذهب إلى 'أعد تعيين كلمة المرور وألغِ الجلسات' في مسار الهوية، والمرفق المفتوح يذهب إلى عزل الجهاز وفحص كامل، و'علامات على اختراق الحساب؟' يصعّد بدل أن يُغلق
• التواصل والإغلاق: 'هل يلزم تحذير لعموم الموظفين؟' يُعتمَد في مسار إدارة الأمن، ويُبلَّغ المستلمون بما ينبغي الانتباه له، ولا يُغلق البلاغ إلا بعد تسجيل المؤشرات والجدول الزمني ومعدلي الإبلاغ والنقر ومتابعة توعوية

متى تستخدم هذا القالب

• لديكم زر إبلاغ في Outlook أو Gmail بلا دليل عمل متفق عليه خلفه، فما يحدث لرسالة مُبلَّغ عنها يتوقف على أي محلل يلتقطها
• يعيد المستخدمون توجيه بريد مشبوه إلى صندوق مشترك لا يملكه أحد فعلياً، وتحتاجون أن يكون الاستلام والقرار والرد على المُبلِّغ مرسومين كمسار واحد
• حملة تصيّد لبيانات الاعتماد وصلت للتو، وتريدون أن يكون الحذف وإعادة التعيين وإلغاء الجلسات وفحص قواعد صندوق البريد مرتبة قبل وصول التالية
• تكتبون قسم التصيد الاحتيالي من خطة استجابة للحوادث وتحتاجون أن يسلّم الحالة بوضوح إلى عملية الحوادث الأمنية الأوسع بدل تكرارها
• طلب مدقّق معرفة كيف يُبلغ الموظفون عن حدث أمني مشتبه به وما يحدث بعد ذلك، وهو آلية الإبلاغ التي تطلبها الضابطة 6.8 من الملحق A في ISO/IEC 27001:2022

كيف تعمل

1. أعد تسمية المسارات لتطابق أدواركم

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

2. دوّنوا كل قناة استلام

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

3. حدّدوا معايير قرار الفرز

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

4. أصلحوا بحث تحديد النطاق قبل الحذف

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

5. اتفقوا على استجابة الهوية ومن يأمر بها

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

6. قرّروا من يعتمد تحذيراً لعموم الموظفين

   ضعوا اسماً مقابل 'هل يلزم تحذير لعموم الموظفين؟' وعتبة تحته: كم عدد المستلمين، وأي علامات تجارية أو مسؤولين يُنتحلون، وهل دفع أحد بالفعل أو أدخل بيانات اعتماد. اكتبوا مسودة التحذير مسبقاً، لأن النسخة المكتوبة تحت الضغط هي التي تطلب من الموظفين مراقبة سطر موضوع غيّره المهاجم قبل ساعة.

7. اختبروه على رسالة مُبلَّغ عنها حقيقية

   خذوا بلاغين حديثين، أحدهما تبيّن أنه بريد مزعج والآخر أصبح حادثة حقيقية، وتتبعوا كلاً منهما عبر المخطط مع من تعامل معهما. الخطوات التي لا يستطيع أحد تسمية مسؤول عنها، والخطوات التي حدثت بوضوح لكنها غير مرسومة، هي الملاحظات الجديرة بالمعالجة قبل نشر دليل العمل وتمرينه.

الأسئلة الشائعة

ما خطوات عملية الاستجابة لحوادث التصيد الاحتيالي؟

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

بم تختلف الاستجابة للتصيد الاحتيالي عن الاستجابة لحوادث الأمن السيبراني؟

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

هل تكفي إعادة تعيين كلمة المرور بعد أن يُدخل أحد بيانات اعتماد في صفحة تصيّد؟

عادة لا. أدوات تصيّد بيانات الاعتماد الحديثة تعمل كوسيط خصم: الصفحة المزيّفة تُمرّر تسجيل الدخول الحقيقي، فتُرسَل كلمة المرور وطلب العامل المتعدد كلاهما إلى الخدمة الحقيقية، ويلتقط المهاجم رموز الجلسة والتحديث العائدة. تبقى تلك الرموز تعمل بعد تغيير كلمة المرور، ولهذا يقرن هذا المخطط إعادة التعيين بإلغاء الجلسات في الخطوة نفسها، ويتبعها بفحص طرق MFA المسجّلة وقواعد إعادة التوجيه في صندوق البريد وتطبيقات OAuth المُصرَّح لها، وهي الأماكن الثلاثة التي يترك فيها المهاجمون عادة طريقاً للعودة. على المدى الأطول، الضابط الذي يزيل الهجوم بدل تنظيفه لاحقاً هو المصادقة المقاومة للتصيد. وترشيحات CISA تسمّي مصدّقات FIDO/WebAuthn والطرق القائمة على PKI مثل البطاقات الذكية أشكالاً مقاومة للتصيد، لأنها تربط تسجيل الدخول بالنطاق الحقيقي وتفشل أمام وسيط.

هل يمكن إزالة رسالة تصيّد من كل صناديق البريد بعد تسليمها؟

جزئياً، ويستحق الأمر معرفة الحدود قبل أن تَعِدوا به. منصات البريد السحابية توفّر إزالة بأثر رجعي للرسائل التي يتبيّن أنها ضارة بعد التسليم. أداة Zero-Hour Auto Purge من مايكروسوفت، مثلاً، تعمل على البريد المُسلَّم بالفعل في صناديق البريد السحابية، ويغطي بحثها آخر 48 ساعة من البريد المُسلَّم، ولا تعمل في صناديق البريد المحلية المحمية بواسطة Microsoft 365. البحث والحذف بقيادة محلل من بوابة الأمن يمنحكم شبكة أوسع، لكن لا يزال ذلك فقط على الصناديق التي تحتفظ بها تلك المنصة. ما لا يصله أي حذف هو نسخة أعاد المستلم توجيهها بالفعل إلى الخارج، أو رسالة سُحبت إلى أرشيف محلي، أو لقطة شاشة في محادثة. لهذا يتكرر المخطط عند 'هل ما زالت تصل نسخ أخرى؟' بدل معاملة الحذف كحدث واحد، ولهذا يبقى إبلاغ المستلمين بما ينبغي الانتباه له على المسار الحرج.

هل يجب الإبلاغ عن حادثة تصيّد إلى جهة رقابية؟

يتوقف ذلك على ما حصل عليه المهاجم، وليس قراراً يتخذه المحلل وحده. بموجب GDPR البريطاني والأوروبي، يجب على جهة التحكم إخطار سلطتها الرقابية بخرق بيانات شخصية دون تأخير لا مبرر له، وفي غضون 72 ساعة كحد أقصى حين يكون ذلك ممكناً من لحظة العلم به، ما لم يكن من غير المرجح أن يشكّل الخرق خطراً على حقوق الأفراد وحرياتهم؛ ويجب أن يحمل الإخطار المتأخر أسباب التأخير. وتضع الأنظمة القطاعية والعقود وبوالص التأمين السيبراني مهلها الخاصة فوق ذلك. القاعدة العملية أنه في اللحظة التي يصل فيها هذا المخطط إلى علامات اختراق الحساب، تُشرَك القانونية ومسؤول حماية البيانات بالتوازي بينما يستمر العمل التقني. وعلى نحو منفصل، تستقبل عدة جهات وطنية العينة نفسها: ففي المملكة المتحدة، تقبل خدمة NCSC للإبلاغ عن البريد المشبوه الرسائل المُعاد توجيهها إلى report@phishing.gov.uk.