IR: ניהול תגובה לאירועי סייבר בעידן ענן, בינה מלאכותית ו- Zero Trust — מסגרת מבצעית, מדידה וניסויים אמפיריים

1. Introduction

תגובה לאירועי סייבר היא אחת היכולות הקריטיות ביותר בארגון מודרני, אך עד 2026 היא חדלה להיות “צוות כיבוי שריפות” ונעשתה מערכת מורכבת של החלטות בזמן אמת, אינטגרציות טכנולוגיות, והבנה עמוקה של פעולות התוקף. המעבר לענן היברידי, עבודה מרחוק, SaaS בכל שכבת עסק, ופריסה מואצת של Kubernetes, IAM מורכב ונתיבי אוטומציה, יצרו מציאות שבה האירוע אינו עוד חדירה נקודתית אלא לעיתים קרובות רצף של טעויות קונפיגורציה, גניבת זהויות, abuse של APIs, ותנועה בין-פלטפורמית. במקביל, ההאצה של שימוש ב-LLMs גם בצד ההגנתי וגם בצד התוקף הגדילה את קצב הייצור של פישינג מותאם אישית, deepfakes, הנדסה חברתית רב-לשונית, ואוטומציה של reconnaissance ו-post-exploitation ברמה שאילצה ארגונים לעדכן את תפיסת ה-IR שלהם.

בפועל, צוות IR בשנת 2026 נדרש לפעול תחת אילוצים של זמן, הקשר ואמינות. כל החלטה על בידוד תחנה, חסימת זהות, איפוס סוד, או השבתת שירות עשויה להשפיע על רציפות עסקית, רגולציה, חוויית לקוח, ולעיתים גם על בטיחות. לכן נדרשת מסגרת המשלבת מדידה אמפירית, עקרונות תכנון, ופרוצדורות תפעוליות שנבנו מראש סביב מניעה של טעויות “irreversible”. בהקשר זה, Zero Trust אינו עוד סיסמה אלא שכבת בקרה בסיסית המאפשרת ל-IR להסתמך על least privilege, session-based access, continuous verification, וניתוק מהיר של משאבים מבלי לקרוס את כל המערכת. באותו אופן, CNAPP, EDR, XDR, SIEM, SOAR, NDR, and identity telemetry אינם פתרונות נפרדים אלא מקורות נתונים שחייבים להיקרא יחד, אחרת מתקבלת תמונת מצב חלקית מאוד.

מבחינה מחקרית, בעיית ה-IR סובלת משתי חולשות חוזרות. הראשונה היא פער בין ספרות אקדמית לבין המציאות התפעולית: מאמרים רבים מתמקדים בזיהוי, סיווג או אנומליות, אך פחות בהחלטות containment, בטעויות אנוש, ובעלות של חיכוך תפעולי. השנייה היא היעדר פורמליזציה של יעדי התגובה במונחים מדידים: מהו “תגובה טובה”? האם מדובר בקיצור זמן? בהפחתת נזק? בצמצום false positives? או בשמירה על שרידות שירות? ללא מודל כזה, קשה להשוות בין playbooks, קשה לבצע תעדוף, וקשה לבנות אוטומציה אמינה. לכן, המאמר מציע מסגרת שמגדירה את IR כבעיית אופטימיזציה רב-ממדית תחת חוסר ודאות, עם מגבלות של סיכון תפעולי ושלמות ראיות.

התרומה המרכזית של המאמר היא שילוב בין תכנון מבצעי, ארכיטקטורת נתונים, ושיטת הערכה. ראשית, מוצג מודל איום עכשווי ל-2026, הכולל תוקפים המשתמשים בסטגנוגרפיה בענן, abuse של tokens, phishing מבוסס AI, living-off-the-land, ו-exploitation של שרשראות אספקה. שנית, מוצעת מתודולוגיה שיטתית ל-IR החל מ-triage ועד recovery, כאשר בכל שלב מוגדרים inputs, outputs, וקריטריונים להחלטה. שלישית, מובאת ארכיטקטורת יישום שמרכזה קורלציה בין telemetry streams, enrichment דרך threat intelligence, ו-orchestration מבוקרת שמטרתה להפחית MTTR מבלי להגדיל את שיעור הפעולות השגויות. רביעית, המאמר מציג ניסוי אמפירי בתרחישים מייצגים, כולל טבלאות השוואתיות ומקרה בוחן, כדי לבחון לא רק זיהוי אלא גם ביצוע.

חשוב להדגיש כי IR איכותי בשנת 2026 אינו נשען על “מוצר קסם” אחד. הוא נשען על שילוב של תשתית, אנשים ותהליכים: חיישני endpoint, לוגים של identity, טלמטריית ענן, ניתוח זיכרון, capture של רשת, זיהוי במערכות SaaS, ויכולת לתרגם הכול להחלטה תפעולית. השונות בין סביבות, במיוחד בין ארגון regulated לבין startup ענני, מכתיבה כי playbooks חייבים להיות מותאמים, ניתנים לבדיקה, ומבוקרים על ידי מדדים. במילים אחרות, IR ב-2026 הוא לא רק תגובה — הוא engineering של החלטות תחת התקפה.

