دليل تشغيل للاستجابة للتصيّد في 12 خطوة: من الطرف إلى الطرف في Krasper Suite
استعراض ملموس خطوة بخطوة لكيفية توصيل دليل تشغيل حقيقي للاستجابة للتصيّد من الطرف إلى الطرف في Krasper Suite، من دخول التنبيه إلى سجل التدقيق. اثنتا عشرة عقدة، وثلاثة تفرّعات شرطية، وبوابة تشغيل تجريبي واحدة قبل أن يلمس أي شيء الإنتاج.
TL;DR: The previous post in this series argued for the four design choices that keep SOAR playbooks alive: reactive data flow, typed node contracts, first-class branching, dry-run. This one shows what those choices look like in a working playbook. Twelve nodes, walked one at a time, with the data shape, the failure mode, and the design intent for each. By the end, the playbook handles the long tail of real phishing variation that scripted automations cave under.
Phishing remains the highest-volume initial-access vector in most organizations. It is also the incident category where the cost of poor automation is most visible: a single broken playbook can either miss real threats or, worse, take destructive action on a false positive (quarantining a legitimate CEO email, isolating a sales laptop mid-deal call). Doing it well is mostly about disciplined wiring; the logic itself is rarely the hard part.
This walkthrough follows one playbook end-to-end as it lives in Krasper Suite's designer. You can adapt the exact shape to any environment; the point of the walkthrough is the discipline it demonstrates.
Contents
- Ingress: alerts arriving from the mail-security signal
- Header parsing and message decomposition
- IOC extraction: URLs, domains, hashes, sender
- Threat-intelligence enrichment
- Sender reputation and domain-age signals
- Recipient resolution and asset mapping
- Phishing-confidence classification (the central switch)
- High-confidence branch: quarantine across mailboxes
- URL-click detection on affected endpoints
- Endpoint isolation (with explicit failure handling)
- Multi-channel notification with role-aware routing
- Ticket creation, audit trail, and post-mortem record
Plus: dry-run discipline and the one branch most teams forget to wire.
الخطوة 1: الدخول
تستقبل العقدة الأولى تنبيهات من إشارة أمن البريد. وفي المصمم، هذه منفذ إدخال واحد بمخطط معلن: كائن التنبيه كما ينشره مهايئ بوابة البريد على ناقل الأحداث المشترك.
┌──────────────────────────────────┐ │ Alert ingress │ │ │ │ in: (event bus subscription) │ │ out: alert: MailAlert │ └──────────────────────────────────┘
What matters here is that the alert is already typed. There is no "parse this JSON" step at the front of the playbook. That responsibility belongs to the mail-gateway adapter, which guarantees the shape before the alert ever reaches the bus. Authors of the playbook write against a contract, not against raw payloads.
If the upstream adapter is unavailable, no alert reaches this node; no execution starts; nothing fails silently. The platform's health view is the place to discover that, not the playbook itself.
الخطوة 2: تحليل الترويسات وتفكيك الرسالة
تفكّك عقدة التحويل الأولى كائن البريد إلى الحقول التي ستحتاجها العُقَد اللاحقة: headers وsubject وbody_text وbody_html وattachments[]. وهذه دالة نقية: بلا استدعاءات خارجية، وبلا آثار جانبية، وبلا أنماط فشل عدا المدخل المشوّه (الذي يُوجَّه إلى منفذ الخطأ ويُطلق تنبيه محلل).
┌──────────────────────────────────┐ │ Decompose message │ │ │ │ in: alert: MailAlert │ │ out: message: ParsedMail │ │ err: ParseError → analyst │ └──────────────────────────────────┘
وسبب كون هذه عقدة مستقلة بدل دمجها في الخطوة 3 هو قابلية الاختبار. فللمحلل مجموعة اختبارات خاصة به. وحين تغيّر بوابة البريد الأعلى اسم حقل، تنكسر عقدة واحدة بالضبط، بإصلاح واحد بالضبط، قابل للمراجعة منفصلًا.
الخطوة 3: استخلاص مؤشرات الاختراق
تستخلص هذه العقدة مؤشرات الاختراق من الرسالة المحلَّلة: الروابط في المتن، والنطاقات المشتقة منها، وتجزئات أي مرفقات، وعنوان المرسِل، وعنوان الرد إن اختلف.
┌──────────────────────────────────┐
│ Extract IOCs │
│ │
│ in: message: ParsedMail │
│ out: iocs: IOCSet { │
│ urls[], domains[], │
│ hashes[], senders[] │
│ } │
└──────────────────────────────────┘
Two design notes that matter at scale.
First, URL extraction normalizes before deduplication. http://x.com, https://x.com/, and https://X.COM collapse to a single canonical URL. Without this, downstream lookups duplicate cost and the classifier double-counts the same indicator.
Second, attachment hashing uses SHA-256 only. Older hash algorithms add noise without value; the threat-intelligence APIs the next step calls accept SHA-256 universally. One hash family, one code path, one less source of integration drift.
الخطوة 4: الإثراء باستخبارات التهديدات
العقدة التالية أول من يستدعي بنية تحتية خارجية. فتتوزع مجموعة المؤشرات إلى مهايئ استخبارات التهديدات (عادةً خدمة مثل VirusTotal أو ما يعادلها)، الذي يعيد حكمًا لكل مؤشر: خبيث معروف، أو نظيف معروف، أو مجهول.
┌──────────────────────────────────┐ │ Threat-intel lookup │ │ │ │ in: iocs: IOCSet │ │ out: verdicts: VerdictMap │ │ err: TIError → degraded path │ │ timeout: 8s │ └──────────────────────────────────┘
وتنطبق هنا تلقائيًا ثلاث ضمانات من المنصة: يحمل الاستدعاء مفتاح عدم تكرار (فلا تضاعف الإعادة حصة الواجهة)، والمهلة محدودة (فلا يستطيع طرف أعلى بطيء تعليق التنفيذ كله)، ومنفذ الخطأ إلزامي (فلا يُخفِّض انقطاع لدى مزوّد الاستخبارات الدليل بصمت إلى «كل مؤشر مجهول»).
ويُوجَّه منفذ الخطأ إلى مسار متدهور لا إلى إجهاض قاطع. فإن كانت واجهة الاستخبارات غير متاحة، يستمر الدليل بالعمل. ويصنّف بالإشارات المتوفرة لديه (سمعة المرسِل، وعمر النطاق، وترويسات البريد) ويَسِم الحكم بـ intel_unavailable في سجل التدقيق. فيعرف المحلل الذي يرى التذكرة الناتجة أن الثقة أدنى لأن الإثراء كان ناقصًا.
وثمة دقة إضافية تستحق التوصيل: تُخزَّن نتائج هذه العقدة مؤقتًا لنافذة محدودة (ساعات قليلة عادةً) بمفتاح المؤشر نفسه لا التنبيه. فحملة تصيّد تُنزل مئة رسالة شبه متطابقة في الصباح نفسه ينبغي ألا تنتج مئة عملية بحث مدفوعة للرابط نفسه. وطبقة التخزين المؤقت جزء من المهايئ لا من الدليل، فلا يحتاج المؤلفون للتفكير فيها، لكن معرفة وجودها هي الفرق بين أتمتة تتوسع اقتصاديًا وأخرى تستنزف بهدوء حصة واجهة الاستخبارات بحلول الأسبوع الثاني.
الخطوة 5: سمعة المرسِل وعمر النطاق
بالتوازي مع استدعاء الاستخبارات، يعمل إثراءان أرخص: سمعة نطاق المرسِل (من مهايئ منفصل)، وعمر تسجيل نطاق المرسِل (عبر بحث بنمط WHOIS). وتوازي بيئة التشغيل بينهما لأنه لا اعتمادية بينهما ولا على نتيجة الاستخبارات.
┌────────────────────────┐ ┌────────────────────────┐ │ Sender reputation │ │ Domain age │ │ │ │ │ │ in: iocs.senders │ │ in: iocs.domains │ │ out: rep_score │ │ out: age_days │ └────────────────────────┘ └────────────────────────┘
وعمر النطاق يهم لأن النطاقات المسجَّلة حديثًا ترتبط بقوة بحملات التصيّد. فنطاق سُجّل قبل ثلاثة أيام ويطلب من مديرك المالي تحويل أموال يستحق تدقيقًا أكبر من نطاق سُجّل قبل خمسة عشر عامًا. وإشارة العمر وحدها لا تكفي؛ لكنها مقترنة بالإشارات الأخرى ترفع الثقة كثيرًا.
الخطوة 6: حل المستلمين وربطهم بالأصول
يسرد تنبيه البريد المستلمين بعناوين بريدهم. أما قرارات الاحتواء فتحتاج أكثر: أي مستخدم، وبأي دور، وعلى أي نقطة نهاية، وأين يقع في الهيكل. وتحل هذه العقدة كل مستلم مقابل نموذج الأصول المعياري المشترك.
┌──────────────────────────────────┐
│ Resolve recipients │
│ │
│ in: message.recipients[] │
│ out: targets: ResolvedTarget[] { │
│ user_id, role, │
│ endpoints[], │
│ privileged: bool │
│ } │
└──────────────────────────────────┘
The privileged flag is a derived field, true if the user is in any group that warrants elevated containment (finance approvers, executive assistants, IT administrators). The playbook treats privileged users differently in Step 11, so this resolution has to happen before the central switch.
If a recipient cannot be resolved (external recipient, freshly provisioned user not yet in the asset model), the target is included in the array with resolved: false rather than dropped. Downstream nodes can filter on resolution status; nothing silently disappears.
الخطوة 7: تصنيف الثقة في التصيّد
هذه نقطة القرار المركزية. فتأخذ عقدة مصنِّف كل إشارة إثراء وتصدر حكمًا confidence: high | medium | low، مع التعليل المهيكل خلف الحكم.
┌──────────────────────────────────────────────────────┐
│ Classify confidence │
│ │
│ in: verdicts, rep_score, age_days, targets, message │
│ out: classification: { │
│ confidence: "high" | "medium" | "low", │
│ signals: [...], │
│ intel_complete: bool │
│ } │
└──────────────────────────────────────────────────────┘
│
▼
┌────────────────────────────┐
│ switch confidence │
│ case high ──▶ Step 8 │
│ case medium ──▶ analyst │
│ case low ──▶ trend tag │
│ default ──▶ analyst │
└────────────────────────────┘
والمصنِّف نفسه قابل للتفسير عمدًا. فهو مجموعة قواعد موزونة، والإشارات التي أسهمت في كل حكم مسجَّلة في المخرجات، فلا يختبئ شيء خلف درجة تعلّم آلي صندوق أسود. وحين يفتح المحلل التذكرة الناتجة، يرى لماذا صنّف الدليل التنبيه كما صنّفه. وقابلية التدقيق تلك تهم بقدر الدقة: فحكم عالي الثقة لا يستطيع المحلل تتبّعه إلى مدخلاته يقوّض الثقة بالأتمتة كلها.
وعمليًا، أوزان الإشارات خاضعة لإدارة الإصدارات إلى جانب الدليل نفسه. فتغيير «عامل النطاقات المسجَّلة حديثًا كأعلى خطرًا» فرق قابل للمراجعة، لا انحراف تهيئة في قاعدة بيانات إنتاجية. وحين يسأل التدقيق «لماذا حُجر هذا التنبيه في 14 مارس»، تكون الإجابة معرّف التزام محددًا بأوزان المصنِّف وقت التنفيذ، مسجَّلًا في سجل التدقيق.
وفرع default موصول، مع أن كل قيمة ثقة ينبغي أن تكون إحدى الحالات الثلاث. وهذا أكثر فرع «نسيناه»، وهو الذي يحمي من تغييرات مستقبلية في المصنِّف تُدخل حالة رابعة لم يحدّث أحد المفتاح لها. فإن تطور المصنِّف ليصدر confidence: "requires-human-review" بعد ستة أشهر، وجّه الدليل إلى المحلل افتراضيًا بدل أن يفشل بطريقة تُسقط التنبيه بصمت.
الخطوة 8: الحجر عبر صناديق البريد (فرع الثقة العالية)
في فرع الثقة العالية، أول إجراء هو حجر الرسالة عبر كل صندوق بريد وصلت إليه. وتستدعي عقدة الحجر مهايئ منصة البريد، وهي لا تكرارية على زوج (campaign_id، message_id) فلا تضاعف إعادة التنفيذ الآثار.
┌──────────────────────────────────┐ │ Quarantine mail │ │ │ │ in: message.id, targets │ │ out: quarantine_result │ │ err: → escalate to analyst │ │ dry-run: synthetic success │ └──────────────────────────────────┘
This is the first destructive node in the playbook. The dry-run discipline matters most here: every modification to this branch is tested against the dry-run corpus before merge, because a regression that quarantines legitimate mail at scale is a production incident of its own.
الخطوة 9: كشف النقر على الروابط
بالتوازي مع الحجر، يفحص الدليل ما إذا كان أي مستلم قد نقر أصلًا أي رابط خبيث. وهذا استعلام على قياسات نقاط النهاية (سجلات الوكيل، وقياسات المتصفح، ووكيل نقطة النهاية) للمستخدمين المتأثرين في النافذة بين وصول البريد وتنفيذ الدليل.
┌──────────────────────────────────┐ │ URL-click detection │ │ │ │ in: iocs.urls, targets, │ │ message.received_at │ │ out: clicks: ClickEvent[] │ └──────────────────────────────────┘
فإن كانت المصفوفة فارغة، تابع الدليل إلى الإخطار. وإن احتوت مدخلات، صعّدت الخطوة التالية إلى احتواء نقاط النهاية للمضيفين المتأثرين.
وهذه الخطوة تقرأ فقط؛ فلا تنتج مخرجًا مدمّرًا ولا تثير قلق عدم التكرار. وهي من نوع العُقَد التي يدمجها المؤلفون أحيانًا في خطوة مركّبة أكبر، وهو ما يستحق المقاومة. فعُقَد الاستعلام النقية تنتمي إلى صناديقها الخاصة لأنها الأسهل في إعادة الاستخدام عبر أدلة أخرى.
الخطوة 10: عزل نقطة النهاية (مع معالجة صريحة للفشل)
لكل نقطة نهاية اكتُشف فيها نقر، يستدعي الدليل مهايئ نقطة النهاية لعزلها عن الشبكة. وهذه الخطوة الأرجح فشلًا في الظروف الحقيقية: فقد تكون نقطة النهاية غير متصلة، أو الوكيل غير قابل للوصول، أو المهايئ محدود المعدل.
┌──────────────────────────────────┐ │ Isolate endpoint (for each) │ │ │ │ in: endpoint_id │ │ out: isolation_result │ │ err: IsolationFailed → │ │ force-priority alert │ │ timeout: 30s │ │ dry-run: synthetic success │ └──────────────────────────────────┘
ومنفذ الخطأ هنا لا يُوجَّه إلى «سجّل وتابع». بل يُوجَّه إلى تنبيه بأولوية قصوى للمحلل المناوب مع سياق نقطة النهاية مرفقًا، لأن فشل الاحتواء على اختراق معروف حدث أعلى إلحاحًا من التنبيه الأصلي. ولا يتظاهر الدليل بأن عزلًا فاشلًا نجح؛ بل يصعّد صراحة، ويعكس سجل التدقيق المحاولة ونتيجتها معًا.
الخطوة 11: إخطار متعدد القنوات بتوجيه واعٍ بالأدوار
يحتاج المستخدمون المتأثرون إلى إخطار، لكن القناة والنبرة تعتمدان على المستخدم. وتوزّع عقدة الإخطار لكل هدف بتوجيه واعٍ بالأدوار:
- المستخدمون العاديون: إخطار عبر القناة الداخلية المعتمدة (بريد أو محادثة)، يوضح ما حدث وما ينبغي فعله.
- المستخدمون المميّزون (المالية، والتنفيذيون، ومدراء تقنية المعلومات): الإخطار نفسه إضافة إلى تنبيه فوري بأولوية قصوى عبر قناة المناوبة، لأن أثر اختراق بيانات الاعتماد أعلى.
- المستلمون الخارجيون: بلا إخطار تلقائي، ويُصعَّد الأمر إلى إنسان للمراجعة.
┌────────────────────────────────────────────────┐ │ Notify (for each target) │ │ │ │ in: target, message, classification │ │ out: notify_result │ │ err: NotifyFailed → analyst │ │ dry-run: synthetic success │ │ │ │ routing: │ │ target.privileged == true → on-call + user │ │ target.privileged == false → user only │ │ target.resolved == false → analyst review │ └────────────────────────────────────────────────┘
ولا يُولَّد نص الإخطار وقت التشغيل بنموذج لغوي، على الأقل ليس في الفرع المدمّر. فالقوالب معتمدة مسبقًا ومُدارة بالإصدارات وتُعرَض بحقول خاصة بالتنبيه مُحقَنة فيها. وهذا يبقي الإخطار قابلًا للتدقيق ومتسقًا، ويمنع انحدارًا في نموذج من إنتاج رسائل مقلقة أو مربكة لمستخدمين غير تقنيين على نطاق واسع.
الخطوة 12: إنشاء التذكرة ومسار التدقيق وسجل ما بعد الحادث
تنشئ العقدة الأخيرة تذكرة الحادث وتكتب سجل ما بعد الحادث. وتتضمن التذكرة التصنيف الكامل (مع الإشارات المساهمة)، وأثر الإجراءات (ما حُجر، وما عُزل، ومن أُخطر)، وروابط إلى التنبيه الخام وأثر تنفيذ الدليل.
┌──────────────────────────────────┐ │ Create incident + audit record │ │ │ │ in: classification, actions, │ │ targets, execution_trace │ │ out: incident_id │ │ err: → emergency mail to SOC │ │ dry-run: synthetic success │ └──────────────────────────────────┘
The execution trace is the part most teams underinvest in. Reconstructing what the playbook did, six weeks later when the audit is happening, requires every node's input, output, branch decision, and external call to be persisted with a stable execution ID. Without that discipline the playbook is effectively a black box; with it, auditors can follow the automation node by node, which is what makes it defensible.
انضباط التشغيل التجريبي قبل شحن أي من ذلك
لا تُشحن أي من الخطوات الاثنتي عشرة أعلاه دون اجتياز تشغيل تجريبي مقابل مجموعة تنبيهات منتقاة. وتحوي المجموعة: تنبيه تصيّد تمثيلي عالي الثقة بمستلمين مميّزين، وتنبيهًا متوسط الثقة بمستلمين مختلطين، وتنبيهًا منخفض الثقة، وتنبيهًا تنتهي فيه مهلة الاستخبارات، وتنبيهًا بمستلم خارجي غير قابل للحل. وكل تغيير في الدليل يعمل مقابل الخمسة في مسار التكامل المستمر؛ وأي انحراف عن أثر التنفيذ المتوقع يفشل البناء.
وهذا هو الفرق بين دليل يثق به الفريق وآخر يلتف حوله. فالفروع أعلاه ليست نظرية: إنها الحالات التي تمارسها المجموعة عند كل تغيير.
الفرع الذي تنسى معظم الفرق توصيله
أعد قراءة الخطوة 7. فرع default على المفتاح المركزي يُوجَّه إلى المحلل. وأعد قراءة الخطوة 10. منفذ الخطأ على العزل يُوجَّه إلى تنبيه بأولوية قصوى. وأعد قراءة الخطوة 4. منفذ الخطأ على الاستخبارات يُوجَّه إلى مسار متدهور يُكمل الدليل رغم ذلك.
وعبر الثلاثة، نمط الفشل موصول ومسمّى ومدقَّق. وهذا ما يفصل أتمتة يثق بها المشغّلون عن أخرى يتجاوزونها بهدوء بعد أول استدعاء في الثالثة فجرًا لم يفعل فيه الدليل شيئًا. إنها تكلّفك عُقَدًا أكثر على اللوحة وتشتري لك دليلًا يعمل فعلًا بلا إشراف.
خاتمة
هذا هو شكل الأمر كله: اثنتا عشرة عقدة، وثلاثة تفرّعات شرطية، وأربعة مسارات خطأ صريحة، كلها خلف فحص تشغيل تجريبي واحد قبل أن يصل أي شيء إلى الإنتاج. وهكذا تبدو الاستجابة للتصيّد من الطرف إلى الطرف حين تأخذ انضباط التوصيل على محمل الجد.
يرتفع المقال التالي في هذه السلسلة درجة، من دليل واحد إلى المقاييس التي تخبرك ما إذا كانت أدلتك، إجمالًا، تحرّك المؤشر. وسننظر في التغطية، وزمن الاحتواء، ومعدل الإيجابيات الكاذبة، وحصة الأتمتة، وهي الأرقام التي تهم مدير أمن المعلومات، وفي كيفية قياسها.
قراءات إضافية
- NIST SP 800-61r3: دليل التعامل مع حوادث أمن الحاسوب
- MITRE ATT&CK: الوصول الأولي: التصيّد (T1566)
- ENISA: التقرير السنوي مشهد تهديدات التصيّد
- CISA: إرشادات Stop Ransomware حول الدفاع عن الوصول الأولي
بنيتك المؤسسية؟
احجز جلسة إحاطة تقنية. بلا عروض بيع، فقط مهندسون وفريقك.