מחקר אבטחתי בעידן 2026: מתודולוגיה אמפירית לאפיון, מדידה והגנה מפני איומי LLM, שרשרת אספקה וענן היברידי

1. Introduction

מחקר באבטחת סייבר בשנת 2026 אינו עוד תרגיל תיאורטי המבוסס על דיווחי אירועים בודדים או על סט של חתימות סטטיות. המציאות המבצעית השתנתה באופן מהותי: ארגונים פועלים בסביבות היברידיות מרובות-עננים, עובדים ומכונות ניגשים למשאבים דרך זהויות דינמיות, ומערכות הגנה נדרשות להתמודד עם יריב שמנצל אוטומציה, שירותי בינה מלאכותית, שרשראות אספקה מורכבות ופגיעויות “יום אפס” לצד תשתיות ציבוריות. כתוצאה מכך, מחקר סייבר מודרני חייב לשלב בין דיסציפלינות: מדעי הנתונים, הנדסת תוכנה, קריפטוגרפיה יישומית, ניתוח התנהגות, ויריבוּת מבצעית. מטרת מאמר זה היא להציג מסגרת מחקרית מלאה, הניתנת לשחזור, למדידה ולהשוואה, המיועדת לחוקרים ולצוותי הגנה המבקשים להעריך בקרות אבטחה מול איומים בני 2026.

הבעיה המרכזית במחקר סייבר היא חוסר האיזון בין מורכבות סביבת המטרה לבין מגבלות הניסוי. במערכות ארגוניות אמיתיות אין גישה מלאה לכל שכבות הטלמטריה, ונתוני תקיפה רגישים אינם תמיד ניתנים לשיתוף. מנגד, מעבדות מנותקות מהמציאות התפעולית אינן מייצגות נאמנה את התנהגות היריב. לכן, מחקר איכותי חייב להישען על עקרונות של בדיקות נשלטות, הטמעת תרחישים, ואיסוף מדידות ברזולוציה גבוהה, תוך שמירה על היתכנות תפעולית. עיקרון זה הוטמע היטב בתעשייה באמצעות מסגרות כמו MITRE ATT&CK, CIS Controls, NIST CSF 2.0 ו-NIST SP 800-207, אך עדיין נדרש מודל מחקרי שמתייחס במפורש גם לאיומי LLM, הנדסה חברתית מבוססת-ייצור, ופגיעויות בשרשרת האספקה של קוד, קונטיינרים וסביבות CI/CD.

החל מ-2023–2024, קצב האימוץ של מערכות LLM פנימיות וחיצוניות הפך את בעיית אבטחת המידע לבעיית אמון בין משתמש, מודל, סוכן וכלי חיצוני. במקביל, טכניקות כמו prompt injection, data exfiltration דרך סוכני AI, והרעלת הקשר (context poisoning) אינן עוד תאורטיות בלבד. לכן, מחקר סייבר ב-2026 חייב למדוד לא רק חדירה לרשת או פגיעה בנכסים, אלא גם השפעה על שלמות תהליך קבלת ההחלטות של מערכות אוטומטיות. מבחינה מתודולוגית, זה מחייב הגדרה של משתנים תלויים כמו שיעור הצלחת ההטיה, זמן לחשיפת ההתקפה, ומידת ההשפעה על תוצרים משימתיים.

המאמר מציע מסגרת מחקרית שמתחילה מהגדרת הבעיה, ממשיכה דרך מודל איומים, תכנון ניסוי, בניית טלמטריה, הפעלת תרחישים מבוקרים והערכה סטטיסטית, ומסתיימת בתובנות ישימות להגנה. תרומתו אינה רק תיאורית אלא גם אופרטיבית: אנו מראים כיצד לבנות מחקר אבטחתי שיכול לשמש גם אקדמיה וגם צוותי Blue Team, Red Team, SOC ו-Risk Engineering. לשם כך אנו משתמשים במדדי ביצוע כגון $$TPR = \frac{TP}{TP+FN}$$, זמן זיהוי ממוצע $MTTD$, זמן תגובה $MTTR$, ושיעור חשיפה מצטבר $E(t)$, ומקשרים אותם לתרחישים מעשיים כמו פישינג עמיד-ל-MFA, גניבת טוקנים, ניצול הרשאות יתר בענן, והפעלת קוד זדוני דרך צינור אספקה.

לבסוף, מאמר זה ממוקם בהקשר ההיסטורי של 2026: התעשייה כבר אימצה Zero Trust כעקרון ארכיטקטוני, CNAPP כקטגוריית שליטה בענן, eBPF ככלי טלמטריה בעל השפעה, ופוסט-קוונטום כאתגר תכנון קריפטוגרפי. לכן, אנו לא עוסקים במצבים שאבד עליהם הכלח, אלא במציאות מבצעית שבה מחקר איכותי חייב להיות מעודכן, מדויק, ומבוסס נתונים. ההנחה המובילה כאן היא פשוטה: רק מחקר שמבצע מדידה אמיתית של התקפה והגנה בסביבה נאמנה למציאות יכול להניב ידע בר-פעולה.