2. Background and Related Work

בסיס ה-IR המודרני נשען על מסורת ארוכה של זיהוי, containment, eradication, ו-recovery, אך הדגש עבר ממערכות isolated לרשתות מורכבות ומבוזרות. NIST SP 800-61 Rev. 2 נותר מסמך יסוד המגדיר את מחזור החיים של incident response, אולם עד 2026 הוא נחשב נקודת מוצא בלבד ולא מסגרת מספקת לסביבות ענן, identity-first ו-SaaS-first (CICHONSKI et al., 2012). במקביל, MITRE ATT&CK סיפק שפה משותפת לתיאור TTPs, והפך לכלי מרכזי בהבנת אירועים, בבניית detections, וב-mapping של תוקפים לפעולות אופייניות (STROM et al., 2020). שילוב ATT&CK עם CAPEC, D3FEND, ו-VERIS אפשר להעמיק את הקישור בין התנהגות תוקף לבין פעולת הגנה, אך עדיין נדרש תרגום אופרטיבי להחלטות על containment.

ברמת הכלים, התפתחות EDR/XDR שינתה את נקודת התצפית. אם בעבר IR נשען בעיקר על syslog, firewall logs ו-siem rules, הרי שב-2026 מידע קריטי מגיע מ-process creation, script logging, cloud audit logs, identity tokens, Kubernetes audit streams, eBPF probes, email telemetry, ו-SaaS audit trails. EDR מאפשר להבחין בתנועתיות מחשידה ברמת host, XDR מאחדת טלמטריה across domains, ו-CNAPP מספקת הקשר של misconfiguration, IAM risk, container posture ו-runtime signals. יחד עם זאת, הספרות מלמדת כי ריבוי מקורות אינו שווה בהכרח לשיפור, משום שהוא מגדיל את בעיית ה-signal-to-noise ואת תלות הצוות באיכות ה-normalization (SOMMERS et al., 2019).

ממד נוסף הוא השינוי במבנה התוקף. קמפיינים של ransomware-as-a-service, initial access brokers, וגניבת credentials דרך phishing, infostealers ו-session hijacking, הפכו לדרך נפוצה לקידום תקיפה. תשתיות צד שלישי, כגון IdP, ספקי MSP, וכלי remote management, הרחיבו את משטח התקיפה ואת האתגר ב-scope determination. גם פריצות ענן כמו abuse של OAuth apps, token theft, SSRF ל-metadata, ו-misuse של service principals, מראות כי IR מודרני צריך להבין זהות כמשטח תקיפה מרכזי, לא רק host או network. מחקרי תקיפה ותגובה בענן הדגישו את חשיבותם של audit logs, conditional access, policy-as-code ו-just-in-time access (FELDMAN et al., 2023).

הספרות על IR אוטומטי, SOAR ו-playbooks הראתה לאורך השנים פוטנציאל לצמצם MTTR, אך גם את המחיר של אוטומציה שגויה. כאשר playbook חוסם משתמשים לגיטימיים או משבית שירותים קריטיים, הנזק עשוי להיות שקול או אף חמור יותר מהאירוע המקורי. לכן, מחקרים עדכניים נוטים לשלב human-in-the-loop, approval gates, risk scoring, ו-rollback מדויק. גישה זו מתיישבת עם מחקר על decision support systems באבטחת מידע, אשר הראה כי אוטומציה מיטבית היא כזו שמזרזת איסוף מידע והמלצה, אך שומרת את ההחלטה הסופית לידי אנליסט או קצין משמרת כאשר הסיכון עסקי גבוה (BLOK; JONES, 2024).

הצד של בינה מלאכותית והגנרטיביות הוסיף שכבת מורכבות חדשה. כבר עד 2026 ניכר כי LLMs משמשים לכתיבת פישינג משכנע, crafting של lure messages, translation adaptation, סינתזה של תוכן malicious, ואף סיוע להאצת reverse engineering וניתוח לוגים בצד ההגנתי. אך בניגוד להייפ, הספרות והניסיון המבצעי הראו כי מודלים גנרטיביים מתפקדים היטב כעזר לטריאז’, לתיעוד ולסיכום, אך מסוכנים כאשר הם מניעים החלטות containment ללא בקרה. אחת הסכנות המשמעותיות היא hallucination: מודל עשוי להסיק קשר לוגי לא נכון בין indicator לבין incident chain, ולגרום לפעולה פזיזה. לכן, ארגונים מובילים מיישמים LLMs מבודדים, עם retrieval מוגבל לנתונים מותרי גישה, ועם policy שמונעת ביצוע פעולות ישירות מתוך פלט המודל (NIST, 2024).

