Incident Response עם Claude | בית הספר של Claude

כשהclock מתחיל לדקות, IR בעידן ה-AI

ב-2021, חברת ביטוח ישראלית גדולה קיבלה alert על flow חריג בייצוא נתונים. מהרגע שה-SOC analyst ראה את האזהרה ועד שהתקבלה החלטת containment, עברו 47 דקות. בזמן הזה יצאו 240,000 רשומות. Incident Response הוא המקצוע שבו כל דקה של היסוס מתורגמת לנזק מדיד: רשומות שדלפו, attacker שמחזק אחיזה, חוקי GDPR שמופרים. Claude לא מחליף analyst מנוסה, הוא רץ במקביל אליו, מנתח logs בזמן שהאנליסט מנסה להבין את העמוד הראשון.

לפי מחקר של Splunk (2025), SOC שמשלב AI מקצר זמן תגובה בממוצע של 40%, ומצמצם alert fatigue משמעותית. זה לא עתיד, זה כבר קורה בכמה מחברות הסייבר הישראליות המובילות.

שלבי IR, ה-NIST Framework בפועל

NIST SP 800-61 מגדיר ארבעה שלבים: Preparation, Detection & Analysis, Containment/Eradication/Recovery, Post-Incident Activity. Claude מוסיף ערך בשלושת האחרונים, ובמיוחד ב-Detection & Analysis שם עצירת השעון קריטית.

שלב	מה עושים	איך Claude עוזר
Detection & Analysis	זיהוי IOCs, בניית timeline, הערכת blast radius	ניתוח logs תוך שניות, מיפוי MITRE ATT&CK, הערכת היקף נזק
Containment	בלימת ההתפשטות, הגנה על ראיות	עדיפות containment actions, containment vs. stealth tradeoffs
Eradication & Recovery	ניקוי הסביבה, חזרה לפעילות	checklist שחזור, validation של clean state
Post-Incident	לימוד, שיפור תהליך	כתיבת blameless post-mortem בפורמט Google SRE

פרומפט 1, ניתוח Logs בזמן אמת

זהו תבנית עבודה לניתוח incident פעיל. הדבקו logs אמיתיים ב-[Logs] ושנו את הפרטים לסביבה שלכם:

אתה SOC analyst בכיר המנתח incident פעיל.
חברה: SaaS ישראלי, 50,000 משתמשים, PostgreSQL + Node.js.
זמן: alert על anomalous data export.

נתח את ה-logs ותן:
1. IOCs, IPs חשודים, accounts מעורבים, volume anomalies
2. MITRE ATT&CK techniques (tactic/technique ID)
3. Timeline כרונולוגי של ההתקפה
4. Blast radius, אילו נתונים ייתכן שנחשפו?
5. Containment מיידי, מה לחסום, ומה לא לחסום כדי לא להתריע לתוקף?

Logs:
[הדבק כאן]

שתי נקודות קריטיות בפרומפט הזה: (א) MITRE ATT&CK, מסגרת תקנית שמאפשרת שפה משותפת עם SIEM ועם כל הצוות; (ב) מה לא לחסום, שאלה שרוב analysts שוכחים לשאול. לפעמים חסימה מיידית מתריעה לתוקף שהתגלה, גורמת לו להאיץ exfiltration או להפעיל ransomware.

פרומפט 2, Runbook על פי דרישה

Runbooks הם המסמכים שצריכים להיות מוכנים לפני incident, אבל רוב ה-SOC teams לא מעדכנים אותם. Claude יכול לייצר runbook מותאם לסביבה שלכם תוך דקות:

כתוב Incident Response Runbook ל-Credential Stuffing Attack.
סביבה: Node.js API + Redis + PostgreSQL.
מטרה: containment תוך 30 דקות.