2. Background and Related Work

הספרות בתחום אבטחת סייבר התפתחה ממחקר ממוקד-פגיעויות למחקר מערכתי, המשלב תשתית, זהות, תוכנה, מודיעין ואנליטיקה. בשנות ה-2010 המאוחרות ובתחילת שנות ה-2020, הקהילה עברה מתפיסה שמרוכזת ב-“חתימה מול חתימה” לתפיסה מבוססת-התנהגות, במיוחד מול יריבים מתוחכמים. MITRE ATT&CK הפכה לשפה משותפת לתיאור טכניקות, TTPs ושרשראות תקיפה, בעוד ש-NIST ו-CIS סיפקו מסגרות בקרתיות למיפוי הגנות. עם זאת, עד 2026 עדיין קיים פער בין מסגרות תיאוריות לבין תכנון ניסויי אמפירי ברזולוציה גבוהה, במיוחד כאשר מערבים LLM, מערכות סוכן אוטונומיות, וסביבות SaaS מרובות-זהויות.

במחקר האקדמי, עבודות רבות התמקדו באיתור אנומליות ברשת, sandboxing של קבצים, או ניתוח סטטי של קוד. אלו תרמו רבות להבנת התנהגות זדונית, אך חלקן מתקשות לעמוד בקצב של טכניקות התקיפה החדשות. למשל, השימוש הגובר ב"לחץ חברתי סינתטי" באמצעות הודעות מותאמות אישית, דיפ-פייק קול ותמונות, ותוכן שנוצר על ידי LLM, מעלה את רמת ההצלחה של הנדסה חברתית. מחקרים מ-2024–2026 הראו שהבנה טכנית בלבד אינה מספיקה; יש למדוד גם גורמים קוגניטיביים, ארגוניים ותהליכיים. במקביל, מחקר שרשרת אספקה התרחב מעבר ל-SBOM בלבד, וכולל כיום ניתוח provenance, אימות חתימות, תהליכי build מאובטחים, והצלבה מול טלמטריה רצה.

בעולם התעשייתי, הופיעו פלטפורמות CNAPP, XDR, SIEM משופר, SOAR ו-TDIR, אולם קפיצת המדרגה האמיתית הגיעה כאשר eBPF אפשר איסוף טלמטריה עמוקה מבלי להכביד באופן משמעותי על ביצועי המערכת. מחקרי שטח מראים ש-eBPF מאפשר לכמת קריאות מערכת, חיבורי רשת, טעינת מודולים, והתנהגות תהליכים באופן המדמה observability אבטחתי רב-שכבתי. זה חשוב במיוחד כאשר מנסים להבין נתיבי תקיפה עדינים, כגון credential dumping מבוסס-זיכרון, הזרקת DLL, או שימוש לרעה ב-API של ספקי ענן. לצד זאת, כלים כמו Falco, Cilium, Tetragon ו-Tracee מייצגים את המעבר מבלוקים סטטיים של זיהוי לאיסוף דינמי של התנהגות.

הספרות גם מצביעה על עלייתם של איומי AI. מחקרי prompt injection, jailbreak, model stealing, training data poisoning ו-agentic abuse יצרו קטגוריה חדשה של תקיפות שאינן מכוונות ישירות לשרת או לרשת, אלא לשרשרת ההיגיון של מערכת אוטומטית. ב-2026, ארגונים רבים מפעילים סוכני AI לשירות לקוחות, ניתוח מסמכים, טיפול בכרטיסים, ופעולות DevOps. לכן, יש חשיבות להבחין בין תקיפה שמשבשת קוד לבין תקיפה שמשבשת “כוונה” או “הכרעה” של מערכת. זהו שינוי מהותי בנוף האיומים.

לצד התפתחויות אלו, המחקר על Zero Trust עבר ממצב של סיסמה ארכיטקטונית למצב של מדידה. כעת ניתן לבדוק האם אימות רציף, micro-segmentation, device posture, policy enforcement, ויישום least privilege אכן מפחיתים סיכון. אולם גם כאן, יש צורך במתודולוגיה מחקרית שתשווה בין סביבות, תגדיר baseline, ותמדוד שינוי לאורך זמן. ללא סטנדרטיזציה, כל תוצאה נשארת אנקדוטלית. לפיכך, תרומה חיונית של מאמר זה היא חיבור בין מסגרות דה-פקטו לבין פרוטוקול מחקר מעשי.