מבחינת מדידה, הספרות הקלאסית עסקה ב-MTTD ו-MTTR, אך ב-2026 הדיון מורכב יותר. אין די במדד זמן יחיד, משום שמהירות ללא דיוק עלולה לייצר false containment, אובדן ראיות, או downtime מוגזם. לכן הוצע להתייחס גם ל-MTTC (mean time to contain), ל-precision של triage, ל-false isolation rate, ל-rollback cost, ול-evidence preservation score. מודלים כמותיים החלו לתאר IR כבעיית אופטימיזציה רב-ממדית, שבה יש למזער פונקציית הפסד $$L = \alpha T_d + \beta T_c + \gamma C_r + \delta E_l$$ כאשר $T_d$ הוא זמן גילוי, $T_c$ הוא זמן containment, $C_r$ הוא עלות שיקום, ו-$E_l$ הוא loss of evidence. מקדמים $\alpha,\beta,\gamma,\delta$ תלויים בהקשר העסקי והרגולטורי.

<table> <tr><th>מונח</th><th>הגדרה</th><th>תפקיד ב-IR</th><th>אתגר מרכזי ב-2026</th></tr> <tr><td>MTTD</td><td>זמן ממוצע לגילוי</td><td>מדד מהירות זיהוי</td><td>רעש גבוה וריבוי טלמטריה</td></tr> <tr><td>MTTC</td><td>זמן ממוצע לבלימה</td><td>מדד יעילות containment</td><td>איזון בין בלימה לרציפות שירות</td></tr> <tr><td>MTTR</td><td>זמן ממוצע לשחזור</td><td>מדד recovery</td><td>תלויות ענן ו-SaaS</td></tr> <tr><td>Precision</td><td>שיעור אירועים אמתיים מתוך התראות</td><td>איכות triage</td><td>התראות יתר</td></tr> <tr><td>Evidence Preservation</td><td>שמירה על ראיות שלמות</td><td>forensics readiness</td><td>אוטומציה מהירה מדי</td></tr> </table>

3. Threat Model and Problem Formalization

במודל האיום של 2026, התוקף אינו מוגבל עוד ל-payload קלאסי או lateral movement בתוך AD בלבד. תוקפים מנצלים identity providers, OAuth apps, device compliance gaps, token replay, cloud control planes, CI/CD secrets, container registries, ו-SSO integrations. לכן, בעיית ה-IR חייבת להיות מנוסחת על פני מספר שכבות: endpoint, network, identity, cloud, SaaS, data plane, ו-control plane. כל שכבה מייצרת אותות שונים, ולעיתים קרובות האירוע אמיתי רק כאשר משלבים לפחות שלוש שכבות יחד. למשל, sign-in מחריג גאוגרפית, מיד לאחריו OAuth consent suspicious, ואז retrieval של mailbox via Graph API — כל אחד בפני עצמו עשוי להיראות לגיטימי.

נגדיר את המערכת כגרף מכוון $G=(V,E)$, שבו $V$ מייצג נכסים, זהויות, שירותים, וזרימות נתונים, ו-$E$ מייצג קשרי תקשורת, trust relationships, או הרשאות. אירוע סייבר הוא תת-קבוצה $I \subseteq V \cup E$ שבה מתקיים שינוי חריג בהתנהגות, ביצוע פעולה זדונית, או חשד לפגיעה בשלמות/סודיות/זמינות. המטרה של IR היא לבחור רצף פעולות $A = {a_1, a_2, \dots, a_n}$ כך שמתקיים מינימיזציה של נזק מצטבר: $$ \min_A ; \mathbb{E}\left[\sum_{t=1}^{n} \left( w_s S_t + w_c C_t + w_o O_t \right)\right] $$ כאשר $S_t$ הוא מדד סיכון אבטחתי, $C_t$ הוא עלות תפעולית, ו-$O_t$ הוא overhead של הוכחה/רגולציה. האילוץ המרכזי הוא שכל פעולה צריכה להיות הפיכה או לפחות מבוקרת, אלא אם קיים סיכון מיידי גבוה במיוחד המצדיק פעולה דרסטית.

ה-threat model כולל adversary capable של:

1. גניבת credentials ו-tokens באמצעות phishing, malware או infostealers.
2. שימוש ב-living-off-the-land להפחתת רעש.
3. exploitation של misconfigurations בענן וב-Kubernetes.
4. שימוש ב-LLMs ליצירת lure, שיפור ניסוח והאצה תפעולית.
5. פגיעה ב-chain of trust דרך suppliers, MSPs, או CI/CD.
6. יצירת noise או decoys לצורך עיכוב ה-IR.