Phase 1, Detection (0-5 דק'):
- Criteria לאישור Credential Stuffing לעומת legitimate traffic spike
- 3 commands ספציפיים לאיסוף ראיות
- מי מקבל notification ובאיזה ערוץ

Phase 2, Containment (5-20 דק'):
- WAF rules לblock
- Rate limiting config ב-Nginx
- Criteria לנעילת accounts (לא רשימה, כלל עקרוני)
- Template הודעה ללקוחות מושפעים

Phase 3, Eradication (20-30 דק'):
- Password reset strategy
- MFA enforcement steps
- Validation שההתקפה הסתיימה

Lessons Learned:
- 3 שיפורים מובנים למניעת הישנות

שימו לב לשורה על "criteria לנעילת accounts", לא רשימה סטטית אלא כלל עקרוני. Runbooks שמכילים רשימות קשיחות מתיישנים תוך שבועות. כלל עקרוני ("נעל כל account שעבר 50+ failed logins ב-5 דקות") תמיד רלוונטי.

עזור לי לטפל ב-security incident

אתה SOC analyst בכיר. יש לנו incident פעיל: anomalous data export מ-SaaS ישראלי עם 50K משתמשים. נתח את auth logs הבאים: (1) זהה IOCs לפי MITRE ATT&CK עם technique IDs, (2) בנה timeline כרונולוגי, (3) הערך blast radius בהיבט נתונים, (4) ספק immediate containment steps ופרט מה לא לחסום ולמה. [הדבק logs]

טעויות נפוצות שעולות ביוקר

Panic containment ללא analysis: לנתק הכל מיד נראה נכון, אבל לעיתים מוחק ראיות קריטיות, מתריע לתוקף שהתגלה, ומכשיל forensic investigation. כלל: Analyze first, Contain second, אלא אם כן ה-blast radius מתרחב בזמן אמת.
לשכוח לpreserve evidence: לפני כל פעולה ב-system נגוע, dump logs, memory snapshot, network capture. ראיות שנמחקות לא חוזרות. Claude יכול לייצר Evidence Collection Checklist על פי דרישה.
להשאיר Legal ו-PR מחוץ ללולאה: Incident אינו רק technical. עורך דין צריך לדעת מה אפשר לגלות ומתי; PR צריך להכין תגובה לתקשורת; CISO צריך להחליט על notification ללקוחות. שלושתם נחוצים, גם כשהטכנאים עמוסים.

Post-Mortem, הנכס הכי חשוב שיוצא מ-Incident

לאחר שה-incident נגמר, רוב הצוותים עושים retrospective שטחי ועוברים לדבר הבא. זו הטעות. Post-mortem טוב הוא ההשקעה שמונעת את ה-incident הבא. Claude יכול לכתוב אותו בפורמט Google SRE:

הנה timeline של incident שחווינו:
[5 נקודות timeline]

כתוב blameless post-mortem בפורמט Google SRE:
- Summary (2-3 משפטים)
- Impact: מה נפגע, כמה זמן, כמה users
- Timeline כרונולוגי
- Root Cause Analysis: 5 Whys
- Action Items: owner + due date לכל פריט

התמקד בתהליכים ולא באנשים.

המילה "blameless" בפרומפט היא קריטית. בלעדיה, Claude (ובני אדם) נוטים לכתוב post-mortem שמצביע על אנשים, מה שמוביל לתרבות שבה אנשים מסתירים בעיות. תרבות blameless גורמת לאנשים לדווח על תקלות מוקדם יותר.

תמיד לנתק את ה-system נגוע מיידית, כל שנייה מסוכנת

לנתח קודם ואז להחליט על containment, תוך שמירת ראיות, אלא אם ה-blast radius מתרחב בזמן אמת

להמתין 30 דקות לaיסוף ראיות לפני כל פעולה

להזמין Legal ו-PR רק לאחר שה-incident נגמר

ה-IP range ממנו יצאה ההתקפה

מספר ה-accounts שהיו susceptible להתקפה

היקף הנזק הפוטנציאלי, אילו נתונים, systems ו-users ייתכן שנחשפו

העלות הכספית של ה-incident

כי לא צריך לחפש root cause, מספיק לתעד מה קרה

כי תרבות שמאשימה אנשים גורמת להסתרת בעיות, blameless מתמקד בתהליכים ומוביל לשיפור אמיתי

כי אין action items אישיים, רק שיפורי תהליך ארגוניים

כי זה דרישה רגולטורית של GDPR

סיכום, מה לקחת מהשיעור הזה

Claude כ-IR analyst: מנתח logs, ממפה MITRE ATT&CK, מבנה runbooks, כותב post-mortems, כולם תוך דקות
הסדר הנכון: Analyze, Preserve Evidence, Contain, לא להפך
Blast radius חייב להיות מחושב לפני containment strategy
Stakeholders non-technical (Legal, PR, CISO) הם חלק מה-IR, לא נספחים
Post-mortem blameless הוא ההשקעה הטובה ביותר למניעת ה-incident הבא
754 cybersecurity skills ל-Claude Code (2026) מאפשרים טעינת runbooks דינמית לפי context

מקורות: MITRE ATT&CK Framework | NIST SP 800-61 | Claude Code Security, Anthropic | 754 Cybersecurity Skills for Claude