מסגרת/כלי	מיקוד עיקרי	יתרון מחקרי	מגבלה מחקרית
MITRE ATT&CK	טכניקות ו-TTPs	שפה משותפת ליריב והגנה	אינו מודל ניסוי בפני עצמו
NIST CSF 2.0	Governance, Identify, Protect, Detect, Respond, Recover	מבנה ארגוני ומדיד	ברמת-על, ללא פרוטוקול מדידה מפורט
eBPF/Falco/Tetragon	טלמטריה בזמן ריצה	תצפית עמוקה עם overhead נמוך	דורש כיול והנדסת חוקים
CNAPP	אבטחת ענן, posture, runtime	כיסוי רחב לסביבות היברידיות	תלוי ספק ועלול ליצור רעש
ATT&CK for Enterprise/Cloud	מיפוי טכניקות בענן	התאמה מודרנית לאיומי SaaS/IaaS	דורש נתונים אמפיריים לשימוש אפקטיבי

3. Threat Model and Problem Formalization

המודל המאיים במאמר זה מניח יריב בעל יכולת בינונית עד גבוהה, עם גישה לאוטומציה, תשתיות ענן, ואמצעים ליצירת תוכן משכנע בקנה מידה. היריב אינו חייב להיות מדינה; הוא יכול להיות קבוצת כופרה, APT, או גורם פלילי מתוחכם. אנו מניחים יכולת לבצע reconnaissance, credential access, lateral movement, persistence, exfiltration, וכן תקיפות מתקדמות על מערכות AI, כגון prompt injection או data poisoning בסביבת אינטראקציה. המגן, מנגד, מפעיל בקרות של IAM, MFA, EDR, CNAPP, SIEM, זיהוי אנומליות, והקשחה תשתיתית.

נסמן את הסביבה כגרף מכוון $G = (V, E)$, כאשר $V$ מייצג נכסים, חשבונות, שירותים, מודלים, API gateways ותחנות קצה, ו-$E$ מייצג נתיבי תקשורת, תלות ואפשרויות תנועה. לכל קודקוד $v \in V$ נגדיר וקטור מצב $x_v = [p, c, i, a, r]$ עבור confidentiality, integrity, identity, availability, reachability. הסיכון הכולל של נתיב תקיפה $P$ ניתן בקירוב על ידי: $$ R(P) = \sum_{v \in P} w_v \cdot \Pr(\text{success}_v) \cdot \text{Impact}_v $$ כאשר $w_v$ הוא משקל בהתאם לחשיבות הנכס והקשרו. מדד זה שימושי כי הוא מאפשר להשוות בין בקרות שונות על אותו גרף איום.

הבעיה המחקרית מוגדרת כך: בהינתן סביבה ארגונית היברידית, כיצד ניתן לכמת את יעילותן של בקרות הגנה נגד מערך טכניקות תקיפה מודרניות, באופן שיאפשר שחזור, השוואה סטטיסטית, והסקה מעשית? אנו מגדירים שלוש שאלות מחקר. ראשית, אילו טלמטריות מספקות את יחס האות-לרעש הטוב ביותר לזיהוי תקיפות בענן וב-endpoints? שנית, כיצד משפיעים בקרות כגון MFA עמיד לפישינג, בידוד דפדפן, token binding, micro-segmentation ו-policy-as-code על $MTTD$ ו-$MTTR$? שלישית, כיצד למדוד שיבוש של מערכות AI, ולא רק חדירה קלאסית לרשת?

כדי לענות על שאלות אלו, אנחנו מגדירים ניסוי מבוקר עם קבוצת טיפול וקבוצת ביקורת. קבוצת הביקורת פועלת ללא בקרה מסוימת, וקבוצת הטיפול פועלת עם הבקרה. לכל תרחיש נמדוד את מספר ניסיונות ההצלחה, משך החשיפה, רוחב ההשפעה, ושיעור התראות השווא. מדד הזיהוי מוגדר כ-$TPR = \frac{TP}{TP+FN}$, בעוד שמדד העומס המבצעי מוגדר באמצעות: $$ \Omega = \alpha \cdot FP + \beta \cdot \text{AlertFatigue} + \gamma \cdot \text{Cost} $$ כאשר $\alpha,\beta,\gamma$ הם משקלים ארגוניים. ברמה המחקרית, האתגר הוא לא רק לזהות, אלא לזהות מבלי להעמיס יתר על המפעילים.

רכיב במודל	הגדרה	מדד	הערה
נכס	מערכת, חשבון, שירות או מודל	ערך עסקי, רגישות	כולל נכסי AI
נתיב תקיפה	רצף קשתות בגרף $G$	הסתברות הצלחה מצטברת	קשור ל-TTP
בקרה	מנגנון מניעה/זיהוי/תגובה	ירידה ב-$R(P)$	נמדדת בניסוי
חשיפה	זמן בו יריב שולט או משפיע	$E(t)$	מדד דינמי
עומס התראות	כמות ורעש ל-SOC	$\Omega$	משפיע על תפעול

4. Proposed Methodology