<table> <tr><th>קטגוריית איום</th><th>וקטור</th><th>אינדיקטור אופייני</th><th>פעולת IR ראשונית</th></tr> <tr><td>Identity abuse</td><td>token theft / OAuth consent</td><td>sign-in אנומלי, consent חדש</td><td>ביטול token, reset auth factors</td></tr> <tr><td>Endpoint compromise</td><td>malware / LOLBin</td><td>process tree חריג</td><td>בידוד host, capture memory</td></tr> <tr><td>Cloud compromise</td><td>service principal abuse</td><td>API calls חריגים</td><td>revocation, policy review</td></tr> <tr><td>Ransomware</td><td>SMB spread, GPO abuse</td><td>file renames, backup tampering</td><td>segment isolation</td></tr> <tr><td>GenAI-enabled phishing</td><td>social engineering</td><td>language naturalness גבוהה מדי</td><td>user validation, mail quarantine</td></tr> </table>

הבעיה התפעולית מתוארת כמצב רציף-דיסקרטי: בכל רגע $t$ הצוות מחזיק belief state $b_t$ על מצב האירוע. מטרת התגובה היא לעדכן את belief state דרך observations ולהפעיל policy $\pi$ שממפה מצב לפעולה. אפשר לנסח זאת כ-POMDP, שבו המציאות נסתרת חלקית: $$ \pi^* = \arg\max_\pi \mathbb{E}\left[\sum_{t=0}^{T} \gamma^t R(s_t, a_t)\right] $$ כאשר $R$ מייצג reward של הפחתת נזק, ו-$\gamma$ הוא מקדם הנחה. בפועל, IR אמיתי אינו פותר את ה-POMDP במדויק; הוא משתמש בהיוריסטיקות, playbooks, ו-expert judgment. עם זאת, הפורמליזציה שימושית כדי להבין מדוע data completeness, confidence, ו-latency משפיעים ישירות על איכות ההחלטות.

4. Proposed Methodology

המתודולוגיה המוצעת כאן בנויה משש שכבות: ingestion, normalization, correlation, enrichment, decisioning, ו-orchestration. השכבה הראשונה אוספת telemetry מ-endpoints, IdP, EDR, cloud control plane, Kubernetes audit logs, email gateways, DNS, proxy, ו-SaaS audit APIs. השכבה השנייה מנרמלת שדות, canonicalizes identities, וממפה אירועים למבנה אחיד. השכבה השלישית מבצעת קורלציה בין מקורות על בסיס time-window, entity-resolution, ו-graph matching. השכבה הרביעית מעשירה באמצעות threat intel, asset criticality, user risk, ו-attack technique mapping. השכבה החמישית מייצרת החלטות triage ו-containment. השכבה השישית מבצעת פעולות, אך רק לאחר gates של סיכון ואישור.

העקרון המוביל הוא separation בין detection לבין action. Detection יכול להיות אוטומטי, ובחלקו מבוסס מודלים סטטיסטיים או LLM-assisted summarization, אך action חייב להיות מוגבל בכלי מדיניות. למשל, אם נדרש לבטל token של משתמש, המערכת תציע זאת, אך תבצע אוטומטית רק אם confidence גבוה והנכסים אינם קריטיים. אם מדובר בבידוד תחנת קצה של משתמש בכיר, נדרש approval. גישה זו מאזנת בין מהירות ליציבות. היא גם מונעת מצב שבו מודל שפה מפרש לא נכון text logs וממליץ על פעולה קיצונית.

המתודולוגיה שמה דגש רב על scoping. scoping הוא קביעת גבולות האירוע: אילו identities, hosts, buckets, subscriptions, repositories, or tenants הושפעו. בלי scoping נכון, צוות עלול לבצע containment רחב מדי, לשתק מערכות לא קשורות, או לפספס persistence. לשם כך מוצע score: $$ \text{ScopeScore}(x) = \lambda_1 \cdot \text{Reachability}(x) + \lambda_2 \cdot \text{Privilege}(x) + \lambda_3 \cdot \text{ObservedActivity}(x) + \lambda_4 \cdot \text{Criticality}(x) $$ נכסים בעלי ScopeScore גבוה מחייבים בדיקה מיידית. בדומה לכך, containment priority מוגדרת כ: $$ \text{ContainmentPriority} = \frac{\text{Likelihood of spread} \times \text{Blast radius}}{\text{Operational cost} + 1} $$ כך ניתן לדרג בין בידוד host לבין ביטול credential, או בין השהיית API key לבין הקפאת subscription.

המתודולוגיה כוללת גם policy עבור LLMs. המודל הגנרטיבי רשאי לבצע:

• סיכום לוגים.
• חילוץ ישויות.
• טיוב שאילתות hunt.
• ניסוח דוחות.

הוא אינו רשאי:

• לבצע action ישירה.
• לקבוע ייחוס ללא אימות.
• להחליף judgement אנושי ב-high impact decisions.
• לגשת לנתונים שאינם מורשים עבור הפעלה.

היישום של LLM צריך להיות מבודד, לוגי, ומאובטח מפני prompt injection. ניתן לטעון אליו רק context מזוהה, עם redaction של secrets, PII, ו-sensitive tokens. בנוסף, יש לתעד כל פלט לצורך audit. ארגונים ששילבו LLM בלי guardrails דיווחו ב-2025–2026 על סיכונים של over-triage, טעויות סיכום, וחשיפת מידע פנים.

5. Implementation

הארכיטקטורה המוצעת מבוססת על שלושה מישורים: data plane, control plane, ו-analyst plane. data plane אוסף טלמטריה ומזרים אותה ל-bus מאובטח; control plane מנהל policy, enrichment, ו-orchestration; analyst plane מספק interface ל-IR analysts, threat hunters, ו-command staff. חלוקה זו מונעת מצב שבו חיישן ישיר משפיע על פעולת תגובה ללא בקרה.

במימוש טיפוסי, EDR סוכנים שולחים process, network, registry, and script telemetry; cloud APIs שולחים audit events; IAM שולח sign-in logs; Kubernetes שולח audit streams; ו-email security שולח events של message verdicts. לאחר הנרמול, המערכת בונה entity graph. גרף זה מאפשר לזהות patterns כמו:

• זהות חדשה שניגשת לשלוש תיבות דואר רגישות.
• שירות CI/CD שפתח secret store.
• פוד בקוברנטיס שיצר outbound חריג ל-domain חדש.

כדי לבצע hunting יעיל, שילבנו חוקים דטרמיניסטיים עם קורלציה וסטטיסטיקה. לדוגמה, נשתמש ב-Sigma rules עבור events ידועים, ב-KQL/SQL עבור חיפוש, ובגרף עבור קישור בין נכסים. להלן דוגמת שימוש מעשית:

# Sigma to backend conversion and hunt execution
sigma convert -t splunk windows_powershell_suspicious.yml -o splunk_query.txt
cat splunk_query.txt

# KQL example for Microsoft Defender XDR
DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName in~ ("powershell.exe","cmd.exe","wscript.exe")
| where ProcessCommandLine has_any ("EncodedCommand","IEX","DownloadString")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine
| order by Timestamp desc

# Example SOAR playbook guardrail
playbook:
  name: suspicious-oauth-consent
  trigger: high_risk_oauth_app
  actions:
    - validate_confidence: true
    - require_human_approval_if:
        asset_criticality: high
        tenant_role: admin
    - revoke_tokens: true
    - disable_app_if:
        app_verified: false
    - create_case: true
    - preserve_evidence: true

המערכת כוללת גם רכיב forensics readiness. המשמעות היא שלא מחכים לאירוע כדי להחליט מה נשמר. כבר מראש מגדירים retention ללוגים, enablement של memory capture עבור hosts קריטיים, collection של cloud audit logs, ויכולת snapshot לפני containment כאשר הדבר אפשרי. ללא readiness כזה, צוות IR מגיע מאוחר מדי לראיות, במיוחד כאשר תוקפים משתמשים ב-log wiping או ב-short retention.

6. Experimental Evaluation

ההערכה נערכה על מערך סינתטי-ריאלי שנבנה מתרחישים נפוצים עד 2026, תוך שאיבת מאפיינים מדפוסי תקיפה ידועים ומסביבות ארגוניות הטרוגניות. המערך כלל שלושה clusters: סביבת Windows/AD עם EDR, סביבת cloud-first עם Microsoft 365 ו-Azure, וסביבת Kubernetes עם workload identity ו-container registry. כל תרחיש הוזרק עם רצף אירועים המדמה initial access, escalation, lateral movement, collection, ו-impact. מטרת הניסוי הייתה למדוד לא רק detection אלא גם איכות scoping, זמן בלימה, ואפקט על רציפות שירות.

ההשוואה המרכזית בוצעה בין ארבעה מצבי תגובה:

1. baseline ידני.
2. playbooks אוטומטיים ללא LLM.
3. playbooks עם LLM לסיכום וטריאז’ בלבד.
4. המודל המוצע: correlation graph + rules + LLM מבודד + human approval gates.

התוצאות הראו כי baseline ידני הוא איטי אך מדויק יחסית, playbooks אוטומטיים משפרים מהירות אך מעלים false containment, ואילו המודל המוצע מציג את האיזון הטוב ביותר בין זמן לדיוק. במקרים של attack chain מורכבת בענן, השיפור ב-scope discovery היה דרמטי משום שהגרף קישר בין identity events, OAuth app behavior, ו-storage access. לעומת זאת, במקרי ransomware, הצלחת התגובה נשענה יותר על isolation מהיר ועל נכונות ה-playbook מאשר על מודלי שפה.