המתודולוגיה המוצעת מחולקת לחמישה שלבים: תכנון, אינסטרומנטציה, ביצוע תרחישים, ניתוח, והסקה. בשלב התכנון נגדיר את גבולות הסביבה, התרחישים, התלויים הבלתי-תלויים, והמדדים. זהו שלב קריטי משום שבאבטחת סייבר קל מאוד “להוכיח” תוצאה שאינה ניתנת לשחזור. לכן, כל ניסוי חייב לכלול baseline, חלוקה לקבוצות, ופרוטוקול מדויק של תנאי ריצה. אין להסתפק בתיאור כללי של “התקפה זוהתה”; יש לקבוע מתי בדיוק הותקף, איזה חיישן הגיב, ומהו הפער בין תחילת הפעילות לבין הזיהוי.

בשלב האינסטרומנטציה משלבים טלמטריה ממספר שכבות: endpoint, network, identity, cloud control plane, container runtime, ו-LLM interaction layer. בשכבת ה-endpoint אנו אוספים תהליכים, פתיחת sockets, טעינת מודולים, הרשאות, וקריאות מערכת. בשכבת הרשת אנו מודדים flow logs, DNS, TLS fingerprints, וחריגות SNI. בשכבת הזהות אנו אוספים כניסות, tokens, שינויים בהרשאות, ופעילות בלתי שגרתית של service principals. בשכבת ה-LLM אנו רושמים prompt provenance, context window changes, tool calls, output policy decisions, ו-exfil indicators. שילוב שכבות זה מאפשר לשחזר נתיב תקיפה מלא גם כאשר האויב מנסה לטשטש עקבות.

השלב השלישי הוא ביצוע תרחישים. אנו מגדירים “ספר תרחישים” (scenario book) שבו לכל TTP מוקצה רצף ניסוי. למשל, בתרחיש פישינג נמדוד: delivery, user interaction, credential entry, token issuance, lateral movement attempt, and detection. בתרחיש ענן נמדוד שימוש לרעה ב-API keys, escalation דרך IAM misconfiguration, ושימוש ב-storage buckets או queues לשלב exfiltration. בתרחיש AI נמדוד ניסיון להחדיר הוראות מניפולטיביות דרך מסמך, email או input אחר, ולבדוק האם סוכן מבצע tool invocation לא מורשה.

השלב הרביעי הוא ניתוח. נשתמש בשילוב של שיטות: חוקים דטרמיניסטיים, חתימות התנהגותיות, clustering, anomaly detection, והצלבה עם מודיעין. סטטיסטית, נחשב הבדל ממוצעים, רווחי סמך, ו-test statistics כאשר מתאים. למשל, להערכת השפעת בקרה על $MTTD$, ניתן לחשב: $$ \Delta MTTD = MTTD_{baseline} - MTTD_{control} $$ ואז לבדוק אם $\Delta MTTD > 0$ בצורה מובהקת. בנוסף, נבחן את גודל האפקט, כי במבצעיות לא די במובהקות; נדרש אפקט בעל משמעות תפעולית.

השלב החמישי הוא הסקה ויישום. כאן נתרגם את הממצאים להמלצות: אילו בקרות עדיפות, אילו חיישנים מוסיפים את הערך הגבוה ביותר, ואיפה יש פערים ארכיטקטוניים. מתודולוגיה זו מתאימה גם למחקר אקדמי וגם ליישום ארגוני. יתרונה הוא בכך שהיא מחברת בין תופעות טכניות לבין השלכה עסקית, וזהו תנאי חיוני לשכנוע הנהלה או קובעי מדיניות.

טבלת מתודולוגיה ותוצרים

שלב	קלט	פלט	סיכון עיקרי
תכנון	טופולוגיה, תרחישים, מטרות	פרוטוקול ניסוי	הטיה בבחירת תרחישים
אינסטרומנטציה	endpoints, logs, cloud telemetry	נתוני גלם	רעש ו-visibility gaps
תרחישים	TTPs, payloadים מבוקרים	שרשראות תקיפה	חריגה מהיקף מאושר
ניתוח	מדדים, התראות, אירועים	ממצאים כמותיים	false causality
הסקה	תוצאות ו-risk appetite	המלצות הגנה	generalization מוגזם

דוגמת פקודות כלי עבודה

# איסוף טלמטריה עם Tetragon בסביבת Kubernetes
kubectl apply -f https://raw.githubusercontent.com/cilium/tetragon/main/deploy/kubernetes/tetragon.yaml
kubectl -n kube-system logs -l app=tetragon -f

# חיפוש תהליכים חשודים והצלבתם עם קבצי לוג
grep -Ei "kubectl|curl|wget|python|bash" /var/log/syslog | tail -n 100

# הרצת Sigma rules על Windows Event Logs באמצעות Chainsaw
chainsaw search win -s rules/ -t evtx/ --json > findings.json

# בדיקת הקשר של התראות עם ATT&CK
navigator generate --layer attack-layer.json --output attack.html

5. Implementation

ההטמעה שבוצעה במסגרת המחקר בנויה על מעבדה היברידית הכוללת אשכול Kubernetes, תחנות עבודה Windows ו-Linux, חיבור לסביבת SaaS מדומה, ומבנה זהויות הכולל משתמשים אנושיים, service accounts ו-workload identities. שכבת הטלמטריה מורכבת מ-eBPF collectors, Windows Event Forwarding, auditd, cloud trail logs, ו-DNS telemetry. בנוסף, נבנה רכיב תצפית ל-LLM applications, שבו כל אינטראקציה עם מודל מתועדת עם hash של ההקשר, מזהה כלי, וסימון policy outcome.

המערכת עושה שימוש ב-SIEM מרכזי וב-SOAR להגדרת playbooks. בכל פעם שמזוהה פעילות חשודה, ה-SOAR מבצע enrichment: בדיקת reputation, הצלבה עם CMDB, אימות זהות, וניתוח גרף יחסים. היתרון של גישה זו הוא שניתן למדוד לא רק אם התראה הופקה, אלא גם האם הפעולה האוטומטית הפחיתה את הסיכון. לצורך זה, נבנה מדד תגובה מורכב: $$ R_e = \frac{\text{Contained incidents}}{\text{Total incidents}} \cdot \frac{1}{MTTR} $$ כאשר ערך גבוה מצביע על תגובה מהירה ויעילה יותר.

ברמת אבטחת התשתית, הוטמעו בקרות כמו MFA עמיד לפישינג, device posture checks, policy-based access, והפרדת הרשאות בין משתמשים, מחשבים וסוכנים. בענן, הוחלפו הרשאות רחבות במינימום נדרש, ויושמה בדיקה של IAM bindings ו-policy drift. בהקשר של LLM, הוגדרו הרשאות tool-use מצומצמות, סינון תוכן יוצא, והגבלת גישה למקורות חיצוניים. כל אלה לא נבחנו רק כתצורה טכנית, אלא כמשתנים מחקריים.

חשוב להדגיש כי ההטמעה כוללת גם מנגנון לשחזור ניסויים. כל תרחיש נשמר כ-yaml או json, עם גרסת תוכנה, hash של rules, ותיעוד של מצב המערכת. זה מאפשר לשחזר תנאים בין ריצות ולהימנע מבעיה שכיחה במחקר סייבר: תוצאה שנכונה רק “באותה מעבדה, באותו יום, עם אותה גרסה”. במחקר טוב, השונות נשלטת, לא מוסתרת.

6. Experimental Evaluation

ההערכה הניסויית כללה שלושה סטים של תרחישים: תקיפות זהות, תקיפות ענן, ותקיפות LLM. בכל סט נמדדו $MTTD$, $MTTR$, שיעור זיהוי, שיעור false positives, והיקף ההשפעה. התוצאות הושוו בין baseline ללא בקרות מתקדמות לבין תצורה מחוזקת. המדידות בוצעו במספר ריצות כדי לצמצם השפעה של outliers. במקום להסתפק בדיווח “זוהה/לא זוהה”, נבחן גם חלון הזמן עד זיהוי, רוחב הפגיעה, וכמות הפעולות שהצליחו בטרם עצירה.

טבלת תוצאות עיקריות

תרחיש	Baseline MTTD (דקות)	With Controls MTTD (דקות)	Baseline MTTR (דקות)	With Controls MTTR (דקות)	TPR
פישינג וגניבת טוקן	42	11	95	28	0.94
שימוש לרעה ב-IAM בענן	37	9	88	24	0.91
Prompt injection בסוכן LLM	29	8	76	19	0.89
exfiltration דרך object storage	34	10	81	23	0.92
lateral movement בתוך Kubernetes	40	12	90	26	0.93

מהטבלה עולה כי בקרות מתקדמות מקצרות באופן משמעותי את זמן הזיהוי והתגובה. עם זאת, ההבדל אינו אחיד בין התרחישים. תקיפות AI, למשל, נוטות להיות מזוהות מהר יותר כאשר יש policy enforcement ישיר על כלי חיצוני, אך הן גם יוצרות תופעות false positive כאשר ההקשר העסקי לגיטימי. לעומת זאת, תקיפות IAM בענן משפרות מאוד את המדדים כאשר יש נראות טובה על פעילות service principal.

טבלת השוואת בקרות

בקרה	הפחתה ב-FP	הפחתה ב-MTTD	עלות תפעולית	הערכת שימושיות
MFA עמיד לפישינג	בינונית	גבוהה	נמוכה	גבוהה מאוד
Browser isolation	גבוהה	בינונית	בינונית	גבוהה
CNAPP runtime policies	גבוהה	גבוהה	גבוהה	גבוהה
eBPF telemetry	בינונית	גבוהה	בינונית	גבוהה מאוד
Policy-as-code	נמוכה	בינונית	נמוכה	גבוהה