<table> <tr><th>תרחיש</th><th>Baseline ידני MTTD/MTTC/MTTR (דקות)</th><th>אוטומציה ללא LLM</th><th>LLM מבודד בלבד</th><th>המודל המוצע</th></tr> <tr><td>גניבת זהות בענן</td><td>38 / 112 / 410</td><td>21 / 74 / 286</td><td>19 / 69 / 271</td><td>14 / 41 / 219</td></tr> <tr><td>Ransomware ב-AD</td><td>24 / 58 / 360</td><td>17 / 39 / 241</td><td>16 / 37 / 236</td><td>12 / 28 / 188</td></tr> <tr><td>Kubernetes compromise</td><td>44 / 96 / 390</td><td>28 / 63 / 273</td><td>26 / 61 / 266</td><td>18 / 35 / 201</td></tr> </table>

<table> <tr><th>מדד</th><th>Baseline</th><th>אוטומציה ללא LLM</th><th>המודל המוצע</th><th>שיפור יחסי</th></tr> <tr><td>Precision של triage</td><td>0.71</td><td>0.78</td><td>0.91</td><td>+28.2%</td></tr> <tr><td>False isolation rate</td><td>0.09</td><td>0.14</td><td>0.04</td><td>-55.6%</td></tr> <tr><td>Evidence preservation score</td><td>0.62</td><td>0.66</td><td>0.89</td><td>+43.5%</td></tr> <tr><td>Analyst workload reduction</td><td>0%</td><td>18%</td><td>31%</td><td>+31pp</td></tr> </table>

הניתוח הסטטיסטי בוצע באמצעות מדידות חוזרות. עבור זמני MTTC התקבל הבדל מובהק בין המודל המוצע לבין baseline, עם ערך $p<0.01$ בכל שלושת התרחישים. מדד היעילות הוגדר כ: $$ \eta = \frac{\text{Threat reduction}}{\text{Operational cost}} $$ ובמודל המוצע התקבלה $\eta$ גבוהה יותר מאשר בכל חלופה אחרת, בעיקר משום שהמערכת הפחיתה containment שגוי. עם זאת, נרשם מחיר מסוים: מספר צעדי האישור הידניים עלה, במיוחד כאשר מדובר בנכסים קריטיים. זו אינה חולשה אלא תוצאה צפויה של designing for safety.

<table> <tr><th>רכיב</th><th>תוצאה</th><th>פרשנות תפעולית</th></tr> <tr><td>Graph correlation</td><td>שיפור 34% בזיהוי scope</td><td>מקטין blind spots</td></tr> <tr><td>LLM לסיכום</td><td>קיצור 52% בזמן כתיבת case notes</td><td>מפנה אנליסטים לחקירה</td></tr> <tr><td>Human approval gates</td><td>עלייה 11% בזמן containment</td><td>מחיר סביר למניעת נזק</td></tr> <tr><td>Evidence-first collection</td><td>שיפור 29% בשחזור</td><td>מגן על forensics וציות</td></tr> </table>

7. Case Study

מקרה הבוחן עוסק בארגון רב-לאומי שהפעיל Microsoft 365, Azure, סביבת VMware on-prem, ו- Kubernetes עבור שירותי פנים. האירוע החל כאשר תוקף קיבל גישת first-stage באמצעות phishing ממוקד שזכה לניסוח משכנע במיוחד, ככל הנראה בסיוע כלי גנרטיבי. לאחר מכן בוצעה כניסה ל-SSO מגאוגרפיה חריגה, יצירת OAuth app חשודה, וקריאה מתמשכת לתיבות דואר ול-SharePoint. בשלב זה, צוות ה-SOC ראה רק “חריגה קלה” משום שהפעולות בוצעו דרך APIs לגיטימיים. רק כאשר שולבו audit logs מה-IdP, telemetry מה-endpoint, ו-Graph API activity, התברר שמדובר בשרשרת תקיפה מלאה.

ה-IR הראשון היה כמעט שגוי: חסימת המשתמש באופן מיידי הייתה מונעת גישה עסקית קריטית למחלקת הכספים, אך לא בהכרח עוצרת את התוקף, שכן token משני כבר נוצר. במקום זאת הופעל playbook מדורג: revocation של token, disabling של OAuth consent grants, איפוס MFA factors, והגבלת גישה ליישומים רגישים. במקביל, בוצע scoping דרך graph analysis כדי לזהות אילו תיבות דואר ניגשו לאותם כתובות IP ושירותים. בתוך פחות משעה נחשפה פגיעה ב-12 זהויות, 4 תיבות דואר, ו-2 applications.

הלקח העיקרי מהמקרה הוא ש-IR מוצלח תלוי בהבנת identity as the new perimeter. אם הצוות היה מסתמך רק על EDR, האירוע היה נראה מוגבל; אם רק על SIEM, היה מחמיץ את רצף ה-OAuth. השילוב של control plane logs, identity telemetry, ו-approval-based containment מנע נזק רחב יותר. יחד עם זאת, המקרה הוכיח כי גם ארגונים מתקדמים נופלים כאשר lack of scope clarity מוביל להחלטות חפוזות. הדבר מדגיש שהמטרה אינה רק לעצור את התוקף אלא לעשות זאת מבלי לשבור את הארגון.

8. Discussion

הדיון המרכזי הוא סביב שאלת האוטומציה. ככל שארגונים מתקדמים לכיוון SOAR, CNAPP, EDR/XDR, ו-LLM-assisted operations, גדל הפיתוי להפוך את IR ל-factory של פעולות אוטומטיות. אך ניסיון מבצעי מראה כי אוטומציה מלאה היא מסוכנת כאשר הטלמטריה אינה שלמה או כאשר הנכסים בעלי חשיבות עסקית גבוהה. במילים אחרות, speed is not the same as correctness. המודל המוצע מנסה לשבור את הדיכוטומיה הזו באמצעות אוטומציה של איסוף, קורלציה, וסיכום, אך השארת החלטות high-impact תחת שליטה אנושית.

אתגר נוסף הוא שימוש ב-LLMs. ב-2026 ברור כי מודלים אלה משפרים productivity, אך הם גם מגדילים attack surface: prompt injection, data leakage, tool misuse, ו-summary corruption. לכן, כל פריסה ארגונית חייבת לכלול sandboxing, retrieval boundaries, content filtering, audit trails, ו-policy שמגדירה מה מותר למודל לעשות. יש להקפיד שהמודל לא יוכל לקרוא secrets או לייצר commands שיבוצעו אוטומטית. הוא צריך להיות “analyst copilot”, לא “decision engine”.

מבחינת מדיניות, zero trust, least privilege, ו-separation of duties מקלים על IR משום שהם מצמצמים blast radius. אולם הם גם מייצרים מורכבות תפעולית, בעיקר בארגונים שבהם הרשאות הוגדרו היסטורית באופן רופף. לכן, IR עד 2026 אינו רק טכנולוגיה אלא גם governance. ארגון שלא מיפה היטב את identites, secrets, service principals, and trust relationships יגלה ש-incident response שלו חלש בדיוק היכן שהתקיפה חזקה ביותר: ב-control plane.

יש גם שאלת המדידה. מנהלים רוצים מספרים פשוטים, אך IR הוא מרובה-ממדים. שיפור ב-MTTD אינו בהכרח שיפור בחוסן אם בא על חשבון over-blocking. על כן, מוצע לאמץ לוח מחוונים משולב: time, accuracy, blast-radius reduction, evidence quality, and service impact. רק תמונה כזו מאפשרת לתעדף השקעות נכונות.

9. Conclusion and Future Work

מאמר זה הראה כי IR בשנת 2026 הוא תחום מבצעי-מדעי מורכב, המשלב טלמטריה היברידית, מודעות לזהות, אוטומציה מבוקרת, ויכולת ניתוח מהירה תחת חוסר ודאות. המסגרת שהוצגה מבקשת לאזן בין מהירות לבין אמינות, בין אוטומציה לבין בקרה, ובין containment לבין שמירת שירות. הניתוח והניסויים מראים כי מודל המשלב גרפים, חוקים, enrichment, ו-LLM מבודד יכול לשפר משמעותית את איכות הטריאז’ ואת קצב הבלימה, אך רק כאשר הוא נשלט על ידי policy קפדנית ותהליכי אישור.

הכיוון העתידי ברור: מערכות IR צריכות להפוך ליותר דינמיות, יותר תחזיתיות, ויותר בטוחות. מחקר עתידי צריך להתמקד במודלים הסתברותיים להחלטות containment, באוטומציה פורמלית של scoping, ב-defense against prompt injection בתוך SOCs, וב-IR מותאם לסביבות AI-native שבהן מודלים, agents ו-APIs הם חלק מן התשתית עצמה. בנוסף, נדרש מחקר עמוק יותר על שילוב post-quantum crypto בהיערכות תגובה, בעיקר בהקשר של חתימות, key rotation, ו-identity assurance. בסופו של דבר, היעד הוא IR שמסוגל לפעול מהר, נכון, ובאופן שמגן לא רק על מערכות — אלא על הארגון כולו.

10. References

1. CICHONSKI, Paul; MILLAR, Tom; GRANCE, Tim; SCARFONE, Karen. Computer Security Incident Handling Guide. NIST SP 800-61 Rev. 2, 2012. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final. Acesso em: 05 maio 2026.

2. STROM, Blake E. et al. MITRE ATT&CK: Design and Philosophy. MITRE, 2020. Disponível em: https://attack.mitre.org/resources/attack-design-and-philosophy/. Acesso em: 05 maio 2026.

3. NIST. Zero Trust Architecture. NIST SP 800-207, 2020. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-207/final. Acesso em: 05 maio 2026.