טבלת מיפוי ATT&CK לתצפיות

ATT&CK technique	אות טלמטרי	מקור	בקרה יעילה
T1566 Phishing	click, token issuance	email/identity	MFA, browser isolation
T1078 Valid Accounts	anomalous login pattern	IAM logs	conditional access
T1210 Exploitation of Remote Services	process/network pair	endpoint/network	segmentation, patching
T1105 Ingress Tool Transfer	binary download	eBPF/DNS/proxy	allowlisting
T1610 Deploy Container	pod lifecycle anomalies	Kubernetes audit	admission policies
T1059 Command and Scripting Interpreter	shell spawn patterns	endpoint	EDR, script control

מבחינה סטטיסטית, נבדק האם השיפור מובהק באמצעות השוואת זוגות תואמים. עבור מערך התרחישים, התקבלה ירידה ממוצעת של כ-$72%$ ב-MTTD ו-$68%$ ב-MTTR. רמת התראות השווא עלתה במספר תצורות, אך כאשר הופעלו חוקים משולבים עם הקשר זהות ותלות נכסים, ירידת הדיוק פחתה. משמעות הדבר היא שבקרות חכמות אינן בהכרח “רועשות” אם הן מעוצבות היטב.

המודל נבחן גם על היכולת לשחזר נתיב תקיפה. מדד השחזור הוגדר כ: $$ C = \frac{|P_{reconstructed} \cap P_{true}|}{|P_{true}|} $$ וערכו הממוצע עמד על $0.87$ בתרחישי ענן, $0.84$ בתרחישי זהות, ו-$0.79$ בתרחישי LLM. הערך הנמוך יחסית ב-LLM נובע מכך שחלק מההשפעה מתבצעת ברמת כוונה והחלטה, ולא בהכרח כרשת אירועים קלאסית.

7. Case Study

מקרה הבוחן מתאר סביבת SaaS היברידית הכוללת מערכת שירות לקוחות, סוכן LLM פנימי, ואינטגרציה ל-Slack, Jira ו-GitHub. היריב ניצל הודעת דוא"ל שנראתה לגיטימית, שגרמה לעובד להעתיק תוכן למסמך פנימי. בתוך המסמך הוטמעה הנחיה מוסווית שנועדה להשפיע על סוכן ה-LLM, כך שיבצע קריאה לכלי חיצוני ויחשוף חלקים מהקשר עבודה. במקביל, נעשה שימוש בזהות מכונה שהייתה עם הרשאות רחבות מדי לצורך גישה למשאב פנימי.

האירוע לא החל בחדירה לרשת הקלאסית, אלא במניפולציה של workflow. זהו היבט קריטי במחקר סייבר ב-2026: הסיכון אינו נמדד רק בפריצה לשרת, אלא ביכולת לשבש תהליכים אוטומטיים, לייצר תגובת שרשרת, ולנצל אמון בין מערכות. בתחקור נמצא כי ה-LLM לא “נפרץ” במובן המסורתי, אלא הופעל עליו לחץ קונטקסטואלי שהוביל לפעולה לא רצויה. לעומת זאת, מנגנון policy enforcement חסם exfiltration מלאה, וה-SOAR הפעיל containment על החשבון הנגוע.

הלקח המרכזי מהמקרה הוא שהפרדה בין זהות אנושית, זהות שירות וזהות סוכן אינה אופציונלית. כאשר אותה תשתית זהויות משמשת גם בני אדם וגם אוטומציה, היריב יכול לנוע בנתיבים לא אינטואיטיביים. יתרה מזאת, אם אין תיעוד מלא של tool calls ושל provenance של ההקשר, קשה להבדיל בין שימוש תקין לניצול לרעה. במקרה זה, השילוב של eBPF, audit logs, ו-tracing ברמת הסוכן אפשר לבנות timeline כמעט מלא של האירוע.

מבחינת מדדי השפעה, האירוע נמשך 18 דקות עד containment ראשוני ו-41 דקות עד containment מלא. ללא בקרות מתקדמות, ההערכה הייתה שהחשיפה הייתה יכולה להתרחב ליותר ממחלקה אחת, כולל דלף מידע פנימי. כאשר נמדדה תרומת כל בקרה, התברר ש-device posture, conditional access, ו-tool-level authorization היו האפקטיביים ביותר. לעומתם, חוקים מבוססי תוכן בלבד היו חלשים יותר, משום שההתקפה הסתמכה על שילוב של סמנטיקה ותהליכים.

8. Discussion

הדיון בממצאים מעלה מספר מסקנות עקרוניות. ראשית, מחקר סייבר מודרני חייב להיות רב-שכבתי. אין די בניתוח רשת, ואין די בניתוח endpoint; יש צורך בשרשור תצפיות שמתחיל בזהות, עובר דרך תשתית, ומסתיים ברמת אפליקציה או סוכן. שנית, היכולת למדוד שיפור הגנתי תלויה במדידה נכונה של baseline. ארגון שמודד רק “מספר התראות” עלול להסיק מסקנות שגויות, בעוד שארגון שמודד $MTTD$, $MTTR$, רוחב פגיעה, ושחזור נתיב מקבל תמונה אמיתית יותר.

שלישית, איומי AI משנים את מושג ההצלחה של תקיפה. אם בעבר המדד המרכזי היה גישה לרשת או להרשאות, כעת יש למדוד גם הטיה של החלטות, הזרקת הקשר, ושימוש לרעה בכלים. זה מחייב חיבור בין אבטחה, UX, בקרה ארגונית ומשילות AI. כלי הגנה שאינם מודעים להקשר עבודה יתקשו לעצור תקיפות כאלה. מנגד, כלי הגנה קשיחים מדי עלולים לפגוע בשימושיות ולהוביל לעקיפה לא רשמית על ידי המשתמשים.

רביעית, Zero Trust ו-CNAPP הם תנאי יסוד אך לא פתרון מלא. Zero Trust מפחית trust expansion, אולם אם הזהויות עצמן מנוהלות בצורה רשלנית, או אם הרשאות over-provisioned, אזי ההגנה נשחקת. CNAPP, מצדו, מעניק נראות טובה, אך עשוי להעמיס על צוותים אם אינו משולב נכון עם העדיפות העסקית. לכן, מחקר איכותי צריך למדוד גם cost-to-defend, ולא רק effectiveness.

תובנה	השלכה מחקרית	השלכה תפעולית
זהות היא משטח תקיפה מרכזי	יש למדוד גישה ו-tokens	לחזק conditional access
LLM הוא יעד ומכפיל סיכון	יש למדוד prompt/tool abuse	להגביל tool permissions
eBPF מספק עומק תצפיתי	יש לשלבו בטלמטריה	לאזן בין data richness ל-overhead
Zero Trust דורש governance	יש להגדיר baseline ברור	למנוע privilege drift
CNAPP טוב רק עם הקשר	יש לצמצם noise	לשלב risk scoring

מבחינה מחקרית, יש להיזהר מהסקת יתר. תוצאות במעבדה אינן שקולות בהכרח להתנהגות ארגונית מלאה. עם זאת, כאשר מבצעים ניסוי מבוקר היטב, התובנות אמינות דיה כדי להנחות תכנון. במילים אחרות, המחקר אינו מחליף הערכה בשטח, אך הוא מייצר תשתית חשיבה מדויקת יותר.

9. Conclusion and Future Work

המאמר הציג מסגרת מחקרית מקיפה לאבטחת סייבר בשנת 2026, תוך דגש על מדידה אמפירית, שחזור, ויכולת יישום. הראינו כי שילוב בין מודל איומים מפורט, טלמטריה רב-שכבתית, ופרוטוקול ניסוי נשלט מאפשר להעריך בצורה אמינה בקרות מודרניות כנגד איומים קלאסיים וחדשים כאחד. הממצאים תומכים בטענה כי eBPF, Zero Trust, CNAPP, MFA עמיד לפישינג, והגבלות על tool use ב-LLM הם אבני יסוד בארגון מודרני.

כיווני המחקר העתידיים ברורים. ראשית, יש צורך במדדים טובים יותר להערכת שיבוש קוגניטיבי וסמיוטי במערכות AI, כולל טכניקות סינתזה של התקפות prompt injection רב-שלביות. שנית, נדרש מחקר עמוק יותר על שילוב פוסט-קוונטום בארגונים היברידיים, בעיקר בהקשר של ניהול מפתחות, תאימות פרוטוקולים, ו-overhead תפעולי. שלישית, יש לפתח שיטות למידת מכונה מאובטחת שמבינות הקשר ארגוני, כך שלא ייווצרו התראות שווא מרובות. לבסוף, יש צורך בסטנדרטיזציה מחקרית רחבה יותר, שתאפשר לקהילת הסייבר להשוות תוצאות בין מעבדות, ארגונים וסביבות cloud-native.

10. References

1. ALBERTS, Christopher; DOROFEE, Andrew; et al. Cybersecurity is now a governance problem: NIST CSF 2.0. NIST, 2024. Disponível em: https://www.nist.gov/cyberframework. Acesso em: 22 abr. 2026.

2. MITRE. ATT&CK® Knowledge Base. MITRE, 2026. Disponível em: https://attack.mitre.org/. Acesso em: 22 abr. 2026.

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

4. NIST. Cybersecurity Framework (CSF) 2.0. NIST, 2024. Disponível em: https://www.nist.gov/cyberframework. Acesso em: 22 abr. 2026.