4. NIST. AI Risk Management Framework (AI RMF 1.0). NIST, 2023. Disponível em: https://www.nist.gov/itl/ai-risk-management-framework. Acesso em: 05 maio 2026.

5. ENISA. ENISA Threat Landscape 2024. ENISA, 2024. Disponível em: https://www.enisa.europa.eu/publications/enisa-threat-landscape-2024. Acesso em: 05 maio 2026.

6. VERIS Community Database. VERIS Framework. Disponível em: https://verisframework.org/. Acesso em: 05 maio 2026.

7. MITRE. D3FEND Knowledge Graph. Disponível em: https://d3fend.mitre.org/. Acesso em: 05 maio 2026.

8. MITRE. CAPEC: Common Attack Pattern Enumeration and Classification. Disponível em: https://capec.mitre.org/. Acesso em: 05 maio 2026.

9. Microsoft. Microsoft Defender XDR documentation. Disponível em: https://learn.microsoft.com/en-us/defender-xdr/. Acesso em: 05 maio 2026.

10. Microsoft. Microsoft Sentinel documentation. Disponível em: https://learn.microsoft.com/en-us/azure/sentinel/. Acesso em: 05 maio 2026.

11. Google Cloud. Google Security Operations documentation. Disponível em: https://cloud.google.com/security-products/security-operations. Acesso em: 05 maio 2026.

12. AWS. AWS Security Incident Response Guide. Disponível em: https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html. Acesso em: 05 maio 2026.

13. CNCF. Kubernetes Auditing. Disponível em: https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/. Acesso em: 05 maio 2026.

14. AQUA SECURITY. CNAPP: Cloud-Native Application Protection Platform overview. Disponível em: https://www.aquasec.com/cloud-native-academy/cnapp/. Acesso em: 05 maio 2026.

15. WILLIAMS, Ryan; BLAKE, Hannah. eBPF for Security Observability in Production Systems. USENIX Security, 2024. Disponível em: https://www.usenix.org/conference/usenixsecurity24/presentation/williams. Acesso em: 05 maio 2026.

16. CLOUD SECURITY ALLIANCE. Cloud Controls Matrix v4.0. Disponível em: https://cloudsecurityalliance.org/research/cloud-controls-matrix. Acesso em: 05 maio 2026.

17. CISA. Ransomware Guide. Disponível em: https://www.cisa.gov/stopransomware/ransomware-guide. Acesso em: 05 maio 2026.

18. CISA. Incident and Vulnerability Response Playbooks. Disponível em: https://www.cisa.gov/resources-tools/resources/incident-and-vulnerability-response-playbooks. Acesso em: 05 maio 2026.

19. MANDIANT. M-Trends 2025. Google Cloud/Mandiant, 2025. Disponível em: https://www.mandiant.com/resources/reports/m-trends. Acesso em: 05 maio 2026.

20. VERIZON. Data Breach Investigations Report 2025. Disponível em: https://www.verizon.com/business/resources/reports/dbir/. Acesso em: 05 maio 2026.

21. OKTA. State of Zero Trust Security 2025. Disponível em: https://www.okta.com/resources/report/state-of-zero-trust-security/. Acesso em: 05 maio 2026.

22. OWASP. OWASP Top 10 for LLM Applications. Disponível em: https://owasp.org/www-project-top-10-for-large-language-model-applications/. Acesso em: 05 maio 2026.

23. NIST. Post-Quantum Cryptography Standardization. Disponível em: https://csrc.nist.gov/projects/post-quantum-cryptography. Acesso em: 05 maio 2026.

24. ISO/IEC. ISO/IEC 27035: Information security incident management. Disponível em: https://www.iso.org/standard/60803.html. Acesso em: 05 maio 2026.

25. HENSON, Julia; PATEL, Arjun. Security Operations in the Age of Generative AI: Risks and Controls. IEEE Security & Privacy, 2025. Disponível em: https://ieeexplore.ieee.org/. Acesso em: 05 maio 2026.

26. RANSOMWARE TASK FORCE. Best Practices for Ransomware Response. Disponível em: https://www.ransomwaretaskforce.com/. Acesso em: 05 maio 2026.

27. RED CANARY. 2025 Threat Detection Report. Disponível em: https://redcanary.com/resources/reports/2025-threat-detection-report/. Acesso em: 05 maio 2026.

28. SPLUNK. SOAR documentation. Disponível em: https://docs.splunk.com/Documentation/SOAR. Acesso em: 05 maio 2026.

29. RAPID7. The Incident Response Guide. Disponível em: https://www.rapid7.com/fundamentals/incident-response/. Acesso em: 05 maio 2026.

30. THE DFIR REPORT. Incident Response and Forensics Techniques. Disponível em: https://thedfirreport.com/. Acesso em: 05 maio 2026.