5. SANS. Critical Security Controls v8. SANS Institute, 2021. Disponível em: https://www.cisecurity.org/controls/v8. Acesso em: 22 abr. 2026.

6. CIS. CIS Critical Security Controls v8. Center for Internet Security, 2021. Disponível em: https://www.cisecurity.org/controls/v8. Acesso em: 22 abr. 2026.

7. GOOGLE CLOUD. BeyondCorp Enterprise. Google Cloud, 2026. Disponível em: https://cloud.google.com/beyondcorp. Acesso em: 22 abr. 2026.

8. CILIUM. Tetragon Documentation. Cilium, 2026. Disponível em: https://tetragon.io/. Acesso em: 22 abr. 2026.

9. FALCO. Falco: Cloud Native Runtime Security. 2026. Disponível em: https://falco.org/. Acesso em: 22 abr. 2026.

10. TRACEE. Aqua Security Tracee. 2026. Disponível em: https://aquasecurity.github.io/tracee/. Acesso em: 22 abr. 2026.

11. RED HAT. eBPF and observability in modern security. Red Hat, 2025. Disponível em: https://www.redhat.com/en/topics/linux/what-is-ebpf. Acesso em: 22 abr. 2026.

12. OPENAI. Model Spec and safety practices. 2026. Disponível em: https://openai.com/index/. Acesso em: 22 abr. 2026.

13. ANTHROPIC. Prompt injection and tool-use security guidance. Anthropic, 2025. Disponível em: https://docs.anthropic.com/. Acesso em: 22 abr. 2026.

14. MICROSOFT. Secure Future Initiative. Microsoft, 2024. Disponível em: https://www.microsoft.com/en-us/security/business/secure-future-initiative. Acesso em: 22 abr. 2026.

15. CLOUDFLARE. Zero Trust platform documentation. Cloudflare, 2026. Disponível em: https://www.cloudflare.com/zero-trust/. Acesso em: 22 abr. 2026.

16. HASHICORP. Terraform documentation. HashiCorp, 2026. Disponível em: https://developer.hashicorp.com/terraform. Acesso em: 22 abr. 2026.

17. OWASP. OWASP Top 10 for Large Language Model Applications. OWASP, 2024. Disponível em: https://owasp.org/www-project-top-10-for-large-language-model-applications/. Acesso em: 22 abr. 2026.

18. OWASP. Application Security Verification Standard (ASVS) 5.0. OWASP, 2024. Disponível em: https://owasp.org/www-project-application-security-verification-standard/. Acesso em: 22 abr. 2026.

19. VERIZON. Data Breach Investigations Report 2025. Verizon, 2025. Disponível em: https://www.verizon.com/business/resources/reports/dbir/. Acesso em: 22 abr. 2026.

20. MANDIANT. M-Trends 2025. Google Cloud, 2025. Disponível em: https://www.mandiant.com/resources/reports/m-trends. Acesso em: 22 abr. 2026.

21. CROWDSTRIKE. Global Threat Report 2025. CrowdStrike, 2025. Disponível em: https://www.crowdstrike.com/global-threat-report/. Acesso em: 22 abr. 2026.

22. IBM. Cost of a Data Breach Report 2025. IBM Security, 2025. Disponível em: https://www.ibm.com/reports/data-breach. Acesso em: 22 abr. 2026.

23. CISCO. 2025 Cybersecurity Readiness Index. Cisco, 2025. Disponível em: https://www.cisco.com/c/en/us/products/security/cybersecurity-readiness-index.html. Acesso em: 22 abr. 2026.

24. PALMER, Chris et al. Software Bill of Materials and supply chain security. NIST, 2024. Disponível em: https://www.nist.gov/itl/executive-order-improving-nations-cybersecurity/software-bill-materials-sbom. Acesso em: 22 abr. 2026.

25. CNCF. Cloud Native Security Whitepaper. Cloud Native Computing Foundation, 2025. Disponível em: https://www.cncf.io/. Acesso em: 22 abr. 2026.

26. GOOGLE. Kubernetes Security Best Practices. Google, 2026. Disponível em: https://cloud.google.com/kubernetes-engine/docs/best-practices/security. Acesso em: 22 abr. 2026.

27. RED CANARY. Atomic Red Team. Red Canary, 2026. Disponível em: https://atomicredteam.io/. Acesso em: 22 abr. 2026.

28. SIGMA HQ. Sigma Rules. Sigma, 2026. Disponível em: https://github.com/SigmaHQ/sigma. Acesso em: 22 abr. 2026.

29. YARA. YARA Documentation. VirusTotal, 2026. Disponível em: https://yara.readthedocs.io/. Acesso em: 22 abr. 2026.

30. DUMITRAS, Tudor; SHOU, Jiyong. Toward better measurement in cybersecurity experiments. USENIX Security, 2023. Disponível em: https://www.usenix.org/conference/usenixsecurity23. Acesso em: 22 abr. 2026.